Adaptation for Free Software funding?

[David Hilvert]

On Sun, 14 Jun 2009 21:34:33 -0400
Michael Allan <mike at zelea.com> wrote:

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

One possible problem with this is that, in practice, projects will often have
an established method for accepting fixes.  As outlined earlier for Linux, this
can take the form of a hierarchy of patch managers, or otherwise can consist of
a single project maintainer, but the general case is that someone who is fairly
familiar with the code being changed will decide whether a fix goes in.

This decision, moreover, appears to generally be made on the basis of actual
code (not merely a textual description of code), on the observed effectiveness
of the proposed change (e.g., via testing by users), and perhaps also (for
large changes) on the basis of whether the author of the changes is trusted to
maintain these changes in the long term.

Given all of this, much of the knowledge regarding how the fix should be
constructed will be something that a developer will know, but that typical
voters will not know.  If a voter can select someone with more knowledge and
skill as a developer, and convince this person to work for him, then the chance
of a successful fix should increase.  If a cascade of such selections can be
made, then the chances of a successful fix should increase with each step in
the cascade.

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

Critique of proposed fixes seems to be fairly well handled already by mailing
lists and bug trackers.

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

I would imagine that selecting developers by cascade of votes would be more
straightforward than electing someone to draft a document naming a developer.
This seems to be an important point for the case that a developer is found to
be inappropriate for the job, or that an additional developer is needed.  If
payments to developers for work on a fix can be changed by changing of votes
(with votes perhaps divisible between many candidates according to an
adjustable proportion), then these sorts of changes -- adding or removing a
developer -- can be made quickly.

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

In the case of voting for developers rather than drafters, developers could
draft proposals where needed to attract votes.  This seems parallel to the
current situation on mailing lists, where ideas are sometimes described in
abstract form, to attract support or help, but where such abstractions are
considered secondary to the task of producing code patches, as it is ultimately
the quality of the final patch that will determine whether the change is
accepted.

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

In the case of legislative drafting, it is the final draft itself that becomes
a part of the law.  In the case of coding, it is a code patch (perhaps having
undergone several revisions) that becomes part of the program.  Hence, the
analog in this case to a legislative drafter would be a developer.

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

Also in the sense that collaboration can occur between developers, just as in
the (rather exploratory) field of the sciences.  If developers who collaborate
can be quickly funded, then there might be greater incentive for new
collaborators to join.

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

One of the special aspects of patching software (and especially Free Software)
is that producing one patch will not necessarily exclude a different patch.  So
long as individuals (and companies) are free to pay for their own development
branch of a program, they lose little (and likely gain) by having others
funding other development.  In this way, software might be a bit different from
the case of shareholder meetings, and from many other activities in the area of
administration and governance.