Subject: Re: Bug Bounties. Making $ from bugzilla.
From: "Karsten M. Self" <>
Date: Sun, 25 Nov 2001 12:38:16 -0800
Sun, 25 Nov 2001 12:38:16 -0800
on Sun, Nov 25, 2001 at 12:31:11PM -0500, Jonathan S. Shapiro ( wrote:

> > What's Bob's incentive to provide the patch speedily?  Why wouldn't
> > all the Bob's of the system wait until the bounty stops going up?
> Bob is in competition with Bob', and it's an all or nothing game. What
> is needed here is a mechanism for Bob to say "I'm fixing it, and I
> need X hours", gaining a time-limited exclusive on the contract.

It is an iterated game.  If the bugs are small, the bounties sufficient,
and the supply of qualified Bobs reasonably finite,  Bob and Bob' see
the outcome as justified in the long run.  Bobs who can't produce
bugfixes quickly enough to secure payment exit the system.

> The problem with the mechanism as described so far is that there is no
> process for determining whether the fix is a "good" fix. Somebody
> knowledgeable about the software actually needs to vet the change.
> However, this can be solved by endorsement models as well. The project
> can identify several people who it believes are reasonable vetters of
> changes.  Individuals can also say "I have this bug, and I'll believe
> it's fixed when one of {Fred, Mary, Jane, * recommended by project}
> say so." The vetting party needs to get a percentage of the take.
> Beyond that, however, I see a flaw.
> If I recall correctly, it was the experience of Cygnus that most
> patches supplied were undesirable, in that they tended to point the
> way toward the right solution but were not themselves the right
> solution. I have a vague recollection that Mike or John Gilmore tols
> me at one point that there were only 10 or 15 outside people whose
> patches they found could routinely just be applied. This leads me to
> wonder what quality level the bug bounty could generate.

There's this.  There's similar data, published, from the Apache project,
out of Lucent.  The core Apache team is some score or less at any one
time, the actual code-contributing population numbers around 200-300,
with the remaining several thousand active community participants
largely supplying bug reports.

The problem as I see runs deeper:  bugfixes aren't generally a deep
problem in free software.  The apparatus for insuring payment for same
institutes more overhead than is necessary, and actually interferes with
some of the functions that seem to make the free software process as
effective as it is.

What's useful to free software is not specific fixes to a bug, but
identification of the probles.  Once identified, the fix tends to be
relatively clear, and doesn't involve a great deal of work.  More often,
it's useful to have several fixes contributed, compared, and contrasted,
and the best selected or synthesized from the submissions.

In general, there are other portions of free software development which
aren't as readily facilitated by individuals which might benefit more
from the structured approach suggested here:

  - Project hosting -- e.g.:  Sourceforge.

  - Code auditing -- e.g.:  the OpenBSD audit and reviews sponsored by Red

  - Overall software architecture and design -- e.g.:  the Mozilla
    project (Netscape), Nautalis (Nautalis), Postgres (Great Bridge and
    Red Hat), GNOME (Red Hat, Ximian), OpenOffice (Sun), Apache (the
    Apache project).  While much design in free software is
    evolutionary, there's a significant amount that isn't.  This process
    generally requires a greater level of infrastructure and support
    than mere bugfixes.

> I therefore think further tinkering in the payment model is likely to
> be needed. One possibility is for the vetting party to be able to say
> "Bob has supplied a fix. It's a workaround, but it's not the right
> workaround because of X, Y, Z. We're going to award Bob 20%, but we're
> not going to endorse the change as an official change."

I'm more generally convinced that "monetizing" the process in the way
proposed creates transactional barriers which interfere with other
positive externalities of free software development.  The problem with
payment mechanisms is to design them in such a way that they don't
interfere with getting business done, as anyone who'se worked under an
onerous time-accounting system can testify.

Facilitating contractor relationships between free software developers
and companies which need and can pay for features or bugfixes is a good
goal.  Doing this on the piecework basis suggested here strikes me as
the wrong means to the end.


Karsten M. Self <>
 What part of "Gestalt" don't you understand?             Home of the brave                   Land of the free
   Free Dmitry! Boycott Adobe! Repeal the DMCA!
Geek for Hire           

["application/pgp-signature" not shown]