I've never really liked the term "maintainer" sort of implies to me that the role is going to be monotonous patching, fire fighting and bug fixing rather than that and influencing the product's direction with the design and implementation of new features. I think "lead developer" would be a better phrase.

Lead developer implies a lot more work. I'm sure they'd be happy to get a lead developer, but at minimum they need someone to just let the patches flow, dig through bug reports, and put out releases at the right time.

Slightly off topic: for quick & common image manipulation stuff, there's also mini_magick: http://github.com/probablycorey/mini_magick

IMHO, there's a huge difference between calling a C library directly and shelling out to an external process.

mini_magick uses Subexec which in turn causes a fork and exec and might, depending on how ruby's backtick operator work, also start a shell which in turn does another exec for the specific ImageMagick binary.

The process startup time alone is a significant overhead and so is the additional memory usage.

In the old days, when I was maintaining a mail server for a free web mail service, I remember the lengths I went through to prevent my MTA from forking for mail delivery due to the huge cost of launching another process.

I use RMagick for a rails based image repository, and I have to shell out to run the RMagick code because of memory problems. When I used to keep it all in the rails process, those guys would get up to the 2-3G range over the course of a couple of days.

I'll have to check out minimagick, it might be cleaner than what I am doing now.

Have you tried manually calling GC.start with rmagick

In this particular application, I have to inspect PDF and TIFF files that might have hundreds of pages or frames. These files can be over 100MB easily. Running those through RMagick makes the process blow up to enormous sizes. Even if the memory gets garbage collected, Solaris doesn't really release it.

Its just safer to keep it in a different process.

Well, the mini_magick documentation mentions that the spawn of a subprocess is the main point of that library:

"Using MiniMagick the ruby processes memory remains small (it spawns ImageMagick’s command line program mogrify which takes up some memory as well, but is much smaller compared to RMagick)"

Forking isn't always bad. See http://tomayko.com/writings/unicorn-is-unix

mini_magic has the advantage of not leaking memory all over the place.

Yep, could someone take this over? And, also fix all the memory leaks while you're at it, thanks! (http://www.google.com/search?sourceid=chrome&ie=UTF-8...)

What kind of an attitude is this? If you care so much about the memory leaks, fix them yourself. It's open source after all.

Requesting bugs fixed this way is bad in a normal situation, but doing so as an answer to a call for help to keep the project moving forward is disgraceful.

Might I suggest that you also read the explanations in the first result?

  http://stackoverflow.com/questions/958681/how-to-deal-with-memory-leaks-in-rmagick-in-ruby/959473#959473

Successful use of rmagick also requires that you explicitly call the ".destroy!" method on all images(including intermediary ones) to ensure that memory is freed up. Looking at Ruby's Object space shows that this method successfully marks the images for deletion. This eliminated the memory leaks for me. You may have to also call GC.start after ".destroy!" if you want the objects cleaned up as quickly as possible.

See: http://rubyforge.org/forum/forum.php?thread_id=1374&foru...