Re: Bounty for Bugs in Open Source Projects?

On Mon, Apr 18, 2005 at 07:48:15PM +0100, Jamie Lokier wrote:
> Adam Turoff wrote:
> > This is the root of another faulty assumption with bug bounties.
> > 
> > Since one user won't spend $10,000 to fix a single bug, the middleman
> > needs to find 500 users paying $20 each; bugs get fixed, developers
> > get paid, everyone is happy.
> > 
> > But if 500 users want to fix a single bug, chances are pretty good that 
> > someone will just scratch that itch (or at least the itchiest part of
> > that itch).  
> 
> Not really, if it's a non-trivial bug or feature request that a
> developer would charge $10,000 for, there's a high chance that none of
> the users will have the time, even if they have the skill.
> 
> Bugs and features vary enormously from the sort that takes 5 minute to
> the sort that takes several people months of full time work.

It's a big enough market that either scenario is true some of the time,
and neither scenario is true all of the time.

My point remains that there is a certain class of bug/feature request
that would cost ~$10,000 in billable time to fix.  Some of these are
"easy" or "moderately difficult" to address, with the added overhead
going to make a complete product -- source code, test cases, doc
patches, smoke testing, backporting, etc.  

Some of these same bugs can be addressed in a more open manner, with the
fix coming from a large group of volunteers, each doing a trivial amount
of work (or nearly so by comparison).  Maybe all the work a user wants
to pay for isn't done, but the most important ~20% (addressing ~80% of
the pain) can get done with volunteer labor.

That does not negate the other case.  There are certainly some issues
where the set of people with the available time, skill and inclination
to fix a problem (even at $10,000) is effectively nil.  In those
situations, there are a couple of options:
	* offer more money, until a developer with time + adequate skill 
	  is inclined to solve the problem
	* simplify the problem to enlarge the pool of developers with the
	  time/expertise necessary to solve it
	* cope in some other manner (i.e. ignore the problem)

Options #2 and #3 are by far the dominant behaviors in open source when
dealing with bugs/missing features, which helps explain why bug bounties 
never really caught on.

> Example: VMware Workstation.  Lots of people wanted similar speed in
> Bochs (a free program which is similar but much slower), and several
> developers wanted to do the work and had the skill, but never had the
> time to do it for nothing.  Meanwhile, VMware are making plenty of
> money because people are willing to pay for that feature - even on
> GNU/Linux.
> 
> We're missing an opportunity here.

Maybe, maybe not.  Maybe we're missing a lesson here.

The reason why VMWare/VirtualPC are much better solutions is *because*
they are proprietary.  In the close source world, the model is to invest
heavily in product development and recoup the investment after initial
delivery.  This includes testing, documentation, support, yadda yadda
yadda.  Bug bounties are a means to nudge existing projects forward by
fixing one sore spot at a time.

A better solution would be to mimic the proprietary model, where money
is invested in product development in advance of a project releasing
finished work.  This is what OSAF is doing with Chandler, and it'll be
interesting to see how that plays out.  This is also similar to what
RedHat, Novell and Sun are doing/did with Gnome, funding future
development today in anticipation of future revenue around Gnome.  
Ditto MySQL (today).

If bochs is withering on the vine compared to VMWare and Wine, perhaps
it's telling us that the funding model (volunteer labor (+ bug bounties))
isn't working, and that we should try a different model instead.

-- Adam