[Foundation-l] Bounties, tenders, and the GNOME experience

Fri Jul 30 22:22:00 UTC 2004

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.