www.levien.com by Raph Levien
21 Dec 1998
7 Jan 1999: Christopher Browne has written a proposal that has many features in common. Worth reading, as it fills in a lot of the motivation and social implications that are missing in this rough outline.
DRAFT - not for distribution
This paper describes a rather speculative proposal for funding development of free software. It draws somewhat from existing funding models for science. At its heart is a technological solution of how to keep track of who is and is not a legitimate free software developer. If the system is functioning correctly, it creates a community of peers who evaluate each other's work, with funding flowing automatically according to the consensus of this community.
The system proposed here has the advantage of being fairly simple. I think it's much more important to spend time implementing interesting free software than playing whatever political games it takes to get compensated. In fact, I wouldn't be working on this proposal were it not for the fact that within it lies a rather interesting piece of software.
Motivation
It is widely regarded as beneficial that free software projects acquire sources of funding. Free software has had some amazing successes on a largely volunteer basis, but it is likely that some ambitious tasks simply require a lot of paid work to be accomplished. Getting these tasks done is a good to society that people may be willing to simply pay for. The hard part is deciding on the worthy recipients. People will be unwilling to contribute to a foundation unless they feel its funding decisions are fair and of benefit to the community (and thus to the funders).
The other major pitfall for charity organizations is for the overhead of administration and fund-raising to dwarf the actual disbursements to the benificiaries.
Trust metrics for groups
My Ph.D. research topic is public key certification for the Internet. I've been using trust metrics to determine authenticity. The application to public key infrastructure has its own share of technical issues, but a simple abstraction is that they test for membership in a group.
After struggling for several months, I have found a trust metric that works pretty well for this task. It has the property of graceful degradation under attack, i.e. as more and more nodes become compromised, the determination of membership in the group gradually becomes less accurate. Most systems in the field have catastrophic failure, i.e. a small number of highly trusted nodes, so that if the trusted nodes become compromised, the entire system is broken.
Let me propose several classes of group membership, all of which symbolize a different degree of commitment and achievement in free software. For the purposes of discussion, let's choose three, here called "apprentice," "journeyman," and "master."
Group membership is determined by peer certification. In other words, members of the "journeyman" group are chosen by other journeyman. The certificates themselves are digital certificates, so they can be verified with high integrity.
The trust metric itself is fairly simple. It is a computation over the graph induced from counting each individual as a node and each certificate as an edge. Start with a small number of "seeds," i.e. people that you have a large degree of confidence in as being members of the group (choosing Larry Wall, Richard Stallman, Peter Deutsch, and friends as seeds in the master group would make great sense). Assign capacities to each node based on distance from a seed; close nodes get high capacities, far ones get low capacities up to a certain point, beyond that point zero capacity. Then compute a maximal open-ended network flow starting from the seeds. The set of nodes touched by this flow is the resulting approximation of group membership.
Analysis of this trust metric is tricky (after all, there is a reason why it's academic computer science research), but the bottom line is that there aren't going to be a whole lot of people accepted by the metric who don't deserve to be, as long as most people exhibit good will in signing certificates.
A simple framework for funding
This section presents a simple framework for adapting this trust metric into an actual organization that funds free software.
The organization itself has a fairly limited set of responsibilities:
- Collect donations from people contributing funds in.
- Determine a representative set of trusted "seed" members of the master group.
- Run the trust metric algorithm periodically.
- Make sure that the system is functioning more or less correctly (i.e. sanitychecking).
- Divide up the funds allocated for each class equally among all the individuals in the class.
My personal preference would be that the funds be disbursed as a simple cash grant, with no strings attached. People shouldn't have to quit their jobs to participate.
The organization itself should be a nonprofit for tax purposes to sweeten the pot for individuals and larger organizations contributing in.
Loose ends
The organization itself probably needs to be international if it attains any size whatsoever. National chapters could accept and disburse currency, with possible payments to even out the balances (or maybe not; maybe different countries can just stay with different levels of funding for comparable work).
Actually, there is no need for there to be one central check-collection agency. Different outfits can compete with each other based on their efficiency in getting the money contributed in to the individual developers. This would help keep the actual funding org honest and provide strong incentives against growing fat and happy.
Conclusion
I have proposed a mechanism for funding free software development. It has following (hopefully desirable) properties:
- It is simple.
- It is based on peer review.
- It has some built-in protections against fraud and cheating.
- It is very inclusive.
- It connects the money directly to the task.
- It contains an interesting distributed certification system as part of its normal functioning.
I have not dealt with the following open issues:
- What criteria should we ask that people use to determine group membership.
- Formal recognition for mentoring/apprenticeship, which should be explicitly recognized.
- Finer granularity of classes, including people who perform other valuable services besides coding.