Subject: Re: Bounty for Bugs in Open Source Projects?
From: "Stephen J. Turnbull" <stephen@xemacs.org>
Date: Tue, 19 Apr 2005 15:58:06 +0900

 Tue, 19 Apr 2005 15:58:06 +0900
>>>>> "A" == A Pagaltzis <pagaltzis@gmx.de> writes:

    A> But wouldn¢t your combined scenario above have the exact same
    A> effect?

No.

    A> Say the company asks for a bug to be fixed and 10 developers
    A> write offers. Who¢s the company going to pick: the most
    A> expensive offer, or the cheapest one?

The company will consider the tenders as bundles of "product quality"
and "cost", and choose the one that in their judgement is the best
bang-per-buck.

The problem with "bounties" is that they ignore the fact that nobody
can write a spec  in advance  that actually defines quality  as
perceived by the end user .  So there is strong incentive to focus on
"low cost meeting static spec" whereas what is desired is "low cost
meeting need" => spec must be dynamic to match changing understanding
of need as the process proceeds.  The tender system provides enough
dynamics, the bounty system does not.

Of course, if the bounty is offered by a single agent, they can always
say (with debatable ethics but effective economics) "but that's not
really what I meant" when the product shows up.  Then you're right:
bounties are equivalent to Ben's tendering process.  However, the
bounty idea typically is intended to allow (a) aggregation of many
demands and (b) avoidance of the negotiation costs.  Both of those
push strongly in the direction of the (often disastrous) world of
static specs, focus on unidimensional "price", and a race to the
bottom in terms of quality.

-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.