I think we need more crowdfunding projects for open source software! And here is one, for example: Yorba, the guys behind Shotwell, are currently running an Indigogo campaign to fund the development of their open source email client Geary. As of this writing, they have raised about \$50,000 of their \$100,000 goal and the rush of the last 24 hours has just begun. So, please head over there now and consider making a dontation. You can always come back here to read on!

Why Funding Open Source Software is Difficult on Kickstarter

Crowdfunding has taken off, for physical goods as well as for software-related products like games. So why do we see so few open source project take advantage of crowdfunding? In fact, Kickstarter is based on the Street Performer Protocol (SPP), a method for raising funds that was originally intended as a model for financing open source software, and that had some early successes such as making Blender open source. Could it be that rewards-based crowdfunding as on Kickstarter simply does not work as well for open source software?

There is one subtle difference between open source and closed source projects on Kickstarter, and this difference may be crucial: The successful game projects on Kickstarter have no intention of giving away their core product for free. This makes pledges pre-sales instead of donations. Open source projects on the other hand announce right away that their product is going to be free. Does this influence backer behavior?

It is certainly true that many crowdfunding campaigns are successful because some altruistic backers pledge huge amounts of money to the project - much more than they would need to pledge to get a copy of the product for themselves. But projects rarely can be funded through such altruistic contributions alone. Take a look at Shrouds of the Avatar, for example: the large majority of backers pledged the minimum amount required to receive a copy of the game. These backers are obviously price conscious and don’t pledge more than they have to. I will call these backers rational, in the economic sense. This means that they are self-interested and act to maximize their own welfare.

This leads me to the following working hypothesis:

Crowdfunding projects need contributions from both rational and altruistic backers to raise large amounts of money.

This would explain why open source projects appear (so far) to be less successful than other creative projects at raising money via crowdfunding: Because open source software is (going to be) free, rational backers don’t pledge anything.

In fact, there is research in the economics literature on the optimal behavior of an entirely rational backer who is faced with the decision of backing an open source project. The amount he or she is willing to pledge is determined by the probability of their pledge being pivotal and getting the project funded. Backers correctly observe that this probability decreases with the total number of backers interested in a project. A consequence is that - if all backers were rational - the amount of money open source projects can expect to raise grows only proportional to the square root of the number of people interested in the project. In contrast, the amount a closed source project can raise grows linearly in the number of people interested in the project. This can quickly lead to a difference of several orders of magnitude!

(Now, before anyone gets a wrong impression: I do not think that people behave entirely rationally or that they should behave rationally. It is vital for our society that people act out of altruistic motives. And it is great that crowdfunding has found a way to get altruism to scale, so that we can make great things happen. I think we should look for more ways in which we can integrate altruism into our economic activities. All I am saying is that there is a reason that our entire economic system is built on the assumption that people tend to behave rationally. Our goal should be to find economic models that incorporate both altruistic and rational motives.)

Fund I/O as a Model for Funding Open Source Software

Fund I/O is a new crowdfunding model based on the Average Cost Threshold Protocol (ACTP). (If you are not yet familiar with Fund I/O, you may want to check out this example before continuing here.) When I developed the ACTP, one of my goals was to find a crowdfunding model that would work for open source software. And in many ways Fund I/O achieves precisely that:

• Most importantly, Fund I/O gets rational backers to reveal how much they would truly be willing to pay for the software.
• This allows open source project to raise as much money as closed source projects.
• Moreover a project can raise more money on Fund I/O than using the Kickstarter model, because it lets the market determine the optimal price of the product.
• At the same time, Fund I/O still allows altruistic backers to dontate as much as they want to the project. (This requires Fund I/O to be used with the option of allowing each backer to set their own minimum price level.)
• Finally, Fund I/O provides a clear path towards the relase of the software product under an open source license.

Now, you may have noticed that I did not quite say Fund I/O “works” for open source software. In fact, I do not think the Fund I/O model gives me everything I would personally want from an open source funding model. However, I do think it works much better than anything that is currently out there. So let me first explain in what way it does work for open source software. In the next section I will then go on to explain the limitations I see.

Fund I/O works great for open source projects if your project meets the following assumptions:

• Your goal is to finance the creation of version 1.0 - no more.
• You are willing to release your software under a closed license at first.

Then you just run through the three phases of the Fund I/O mechanism (with individual minimal price levels) and at the end:

• you have completed the software you wanted to write,
• you have released the software and its source code under an open source license, free for everyone to use and modify,
• your costs were covered right from the start and
• you even made a certain profit that you can determine in advance.

The release under an open source license happens if and only if there is enough altruism among your customers to finance the costs of production through voluntary donations. However, this absolutely not the same as simply using the SPP. First of all, your project gets made if there is enough rational interest in your software. It just won’t be open sourced unless there is enough altruistic interest. Second, Fund I/O achieves a smooth transition from the state where there are few users who would need to donate very large amounts to the state where there are many users who need to donate just a couple of dollars. This lessens the burden on any individual donor considerably. Moreover, the donation is a sunk cost for the customer: donating means forgoing future refunds instead of paying money now. All of these factors make it much easier to gather the required donations, than using the SPP, even if Fund I/O is used with individual minimal price levels. If a fixed minimal price level is used for everyone, then gathering the required donations gets easier still.

Caveats

Now, I believe the above could work great for developing, say, an open source game. But for open source software I see a couple of caveats.

First of all, the user base of the software has to be willing to use closed source software during the second phase of the protocol. If a substantial number of users will never run anything but free software, then you are of course out of luck. I do not think this will be a problem; it was not a problem for Light Table during its crowdfunding campaign.

Second, it has to be reasonable to make the software non-free during the second phase. This means that the software is for sale and according to the license users are not allowed to pass copies of the software along to their friends. This is a stronger restriction than just not releasing the source code and may turn off more of the free software crowd. More importantly, this limits viral marketing effects during the crowdfunding and sales phases. People have to buy the product to try it out. (Even though a demo could certainly be offered.)

Of course the whole point of Fund I/O is that because of the refund mechanism, there is less of a disincentive to buying than in a classical sales context. In particular, if a customer sets their minimal price level to zero, then they get a full refund in case the software is released as open source. But in a world where many people expect application software (as opposed to games) to be free, this may be a hurdle. I’d be optimistic and say that the compromise of making software non-free for a limited amount of time, according to a transparent mechanism, in order to cover the costs of development is convincing enough to assuage these concerns.

Finally, and most importantly from my point of view, software requires maintenance. Application software needs to be developed continually. A game may be “done” after the 7th patch or so, but application software never is. If the only goal is to fund the creation of a version 1.0, then this is not a problem. But what if you are looking for a way to finance the development of open source software throughout its entire lifecycle?

An obvious modification to Fund I/O for financing several consecutive versions would be to run a new campaign for each major version. The mechanism could easily be adjusted to make a part of the revenues from the version 2.0 sales refunds for version 1.0. And once 1.0 is free, buyers/backers of subsequent versions could stop paying refunds to version 1.0 owners. The problems I see with this are therefore not theoretical, but practical in nature. The company developing the software would have to maintain several versions of the software side-by-side, they would have to backport security patches and provide support, and they would have to finance these activities from their version 2.0 revenues. While all of these concerns appear in commercial (and open source) software development anyway, they are exacerbated by keeping different versions under different licenses around - just because of the funding scheme.

Ultimately, it will depend on the particular project which of these considerations are relevant, and which variant of Fund I/O makes the best fit. Personally, I view Fund I/O as a toolbox that can be tailored to fit many different needs.

Conclusion

I hope to have convinced you that crowdfunding open source software is possible at much bigger scale than we have seen so far. What we have to do to make this happen is to find a crowdfunding model that takes the backers’ diverse patterns of economic behavior into account. I think Fund I/O is a step in the right direction, but can certainly be improved upon with regard to funding open source software.

What do you think would be the challenges when applying Fund I/O to open source software? How would you modify Fund I/O to make it more applicable to open source software? Comments and questions are welcome!