Subject: Re: Bug Bounties. Making $ from bugzilla.
From: Michael Tiemann <>
Date: Mon, 26 Nov 2001 08:15:48 -0500

To answer the question below (without thinking about the *exact* 5, 10, or 15 
people in question.

Most were people who just didn't want to be employed as compiler or debugger 
hackers.  They were working on some other project that was much more 
interesting to them, and when the compiler or debugger was a roadblock instead 
of an enabler, they fixed it.

A smaller number were independent consultants who were, in fact, competing with 
Cygnus.  Not that there weren't many consultants all trying to serve the same 
market, but there were a very small number (1 or 2?) who could write 
high-quality patches that did not cause more trouble than they solved.

There might have been one person from a customer site that could do this. 
Normally there were very few because (1) customers paid Cygnus for this kind of 
expertise, and (2) most customers focused on very narrow problems, and like the 
consulting population, that view tended to create patches that may have solved 
one problem, at the cost of creating 5-10 more serious ones.


Karsten M. Self wrote:

> on Sun, Nov 25, 2001 at 11:10:54AM -0800, Ian Lance Taylor ( wrote:
>>"Jonathan S. Shapiro" <> writes:
>>>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 told 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
>>That is true, except that when I was at Cygnus there weren't even as
>>many as 10 or 15 outside people who submitted high quality patches.
>>There were maybe 5.
>>This was in part due to the nature of the programs at Cygnus:
>>primarily compilers and debuggers.  They are not projects which lend
>>themselves to splitting up comprehension among a large number of
>>people.  For example, you can write an Emacs lisp program which adds a
>>useful feature without understanding many other Emacs lisp programs.
>>But when working on a compiler or debugger, you pretty much do have to
>>understand the full array of data structures and interdependencies.
>>You can split based on processor, and you can split on front end
>>vs. back end, but the chunks you are left with are large.
> I think this situation may be more common to software development than
> is generally realized.
> In any field, there is a top cadre of a relatively small number of
> widely recognized top-flight developers.  It may be five, it may be a
> few score.  But it's small.  I've seen this across a range of free
> software _and_ proprietary software fields, as well as other
> disciplines.
> The issue isn't so much finding a large mass of developers, as getting
> the small amounts of skill in touch with one another.  The advantage
> free software has over proprietary development is this:  while in some
> cases some large firms can hire a bulk of talent in a proprietary field,
> the typical firm may have only one or two such developers, and may be
> lucky to settle for second or third tier expertise.  In the free
> software model, most of the top talent is in close contact, and isn't
> overly encumbered in communicating with other developers by corporate
> confidentiality and liability restrictions.  This is the "free software
> development as virtual think tank" concept.
> Cygnus probably employed a lion's share of top GNU development at the
> time it existed independently (Ian can speak to this better than I), but
> not all of it.  The five outsiders were essentially virtual on-tap
> consultants for the company.
> The interesting question then becomes:  why did these five contribute to
> Cygnus's effort?  I've got my own thoughts, they're largely theoretical,
> might be interesting for Ian (or some of the five if they're reading) to
> tell his side of the story. 
> Peace.