A recent NewsForge article,
Time to stick a fork in the GIMP?, begins with this paragraph:
Some people like the GIMP, the open source community's answer to Adobe Photoshop, but a recent survey by Novell showed that Photoshop is one of the top three applications Linux users want ported to their platform, which indicates the GIMP may not be meeting the needs of Linux users. Designers' efforts to improve the GIMP have failed in the past. Maybe now is the time for a more radical approach.
The GIMP is (obviously) a photo editing program, and one of the big Free/Open Source (FOSS) programs that everyone knows about (well, everyone who runs FOSS at least), and have acheieved a fair amount of popularity. Some others are Firefox and Linux itself.
Most of the benefits of the GIMP are the same as the benefits of any other FOSS application, namely it's free to use and modify and it won't just go away one day because some company goes out of business or decides it's not profitable enough any more. Also, it is more than capable of handling most image editing tasks normally handled by Photoshop. However, as this article discusses, a lot of people do not like the user interface. Personally, I like it fine and use it for touching up my photos for
18%, but that doesn't change the fact that a lot of people don't.
The author of this article knows how to fix this, or at least claims to. He begins to construct his argument by pointing out that some people have been discussing the new closed-source image editing program, Pixel, as an alternative to the GIMP.
Interestingly, the bulk of discussions have focused on the GIMP's GUI. The interface seems to irritate users more than the software's missing features.
He then goes on to discuss two unsuccessful attempts to revamp the interface. The first is GIMPshop, which is a GIMP plugin that modifies the interface to be more like Photoshop.
...Another more interesting undertaking was an interface redesign project on the OpenUsability Web site. The idea was to invite input from the community that could be used in the GIMP's upcoming releases.
The OpenUsability initiative had a promising start. Designers from all over the world injected a great deal of input into the discussions. Unfortunately, this collaborative effort ended because designers and developers couldn't agree on the basics. Designers wanted a radical overhaul of the GIMP, but developers were interested only in minor interface changes. As a result, the most creative proposals were dismissed without serious consideration...
The disappointing end of the GIMP redesign initiative confirmed that the GIMP project is cruising along on its own closed trajectory, hardly touched by users' needs.
Ok, here's where the article starts to come apart. I was basically with him until that last line. The thing about FOSS is that if you don't like something, the GIMP's interface for example, you can change it. If the main developers don't want to make your changes, you can fork the code, make your changes, and release it as a new program. If it's better, people will use it instead of the GIMP. If the GIMP wants to survive, it'll incorporate your changes or die. Either way, you've got a program that has the interface you want. This doesn't even mention the fact that you could just make an advanced version of GIMPshop that more fully modifies the interface.
Whatever. That's not the main problem with this article. The main problem is in the next part of the article, where he defines the users' needs:
The open source community needs separate programs targeting Web development and desktop publishing. Since each field demands different tools and functionalities, the programs should support these standards to the full.
Adobe, several years ago, created ImageReady for Web designers and Photoshop for desktop publishers. One way to revitalize the GIMP would be to fork the project along these lines. In other words, the program should be split into two parts, one supporting Web development and the other offset printing.
If the problem with the GIMP is the user interface, why is the solution a change in functionality? Ok, let's just accept that leap of logic, move on past the implied statement that FOSS should always mimic proprietary software, and look at the problems with the suggested solution.
First, there is no reason why one program can't handle both functions perfectly; in fact, the author doesn't even bother to present a reason; instead, he just states it as fact and then goes on to present the benefits. Most of the functionality of the two would overlap, so there would be a lot of duplicate work being done unnecessarily. Also, having two programs, following their own development paths, would end up with inconsistent user interfaces. So, someone who did both print and web work would have to learn two interfaces that have subtle (read: annoying) differences.
The Web-oriented editor should support Web-based file formats only and should be able to create rollover effects, menus, animated buttons, and photo album, and support batch processing. Its development could be coordinated with Nvu, so that the code it generates is supported by the Web editor. Ideally, these applications should work closely together like Fireworks and Dreamweaver.
These features could easily be added to the GIMP, either in the main code, or better yet, as a plugin. In fact, plugins
already exist that handle rollover effects and animated buttons, not to mention the fact that the GIMP can do batch processing from the command-line (something that a nice plugin could give a pretty graphical front-end to, I'm sure). I'm not sure exactly why you'd want to
remove file-formats. Note again the implied statement that FOSS should mimic the functionality of proprietary software; why bother to innovate?
The second program should be optimized for complex image editing supporting CMYK, LAB, and Duotone color modes. Incorporating these features would allow the developers to integrate the program with Scribus, an open source page layout and desktop publishing program, which has been crying out for a bitmap editor.
Again, many of these functions and features either are being, or could be, added to the GIMP. Wouldn't the developer effort of splitting the program into two be better served just adding these missing features?
So, as far as I can tell, there is no valid reason why both sets of designers couldn't be well served by one application. Furthermore, I think that Adobe splitting off the web functionality into another program is more for marketing reasons than usability/functionality reasons.
Here's another problem. Since the GIMP developers are resistant to changing the interface, I think it's safe to assume that they would also be pretty resistant to splitting the program into two completely separate applications with different goals. So, the author's 'solution' implies that someone other than the current GIMP developers should step in, fork the code, and make this happen. If that's the case, then why wouldn't that someone just step in, fork the code, and 'fix' the interface? Isn't that a better solution, since that's what the people who are complaining don't like?
The author concludes thusly:
The conditions are right for an undertaking like this; first, because startups such as Pixel are targeting the Linux platform, and second, because designers need a user-friendly open source image editor.
In its current state the GIMP is the victim of a design philosophy that doesn't meet user expectations. If its developers can't resolve this situation, the software will be marginalized by startups such as Pixel.
I conclude thusly:
Don't read the linked article for two reasons: first, I've quoted most of it, so if you've read this whole entry, you've already read it; and second, this article is the victim of a bunch of unconnected points and faulty leaps of logic that don't lead to the conclusions reached. If its author can't resolve this situation, the article will be marginalized by blog entries such as this one.
