A Distributed Funding Model for Free Software Development
One of the frequently-touted benefits of using Free software is that users are not helpless: if a program doesn’t work, or doesn’t do quite what they need it to do, they can either fix the problem themselves (because they have the source code) or they can ask someone else to fix it, possibly for a fee. Users with the same needs can pool their resources to ensure that those needs are met. No user is dependent on a specific developer or company to make the changes they need.
In practice, it is difficult for individual users to exercise this freedom. This is because:
- users may have no idea who to ask to fix a problem or add a new feature; given the nature of most Free software projects, finding the right programmer might be difficult
- even if a user knows who to ask, the programmer or development community might be unwilling to fix the problem because they don’t see it as worth their time
- if the programmer or development community offers to fix the problem or add the feature for a fee, the user may not be able to afford it herself, and may have no idea how to find other people who are also willing to pay for the feature or bugfix
So, although users of Free software have an important freedom in theory, they are still often unable to reap some of the benefits that Free software promises, such as avoiding dependence on a particular developer, or pooling their resources to support development.
This may be one reason why users of popular desktop systems like Ubuntu are often perfectly happy to install proprietary software: even if they know the advantages of using a Free program, without a way to exercise their freedoms, they might as well use a proprietary program that works better or has commercial support.
Meanwhile, because programmers don’t often have a way of getting paid by users to write or adapt Free code, there is a common perception that the only way to earn a living writing software for the masses is to make it proprietary, or to be hired by a large company that will pay you to write software they need. It is difficult for programmers to earn money just by contributing to the Free software projects they are most interested in; sometimes, they ask for donations, but I doubt that many of them expect to earn much from them. We continue to see proprietary programs offered for Free systems as a result. Ubuntu’s Software Center is the latest incarnation of a solution to this perceived problem: Canonical plans, eventually, to sell proprietary applications alongside Free programs as a way of earning money to support their organization. They also think it will attract more programmers to GNU/Linux generally. I hope to be corrected, but I don’t see any part of their proposal that will alleviate the bad choice developers currently face between writing Free code and earning money. They aren’t proposing a payment system for Free software development.
This problem seems eminently solvable. I think we can and should fix the problem of allowing users to exercise their freedoms, and helping developers get paid to write Free software, at the same time. I have a proposal for how to do so: let users pledge contributions toward bugfixes and feature implementations. The basic idea is that the issue trackers used by many Free software projects could easily be extended to allow users to pledge contributions toward particular programming projects; when those projects are completed, each user would pay their pledge to the programmer or team who submitted the patch.
Imagine the following scenario, for example. Janet notices a bug in the way her wireless card works in Ubuntu. She searches on Launchpad and discovers that others have the same problem; there is an open bug report for her issue. Though she has no programming knowledge herself, she is willing to pay $50 toward getting this bug fixed, because it is a major inconvenience and she has no workaround. She clicks a “Pledge now” button in the Web interface and enters this amount. Meanwhile, Katherine, a savvy kernel hacker, notices that a lot of people are having the same problem, and spends some time improving the wireless driver for Janet’s card. Her patch fixes the issue, and the bug is closed. Janet (and anyone else who pledged) are notified that a patch is available, and that they must forward their payments to Katherine. Katherine earns a modest sum for her work, allowing her to spend more time fixing wireless card issues than she otherwise would be able to.
Obviously, there are a lot of logistical problems to be solved here, such as:
- What happens when multiple patches are required to fix a bug, or multiple programmers work on the fix? How should the payment be distributed among patch writers, package maintainers, and others who contribute to improving the quality of the software?
- How do users get a hold of the new version? Do they wait for the patch to move through the normal packaging process before sending their payments? (What if a fix is already available upstream at the time a pledge is made?)
- Who collects the payments, and who ensures that they are made? (Would an arbitration system be needed?)
- What happens to pledges if a bug is marked invalid, or made a duplicate of another?
- What if the patch fixes the problem for some users, but not others?
I think these problems can be addressed by a little engineering and/or “social” innovations. They make a case for experimenting with different informal payment mechanisms to see what works best; they don’t constitute an argument against pledge-based payment systems in general.
The real hurdles presented by this approach are more abstract. They crop up whenever money is introduced where it was previously absent. Payment systems could significantly re-structure Free software communities, and possibly even threaten their existence. Although a payment system could help users exercise their freedom and help programmers to earn a living writing Free code, it might do so at the expense of the volunteerism and collaborative spirit that have made the Free software movement so successful. Programmers who currently work on a project as much as they are able, for their own satisfaction, might become resentful if others start earning money to do the same kind of work. Project leaders might find themselves having to manage payments, in addition to the difficult technical and social problems they already work to solve. And while some users would be able to exercise their freedom more effectively than they can now, the extent to which they can do so would essentially be a matter of their ability to pay, a difficult moral problem in its own right.
For these reasons, we should proceed with caution. I think organizations like Canonical can and should help design these payment systems; after all, they have an interest in making money by developing and distributing Free software. But it should be up to the teams behind individual projects to participate in any payment system, and to decide how they will distribute payments among their members.