Subject: Re: Public Software Fund
From: Tom Lord <>
Date: Thu, 11 Jul 2002 20:54:42 -0700 (PDT)

	> There's an announcement on Slashdot, of the Public Software
	> Fund's first project.


	> The Public Software Fund's raisin d'entre is simple: to
	> reward individuals who are currently funding the development
	> of public software, and to encourage individuals who are
	> funding proprietary software or not software at all, to fund
	> public software.

I have a suggestion for how to administer that kind of fund which I'll
try to concretely relate to the projects OpenCM, Subversion, and arch.

Let us (the public) define categories to which donated funding can be
directed.  If I give money to your fund, I can earmark it for a
particular category.  Someone might define the category "new revision
control technology for open source development", for example.

So -- what precisely are categories?  Operationally, I propose that a
category is defined by a set of parameters that you ( can
store in a file or a database.  These are:

  + cash balance	:::	the total of donations earmarked for
				this category, minus the amount paid
				out by this category

  + payout rate		:::	a variable periodic fixed or
  				%-of-balance rate at which the cash
				balance is issued to open source

  + paylist		:::	a dispersal rule for each payout

  + web page		:::	a web page of introductory text
				describing the category, the criterea
				for being added to its paylist, and
				similar information.

  + committee		:::	the list of people with authority to
				make changes to the payout rate, 
				paylist, and category web site.

The Foundation gets to establish the minimimum paylist criterea.
(Self-appointed) committee's just get to add aditional requirements
and link those to donation earmarking.

In terms of arch, subversion, and opencm: someone might reason that
lots of people agree that a new generation of revision control tools
is desirable, but not everyone agrees where the sweet-spot is in the
design space.  It is rational to fund competing projects until the
situation becomes clearer.  

Any small group of, say, FSB engineering managers could step forward
and create a "new revision control system" category, setting out
minimum requirements, fund-sharing policiies etc.  If they do a good
job, their category might attract both donations and the cooperation
of the various revision control projects -- they'd become de facto,
inter-corporate open source project managers, with real budgets and

At the same time, the basic "payout rate" and "paylist" structure, 
if managed with stability by the committee, gives volunteers who
reach the status of being on paylists pretty much the same type of
of financial security and regularity as regular employment (but
without all the hassles :-).