The Wall Street performer protocol
First Monday

The Wall Street performer protocol: Using software completion bonds to fund open source software development by Chris Rasch

In their article “The street performer protocol and digital copyrights” (Kelsey and Schneier, 1999) suggest that copyright will become increasingly difficult to enforce. They propose a general mechanism for funding digital public works, the “street performer protocol” in which authors produce their work only after they receive enough contributions to make it worth their while. In this article, I sketch out a proposal for the creation of a software completion bond market. I think such a market would be a practical implementation of the “street performer protocol” for the funding of open source software. I first describe how such a bond market might work, and why I think the open source community needs a bond market. Then I examine the underlying economics of open source software. Finally, I review some of the existing and potential alternatives to a software completion bond market [1].


Social policy bonds
Open source marketplaces
How could a software completion bond market help existing open source markets?
How to get there from here
Current challenges facing the open source community
What’s wrong with current open source software funding mechanisms
How can the free rider and assurance problems be solved?
What would an ideal mechanism for funding open source software look like?




A software completion bond is a promise to pay the bond owner the face value of the bond when anyone, anywhere in the world, completes software that meets the bond specifications. A software completion bond is created when an individual who wants to fund the development of an open source software package backs a bond by agreeing to place the face value of the bond in an interest bearing escrow account. The “bond backer” agrees to accept the judgment of the “bond judge(s)”, who are appointed at the time of the bond’s creation. The “bond backer” agrees to pay off the bond when the “bond judge(s)” determine that the specs have been met. A bond may or may not have a time limit associated with it, depending on the desire of the bond backer.

Here’s a scenario describing how completion bonds might be used to fund the development of a medical practice management system:

For the past six years, Ed E. was the lead developer for ClosedMed Corporation. ClosedMed sold ClosedPM, a $50,000, $15,000/year physician’s practice management (PM) system. Although ClosedMed projects took up much of his time, Ed dabbled in open source software development. He watched Linux grow from a hacker’s toy to a ubiquitous software tool supported by software giants like IBM, Oracle, and Hewlett Packard. Ed likes the freedom that Linux, the GNU tools, and other open source software packages have brought to both programmers and users. Ed believes that an open source PM system would offer physicians several advantages over existing closed source PM systems, such as:

  • lower cost of acquisition and lower service costs;
  • greater reliability;
  • increased “future proofing”; e.g., medical records won’t become unreadable if the vendor goes out of business;
  • greater interoperability with data gathering equipment; and,
  • increased security.

Ed wants to use his experience to build such a system. However, he realizes that developing a medical practice management system entails high initial investment costs. Such software must be reliable, secure, and user friendly from the start. Physicians won’t tolerate software that crashes every other day, or requires learning obscure commands, or lets unauthorized individuals see someone else’s medical records. The creator of the software could even face legal penalties if the software is insecure. Creating this kind of software will require lots skilled programming time, security and usability testing, and customer training.

How might a software completion bond market help Ed fund the development of an medical practice management system?

First, Ed goes to the Web site. He searches for existing open source PM system bond issues. Seeing none, Ed decides to write a proposal for a medical practice management system of his own (let’s call it OpenPM, for brevity’s sake).

After Ed specs out the medical practice management system, he estimates that it will cost $2 million dollars to develop, test, and debug. He writes a proposal describing his intention to build such a system, and e–mails it to his network of programmer acquaintances. Based on their feedback, he refines his proposal.

Next, he puts his proposal on the OpenPM Web site. The proposal contains a functional specification, a timeline, documentation requirements, and a list of potential programmers, documentation authors, and others who have provisionally agreed to help with the project.

He also nominates a pair of “bond judges”. The bond judges decide when the terms of the software bond have been met. In the case of the OpenPM system, someone will have to judge the a) usability of the system, and b) the security and technical design of the system. Ed nominates two bond judges:

  • Judge Judy, an M.D. with broad experience with a number of proprietary PM systems; and,
  • Judge Wapner, a programmer with 10 years experience writing code for one of the top three vendors of commercial PM systems.

Then Ed goes to AMA meetings, his physicians, and so on, looking for project backers. A backer agrees to pay off the bond at face value when the bond specifications have been met, as determined by the “bond judge”. Most often, the backers of a bond issue will be the ultimate users of the software.

For example, Ed persuades Dr. Bob to agree to back 20 bonds of $100.00 each. Dr. Bob, submits his credit card to the site. charges him $2,000 and places the bonds in an interest bearing escrow account. Dr. Bob then sells the bonds on the OpenBond market, which Ed then buys at $1.00 each.

Ed continues to promote the OpenPM bond issue until he finds enough bond backers to pay for the development of the software. Note that Ed is not necessarily alone — others who believe that they can contribute to the project in some way may also promote the project to potential backers.

Once Ed collects enough bonds to fund the development of the software, he can then approach a lending institution, such as a bank, to give him a loan to finance the development of the software. Ed uses the loans to pay the programmers, documentation authors, managers, and others who will help with the project.

Finally, a year later, the OpenPM system is complete. Ed submits a “bond judgment request” to the “bond judges”. Initially the bond judges don’t believe that the code has met the bond requirements. They give Ed a list of things that must be done to complete the requirements. Ed makes the suggested changes, and a few weeks later, he submits another “bond judgment request”. This time the “bond judges” agree that the OpenPM system meets the bond specs. They inform to release the bond backers money from escrow, and pay off the bond owners. Ed uses the funds he’s earned to pay off the bank loan, pocketing a reasonable profit for himself.



Social policy bonds

Others have suggested similar software completion bond markets [2]. However, since I was most inspired to develop the software completion bond idea by Ronnie Horesh’s social policy bond proposal, I think it’s worthwhile to summarize it in some detail.

As an agricultural economist at New Zealand’s Ministry of Agriculture and Forestry, Horesh observed that policymakers, however well–intentioned, were often not rewarded in ways that correlated with their success in achieving their stated objectives. As a result, policymakers often impose wasteful, inefficient, and costly programs that either exacerbate the problems they were intended to solve, or create different, but equally knotty additional problems.

For example, Horesh noted that EU trade tariffs, subsidies, and price controls intended to assist small European farmers, cost European consumers an incredible amout of money:

“The most recent calculations show that the annual cost to consumers and taxpayers of [Organisation for Economic Cooperation and Development, OECD] 29 member countries’ support for agriculture and horticulture amounts to US$361 billion. Such a large sum is difficult to grasp, but it is large enough to pay for a first class, round–the–world air ticket for each of the 56 million cows in the 29–member OECD’s dairy herd, and to give each cow a further US$1,450 spending money for her stopovers in the U.S., Europe and Asia. Or the cows could slum it in business class, and have US$2800 spending money. And they could have this sort of trip every year, thanks to the generosity of OECD consumers and taxpayers.” (Horesh, 2000)

Worse, most of that government support goes to the wealthiest farmers and agricultural corporations, those who presumably need it the least:

“But because much assistance to the sector takes the form of subsidised prices for their production, most of it goes to the farmers who produce most, and who you might think need support least. In the U.S., for instance, about 88 percent of support goes to the largest 25 per cent of the farmers (in terms of gross sales). So the proportion of the billions of dollars for OECD agriculture that does end up with the smallest farmers is tiny: around three or five per cent.” (Horesh, 2000)

Horesh suggests that governments could avoid such waste, and solve social problems (poverty, crime, lack of healthcare/eduction) more effectively by harnessing individual self–interest. To that end, Horesh made the following proposal:

“ … [government should] issue non interest–bearing bonds that are redeemable only when the the social objective in question has been achieved. Social Policy Bonds would be issued by government at whatever price they will fetch on the open market and therafter could be bought and sold by any willing individual or institution at their free market price. Once the targeted objective had been achieved, they would be redeemable, as are conventional bonds, for a fixed, predetermined sum.” (Horesh, 1992)

Bond holders would have incentive to bring about the desired social goal as quickly, and as efficiently as possible. Those who knew they could do the most towards achieving the social goal would be the most likely to purchase the bonds. Those who could contribute toward the achievement of part of the goal could do so, then sell the bond in the secondary markets, and realize a profit for their efforts to bring the bond’s objectives closer to fruition. Although Horesh promotes social policy bonds as a way for governments to meet their objectives, I suggest that similar bonds could be used to fund open source software (and need not be government subsidized).



Open source marketplaces

Several efforts have been made so far to create marketplaces for open source software, though none as yet employs a software completion bond mechanism. Axel Bolt, a university mathematics professor, began the first free software marketplace, the Free Software Bazaar, in September 1998. Bolt operates the bazaar as a volunteer service, and takes no fiduciary role in the exchanges. Potential sponsors submit “requests” (the software they want written) and “offers” (how much they will pay for it) to the system. If a programmer sees a request he thinks he can meet, he writes the software and posts it to the Web site. If the sponsor agrees that it satisfies his need, he pays the programmer.

Since then, several companies have created a number of different “market lubricant” services, each designed to help reduce the transaction costs, free rider, and assurance problems involved in contracting for open source software development. Among those services include:


Provide a mechanism for those who want open source software written to find and contract with those willing to write it. Examples include the Free Sofware Bazaar, Cosource, and SourceXchange.

General contracting services

Provide marketing, technical support, billing, legal services, and act as a single point of contact for teams of open source independent contractors. Examples include Asynchrony, Exropia, and

Portal services

Provide hosting and project management services (CVS, mailing lists, Web space) for open source projects. Examples include SourceForge and OpenAvenue.

Here I will focus only on the companies attempting to create marketplaces, currently Cosource and SourceXchange. Both follow a similar model to Axel Bolt’s Free Software Bazaar. To illustrate how they currently work, here’s a description of how a hypothetical IBM manager (let’s call him Ivan), might use SourceXchange to contract with an open source team to add a Perl interpreter to the AOLserver Web server.


First, Ivan writes a Request for Proposal (RFP), detailing IBM’s desire for an integrated Perl interpreter in AOLserver.

Next a SourceXchange technical reviewer vetts the RFP. If it passes muster, SourceXchanges posts it on the Web site for comment from the developer community.

Now potential developers may also begin to post proposals detailing how they would meet Ivan’s need. The proposals generally include project specifications, a timeline, milestone payment schedule, and other information relevant to the project.

Ivan, with the assistance of a SourceXchange peer reviewer, then selects one of the proposals to fund. Let’s suppose Dan, an AOLserver guru, submits the most appealing proposal. SourceXchange notifies Dan that Ivan selected his proposal, along with any suggested revisions Ivan may have.

Dan begins work on the project. As development projects, Dan and Ivan communicate via e–mail to resolve ambiguities, or problems that may arise. SourceXchange pays Dan after he achieves each milestone. If Ivan and Dan disagree about whether he has achieved a milestone the peer reviewer may arbitrate the disagreement.

Upon project completion, both Dan and Ivan rate each other’s performance, and provide suggests for improving the development process. Finally, SourceXchange archives the entire project for future reference.



How could a software completion bond market help existing open source markets?

A software completion bond market would help reduce the free–rider problem to any level that a potential bond backer wished. Bond backers will vary in their sensitivity to potential free riders. For example, Ivan might be indifferent to free riders, but Harry, another potential bond backer, might not want to pay unless other potential users also contributed at least $1,000. Both preferences could be met, by allowing bond backers to specify that their bonds would not pay off unless someone else bought at least $n worth of bonds. A bond backer could even specify that their bond would not take effect unless specific companies or individuals contributed n dollars.

Bond markets would also increase the flexibility with which developers can join or leave the project. Developers, like Dan, who believe that they can help with a given project need only purchase bonds on the market. Likewise, suppose Dan believes that he has contributed all he can the project. He can leave the project by selling his bonds on the secondary market (presumably at a price higher than his purchase price) to someone else who can carry the project forward.

Non–programmers would have more incentive to promote and aid open source projects. It is often difficult to find both the skill to write good software and the skill to teach or sell the software to someone else embodied in a single individual. Software completion bonds would give greater incentive to those with selling (and other non–programming) skills to help with open source projects.

With the current implementation of the CoSource and SourceXchange markets, only one development group can win the bid for a project. Programmers must compete against each other for the bid. Those who lose the bid have little financial incentive to help with the project, even though they may have valuable skills or resources to contribute. Bond markets as described above would encourage developers to cooperate instead of compete against each other.

Bond price levels would increase information about the difficulty of the project. A low bond price would indicate that the bond owner believes that developers will not succeed at meeting the bond specs quickly.

A bond market would encourage flexible team management. Development teams can organize anyway they wish. Given that the bonds only pay off once the specifications have been met, developers have an incentive to choose the most efficient organization structure they can. This will vary, depending on the nature of software, size of the project, and the personalities of the developers. Long–term, complex projects might become more feasible since the bond backer only has to specify the ends, not the means.

Finally, a bond market would encourage open source programmers to write precise, detailed specifications, since both the programmer and the bond backer have an interest in making sure that the specifications can be met unambiguously.



How to get there from here

Ideally, SourceXchange and Cosource would cooperate to create a market for software completion bonds, since both companies have an interest in seeing that the market for such bonds is as liquid as possible. Failing that, one or more other companies might be formed to create a exchange market/escrow service for completion bonds.

If the software completion bond market is based in the United States, the market operators would need to get permission from the Securities and Exchange Commission (SEC) or Commodity Futures Trading Commission (CFTC) to operate it, as it seems likely that it would fall under U.S. law regulating futures contracts. According to Bell (1997)

“ … 7 U.S.C.A. § 6(a) (1996) provides that, absent an exemption by the CFTC, "it shall be unlawful for any person to offer to enter into, or enter into, … a contract for the purchase or sale of a commodity for future delivery”

unless the transaction takes place through a contract market certified by the CFTC. See also, 7 U.S.C.A. § 2(i) (granting the CFTC exclusive jurisdiction over “transactions involving contracts for sale of a commodity for future delivery).”

These provisions, together with the legislative history of the Commodity Exchange Act (CEA), led one commentator to conclude that “Congress has vested solely in the CFTC both authority to determine whether to designate a contract market for a proposed future, and exclusive jurisdiction for the regulation of such markets after their designation” [3].

Ideally, the regulatory agencies would issue a no–action letter similar to the one that the CFTC issued to the University of Iowa finance department, which allows them to run the Iowa Electronic Markets. However, getting regulatory approval is likely to be an onerous process, if possible at all. The most economical approach may be to locate the bond exchange in a non–U.S. jurisdiction with a lower regulatory burden. This was the approach taken by C2Net software when they developed the Apache Stronghold Web server. In order to avoid violating U.S. export restriction on encryption software, C2Net hired non–U.S. programmers to incorporate strong encryption into Apache. Apache Stronghold could then be legally sold in the U.S. as well as non–U.S.jurisdictions.

Technically, there are several software platforms which could be used to create the market. I’m biased toward the ArsDigita Community System. It’s an open source (GPL) toolkit designed and maintained by the 250+ software engineers at ArsDigita. Extensive documentation is freely available online, and several universities (MIT, Stanford, Caltech, Carnegie Mellon, among others) train students to build Web sites using the ACS. ArsDigita also offers free one to three week training courses almost every month, at any number of locations in the U.S. and internationally. Although ACS “Classic” (the primary version supported by ArsDigita) is built on top of the proprietary Oracle database, it has been ported to PostgreSQL by the OpenACS team. Finally, the ACS has already been used to create a working bond market, (, a Web site for municipal bond traders.



Current challenges facing the open source community

Software completion bonds might help the open source market places, but why should the open source community as a whole care?

Most open source software companies don’t make money (yet)

Red Hat and VA Linux are two of the most prominent companies in the open source community. Both companies provide a great deal of support to the open source community, funding such projects as the Gnome desktop (Red Hat) and SourceForge (VA Linux). Unfortunately, although both Red Hat and VA Linux garnered large sums of venture capital, neither is currently profitable. According to Red Hat’s most recent 10–Q SEC filing, Red Hat has lost money in five of the past six years. VA Linux is on the Deathwatch at The failure of either Redhat or VA Linux would chill investment in open source companies.


Table 1: Overview of Red Hat and VA Linux.
Note: Data from each company’s SEC 10–Q filing.
Red HatTotal revenuesNet loss
31 August 1999$10,536,072$4,844,119
31 August 2000$18,493,389$15,712,873
VA Linux  
27 October 1999$14,848,000$14,955,000
27 October 2000$56,062,000$51,347,000


Of course, these companies are growing rapidly, and consequently, they’re investing a lot of money in infrastructure; both RedHat and VA Linux have purchased a number of other companies that will take time to integrate.

The basic business models that both companies offer are reasonable. For example, Red Hat hopes to make money selling services and support. Many proprietary companies derive most of their revenues from selling services, not from initial sales of the software. For example, according to Oracle’s August 31, 2000 10–Q filing, out of total revenues of $2,261,875,000, only 36 percent derived from initial sales of Oracle’s software — the rest came from services.

However, much of the initial development costs of Linux were paid for paid for by other individuals and organizations. To increase the desirability of Linux, both companies have invested and will likely invest more money to make Linux easier to use and increase the number of applications available. These companies would be able to achieve profitability faster if they could recoup more of their investment in Linux development.

Open source programs often lag behind closed source programs

Open source software applications often lag years behind their proprietary counterparts. PostgreSQL, for example, the best libré database, lacks outer joins, and didn’t get referential integrity constraints until late 1999. Proprietary databases had them years earlier. Mozilla is just barely reaching usability. Richard Stallman, perhaps the most influential pioneer in the free software community, recognized the dearth of open source alternatives in some areas:

“ … We are still working on a free replacement for ssh. People are working still on the free replacements for Microsoft Office. There are some free word processors. Whether they are good enough, I don’t know. I don’t think there is any free desktop publishing software yet, but there needs to be.” (Barr, 2000)

Here are some additional examples where open source offerings do not compare with closed source offerings:

  • Accounting software.
    To my knowledge, it wasn’t until September 2000 (with SQL–Ledger’s v. 1.2 release) that a feature complete open source accounting package for small– to medium–sized businesses existed.
  • Multimedia player.
    I’ve played around with a couple of open source media players. I could not get most of them to work, or they immediately crashed. When they did work, the image was small (and unscalable), and frames advanced in time measured in seconds.
  • Device drivers.
    According to an Evans Marketing Services survey of Linux developers, 66 percent complained about lack of device drivers for many kinds of hardware (Speedie, 2000).

New users (and often experienced users) often find open source software programs to be buggy and user–unfriendly

Isn’t code quality listed as one of open source’s virtues? Yes, and software that programmers use frequently for mission critical applications doesn’t often fail. For example, I last rebooted my Linux box 33 days ago. Xemacs has only crashed once on me in the past year.

But programmers pay less attention to code that’s used for less critical applications. For example, until the release of OpenOffice (formerly a closed source program) Gnumeric, was probably the best open source spreadsheet program. Yet Gnumeric crashed whenever I tried to print, and lacked many useful features relative to its commercial competitor.

Programmers often pay too little attention to ease of use as well. Here’s a typical comment from an experienced Windows user trying to install a Linux desktop:

“One does have to admit that for the neophyte Windows is far easier to use than a Linux/Gnome or Linux/KDE box. Theoretically, you throw a CD in, answer a few questions and seconds later are presented with a desktop. The last time I tried to install KDE2 on my laptop it was a festival of searching rpmfind for missing dependencies and when I finally had satisfied them and launched KDE … my screen blacked out and stayed that way. Mind you, eventually I was able to successfully install it, but at the cost of several hours and a lot of poking around. I am certainly not saying that Windows is superior to Linux in any way. What I am saying is that its usability is a prime factor in its success.” (Starchman, 2000)

As a Linux/Unix newbie, I remember how frustrated I got at how long it took me to figure out how to mount and read from a Zip drive, something that’s easy to do in Windows.

A lot of open source software is written by programmers for programmers, often for intrinsicly pleasurable reasons. Making software easy to use often requires doing work that programmers find boring — creating a GUI, making test cases, running user interface tests. Closed source companies induce programmers to do the boring work by paying them. Since many open source programmers aren’t directly paid for their work, bugs and usability barriers like those described above often prevent open source programs from becoming more widespread.

Some talented open source developers leave the community for better paying jobs at closed source companies

Salary depends on many factors including whether or not the programmer is developing for

  • a non–profit or for–profit organization;
  • internal use or for distribution;
  • a broad market or narrow vertical market; and,
  • an organization located in an area with high cost of living or low cost of living.

Salaries for those skilled in the use of open source technologies are high in general. According to a recent (June 2000) Datamation survey, the average open source developer earns $80,850/year and contracts out at $74.00/hour (Rogers, 2000). However there’s a distinction between getting paid to use an open source tool (e.g., keeping Sendmail up and running), and contributing to the development of that tool (e.g., submitting a patch to the Sendmail team.)

Historically, it appears some prominent open source programmers chose to live unusually frugal lifestyles, to be free to push the development of their software. For example, for 13 years, Richard Stallman lived out of his office at the MIT Artificial Intelligence Lab. Stallman has no children. In fact, he dismisses the desire for a house, car, or children as frivolous and expensive habits:

“ … I live cheaply. I’ve resisted acquiring the expensive habits that some other people pick up as soon as they get enough money to. You know, like houses and cars and children and boats and planes. Art collecting. People tend to think, ‘I have money now, let me look for some frivolous thing to blow it on.’ But my idea was, ‘I’m going to save this so that in the future I won’t have any worries about it.’ Living cheaply helps doing that. It also enabled me to decide what I was going to do with my life instead of having money decide for me.” (Barr, 2000)

Even in the present, some organizations that make important contributions to the development of open source software don’t pay very well. As of Fall 2000, the Free Software Foundation pays full–time programmers approximately $35,000/year. This is approximately a third of the going rate for programmers in the Boston area. Of course, the Free Software Foundation is a charity, and the programmers who work there receive intangible benefits (greater freedom to pursue their own initiatives, ego gratification, etc.) to compensate for the poor salary. Even so, although Stallman may personally regard children to be an “expensive habit”, I’m sure he recognizes that they are important to the happiness of many people. Therefore, since children are admittedly expensive to raise, the FSF would likely find it easier to attract highly skilled, experienced programmers if it could offer more competitive salaries.

For many open source software applications, there’s often no clear route for funding the direct development of the software. For example, the GIMP, an image editing program similar to Adobe Photoshop was originally developed by two college students, Peter Mattis and Spencer Kimball. However, neither programmer now works on open source software much anymore. Peter Mattis works for Inktomi; Spencer Kimball works for Delphi Structured Finance Corporation. Their departure dramatically slowed the development of the GIMP:

“Progress on the Gimp screeched to a halt when Spencer Kimball and Peter Mattis left college to take paying jobs. Gimp development resumed only slowly as new volunteers picked up where the UC Berkeley developers had left off. After 20 months, Gimp is more stable, but it still crashes and its Intelligent Scissors tool still doesn’t work quite right.” (HackVän, 1999)

If there had been a better way for the community of GIMP users to pay Kimball and Mattis directly for the development of the software, they may have been willing to stay a bit longer and finish the software.

Fighting bad laws will require a lot of money

Some open source/free software advocates argue that it doesn’t matter whether or not businesses can make money from open source software. They argue that free/open source software began as a hobbyist/academic pursuit, and it can be continued regardless of the profitability of companies supporting Linux. However, laws shape the kinds of environment that we live in, regardless of whether we’re making money or not.

As with any business, traditional companies lobby, both in court and in the legislature, for laws to protect their interests. Often the laws these companies advocate hinder open source software development, or are otherwise antithetical to the values of many members of the open source community. Among the legal defeats that the open source community has suffered:

Although not strictly related to open source software, many open source programmers are also sympathetic to efforts to oppose other efforts to restrict online freedoms, which include:

Hiring competent lawyers, lobbyists, and fundraisers to fight these laws will be expensive, and many supporters of laws damaging to the open source community have deep pockets. They include organizations such as the Recording Industry Association of America, Federal Bureau of Investigation, Business Software Alliance, Software and Information Industry Association, Disney Corporation, and the Microsoft Corporation.

Non–profit organizations that help defend our online freedoms raise their operating funds from companies and individuals who share values with them, e.g., open source companies and programmers. They include the Electronic Frontier Foundation, League for Programming Freedom, Free Software Foundation, American Civil Liberties Union, and Computer Professionals for Social Responsibility.

For example, John Gilmore, a cofounder of Cygnus Solutions, the first company to demonstrate that you could make a profit supporting open source software, is also cofounder of the Electronic Frontier Foundation. Gilmore, along with Dan Bernstein, instigated a lawsuit against the U.S. Department of Justice that led to the courts to rule that encryption export controls were an unconstitutional obstacle to free speech. Cygnus has provided support to a number of other activists in the fight for encryption freedoms in the U.S., such as providing meeting space for pro–encryption activists.

Cygnus was recently purchased by Red Hat, as was C2net software (distributors of Apache Stronghold, a market leader of secure Web servers). Recall that, at this writing, Red Hat has not made a profit in five of the past six years. If companies like Red Hat, and the individuals supported by them, become impoverished or go bankrupt, non–profits like EFF or the FSF will not be able to fight effectively for our online freedoms.

I don’t want to paint too bleak a picture; the free/open source movement has enjoyed a number of successes. To cite just a few examples:

  • IBM, Dell, HP, Sun and a number of other computer giants have begun to offer Linux services. Linux now ships pre–installed on six percent of all servers sold (Nguyen, 2000);
  • In October 2000, Sun released OpenOffice (an office productivity suite formerly known as Star Office) under a GPL license; and,
  • Lou Gerstner, IBM’s Chairman, recently announced that IBM would budget almost $1 billion for Linux investment in the year 2001 (Burke, 2000).

In the long run, I think that free/open source software will gradually displace most closed source software, and that companies like Red Hat, VA Linux, and Linuxcare will eventually become profitable (if perhaps not so profitable to justify their stratospheric IPOs). However, that day will arrive earlier if open source companies can recover more of the costs of the initial development of open source software.



What’s wrong with current open source software funding mechanisms

Cooperation may be defined as two or more individuals aiding each other for mutual gain. Cooperation can be contrasted with parasitism, in which one party benefits at the expense of the other.

There are many dimensions along which two or more people can cooperate, to varying degrees. For example, they can cooperate by sharing:

  • information, such as software code, directions to a grocery store, and gossip;
  • tangible goods, such as food, clothing, shelter, and money;
  • common goals, laws, moral and behavioral norms; and,
  • services, such as two neighbor’s agreeing to babysit each other’s children risk, via life insurance policies and charities.

For much of history, humans lived in small tribes of 50–100 people. Individuals who cooperated with each other enjoyed a number of benefits. If one hunter returned empty handed, other, more successful hunters would share with him. The successful hunters expected, of course, that the hungry hunter would reciprocate in the future, when their own hunts did not go so well. Groups of cooperating individuals could also help each other build shelter, or fight off marauders.

The community of computer science and artificial intelligence researchers in 1971 appears to have been a modern version of this tribal environment:

“I went to MIT in 1971, and I became part of a community of people who shared software. This community went all the way back to the beginning of computation. It included various high–powered computer science departments, and sometimes computer companies — people who would write programs and share them with the whole community, and people would improve them. In fact, at MIT we entirely used software that was part of this community. We did not make big fuss over whether it was free, but if anyone wanted a copy, they could have it.” (Bennahum, 1996)

In such small communities, thieves, liars, and goldbrickers could easily be identified. Such scofflaws and moochers faced boycott and ostracism. In early societies, these punishments were much more effective than they are today. Ostracism from the group meant loss of access to potential mates and a much greater risk of predation and starvation. Therefore, the offspring of individuals who felt a desire to cooperate with others were more likely to survive to reproduce (Wright, 1994).

An innate desire to cooperate survives to this day, even though the environmental conditions in which this desire evolved have changed. With the invention of the stirrup, followed by the advent of horse drawn carriages, cars, sailing ships, and airplanes, humans more easily moved out of their communities. Social pressures that tended to keep non–cooperative individuals in check, such as peer disapproval, ostracism, and boycott became less effective; an offending individual just moved to a new town. New social mechanisms evolved to combat anonymous defectors, such as contract law, credit bureaus, and certification exams (Shearmur and Klein, 1997; Klein, 2000).

The GNU General Public License (GPL) is another mechanism for enforcing cooperation in modern society. One of the great benefits of using an open source licenses like the GPL is that it encourages people who may separated by time and distance, who may never even know of each others existence, to cooperate with each other. However, the GPL enforces cooperation only along a single dimension — code availability. In doing so, the GPL makes it difficult to exclude non–cooperators along another dimension — funding the development of the software in the first place. As a result, open source software covered by the GPL falls into class of goods economists label “public goods”. Two characteristics separate public goods from private goods. Public goods are:

  • non–rivalrous, which means that my enjoyment of the good does not interfere with my neighbor’s enjoyment of the same good. Clean air is a non–rivalrous good; my breathing clean air doesn’t normally interfere with my neighbor’s ability to breathe clean air. By contrast, a chocolate chip cookie is a “rivalrous” good; if I eat a cookie, my neighbor can’t enjoy the same cookie.
  • non–excludable, which means that non–contributors cannot easily be excluded from enjoying the good.

The classical example of a public good is national defense. To illustrate, let’s examine the problems faced by the tiny island nation of Economia, population 1,000. Few enemies threaten Economia, and the nation’s economic advisor (Vinnie Greenspan) estimates that it would cost a mere $1,000,000 annually to provide an adequate national defense (consisting primarily of a fleet of small gunboats).

The president of Economia (Sally Boxer) calls for each Economia citizen to give $1,000 annually to pay for Economia’s defense.

Now consider the perspective of the average Economian, Moe Sizlak. Before writing his check, Moe might reason as follows:

“The patrol boats can’t protect the Economians who helped pay, without also protecting individuals who did not pay.

Either the other 999 Economians will raise $1,000,000 to pay for the gunboats, or they aren’t.

Suppose they do raise enough. Then the gunboats will be funded whether I pay or not, so I might as well not pay. That way, I will enjoy the gunboat’s protection, yet still have enough to pay for a new satellite dish.

On the other hand, suppose they don’t raise enough. It’s unlikely that the gunboats will be funded even if I do contribute, so there’s no point in throwing my money away. So either way, regardless of what others do, it’s in my interest not to contribute. So I won’t.”

Moe puts his checkbook away.

However, the other 999 Economians reason the same way, and the gunboats never get funded. Six months later, in the middle of the night, a flotilla of war canoes from the neighboring island of Postmodernista lands and overthrows the Economian government.

The sad tale of the Economians illustrates two barriers to the provision of public goods. First, Moe would enjoy the gunboat’s protection even if he didn’t help pay, so he succumbed to the temptation to “free ride” on the efforts of others. Although it was in everyone’s collective interest to cooperate, it was in every individual interest to defect. Since it is individuals, not collectives, who make decisions, the result is that no one cooperates and the public good — the gunboats — was not funded. Second, Moe could not be “assured” that the gunboats would be provided even if he did pay. As a result of these characteristics, many economists argue that public goods will be underprovided, unless government steps in and forces everyone to pay for them.

Open source software suffers from the same problems. For example, suppose I want to run Windows software on Linux. I could donate $100 to the Wine Project, an effort to re–implement the Windows API on Linux. But why donate? If I wait long enough, someone else may provide the funds necessary to complete the project.

In addition, suppose that I do donate $100 to the Wine Project. My contribution, though helpful, will not by itself determine whether or not the project ultimately succeeds. The project may die, or languish, to the point that I would’ve valued investing my money in some other good, had I known that it was going to take so long for the Wine Project to bear fruit. I have no assurance that spending $100 to support Wine will result in useful software. See Brubaker (1975), Schmidtz (1987), Demsetz (1970), and Long (1984) for more extended discussion of the free rider and assurance problems involved in the voluntary provision of public goods.



How can the free rider and assurance problems be solved?

Solution #1: Close the source code

Closed source software companies solve the excludability problem by using copyright laws to prosecute individuals who use their software without paying for it. More recently, since U.S. courts began to enforce software patents in the mid–1980s, companies have also begun to use them to protect their investment in software.

To be sure, many people still free ride, albeit illegally. The Software and Information Industry Alliance alleges that one in every three business software applications in use during 1999 was pirated (Beruk, 2000). For example, many business startups probably do not strictly account for every copy of Microsoft Word running on their computers. However, the costs of a potential prosecution are high enough that most individuals and businesses pay the licensing fees.

As for the assurance problem, potential buyers of software want to know a) will the software be finished, and b) will the software meet my needs? Closed source software makers solve the first problem by investing the money to complete the software before they offer it for sale. They solve the second assurance problem by offering time–limited demonstration copies or “cripple” the software in some way, such as turning off the ability to print.

The disadvantages of completely closed source code have been discuss at length elsewhere. Here I will focus on two free/closed source hybrid models. One hybrid model is to keep the software closed for a while, then release it as open source once you’ve recaptured some of the costs of development; Eric Raymond calls this the “free the future” model. This is the de facto model followed by several open source projects; Star Division/StarOffice, Netscape/Netscape Navigator and Inprise/Interbase were closed source products for many years. However, competing closed source products captured so much market share that the owners of these programs decided that the best way to compete would be to open source the code.

Another variation of this model is that followed by Peter L. Deutsch, author of the Postscript interpreter, Ghostscript. Deutsch distributes the latest version of Ghostscript under the Aladdin Free Public License (AFPL). According to the AFPL, the software may be downloaded and used without cost for personal or internal use, but may not be incorporated into commercial software without payment. Older versions of Ghostscript are released under the GPL. The GPL versions are generally a year (two versions) behind the latest version.

Deutsch reasoned:

“I put a lot of thought into what I saw as the flaw in the GNU license when formulating the Aladdin license. The essence of the Aladdin license I can describe in one sentence, and it is very much about social contracts. Namely, if you are willing to play by what I think are the 1960s rules, then the Aladdin license gives you exactly the same rights and benefits as the GPL: it’s free to use, it’s free to copy, and you are free to modify it. All of those things. In a nutshell, I see the 1960s rules, or the cooperative rules, this way: ‘everybody contributes, so everybody benefits.’ Unlike the GPL, I make a very solid distinction between distribution as part of a commercial endeavor and distribution not as part of a commercial endeavor. Distribution not as part of a commercial endeavor is covered by essentially the GPL rules, while distribution in any commercial endeavor is not permitted by the Aladdin Free Public License. The philosophical weight of this is that if you want to play by cooperative rules, you get the benefits of Aladdin’s work within the context of those rules. If you are not playing by the cooperative rules, then it’s going to cost you something to have the rights to get the value from Aladdin software.” (HackVän, 1998)

The “free the future” model solves the free–rider problem to some extent, and it’s demonstrably successful, as Deutsch’s example indicates. Unfortunately, both the Netscape variation and the Deutsch variation of the “free the future” model have some disadvantages. Closing the source completely, as with the Netscape variation, prevents outsiders from critiquing the code design at the beginning of the project, when outside criticism will be most helpful. When the code is eventually released, it will likely require a lot of clean up and redesign, as both the Mozilla and OpenOffice projects demonstrate.

Another disadvantage, is that both the Netscape variation and the Deutsch variation prevent the code from incorporating, and being incorporated by, other GPL’d software (or at least until code owner releases the GPL version). This limits one of the principal benefits of free software, the ability to re–use existing software.

Solution #2: Derive support from government agencies (or tax-supported bodies)

Historically, a great deal of open source software development was initially funded in just this way. Larry Wall, author of Perl, was originally funded by the U.S. National Security Administration (NSA) as part of the “Blacker” project (Wall, 1999). Both Mosaic and Apache began as projects funded by the National Center for Supercomputing Applications (NCSA) at the University of Illinois. CERN (European Organization for Nuclear Research or Organisation Européenne pour la Recherche Nucléaire), a tax–subsidized European particle physics research lab, paid the salary of Tim Berners–Lee while he developed the protocols behind the World Wide Web. And U.S. Department of Defense (DOD) grants paid for the equipment that Richard Stallman used to write the GNU tools that would later make up the bulk of the GNU/Linux operating system.

Some open source advocates, such as Richard Stallman, support continued tax–supported subsidies for open source software development. Although tax–subsidized software development solves one free–rider problem (paying for the development of the software), it has a number of disadvantages [4].

Solution #3: Fund development from profits on the sale auxiliary goods and services

There are excellent summaries in the literature that provide reasons why companies have funded open source software development in the past, and might wish to fund open source projects in the future; see Behlendorf (1999), Hecker (2000), and Raymond (1999). At least two companies have profitably funded substantial open source development from service income. Cygnus Solutions was probably the first company, and to date, most profitable company to have followed this model. Cygnus was purchased by Red Hat in November, 1999 for $675 million. Cygnus developed and sold support for GCC, the Gnu C compiler.

Other examples:

  • ArsDigita, without venture capital, has grown to at least $20 million/year in revenues by selling Web development services based on their GPL’d ArsDigita Community System toolkit;
  • O’Reilly profitably publishes technical manuals for many open source programs. They make enough money selling books documenting the Perl language that they hired Larry Wall to work fulltime on the language’s continued development; and,
  • IBM apparently believes that Linux will enhance its hardware and service sales enough to budget almost $1 billion for Linux support in 2001.

Income from the sale of auxiliary goods and services can therefore demonstrably support open source development. However, there is an inherent tension between creating software that’s robust and easy to use and deriving an income from selling services. This hasn’t been as big a problem as one might predict because a) if the software is too hard to use or buggy, no one will use it, regardless of cost, and b) by making the software easy to use and robust, a company may lose service income from that particular piece of software, but increase its income by expanding the range of software that they provide services for.

Some companies pay for open source development in order to reduce their cost of operations or cost of goods sold. For example, both the Apache Web server and X Windows system are maintained by consortiums of businesses and universities (Apache Group and X Consortium respectively). The consortium members find that the reduced costs, greater reliability, and flexibility that result from open source development is great enough to tolerate free riders. VA Linux, Compaq, IBM and a number of other companies fall into this category.

Even so, both service and hardware companies have benefited from tax–subsidized development; they may be only able to profitably offer services because had they did not have to pay for the initial development themselves. In any case, I’m sure these companies would like to recapture more of the costs involved in the development of the software in the first place.

Solution #4: Use a mechanism like the current implementations of SourceXchange or CoSource

The biggest problem with CoSource and SourceXchange is that they encourage open source programmers to compete against each other, instead of cooperating with each other. CoSource and SourceXchange also aren’t as flexible as a bond market could be, in terms of how projects are organized.

Solution #5: Ignore it

Charitable organizations, such as the Free Software Foundation, pay for some open source software development. Universities, to the extent that their funds come from alumni and other donors, also fall into the charity category.

Many programmers contribute to open source projects out of love of programming, and a desire to reciprocate for contributions they enjoyed from other programmers. In additional, many important programs were originally developed by university students. Linux began as Linux Torvald’s hobby while he was a second year graduate student. To be sure, such programmers can benefit monetarily from programming they do primarily for fun. For example, it’s often difficult, expensive, and time–consuming for employers to identify programmers with good programming skills. A programmer with a portfolio of contributions to popular open source programs makes his skills more transparent to potential employers. Contributing to an open source project therefore serves as an advertisement for his skills.

Although underpaid charity employees and students have produced some fine software, it does seems to me that software funded by donated time and money alone will only be able to meet a small part of the total demand for software.



What would an ideal mechanism for funding open source software look like?

Having explored some of the problems with current methods for funding open source software, here’s a list of the characteristics that an ideal open source funding mechanism should have:

  • Economic incentives should encourage cooperation rather than competition. It should encourage programmers to share information, code, and documentation as soon as possible. It should discourage essentially redundant efforts (e.g., 150+ text editors on SourceForge);
  • It should discourage individuals from free–riding, using and benefiting from the software without supporting the development of the software with money, advertising, documentation, or other forms of assistance;
  • Proportionate compensation. All contributors to the software (sales staff, documentation authors, managers) should be compensated roughly in proportion to their contribution to the software;
  • Decentralized. No single “grant body” should be able to decide who should and should not get funded;
  • Low transaction costs, both financial and cognitive. Those who want to purchase software should be able to do so by submitting their credit card information once;
  • Voluntary. It should not depend on tax subsidies;
  • Timely. It should encourage software developers to work quickly;
  • Compatible with the GPL, BSD, and other open source licenses. This means that the software should be able to immediately incorporate, and be incorporated by, other GPL programs; and,
  • Inexpensive. The transaction costs should be low enough to make $500–$1,000 projects worthwhile.

In theory at least, I believe that software completion bonds meet all of the criteria listed above as well or better than any of the existing mechanisms for funding the initial development of open source software. Obviously, however, the true test of the idea is a working bond market involving real money and a real project. End of article


About the author

Chris Rasch is working on open source Web development with the ArsDigita Community System.



Several previous ideas and authors influenced my thinking about software completion bonds. I’ve listed the one’s that I’m aware of below (if you know of someone else who came up similar ideas independently, please let me know):

Many thanks to Jean Camp and Mike Linksvayer for their comments and criticisms. Of course, any errors or omissions are my own.



1. If you’re unfamiliar with free/open source software, see my essay A brief history of the free/open source software movement. For a review of the advantages that free/open source software offers, see What’s right with open source software? Please feel free to post any questions or comments you may have in my discussion forum.

2. See the Acknowledgements, especially Grigg and Petro (1997).

3. Kevin T. Van Wart, “Preemption And The Commodity Exchange Act,” 58 Chi.–Kent. L. Rev. 657, 720 (1982). See also, American Agriculture Movement, Inc. v. The Board of Trade of the City of Chicago, 977 F.2d 1147, 1157 (7th Cir., 1992) “[S]tate laws specifically directed towards the futures markets naturally operate in an arena preempted by the [Commodity Exchange Act].”

4. Government funding is a large enough issue, that I’ve written a separate sidebar discussing the disadvantages of tax–subsidized open source software development; see



Robert Axelrod, 1984. The Evolution of Cooperation. New York: Basic Books.

Joe Barr, 2000. “An Interview with Richard Stallman,” LinuxWorld (10 February), at, accessed 22 November 2000.

Brian Behlendorf, 1999. “Open Source as a Business Strategy,” In: C. DiBona, S. Ockman, and M. Stone (editors). Open Sources: Voices from the Open Source Revolution. Sebastopol, Calif.: O’Reilly & Associates, and at, accessed 26 December 2000.

Tom W. Bell, 1999. “Internet Gambling: Popular, Inexorable, and (Eventually) Legal,” Cato Policy Analysis, number 336 (8 March), at, accessed 29 December 2000.

Tom W. Bell, 1997. “Idea Futures: Making the Marketplace of Ideas Work,” at, accessed 1 January 2000.

David S. Bennahum, 1996. “Interview with Richard Stallman,” Meme 2.04, at, accessed 3 June 2001.

Peter Beruk, 2000. “Five years: $59.2 billion lost,” press release of the Software and Information Industry Association (24 May), at, accessed 3 January 2001.

Earl R. Brubaker, 1975. “Free Ride, Free Revelation, or Golden Rule?” Journal of Law and Economics, volume 18, number 1 (April), pp. 147–161.

S. Burke, 2000. “Gerstner: IBM To Place Billion–Dollar Bet Linux Could Overtake NT,” LinuxToday (13 December), at, accessed 25 December 2000.

Harold Demsetz, 1970. “The Private Production of Public Goods,” Journal of Law and Economics, volumes 13, number 2 (October), pp. 293–306.

Ian Grigg and Christopher C. Petro, 1997. “Using Electronic Markets to Achieve Efficient Task Distribution,” at, accessed 4 January 2000.

Robin D. Gross, 2000. “DMCA Takes Full Effect - Millions of Americans Become Criminals,” Effector, volume 13, number 11 (13 December), at, accessed 29 December 2000.

Stig HackVän, 1999. “Where did Spenceer Kimball and Peter Mattis go?” LinuxWorld (January), at; quote is from Hackvan’s Web site at, accessed 20 December 2000.

Stig HackVän, 1998. “Interview with L. Peter Deutsch,” Usenix, at, accessed 30 December 2000.

Frank Hecker, 2000. “Setting Up Shop: The Business of Open Source Software,” at, accessed 29 December 2000.

Ronnie Horesh, 2000. “Trade and Agriculture: the Unimportance of Being Rational New Zealand Orchardist,” at, accessed 20 December 2000.

Ronnie Horesh, 1992. “Injecting market incentives into the solution of social problems,” at, accessed 1 January 2000.

Cem Kaner, 2000. “Why you should oppose UCITA,” Computer Lawyer, volume 5, number 20 (May), at, accessed 20 December 2000.

Denis S. Karjala, 2000. “What Are The Issues In Copyright Term Extension — And What Happened?” at, accessed 20 December 2000.

John Kelsey and Bruce Schneier, 1999. “The Street Performer Protocol and Digital Copyrights,” First Monday, volume 4, number 6 (June), at, accessed 4 January 2000.

Daniel B. Klein, 2000. “Credit Information Reporting: Why Free Speech is Vital to Social Accountability and Consumer Opportunity,” at, accessed 20 December 2000.

Roderick T. Long, 1994. “Defending a Free Nation,” Formulations (Winter), at, accessed 4 January 2000.

Hoang Nguyen, 2000. “IDC Declares Linux Is Red Hot in the Server Market,” International Data Corporation (10 April), at, accessed 20 December 2000.

Eric Raymond, 1999. “The Magic Cauldron,” at, accessed 29 December 2000.

Reno vs. ACLU (1997), at, accessed 27 December 2000.

Zach Rogers, 2000. “IT Salary Tracker: Open source professionals,” Earthweb (1 August), at, accessed 1 January 2001.

David Schmidtz, 1987. “Contracts and Public Goods,” Harvard Journal of Law and Public Policy, volume 10 (Spring), pp. 475–503.

Jeremy Shearmur and Daniel B. Klein, 1997. “Good Conduct in the Great Society: Adam Smith and the Role of Reputation,” In: Daniel B. Klein (editor). Reputation: Studies in the Voluntary Elicitation of Good Conduct. Ann Arbor: University of Michigan Press, pp. 29–45, and at, accessed 20 December 2000.

Seth Shulman, 2000. “Software Patents Tangle the Web,” Technology Review (March/April), at, accessed 26 December 2000.

Anne Speedie, 2000. “What are Linux Developers Thinking?!” Wide Open News (27 March), at

G. Starchman, 2000. “RE: Open Source for Windows,” Free Software Business (18 December), at, accessed 20 December 2000.

Larry Wall, 1999. “Uncultured Perl,” Linux Magazine (October), at, accessed 29 December 2000.

Wired, 2000. “‘Carnivore’ Eats Your Privacy,” Wired (11 July), at,1283,37503,00.html, accessed 29 December 2000.

Robert Wright, 1994. The Moral Animal: The New Science of Evolutionary Psychology. New York: Pantheon, pp. 189–209.


Editorial history

Paper received 23 April 2001; accepted 28 May 2001.

Copyright © 2001, First Monday.

Copyright © 2001, Chris Rasch.

The Wall Street Performer Protocol: Using Software Completion Bonds To Fund Open Source Software Development
by Chris Rasch
First Monday, Volume 6, Number 6 - 4 June 2001

A Great Cities Initiative of the University of Illinois at Chicago University Library.

© First Monday, 1995-2017. ISSN 1396-0466.