Adaptation for Free Software funding?

[Michael Allan]

Interesting the perspective this app gives.

> > ... 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)...
 
David Hilvert wrote:
> 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.

Coding and review of a bug fix in the free software (FS) perspective
may correspond, in the political perspective, to the execution of a
plan or the promulgation of a law.  As such, it is maybe beyond the
scope of the intitial decision process.  The intitial decision process
answers the question: Which plan do we want?  Or which law?  Or, in
the FS case, which bug fix?

Once people at large reach consensus on a legislative bill (say), it
still has to be voted up in the official assembly, to pass judicial
review, and be enforced.  (See more below.)  A bug fix has a similar
process of action that follows on the process of decision, and the two
processes are logically more-or-less distinct.

The fix description itself may allude to the action process.  For
example, it may typically reserve the bulk of payment until the fix
has been accepted by the maintainers, commited to the repo, and
released to the users.  Or maybe this would be the general rule.

If the fix is instead rejected, then it bounces back to the users'
court.  The users may then decide to alter the description, or shift
votes to a different developer, and so forth, and then try again.  So
there's a slow dance or dialogue between decision and action.

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

OK.  So a user drafts the initial fix description (very rough), and
gets a few votes for it.  She then looks for a developer to vote for,
in the hopes the dev will copy the description and refine it into
something that's actionable, and that can attract further votes.
Other developers will see this happening, and they may help out both
with critique ("watch out there, you'll be injecting side effects into
my own code!") and votes of their own ("yeah, we really should fix
that, it's been getting on my nerves").

So the initial initiative and consensus of the users establishes a
kind of bridghead into the dev community.  If so, this would be
roughly parallel to what we've forseen for legislation:

  A public bridgehead into a legislature.
  http://zelea.com/project/votorola/d/theory.xht#figure-20

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

OK.  The only addition to that is the focus on particular, concrete
fix docs.  Also the shifts of votes/pledges and textual content in
response to that critique.  (All this long before it hits the patch
review stage.)
 
> > This [race] 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.

The prob. I was trying to solve was a race among devs, and consequent
watering down of the pay incentive (as you said).  Writing a dev's
name into the fix draft is just one solution.

Another (and maybe better) is a rule: payment goes to the
end-candidate drafter of the fix.  So the end-candidate must be a dev
who can act on the decision, unless it's a documentation bug or
something.

(If a developer is incompetent, then no payment.  Proof of competence
 is whether or not the fix is delivered as drafted/agreed.)

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

OK.  And switching apps, if this tendency affects legislative voting
too, then the end candidates will often be professional jurists or
politicians.
 
> 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.

I don't think so, not for legislative drafting.  The public's formal
consensus draft may express the content of the intended law, but it's
not an actual law until it passes a process of official acceptance by
the legislature, promulgation, review and enforcement.  Likewise for
the users' formal proposal of a bug fix; it's not an actual fix until
it is delivered.
 
> 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.

And collaborators may vote for each other in a cycle, thus effectively
pooling their votes and signalling their intention to work as a team.
The voters may respond to this signal by shifting their votes toward
the team, or away from it.

Where the end-candidates are in a team cycle like this, both will be
paid equally on successful delivery (unless the fix draft states some
other allocation).

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

It's not necessarily a matter of consensus then.  If 1% of users vote
up a fix, and the $$ is attractive enough, then it can go ahead
regardless of what the remainder of the users think.  The
responsibility for the codebase as a whole falls to the maintainers,
those who allow/reject the patches.

Likewise for political issues.  A plan to improve a neighbourhood park
does not necessarilly require consensus from the whole town.
Politicians and bureaucrats must judge what's an appropriate,
actionable consensus depending on the context.  And they must guard
against external effects on other neighbourhoods, etc.  If they judge
wrong here, they'll lose votes in the parallel elections that run
24x7.

Same for FS issues?  Will users be voting in maintainer/admin
elections?  Will $$ be attached to the votes?

It's an interesting app.  Votorola's design can cover it, except for
the authentication of pledges.  But authentication is glued in by
config scripts, in any case.  So it looks painless.  I think it can
fly.

-- 
Michael Allan

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