> I think the problem we have here is that there's quite a big difference 
> between the developers and the users of the program. The people who make open
> source racing games probably do that because they like to play racing games 
> as well. The average Gimp developer seems to do it because they like to write
> image manipulation software, things like writing filters and scripts and 
> stuff, not necessarily because they like making digital art. 

Allow me to correct some impressions... 

Very little has happened recently in the way of scripts or filters; saying that
gimp developers concentrate on that is ridiculous.

I think you seriously overestimate the amount of developers working on it.  The
few that do make regular contributions are more than swamped with their
ambitious primary goal of making it cleaner and easier to hack.  (Look through
the ChangeLog for the past 12 months - only Mitch and Sven are at all regular

Also, the fact is that the codebase has really outgrown the developer power to
support it; it needs cleaning and restructuring so a developer can go in, see a
sane structure in place, and change what needs to be changed easily.  This is
extremely dull work (for me anyway) and we're lucky we have a couple guys that
love the program enough to put the huge amount of time into fixing it.

When they do get around to making user-centered choices, they tend to do a good
job IMHO.  But they are few, and thier task is large - its not all thats on
their plate. 

> And that the maintainers won't accept contributions that don't help 
> the users in some way. 

Most of the work being done right now doesn't help the user one little bit, but
should help developers make it easier to help users in the future.  Putting a
restriction like this in place would result in complete stagnation of the tree
simply because nobody has the time to learn all the stuff needed to go in and
hack right now.  It makes difficult tasks impossible.

Some things won't happen for a while.  For example, take CMYK support (or other
colorspace support for that matter).  To do this successfully requires an
internal representation thats different throughout.  A lot of work has been
done towards this goal (changing spots to use GimpColor, or separating out
colorspace operations from the UI for instance), but a lot remains as well. 
The idea is to hopefully get it into 2.0.  At our current release cycle, thats
probably 5 years out.

Some things are happening currently, but take awhile for the underlying
technology to stabilize.  The CVS HEAD branch has some primitive direct support
of fonts through PangoFT2, which produces great looking fonts not dependant on
an X server.  However, its not a drop-in replacement, and the PangoFT2
interface is still changing in response to developer requests.  When this other
project stabilizes, I expect you'll see much more on the font support front in

I think the current regular developers (both of them) as well as the occasional
contributors are all doing great things for the program.  They find time to
respond to most feature requests submitted through gnome bugzilla.  If you have
specific, well thought out ways of progressing gimp along without radical
change to everything, please do submit your feature request.  Things do get
implemented this way, and coders do pay attention.

Well, thats it for my armchair developer counter-rant :)

Seth Burgess

Do You Yahoo!?
Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
Gimp-developer mailing list

Reply via email to