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 .

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.

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).

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?

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. 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. 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). 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. 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". 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." 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). 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. Academic research. A research grant to answer an interesting research question with your project. 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. 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. 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.