User:Pde/Funding free software

This draft discussion paper is not part of wikipedia, though it may be of some interest to wikipedians and this is an easy place to collaboratively edit it...

Funding Free Software as a Public Good : A Discussion Paper
There are today several different software industries that operate in parallel:


 * Custom software that is produced for a single paying client or employer.
 * "Shrinkwrap" software that is produced for proprietary software firms, to be sold in a marketplace regulated by copyright, trade secret, often contract and sometimes patent law.
 * Web services. Much of the source code that makes web services different from one another is kept secret and protected primarily by trade secrecy law; the ability to use the services themselves is often priced at zero dollars and funded by advertising.
 * The free software universe, which partially overlaps with the other categories, but prominently features a great deal of volunteerism. Within the free software world, groups produce code using different development and funding models, but have in common the practice of publishing and licensing their code freely.

There are three principal arguments why it is desirable for software to be in the fourth category, ie published and free of copyright restrictions.


 * 1) Freedom and autonomy. Software is an important part of the structure of the world we live in, and a direct influence on us at mainy points in our daily lives. It can be argued that we should therefore be free to understand, improve and share improvements to software that affects us. As a practical matter, arguments from this freedom appear to be much more compelling to people who can program than it is for others who have to rely on others to program for them.
 * 2) More efficient development. Eric Raymond popularised the argument that by decentralising development, enabling users to modify their own software, and reducing barriers to contribution, free software can be produced more efficiently than proprietary software that is developed within a single firm.
 * 3) Avoiding artificial scarcity costs. Software is a public good; the creation of property rights (whether legal, as in copyright) or practical (secret source code to a web service) in software necessarily leads to significant waste or economic "deadweight loss". Every time someone wants to use Photoshop, but not enough to to purchase a copy, the outcome is wasteful.  Every time a firm decides that they want to but cannot use gmail/Google Apps because of the confidentiality implications of relying on Google for hosting, the outcome is wasteful.


 * Although artificial scarcity costs are sometimes reduced by the reality of widespread piracy of proprietary software, the fact remains that these costs are likely to reduce the social value of proprietary software by a non-trivial percentage.

Taken together, these are compelling arguments that as much software as possible should be free. Unfortunately, it remains very likely that there are situations in which there is much more commercial incentive to produce software using proprietary development models. Greater commercial incentive makes it possible to hire programmers to write code quickly, and it may be that some software would not be written as soon, or at all, if it copyright and trade secrecy monopolies did not offer these incentives.

The question, then, is can we write our code and free it too? Can we find a way of coupling the commercial incentives that motivate Microsoft and Google to produce so much useful code, and also attain the benefits of making that code free for anyone to inspect, modify and redistribute?

We would reach the same question if we approached the subject from the other direction, by taking seriously the observation that software, and free software in particular, is a collection of economic public goods. It is well established in economic theory that the rates of spontaneous production of these goods are well below the social optimum (Cornes and Sandler 1996, p. x), and we should therefore be interested in what institutions might increase the production of free software.

Bottom-up, contracting institutions
There has been persistent interest in the possibility that communities of free software users (or potential users) could get together and arrange by contract to fund the production of code that they all want.

In 1999, Kelsey and Schneier proposed what they called the "street performer protocol" (SPP). In the Street Performer Protocol, a copyrighted work is produced, the author names a total price for the publication of that work under a liberal copyright license, and members of the community offer pledges (which may be implemented as escrow payments) to pay if the work is liberated. If the pledges reach the total the author asked for, the work is published; if not, the escrow payments may be returned to the people who made them. SPP is sometimes also called a "threshold pledge" or "fund-and-release" system.

Adam Theo (2002) proposed something similar to the original street performer protocol, which he called the "ransom license". The main difference between the two is how they handle payments from individuals before the total price has been reached. Rather than placing these payments in escrow, as the SPP does, the ransom license treats them as a purchase of a proprietary software license. There is also a sunset clause &mdash; after a certain number of years, the software becomes free regardless of whether the requested total number of payments has been reached.

Chris Rasch (2001) suggested a different and more distant variant of the SPP idea called the "wall street performer protocol" (WSPP). Under WSPP, software users offer prospective pledges to pay certain amounts if certain software features are implemented in a particular timeframe. If any coder is able to implement the requested feature in time, they can collect the pledges. The WSPP is also often called a "bounty" model.

Love and Hubbard (2002) proposed a scheme called "Matching Funds" (MF) which is similar to WSPP, except that there is an explicit role for a manager/broker to propose projects and promote them amongst both developers and potential contributors.

Sporadic attempts have been made to actually implement these kinds of bottom-up contracting institutions for software (there is also a much longer and arguably more successful history of using these kinds of arrangements to fund non-software creative works, but that history is beyond the scope of this essay). In 2002, the SPP was successfully used to raise €100,000 for the open-sourcing of Blender, a 3D modelling tool. Although this was clearly a success, €100,000 is a small sum compared to the cost of developing Blender in the first place.

In 2004 website called opensourceexperts launched which offered, among other things, to be a registry for WSPP bounties. The Gnome and Asterisk projects, in particular, offered a substantial number of these. A few were claimed, but the endeavour does not appear to have been particularly successful &mdash; only a handful of bounties have been posted each year since 2005.

Flaws in the (W)SPP Models
There are at least two reasons for the failure of WSPP variants to catch on more widely in the free/open source world.

The first problem is that, despite occasional claims to the contrary, none of the SPP variants solve the free rider problem in the sense of making it rational in a game theoretic sense for a self-interested party to pledge or contribute money through the protocol when they would not have simply donated the same money voluntary. There are narrow exceptions to this problem, under which the successful use of these protocols may be a Nash equilibrium, but they are special cases and arise when individual participants have so much information about the producers' costs and other participants' willingness to pay that they can deduce that their own pledge or contribution has a significant probability of being causally determinative of the protocol's success. But whenever the community of potential participants is of a large and indefinite size, the normal case is that the project would succeed or fail regardless of the action of any individual participant, and they will therefore choose not pledge or contribute.

The second problem is one of transaction costs. In order to successfully mimic the size of incentives available in proprietary software marketplaces, or to produce incentives large enough to be worth a professional programmer's time, large numbers of users would need to combine their bounties on the same features (or bugfixes) within the same programs. Because there is currently no established infrastructure for these users to know that such bounties are being accumulated, and no culture of looking for them, the transaction cost barriers to obtaining large enough bounties are overwhelming. Bug tracking databases would probably be the most sensible place to advertise and encourage bounties, but even there, it isn't clear how many free software users would notice them.

At this stage it seems that most free software projects are better served by adding a "donate" button to their websites than by attempting to use SPP variants to raise funds from large userbases. It is unclear whether this is necessarily as true of ransom licensing.

Could ransom licensing do better than (W)SPP?
In principle, ransom licensing should be able to avoid both of the problems discussed above with respect to SPP/WSPP: paying for ransom licensed software should be rational for users (assuming they would pay for similar proprietary software), and the need to purchase a copy of the software should motivate users to pay/overcome transaction costs, at least in cases where they do not engage in piracy.

The bottom line is that ransom licensing is probably an under-explored strategy for free software production, especially in domains where people are used to purchasing proprietary software packages to run on otherwise free/open source operating systems.

Government Funding Institutions
In 1985, Richard Stallman wrote the GNU Manifesto, which outlined the principles of the modern free software movement. In that document, he speculated that one way to ensure that software development was adequately funded would be to levy a "software tax" on computers, and use that money to write free software.

Since then, the rise of P2P and the copyright industries' various efforts to stamp it out, many authors have examined in depth the idea of using a taxation-funded alterntative compensation system to fund cultural copyright works like music, writing and film. A parallel and growing literature has examined the question of designing prizes or other mechanisms to free essential medicines from patent-based monopoly pricing. There has been comparatively little discussion of the particular complications that an alternative compensation system for software might involve.

This section is not an attempt to review ideas in the already extensive literature on publicly funded compensation systems for creative works or drugs; instead, it focuses on the distinctive problems of public funding for free software.

To What Extent Do We Already Do This?
It could be argued that the U.S. National Science Foundation and other national research organisations had been funding software development to some degree for as long as there had been computers. In fact, Chris Kelty has argued that the cultural values of the free/open source software movement are actually a direct product of the fact many of the people writing software were working at universities funded by research grants.

One criticism of these existing scientific granting processes is that academics do not, for the most part, have incentives to spend their time writing software that is useful to as many people as possible. Normally, their career incentives encourage them to write software that works well enough to demonstrate the possibility of some novel algorithmic or technical possibility, write a paper about it, and move on. To the extent that academics write free software that is useful to a broad audience &mdash; especially when that audience extends beyond the scientific discipline they are working in &mdash; it is often because they are motivated by something other the normal institutional career paths of academia.

In theory, we should be able to do much better by adapting and specialising parts of the system for public funding of research in order to explicitly encourage software engineering.

How Granular Should Funding Be?
The funding of free software projects can be organised on completely different scales. Many free/open source projects in the academic world are the results of research grants in the scale of hundreds of thousands or millions of dollars. But we could equally imagine giving out smaller grants to programmers in order to implement specific new features for existing software &mdash; projects more in the range of tens of thousands of dollars. Lastly, funding could be offered for fixing specific bugs. In many cases, such funding could be another order or magnitude or two smaller in granularity.

There is a clear tradeoff between these scales of operation: the smaller scales allow more useful information to flow from users to developers about what aspects of available free software need to be improved, while in the other direction, larger scales reduce transaction costs and may allow developers more freedom for R+D and innovation. It is quite possible that the best way to organise funding for free software development would combine several or all of these granularities.

Ex ante vs ex post funding; ex ante vs ex post specification
In any arrangement to produce code in exchange for money, the amount of money to be given can be determined either before or after the code is written, and the precise requirements or specifications for the code can be determined in advance, or not. All four combinations of these two variables could make sense in certain circumstances.

For instance, one could imagine a funding system that attempts to measure the most valuable and widely used software, and pays the developers retrospectively for having produced that software (ex post payment with no specification). The opposite is also possible: a project might receive a grant in advance in order to implement a program with a pre-specified set of requirements (ex ante payment with specifications). Projects can also receive grants without specific requirements; many tender processes specify ex post payment if and only if a requirements are met (WSPP is also an example of ex post payment with advance specifications).

How To Measure The Value of Free Software
In any of the four cases discussed above, judgements must be made about the value of various pieces of free software (or of improvements or bugfixes to pieces of software). In the ex post/no specification example, the judgements would be based on numerical measurements. Some possibilities include:


 * the number of people using the software
 * the amount of time spent using the software
 * surveys used to elicit measures of the software's "quality" from users
 * contingent valuation surveys used to elicit dollar values from users
 * the amount of private money being spent on the programming effort

There is no question that these measures would only give noisy estimates of the underlying social value of a piece of code. The more important question is the comparative accuracy of the measures, and the general issue of whether they might be so approximate that they inherently make the idea of public funding for non-specified free software projects inadvisable.

Interestingly, some free software projects already receive funding from commercial sources that are based on measures somewhat like these. For instance, Firefox receives funding from Google based on the number of Google searches that are made from the Firefox toolbar. Many nations have tax credits or concessions for private investment in R&D; when those schemes are available to particular free/open source software projects, they effectively count as governmental support for those projects.

The other road, of course, is not to try to elicit data from users about the value of software but to rely on various kinds of expert judgement about what software ought to exist. That is, to first approximation, the way that governments fund scientific research. There is no question that the process is extremely approximate, or that it has produced some extremely worthwhile results.

The "Who Wrote That Program?" Problem
Some (but not all) of the combinations of answers to the preceding questions would involve funders giving certain amounts of money to the programmers responsible for a particular project. This seems to lead to some fairly tricky questions of authorship. Suppose, for instance, that a a fancy new 3D Web Browser is released, and after some time it is determined that a sum of $10,000,000 is the appropriate remuneration for having produced it. Who does that money go to?

The obvious answer is a nonprofit or other organisation that sponsored the development of the 3D Browser, if such an organisation exists (it might not). But this answer is by no means guaranteed to be satisfactory. What if there are programmers outside the organisation who in fact contributed significantly to the code? More complicatedly, what if there are other projects that are indirectly responsible for the merit of the Browser? Perhaps the browser was extremely easy to write because of recent improvements to the 3D graphics, GUI toolkit, HTML parsing and networking libraries that the browser is built on. What happens if these projects start to argue (with varying degrees of legitimacy) that they deserve a share of the funding?

These problems tend to be more severe with higher-granularity funding schemes. More narrowly specified, smaller-granularity improvements to code are more likely to apply to unambiguous pieces of code, and to be written by identifiable authors.

Complications in Funding Free/Open Source Communities
An important point to understand is that the free software movement has succeeded by producing collaboration between programmers with disparate motivations for their work. A study by Lakhani and Woolfe suggests that there are four primary and fairly distinct classes of reasons that people find themselves writing free software: (1) learning and intellectual stimulation (29%); (2) a personal need for the software they are writing (27%); (3) being paid to write the code or other career-related motivations (25%); (4) idealism and community reciprocity (19%). This collaboration of individuals with disparate motives has been sufficient to build systems that would likely have cost in the order of tens of billions of dollars as works for hire. New funding institutions need to be designed in such a way that they do not disturb these established, successful ecosystems of collaboration.

Psychologists have noted that the presence of financial incentives for a person can "crowd out" voluntary efforts that that same person might otherwise have made. There is also evidence that payments to some members of a community will "crowd out" volunteer efforts by others in the community. Benjamin Mako Hill has attempted to work through some of the strategies that can mitigate these problems. As he points out, there are some projects, such as Ubuntu, which appear to have succeeded in paying large numbers of programmers while also maintaining volunteerism by many others, though even in those cases we cannot be certain that some crowding out is not occurring.

Conclusions
(in development)

The *SPP protocols suffer from inherent flaws which make it unlikely that they will ever become the basis of major institutions for supporting free software. In principle, these flaws might not apply to the ransom license model, and further promotion and experimentation with that model might be appropriate in certain niches where it does not conflict too profoundly with developer and user expectations, and community based software development practices.

Organised government funding for free software production already exists, although when it comes via science funding institutions it is frequently not "organised" from a software engineering point of view. National scientific granting bodies should experiment with the idea of making usability (and a healthy userbase) one of the objectives they explicitly fund and evaluate for in a subset of projects that involve writing software.

It is clear that the spillover public goods produced by free/open source software development are similar or greater than those produced by other kinds of R&D. Nations should therefore ensure that any R&D tax concessions they make available can be claimed for free/open source software development projects, including those produced solely by individual volunteers.