For those of you who haven't followed the discussion, GNOME is a highly popular open source desktop suite. GNOME development is to some extent coordinated by the GNOME Foundation, which has employed bounties to get certain key development tasks done.

http://www.gnome.org/bounties/

This of course is of great interest with regard to our own thoughts about doing something similar.

In order to qualify the success of the GNOME bounty system I contacted the GNOME foundation and asked them for their opinion on whether the project had been a success or failure, and how it affected the culture of the GNOME development community. Their conclusions are almost entirely positive and they want to repeat the bounty process, see attached reply by Jonathan Blandford of Red Hat / GNOME Foundation.

Caveat lector: The system which I think should be used by the Wikimedia Foundation is different. With GNOME's bounty system, you have potentially the situation where two developers hack away on the same stuff, but only one of them (who submits the code earlier) gets paid.

I think there should be an open call for tenders process, where a technical-minded steering committee appointed or elected by the foundation outlines certain key tasks, and the developers can name the conditions under which they are willing to complete them (e.g. "I'll do this for free by February next year", "I'll do this for a rate of $20/hour", "I'll do this for $200 upon delivery of the code"). These competing tenders can then be held up against one another, and the committee decides which one, if any, to take up. Once they do so, there is a contract between the Foundation and the developer, and there's no risk of competing work being done at the same time.

In this system, those who allege that volunteer effort is good enough will have the opportunity to prove this by negotiating voluntary agreements over contracts with the steering committee. So payment is not given an advantage over non-payment; both solutions are equally acceptable. Similarly, this scheme gives both the foundation and the developers wiggle room to settle on mutually acceptable terms, rather than giving one or the other an advantage from the outset.

A wiki is perfect both for the negotiations and the collaborative writing of the task specifications.

Because "bounty" carries strong connotations of competition rather than cooperation, I would like us to stop using that word, at least when referring to the proposal described above. Instead, it should be described as a tender process.

Regards,

Erik

- - - - - - - -

From: Jonathan Blandford <jrb at redhat dot com> To: Erik Moeller <moeller at scireview dot de> Kopie: <board at gnome dot org<

Hi Erik,

Sorry for the delay in answering your questions. I'm hoping we can get some of the administrators of the bounty system to comment, as they have a better idea a lot of the details of the last round. I'll try to fill in a few gaps until they reply.

As you noticed, the bounties were modest in scope, and were pretty successful. It helped get several new hackers involved in GNOME, and brought attention to integrating several modules. It doesn't seem to have modified GNOME's culture in any noticeable way, and contributed to some neat code being written. Even the bounties that weren't fully filled had positive effects.

On the flip side, a few maintainers felt extra pressure to look at and accept the bounty patches, which was to be expected. Also, the bounty program was intentionally very uncontroversial and small in scope[1]. We don't really know how well an expansion of the system to a larger scope would be like. We do plan to repeat the process soon on a similar scale.

Thanks, -Jonathan

[1] compared to the size of the rest of the project.