Tragedy of the Commons and open source projects

The tragedy of the commons is "the depletion of a shared resource by individuals, acting independently and rationally according to each one's self-interest, despite their understanding that depleting the common resource is contrary to their long-term best interests." (from Wikipedia). The tragedy exists because of the asymmetry between costs and benefits to individuals using a shared resource: the advantage goes directly to the individual, while disadvantage is shared among all users of the resource. One popular example of the tragedy is a group of herders sharing a common parcel of land with each herder benefiting from putting a new cow it acquires on to the land (thus gaining direct advantage), even if the quality of the land is damaged as the result (with the disadvantage being equally shared by all participants).

What does it have to do with open-source projects? I have been recently running a small experiment to see how many people may be willing/interested to pay what they want for an open-source project (a Lua IDE; the payment/support page is here). This is similar to directly benefiting from using a shared resource, with the provider of the resource bearing the main cost. Adding more and more users increases this cost (which manifests itself in more opened issues, handling more corner cases, testing on multiple platforms, questions to answer, requests for documentation and new features, and so on), with each user directly benefiting from everything that goes into the resource. If the cost is not shared by the users (by contributing patches and documentation, answering user questions, and providing financial support), over-exploitation of the resource is inevitable until the resource is no longer able to support itself and is gone.

One obvious response to that is that it's not a problem for an open-source project; if the current author/team is not interested or is not able to continue with the project there will be someone else to continue working on it if the project is useful to other people. While this is true (and indeed something similar happened to another open-source project I worked on), this doesn't create a sustainable model for the current provider of the resource.

Potential solutions to commons problems

The original essay by Garrett Hardin that explored the tragedy discusses potential solutions to commons problems: privatization, polluter pays, and regulation. Extending the analogy to open source projects, privatization would mean going closed source or at least dual license (free for personal/educational use with a commercial license for everything else), polluter pays may mean charging those groups that require more sophisticated features (like code refactoring or profiling in my case), and regulation may mean limiting access to the compiled bundle to those who pay, while still maintaining access to the source code for those who may be willing to do the work themselves.

Hardin considers these solutions and categorizes them as the "enclosure" of commons: common resources with unregulated access are (historically) being changed to systems in which commons are "enclosed" and become subject of more and more regulated use and controlled access. There is another option -- education -- that Hardin mentions only in passing: "Education can counteract the natural tendency to do the wrong thing, but the inexorable succession of generations requires that the basis for this knowledge be constantly refreshed."

Early results of the experiment

What are the results of my experiment? This is what I have to report so far: $109 from 6 payments after approximately 145 downloads in 4 days. The average payment is $18, which is a good number, but the response rate is about 4% (with $0.75 being average per download; the number is higher if we only count returning users, which is around 40%). It may have something to do with using Google Wallet as the payment provider (as I received more in payments in one day twelve hours through Amazon Payments, than in one week four days using Google Wallet), but I couldn't come to an agreement with Amazon on whether pay-what-you-want for an open-source project is the same as donation, so I can't continue using Amazon Payments. [updated the duration to exclude the time when payments were disabled on the page.]

What would the ideal situation be? Every user pays what he or she deems to be a fair value of the product to them. Hardin argues (the paper is only five pages long and is well worth reading) against relying on conscience suggesting that free riders will outnumber and outrun those who are more altruistic: "Conscience is self-eliminating" in his own words.

Options for financial support (other than direct payment)

Given that my naive altruistic expectations go against perfectly rational choices that people make (why pay if it is available for free?), what are other options?

  1. Paying for support. The product is free, but the support is not. This may be combined with consulting services around the same product. Unfortunately, this is not an option for a Lua IDE.
  2. Paying for features. Most of the product is free, but some features are distributed under different licenses. Note that this is a mini tragedy of the commons: I would want to share refactoring and profiling with everyone, but given the choice, I may decide to take those functions private, thus depriving most users of access to them. As the result, instead of paying, let's say, $10 for the features if everyone pays, you end up paying $50 (if you need those features) as only few users pay.
  3. Corporate sponsorship. It may be in the form of a company paying salary to open source developers (for example, Sierra Wireless), or companies directly supporting projects (like LuaJIT).
  4. Paying for bugs/features. Users paying a small fee if they need a particular feature added or a bug fixed (sort of like priority queue). It may be even per-commit payment, but this runs into the issue of keeping track of various features in various branches. This is different from having access to a private branch and may simply mean re-prioritization of a fix/feature with everyone else getting access to it for free.
  5. Bonus content with a payment. This is used by sites like HumbleBundle that provide additional content as "pay more than average/X and unlock these games/books".
  6. Nagging screens and coercion into paying. This is used by many programs from XChat for Windows to SublimeText 2. Coercion may be considered too strong of a word in this context, but this is the same terminology as was used by Hardin in the essay: "We institute and (grumblingly) support taxes and other coercive devices to escape the horror of the commons."
  7. Ads. This can be considered a form of pollution with users paying to avoid it or a form of tax on users that takes their screen space (with advertisers picking a tab).
  8. Premium branch. This is something suggested by Zed Shaw to offer restricted access to some of the branches that include a premium set of features for a project. Users are paying for (early) access to these features.
  9. Academic research. A research grant to answer an interesting research question with your project.
  10. Gittip. This is a service around developers paying other developers on a recurring basis. The main idea is to support someone who does a good thing for the community. The model calls for a large number of small payments, but it may be difficult to get many contributions if you are not already well known.
  11. Crowdfunding before development. Kickstarter and Indiegogo are two popular options. In my case, I have considered adding interesting features that may take several months to implement and it would help to potentially have funding from interested users available before the development is done in return for early access or licenses to those features.
  12. Cash star on GitHub. This is something I'd like to see implemented on GitHub. GitHub used to provide integration with Pledgie, but I'm looking for something more simple and more powerful. It is in some ways similar to Gittip, but around projects, rather than people. Having a cash star would trigger a transfer of, let's say $10 on a monthly basis between star giver and star receiver accounts (for as long as the star is there). If I no longer care about the project, there is no reason for me to keep the star granted. This option also has an advantage of providing support for those projects that your own project uses or depends on.

I'm considering options 2 and 5 and exploring 3. Some of the options (specifically 4, 6, and 7) are simply not acceptable to me for this product. I'm still hoping that maybe with enough exposure there will be a sufficient number of altruistic customers paying for the product they enjoy to use.

Note an interesting observation that Hardin presents as an inevitable result of the tragedy: "Freedom in a commons brings ruin to all." The only way to avoid the tragedy is to limit freedom in one way or another to extract payments that balance advantages with disadvantages.

TL;DR: We would all have more freedom in using common resources (OSS being one example) if only we could altruistically pay fair value of using those resources when asked.

[Updated 10/31/2012] Added academic research as an option.

[Updated 10/31/2012] I found a discussion from two years ago about funding Clojure that discusses options for funding of open-source projects in great detail (also related discussion on reddit).

[Updated 11/02/2012] Removed expectations that didn't look right in the context.

You should get a copy of my slick ZeroBrane Studio IDE and follow me on twitter here.

14 Comments

Hi Paul, Good article, I had a couple of things to add to that so I put them as a blog post here http://howto.oz-apps.com/2012/11/opinion-opensource-projects-funding.html

cheers,

Jayant

I think feature level crowdfunding is the answer. People are much more willing to donate if their donations are used for the specific feature they want implemented, instead of funding the whole project.

So a project would list all the features which can be implemented, with a price meaning the feature will be done if the given price is collected from donations. When the feature is done it will be accessible to everyone.

So it's voting for features with money. Those who want a feature implemented quickly would pay for it, because the need it and others would also benefit from this. Everyone would benefit from it, because different people would sponsor different features and all these features would be available for everyone.

I think this is the future. Open source crowdfunding with targeted donations.

OK why don't you start by telling everyone how much you donated to: gcc Lua wxLua wxWidgets Estrela LuaFileSystem LuaSocket ZMQ MojoShader MetaLua luainspect keplerproject LuaSec

@Disgusted, this is precisely my point. I want to be able to do that; this is one of the reasons I suggested "cash star" on github that allows me to support the projects my project depends on. And I've explicitly said that there is a variety of ways to support a project by contributing patches and documentation, answering user questions, and providing financial support. Many of these projects don't even give me a way to donate and to some projects I already contributed in the form of patches and answering questions.

"this is precisely my point. I want to be able to do that" So these projects are going to have to wait until you earn how much? I ask because what makes you as a user of these libraries different from users of your application? Maybe they want to donate yet do not have enough money yet however you expect a certain figure to be donated to you?

Sorry but this whole post sounds really wrong to me and because of it I deleted the install on my machine. If you want to make it a paid application or try to make it your main bread winner then do so but please do not beg and moan about donations for an open source project instead you should be grateful and shouting thanks from the roof tops; maybe I missed this blog post?

Disgusted, appreciate the feedback. I'm not sure why the post came as "beg and moan" for you when I tried an experiment to answer a question of "how many people may be willing/interested to pay what they want for an open-source project" and tried to analyze the (early) results and look at the options. It seems like your disgust is with my appeal to altruism even though the other two options are not doing this or setting limits to extract money. Or are you disgusted because from your perspective I didn't show the same altruism toward other open-source projects even though my open source projects go back 12 years? Are you disgusted with Ubuntu being open source and asking to Pay what you think it's worth?

  1. and 11.

Features are definitely something that makes difference. Paying for new features speeds up the development. Faster growing apps gain attention which makes perfect loop.

OK, I am not 100% convinced that "Pay for feature" thing can work but this is most realistic choice from the list. There are examples of the same concept but I am not sure how successful they are: www.codelobster.com

Another possible solution is to have free and open source app for Lua and free engines like Love and commercial version with special features and support for commercial engines.

Srdjan, I agree, although I do have my concerns about "pay for the feature" model:

  1. As some people commented on reddit, it may produce feature bloat. If you are only paid when you add features, naturally, you end up with more features, rather than with a simpler way to achieve what the user is trying to do.

  2. More importantly, paying for features seems to kill a rapid feedback loop. Take Corona integration you initiated as an example. If I had waited for more users to join and to agree to pay, it would have taken much longer and your enthusiastic support could be lost. The same thing with this Break/Pause issue. I could turn it into a "paid feature", but instead of fixing it right there (although it took good 3h or so to fix), it would be delayed by days if not weeks.

The model may still work, but it's probably better used as a prioritization mechanism: just pay enough to push your favorite feature over the top (sort of like an auction). You are only charged whatever amount you pledged if your feature is "picked up" for implementation (and your pledge for other features remains to influence their prioritization).

Another option is to do crowdfunding for more long-term features. For example, I may want to do deep code analysis, which may improve coding efficiency, but this may take several weeks to implement. To gauge interest and support for the feature, I can start a campaign to see how many people may be interested. Unfortunately, this may not work well with Kickstarter, but there may be other alternatives.

btw, the beginning of you comment seems to be cut off...

Interesting (reddit)discussion indeed.

In my previous post number 4 is missing(pay for feature). But your answer makes sense. I haven't thought about it...

Honestly, I am not a big fan of Open Source software.

Take my example: I am not a programmer. I am designer and programming is my hobby. But I am constantly looking for better tools to get my work done faster and with less effort if possible :-) ZeroBrane IDE is great tool because it cuts my time wasted in fixing bugs. It is not perfect, but in time it will get better (I hope :-). So, I am interested in further development in ZBS. I prefer old school: trial period and purchase, forum for discussions, bugs and feature requests and that's mostly it. If I have to vote, I'll go for crowdfunding.

From my experience, development of OpenSource software is slow and its quality and features often lags behind paid software. Take Gimp for example. My first contact with Gimp was 15 years ago. Nothing radically changed since then. People behind that project is having big fun changing graphics libraries, changing core etc. But practical things which will make it more helpful and user friendly for us, end users, like CMYK support, better layers, tools, even something smart and original are still missing.

Of course, there are examples of successful OS projects. In my opinion, OS project can be successful if there is a void which needs to be filled. The bigger the void the faster growth and development...this is the case when everybody can benefit from it. Like building the bridge across the river.

Ideas mentioned in your article are intriguing. I am very interested to follow the development of ZBS because this story is not just about software. It is about development too...

Great article! The "pay for feature" is a good approach for funding open-source projects. But I think this model can be improved by making the term "pay" more "flexible". For instance, let's say you add a plugin-based API where advanced users can create their own features and there is set of payable plugins for ZeroBrane. As long an advanced user creates a new plugin (feature) and give support for it, s/he is "paying" access for other plugins. Thus, it works as a virtual money. Users who are not able to contribute can pay real money for accessing the plugin features.

As long an advanced user creates a new plugin (feature) and give support for it, s/he is "paying" access for other plugins.

@andré, It may be difficult to keep track of, but I like the broader view of what is "payment" you are taking.

Hey, add Bitcoin as payment provider :) Bitpay I've heard is easy to setup and you don't have to handle bitcoins directly ^.^

Like some of the other commenters, I too think feature-specific crowdfunding would be a good way to go - at least try it as your next experiment.

I can think of one my employer would be willing to pay you to do: support for the Kepler LuaDoc or the Koneki Lua Documentation syntax for API meta-data, for ZBS's code highlighting/assist feature. Right now, if I understand it right, ZBS supports third-party APIs using Lua tables to describe them, but it's not clear how they work or how to go about writing a new one, where to put it, etc. Unfortunately there's no documentation for that, just the source code, and I would rather pay you to implement support for another already-documented format than spend my time figuring out yet another format to create an API for. :)

Why should you want to do that? Well, the more companies that document their APIs for ZBS to support, the more they'll tell their user-base to use ZBS to write Lua scripts for them, which should mean more users for you - even if those end-users don't pay you for ZBS, the companies would have an incentive to fund ZBS for more features.

I think there is a strong demand for cross-platform editors which can be loaded with Lua APIs for code-assist support, and there aren't many such editors available. Koneki is one, but it would be nice to have a editor we can pay for features we want to be added. (by that I mean to prioritize features - I still expect the features to be available to everyone)

@Hadriel, this makes total sense and, in fact, it is one of those features that is already high on the list. Drop me an email if you are interested to discuss details (my address is at the bottom of the page). Thank you.

Leave a comment

what will you say?
(required)
(required)

About

I am Paul Kulchenko.
I live in Kirkland, WA with my wife and three kids.
I do consulting as a software developer.
I study robotics and artificial intelligence.
I write books and open-source software.
I teach introductory computer science.
I develop a slick Lua IDE and debugger.

Recommended

Close