Like in any Free Software project, developers are leaving from time to time to pursue other projects. And from time to time, new developers are joining the team and starting to contribute. However, it looks like the number of new developers joining the GIMP development has been decreasing in the recent years.

Probably one of the main reasons is that Gimp isn't the only major open-source end-user app anymore.

But yes, I would not be surprised if Gimp was percieved as stagnating.

There should be a section on www.gimp.org or developer.gimp.org titled "How to contribute?" or "How to get involved?". It should be easy for potential new developers to see where to start and how they can help.

Absolutely. We need to make it as easy as possible.

It would be very nice to have Windows binaries for the development version.

I would say that Mac users and Windows users are much more likely to expect and use binaries.

Is Bugzilla too hard to use for new users? ------------------------------------------

It was suggested to make it easier for users to submit bug reports, for example by having an e-mail address to which bug reports can be sent without having to register to Bugzilla (we already have such an address, although it is not widely known).

Personally, I'd like to see Bugzilla be the only place for gimp bugs.

This proposal was rejected because most of the bug reports (especially from new users) are incomplete and require additional information. If the user does not have a Bugzilla account, it is not possible to rely on the automatic notification system to send messages to the user when a comment is added to their bug report or when the status of their bug report changes.

Agreed.

Most developers consider Bugzilla to be a very valuable tool that works well. Instead of trying to hide Bugzilla from the users, we should try to make it as easy as possible for the new users to join. This is already done to some extent by the bug submission wizard available from http://bugs.gimp.org/. There is a small problem with the GNOME2 keyword that prevents the open GIMP bugs from being displayed to the user and we should try to get this fixed.

A good wizard would go a long way towards making first-time Bugzilla submission not so overwhelming.

List of open tasks
------------------

There are many open bug reports or proposals for enhancements that would be relatively easy to fix or implement. We should make it easier for potential contributors to see the list of easy tasks that are open. The "easy tasks" should include anything that can be done in one or two hours by an average developer or maybe a bit more if the contributor is not familiar with the code.

The best way to keep the list of open tasks up-to-date is probably to base it on Bugzilla. We could for example use a Bugzilla keyword for all bugs that are easy to fix (there is already a keyword "easy-fix" reserved for that, although we could invent our own). It would then be easy to create a Bugzilla query showing the list of easy tasks.

I think that this is the best solution. I have already marked some easy bugs with the easy-fix keyword.

Another solution would be to have a page on www.gimp.org or developer.g.o containing a list of all these bugs, with direct links to the corresponding bug reports. The second solution may require a bit more work because it would have to be maintained by someone, but it might be a bit easier to use.

I doubt there would be much advantage to doing this.

The following items should be available in the web site: - "How to contribute?" / "Getting involved" - List of tasks

I propose that other outstanding tasks, like things that we would like to see in the next version, be available as Bugzilla query links. When necessary, we can add keywords or tracking bugs.

- List of sources of contains some useful items such as "Bugs", "FAQ", etc. information (mailing lists, newsgroup, ...) - FAQ

As with the other documents summarizing what is happening here at GimpCon, comments are welcome...

> Another reason may be that it is difficult to build the development > version because it depends on released versions of some libraries that > are not included yet in the major GNU/Linux distributions

Whether they're included in the latest major distributions is quite irrelevant unless a developer (or indeed, user) is USING the latest major distributions. I imagine (okay, know) that unix-heads can be pretty shy of re-installing their operating system world just to get a small handful of the latest versions of OMG L33T DEPS!!! apps working properly.

As you say, as time approaches infinity the issue tends to zero.

Meanwhile...

--Adam

Nathan Carl Summers wrote:

Like in any Free Software project, developers are leaving from time to time to pursue other projects. And from time to time, new developers are joining the team and starting to contribute. However, it looks like the number of new developers joining the GIMP development has been decreasing in the recent years.

:-(

Probably one of the main reasons is that Gimp isn't the only major open-source end-user app anymore.

I don't think that's the reason. GIMP is still the only major 2D paint and image processing program - and developers who want to work on graphics are unlikely to defect to OpenOffice or GCC or something.

But yes, I would not be surprised if Gimp was percieved as stagnating.

No - I think some people may percieve it as "finished" - although I personally know that's not true, many people are quite happy with GIMP as it is today.

As a committed OpenSource developer who might have been interested in working on GIMP, I have to say that the level of acrimony and hostility that I see between developers is VERY off-putting. (I've been lurking here for quite some time).

Other projects I work on are generally places where friends meet to develop software - and which have the occasional bust-up over some technical issue. Here, it seems that there is a continual hostile undercurrent and everything is challenged and fought over tooth and nail.

I don't know whether you all believe that - or how you do anything about it if you do believe it. But for me, it's the number one reason not to get into mainstream GIMP development.

I'm only one data point though - others may have quite different reasons to stay away.

One thing that would revive GIMP's fortunes immensely would be to merge GIMP and FilmGIMP back into one package. I know that's a difficult task - and a highly contentious issue too - but if there are only 'N' GIMP developers in the world, you'd really hope that N/2 of them were not off working on FilmGIMP.

---- Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: sjbaker@link.com http://www.link.com Home: sjbaker1@airmail.net http://www.sjbaker.org

On Mon, 11 Aug 2003, Stephen J Baker wrote:

No - I think some people may percieve it as "finished" - although I

Even if the GIMP had every feature of the current versions of Adobe PhotoShop, Corel Painter, and Jasc Paint Shop combined it still wouldn't be finished. There is always something more, more features more file formats, more platforms.

personally know that's not true, many people are quite happy with GIMP as it is today.

The GIMP is quite simply the best Free Software, Open Source Raster Graphics tool out there but I want MORE! I hope the GIMP will (eventually) become the best Raster Graphics tool bar none.

As a committed OpenSource developer who might have been interested in working on GIMP, I have to say that the level of acrimony and hostility that I see between developers is VERY off-putting. (I've been lurking here for quite some time).

I don't know whether you all believe that - or how you do anything about it if you do believe it. But for me, it's the number one reason not to get into mainstream GIMP development.

I feel that way too, unfortunately it is so hard not to react in the same way and get off the downward spiral. I only very grudginly subscribed to the developer list at all.

I feel that the active lead developer(s) need to admit this is not a democracy and be the bad guy, be the benevolent dictator, be the leader and take decisions that move the GIMP forward.

I'm only one data point though - others may have quite different reasons to stay away.

I am sure there are other factors too but I tend to believe that the hostility is a deciding factor that turns off new developers.

One thing that would revive GIMP's fortunes immensely would be to merge GIMP and FilmGIMP back into one package. I know that's a

Not as impractical as trying to merge Gnome and KDE but they have freedesktop.org and are increasingly working together on shared standards so GIMP and CinePaint should be able to work together too.

If you look at the history of FilmGIMP it was on an older Hollywood branch of the GIMP and remerging the branches would have been very difficult even then and the GIMP developers seem to favour waiting for GEGL to provide the 32-bit image support.

The port of the GIMP to Gnome2 and various restructuring of FilmGIMP now CinePaint (they are gradually creeping towards using more C++ for example) have made the two increasingly incompatible.

difficult task - and a highly contentious issue too - but if there

I dont even understand why it is contentious anymore.

The split has happened and people need to accept it and move on. Blame, accusations or resentment help no one. One the emotional issues are out of the way it just becomes an issue of how willing people are to what needs to be done.

are only 'N' GIMP developers in the world, you'd really hope that N/2 of them were not off working on FilmGIMP.

Keeping a shared standardised Plugin API might be a realistic achievable goal and help minimize duplication of effort but again the question is if there are people willing and able to do the work.

There are file format incompatibilities in XCF which Sven recently 'brought up' on the CinePaint list, without 32-bit colour depth there is only a limited amount that GIMP can do but if there are people willing and able to do the work...

The next generation file format will have to consider interoperability with third party applications and make some compromises for the greater good (use existing standards wherever possible would clearly be a good star) and hopefully CinePaint will be considered and kept in mind as part of this process.

Sincerly

Alan Horkan http://advogato.org/person/AlanHorkan/

Alan Horkan wrote:

I feel that way too, unfortunately it is so hard not to react in the same way and get off the downward spiral. I only very grudginly subscribed to the developer list at all.

I feel that the active lead developer(s) need to admit this is not a democracy and be the bad guy, be the benevolent dictator, be the leader and take decisions that move the GIMP forward.

I like the 'benevolent dictator' model for OpenSource management - it works well in so many projects - ranging from tiny three man projects right up to the Linux kernel itself.

It's really hard to come to a firm decision in a timely manner in an environment where everyone's voice counts equally...doubly so if things get ugly.

The art is to find a dictator who actually *is* benevolent.

---- Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: sjbaker@link.com http://www.link.com Home: sjbaker1@airmail.net http://www.sjbaker.org

Dave Neary writes:

Another reason may be that it is difficult to build the development version because it depends on released versions of some libraries that are not included yet in the major GNU/Linux distributions (e.g., GTK+ version 2.2.2).

both debian unstable, mandrake and redhat provides gtk+2.x for quite a long time.

there's no problem in providing both gtk+-1.2.x and gtk+-2.x in a distro.

Also, the number of dependencies for GIMP 1.3.x is much higher than the number of dependencies for GIMP 1.2.x, so it is more difficult to have a working build environment for the 1.3.x version.

this is a valid point for:
- users of very old distributions
- non developer users (that is most end users) - windows users (for which getting both a working development suit and enough knowledge to build something with required dependancies is probably not easy)

Do we need binary distributions?
--------------------------------

There was a discussion about binary distributions. This may help people to try some versions of the GIMP (especially the development versions) without having to compile everything. However, maintaining binaries is a lot of work, even if we only maintain binaries supplied by others. In addition, this would bring some additional responsabilities that we do not want to have. For these reasons, it was decided that www.gimp.org would not host any binaries but would link to the pages of those who are providing binaries for various platforms.

yes development and packaging (well binary tarball is some kind of packaging) are two different tasks.

you can either: - leave it to distributions (after all gimp-1.3 is already provided in mandrake contribs and in debian unstable) - leave it to a nightly build system (see mozilla) - leave it to another specialized team (aka you need one people that sometimes build windows binaries and someone who sometimes build static gimp for linux)

Is Bugzilla too hard to use for new users? ------------------------------------------

It was suggested to make it easier for users to submit bug reports, for example by having an e-mail address to which bug reports can be sent without having to register to Bugzilla (we already have such an address, although it is not widely known). This proposal was rejected because most of the bug reports (especially from new users) are incomplete and require additional information. If the user does not have a Bugzilla account, it is not possible to rely on the automatic notification system to send messages to the user when a comment is added to their bug report or when the status of their bug report changes.

even if bug reporting by mail may not look suitable, being able to anwser bugzilla by mail is a must.
it saves quite a lot of time and is often see as more easy to use by developers (at least here at mdk).

there're several extensions that do this (see freshmeat.net or soft/bugs module in mandrake cvs).