Adaptation for Free Software funding?

David Hilvert dhilvert at
Sat Jun 13 01:50:44 EDT 2009

On Sat, 13 Jun 2009 00:45:47 -0400
Michael Allan <mike at> wrote:

> Shouldn't you pay whoever fixes it?  You could attach an offer of
> payment directly to the bug itself, as a kind of pledge.  The sum of
> all the pledges for that bug would serve as bait/reward for whoever
> could fix the bug.

Bug bounties don't seem to have worked so far; a couple of reasons might be:
(a) whether a bug is fixed isn't easily measurable (but whether someone is paid
is measurable); (b) the bugs of greatest concern will attract a lot of
developers, and if the first developer with a fix is the developer paid, then
the expected payoff of a bounty drops (since it is likely that someone else
will be paid instead).

If, on the other hand, funds are directed by votes, then problem (b)
disappears, as the developer can know in real time whether he is being paid,
and problem (a) becomes degenerate -- each contributor can decide for himself
whether a bug has been fixed, which developer(s) are making the greatest
progress, etc.

> Feature requests are a different story.  I think that voting might be
> useful here, because there's something to construct.  (Voting always
> seems to be about constructing something.)  In this case, the thing to
> construct is the technical description of the feature that is being
> requested.  So it is much like a political norm, such as a planning
> document, where the shifting of the votes has the effect of shaping
> the evolution of the text:
> The vote shifts might also shape the assembly of the development team.
> The winner would become the team leader of course.  He might then pick
> his team members from among the runners up.  (Does this make sense?)
> It would then be like an electoral vote in which the issue was an
> executive power structure:
> Then there's the idea of attaching money to the votes.  I wonder how
> that would play out?  (There is no political equivalent in this case,
> or none that we would hope for!)

The money being paid could be seen as funding an exploratory effort, with the
cascade of votes determining (or estimating) which developers will be most
efficient in this exploration.  When a solution is considered to be found,
exploration can stop.  Creation of development teams seems to be, oddly enough,
an easier problem than funding; as an example, Linux has developed a hierarchy
of patch managers that seems to work rather efficiently, with multiple
individuals maintaining their own trees drawing from a variety of sources.
Getting developers to pay attention to specific bugs seems to be a harder

More information about the Votorola mailing list