Adaptation for Free Software funding?

[Michael Allan]

I'm not sure if this matches your own idea of a solution, but I'll
describe what comes to mind.

> 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)...

I guess you're right.  There are always multiple fixes that might be
coded, and not all of them are acceptable.  So now we have something
to vote on, something to construct: the fix.  Instead of voting for a
bug, the users will vote for fixes to that bug.

So it's exactly like voting for feature requests (per my last).  But
forget what I said about team building.  The object of the voting -
the thing to be constructed - is a textual description of the fix; of
its various deliverable phases; and of the % of payment awarded on
delivery of each.

This solves your earlier concern about "how well voters can estimate
the effectiveness of those they are voting for."  They'll be voting
for fix-drafters, and their drafts will be open to public critique.

>             ... (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).

This can be solved by writing the name of the developer into the fix
draft.  Any developer can fix the bug, but only those who are named
and receive votes of confidence will be paid from the pledges that are
carried by those votes.

> 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
> problem.

A developer's attention to a given bug would correspond to the amount
of money attached to its various fix drafts, their quality as work
estimates, and the estimates themselves.  The developers will be
actively participating in the drafts, and may themselves be receiving
votes as drafters.

This is similar to legislative drafting where the official assembly
members who must eventually promulgate the bill as law, may also be
participating in the drafting.  Or to plan drafting, where the
executives who must eventually approve and execute the plan are
participating in its drafting, either directly or through negotiation
with the consensus drafter.

The only thing that's weird here is the naming of the developer in a
fix draft.  If the developer is too busy, or shows too little
interest, then the drafter may decide to name another developer.
Votes may then shift as a consequence of this decision, and the other
developer's interest may rise or fall in response.  So it's
"exploratory" in that sense, just as you say.

I think it could work.  What do you think?  Maybe there are other
applications too.  Where else do votes and money mix?  Shareholder
meetings?

-- 
Michael Allan

Toronto, 647-436-4521
http://zelea.com/