> 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 contributors). 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 gimp. 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 sjburges@xxxxxxxx __________________________________________________ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1
