Adaptation for Free Software funding?

[Michael Allan]

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

If I were the architect, I'd view it as a question not of application
architecture but of domain architecture.  So I'd look at open
standards, stuff like this:

  http://www.metagovernment.org/wiki/Standardization
 
That's for e-dem.  E-dem is an emerging domain while FLOSS already
exists, but I think the two could have a similar look and feel: loose
and flexible integrations, but not precluding islands of tighter
clumping in particular apps (a la IDEs).

Roughly speaking, all a developer needs to know is that Fix-135A for
Bug-6711 is pledging $2000 to him, if he can meet its terms.  This
requires no integration with FLOSS aside from the bug ID.

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

So payment is hourly rate vs. lump sum?  In both cases, the amount may
dependend on the stage of delivery.  The big difference you suggest is
that users can pull out of the contractual fix (e.g. by shifting their
votes away from it), even after the work has commenced.
 
> 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.  I guess anything goes when it comes to drafting a fix contract.
The users and their lawyers can get creative.  (Lessig will like it,
as proof that indeed "code is law". ;)
 
> 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.

Now this is interesting.  With a loose enough integration (desireable
anyway, per above) there need only be a single voting site for all
projects, FLOSS or not.  Hmmm... temptation.

Much depends on the authentication requirements.  If only the pledges
need to be authenticated, and not anything like residential addresses
(as in political voting), then the entire facility could easily be
centralized.
 
> > 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?

If the funds were to stop with the vote, then fund distribution might
be uneven in a cycle - unlike vote distribution.  Alternative is to
spread funds out evenly (not difficult).

-- 
Michael Allan

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