One example of a highly successful free software application is the GIMP. It is, however, also one of the more widely criticised of such applications, with many users citing its interface as a source of great frustration. A lot of questions are asked along the lines of “why doesn’t the GIMP do X like Y does” or “what were they thinking when they designed Z?”, but I think they’re missing a much more important question:
Where is libgimp?
Ok, so I know there is a library called libgimp, but that’s not what I’m talking about — in the words of GIMP hacker Sven Neumann, there is “no image manipulation functionality in libgimp”. What I’m suggesting is that there should be, or rather that the majority of the GIMP’s functionality should be split out into a library, whatever the name.
Why? Well, one of the best things about free software (in my opinion) is the frequent sharing and reuse of code, which often prevents pointless duplication of effort — a hallmark of the proprietary world. However, this brilliant opportunity is all too often wasted when software is not designed with re-use in mind.
Sure, the GIMP is extensible insofar as its interface is scriptable, but that’s not the kind of modularity I’m after; you’re still bound to use the full GIMP even if you only need a tiny subset of it. Take, for instance, the task of implementing a simple paint program. Gpaint seems to me like a brilliant example of how not to do this. But would vastly superior alternatives exist if the (potential) developers could tap into a powerful libgimp for most of the functionality they need? Would said libgimp (and in turn the GIMP itself) benefit from the increased interest? Would other types of programs such as video editors benefit also? I can’t know for sure, but I’d be willing to bet on all three.
From what I can see, the GIMP is far from alone in this; it’s just one example that’s been on my mind recently, along with a couple of others:
- GNU Debugger (GDB) — I can’t seem to find out how this is coming along, but at present, the way in which front-ends interact with GDB is worrying at best, with text-based hacks all over the place. See here for some insight into why this is such a problem.
- TeX — Somewhat like the GIMP in this aspect, TeX is usually extended through its macro language (the most popular extension being LaTeX) and also like the GIMP, I think this is woefully inadequate. TeX contains a host of clever technology that might be useful if other applications could tap into it easily.
The most curious thing about the current situation to me is that GIMP developers have already seen first-hand the benefits of splitting parts of a product off into independent modules. The GTK+ widget toolkit has its roots in the GIMP project, and look how far it’s come since!
Maybe it’s time to learn from past success and try to do the same with the GIMP’s image manipulation portions?
