Adaptation for Free Software funding?

[David Hilvert]

On Mon, 15 Jun 2009 22:45:29 -0400
Michael Allan <mike at zelea.com> wrote:

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

How would a Votorola implementation of this integrate with a project relying on
existing tools such as bug trackers and mailing lists? 

> 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 two can be intertwined; as an example, one of the salient points in the
Linux scheduler (CFS) debate was responsiveness of the developer to users'
reports, illustrating that user concerns and the process of patch acceptance
are not always easily disentangled.

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

This leaves the question of whether a fix has been achieved, which is often
determined in practice by a cycle of testing between developers and users (and
hence difficult to define in an initial fix description).  If users instead pay
for a developer's time, then users not satisfied with a committed fix (or
dissatisfied with progress toward a fix) can choose to fund a (different)
developer of choice.

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

In practice, new proposed patches can be published within hours or days, so
that it might be best to provide a mechanism that allows voters to quickly
change the stream of funds (e.g., allowing voters to specify a maximum funding
amount and a maximum rate of payout, with developers immediately able to draw
at a rate up to the aggregate maximum rate defined by 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

A chosen voting system should also allow for effective coordination between
developer communities, which seems to be a harder problem.  E.g., an Ubuntu
package maintainer encountering an upstream bug should be able to fund an
upstream developer, and a Linux kernel developer encountering a GCC bug should
be able to fund a GCC developer.

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

I notice that you had included a stipulation that a vote cascade would stop
prior to repeating a cycle; could funding cycles be handled similarly?

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

It seems generally preferred that maintainers have a certain independence from
their funding sources.