The flag creation effort we are doing at Sodipodi.sf.net is continuing at a brisk pace. Seeing the overwhelmingly positive response it has gotten and the large number of contributors has been an eye-opening experience. Given the opportunity there are a lot of people out there who wants to contribute.

This has started me thinking about the never ending problem that major projects face in recruiting new contributors, and how some projects seem to have a much easier time than others in getting new contributors.

One successfactor of the flag project in my mind is probably that fact that helping with it is open to people with a lot of different skill levels when it comes to vector drawing. If you are relativly new you could make flags like the French, Japense or German. For the people with a little experience there are flags such as the US, Chinese or Indian. And for the higly experienced we had flags like the East German or Croatian flags. Each flag is also a standalone entity so people can work on it without thinking to much about people working on other flags.

Another successfactor was that the target is clearly and easily defined. People could easily identify a flag that needed doing that was within their skill level and they had a good resource like flagspot to get information on apsect ratio’s and colors.

Based on this I started to think about the projects that I am familiar with. Mono seems to be an example of a project that has had relative ease at attracting new developers. While a part of this of course is attributed to the energetic style of Miguel, which clearly helps to both bring in new people and motivate excisting ones, so do Mono share many traits with my flag project. You have a clearly defined list of classes that needs implementing with some classes perfect for someone new and some classes a good challenge for someone experienced. Each class is to some extenxt also a standalone entity which you can work on as a separate project.

For GNOME there are a lot of people doing stuff around it, but inflow of new developers to work on the core is relativly slow. But then again GNOME is very much the opposite of the Flag project or Mono. First of all it doesn’t have something predefined to implement, which means there are no good list of tasks needing doing. Secondly as things gets more and more integrated many of the tasks have ramifications for other parts of the project, which means doing something tends to mean you might need to relate to a lot of different stakeholders which can be both frustrating and hard, especially for someone new to the project.

If you go into #gnome on IRC and say ‘hi, I want to help with GNOME’ the standard reply is often something along the lines of ‘cool, go look in bugzilla and find a bug you can work on, that is a good way to get started’. This is really a sucky and stupid reply I realized today. The problem is that while bugzilla theoretically could be the GNOME version of the list world flags or the C# ECMA specification, it is next to useless for that task today.
For instance if I wanted to help out with Nautilus and was sent into bugzilla looking for a task I would a) have quite the job of actually finding a bug with a clear enough scope to work on. ‘Started Nautilus and it crashed’ is not a good work description for a hacking newbie. b) If I did found a bug I could work on I would have no idea if that fix is still wanted. Could be that since that bug was filed the design goals of Nautilus has changed to make it obsolete. c) bugzilla does not tell me anything of how to implement it, so even if I did manage to make a patch it could be refused due to not implementing the solution in an acceptable manner.

So my conclusion to todays ‘thinking in public session’ is that if we really want to be able to say ‘go look in bugzilla for a task’ then we need to make sure no module has more open bugs than the maintainer(s) are able to handle/keep control over. For some modules that would mean getting though on some bugs that are not really bugs but design discussions, loose plans for the future, trivial behaviour changes etc. It would also mean that when a new bug arrives the maintainers should probably add a comment on how/where to fix it. That way if they don’t get to it and this new developer comes along he/she can actually be productive.

That said, GNOME is a much more complex project than the flag project, so no matter how much we alter structures and systems to make things easier it will always have to pay some efficency price for being a large and compex project.