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.
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.