By Brent Toderash
Published January 3, 2025
≅3,991 Words
on The Commons

Timeline & Summary Articles

• The Mullenweg/WPE Thing
• What’s With the Open Source Drama Between WordPress and WP Engine?
• Timeline of the WordPress Drama
• How Corporate Greed Kills Open Source
• Mullenweg.wtf
• WP Engine’s Timeline
• wpvswpe.report

Introduction: The Free Rider Problem

The “Free Rider Problem” is an economic concept wherein some users of a public good or common pool resource (CPR) use but do not pay for, while other users pay a fee or make some form of contribution to its maintenance. The name for the theory is taken from the example used in its explanation, which is that of a transit bus. The theory posits that if some riders pay and others optionally do not, people will ride for free, which is not a sustainable model for the continued provision of the service. The assertion is that if the benefit can be had without payment, riders who might otherwise pay will also choose to ride for free, resulting in the loss of all contributions necessary to operate the bus. The logic of the argument is axiomatically sound.

A free rider, most broadly speaking, is someone who receives a benefit without contributing towards the cost of its production.¹

As we saw when “Unmasking the Tragedy of the Commons,” common pool resources are those which are shared by a group of people.² This brings us to the free rider problem, which specifically uses public transit as its example to make the argument that non-contributing users will lead to the ruin of the resource itself. The assertion is that given the option, users will access it without paying fares, user fees, tolls, or taxes. These users then overuse the resource, degrading or depleting it. In the bus analogy, the result is that there are no seats left on the bus. With public roadways, it is argued that traffic congestion is the result.³ The theory sees the result of free riding to be underproduction or overconsumption so the supply of the resource cannot meet the demand of its users.

A prima facie reading of the free rider problem in the context of free software suggests that this issue would also apply. In free and open source software (FLOSS),⁴ there appears to be an inequity where contributors invest time and effort while non-contributors freely benefit. As a result, corporations may rationally choose to save costs by not contributing to the development, even though their contributions could improve the software and strengthen its ecosystem. A complaint may thus arise from contributors about “fairness” in who benefits from the software, either in its direct use or financially from the ecosystem which surrounds it. This appears to be a logical application of the free rider problem to FLOSS, because the software clearly needs contributors to remain viable.

Surface readings can be problematic though, as they tend to be based on untested assumptions. If we dig a little deeper, we find that the free rider problem is not as applicable to free software as we might have assumed.

Similar Economic & Game Theory Models

The free rider problem  has much in common with other models in economics and game theory, so it may be helpful to outline a couple of those relationships here, as we may jump between them somewhat in discussing their commonalities. For the most part, they all break in the same place with regard to FLOSS.

Economics: Tragedy of the Commons

In my earlier piece on the tragedy of the commons and Elinor Ostrom’s work disproving its primary assumption, we found it did not apply directly to FLOSS.⁵ When Ostrom took a research interest in the commons, her work documented over 800 currently-functioning commons arrangements of the type that Hardin had argued couldn’t work. For her extensive field work work and published demonstration that Hardin’s assertion was not an inevitability when certain structures were in place, Ostrom was awarded a Nobel Prize in economics.⁶ The key takeaways from Ostrom’s work disproving Hardin’s thesis are, firstly, that Hardin’s tragic forecast is not inevitable, and secondly, that where commons (CPR) arrangements are functioning successfully, some version of eight specific governance rules can be found consistently functioning to prevent Hardin’s tragedy.

The contrast between Hardin’s theory and Ostrom’s documented practical exceptions is best summed up in what has been dubbed “Ostrom’s Law,” that what works in practice can also work in theory.⁷

The free rider problem makes a similar assumption about inevitability, leaping to some of the same conclusions about free riders as commons-users who don’t contribute to the upkeep of CPRs. In both cases, governance is an answer, since a simple set of rules could potentially prevent the failure of the system. For example, if a bus had 10 seats available to free riders and 20 for paid riders (or such ratio as would be appropriate), the system could suddenly work by ensuring that seats were always available to paying riders. If there were no free-rider seats available, the next rider would either have to pay or wait for the next bus. In this respect, the argument of the free rider problem may break down with the application of even modest governance rules.

As with the tragedy of the commons, the application of governance prevents the tragedy. This observation is not made to dismiss the free rider problem so swiftly, but to note its relation to the tragedy of the commons in its lack of inevitability, which was the fatal flaw in Hardin’s argument. We’ve still got more work to do in a full consideration of the free rider problem. We can foreshadow a bit by observing that the tragedy of the commons is not directly applicable to open source software. As Bruce Perens argued in 2005, “The traditional economic concept of the tragedy of the commons fails to capture the regenerative nature of open source communities, where use actually enhances rather than depletes the resource.”⁸

Free-Riding FLOSS

In the context of free software, assumptions about human nature aren’t the only issue with the free rider problem and its related frameworks. Upon further analysis, we find some of the same discrepancies for the Free Rider Problem as we found in the Tragedy of the Commons, namely that it doesn’t work that way because it’s not that kind.

In the free rider problem, we find that our bus, like any commons, deals with resources that share two crucial qualities. First, the resource (seats on the bus) must be non-excludable, or freely-accessible, meaning that people may use or consume the resource in an unfettered manner. FLOSS easily fits this requirement as well, since there are no barriers to sharing and using the software.

The second requirement for a traditional commons presents a greater problem for the application of the free rider model to free software. While FLOSS is generally accepted to be a commons (or CPR, where the free rider problem could apply), it is non-rivalrous, or non-subtractive, meaning that use or consumption by one person does not diminish supply or availability to the next.

As we saw with the tragedy of the commons, this contravenes the second requirement for CPRs. Since if the resource pool is not diminished by withdrawals, it’s not the usual kind of commons. In the analogy used by the free rider problem, it turns out that our bus has an infinite number of seats, so with free software there can’t be a problem with free riders.

“Unlike traditional public goods, open source lacks rivalry in consumption – the consumption by one user does not affect the supply available to other users.”⁹

We can add another point of distinction between the commons of free software and the traditional forms of a commons, being incentives to contribute. Contributor incentives may be greater in some respects for free software than for other CPRs, though not in consistent manners or to a consistent degree. This makes it hard to enumerate clear differences between the incentives to participate between traditional CPRs and free software, but with free software, contributors can earn reputation and gain career advancement through acquisition of new skills, gaining experience with existing skills, or building a portfolio of work. Perhaps to an even greater degree for corporations than for individuals, contribution and reputation enable greater influence on the direction of the project and greater assurance of its sustainability. Some of these incentives may exist in certain kinds of CPRs to a lesser extent and, as in most situations these types of incentives are greater for free software contributions than would be found in a typical CPR.

Nadia Eghbal also observed that open source software doesn’t fit the economic mold of common public resources that may be prone to suffer from free riders.¹⁰

The traditional economic frameworks we use to understand public goods don’t capture the unique dynamics of open source software, where the challenge isn’t free riding but rather managing the influx of contributors and maintaining sustainable practices.

Eghbal isn’t alone in pointing out that FOSS projects don’t conform to what’s expected based on traditional models. As Siobhán O’Mahony observed, “Contrary to what free rider theory would predict, we find that commercial firms actively contribute to open source projects even when they could theoretically benefit without contributing.”¹¹

Rethinking Free Riders: Network Value

As I’ve pointed out elsewhere previously, free riders are part of the inherent nature of free software. In tech jargon, free riders are a feature, not a bug. In software, free riders can be given a different title: users. In commercial software, users are customers in the market you serve. As free riders, this group may not directly contribute to the cost of producing and maintaining the software, however as users, they provide different benefits which are clear enough that we can list five of the primary ones, which all fall under the category of network value.¹²

1. Bug Reporting

More users may tend to uncover more bugs through testing with a greater set of use cases and environments. With an increased number of users, the likelihood of those bugs being reported increases, and multiple reports can be combined to more accurately and easily identify and remedy issues.

2. Use Cases & Feature Requests

More users mean more use cases. While this can have a detrimental effect in some phases of a software project, over time mature software projects may want to address a wider range of use cases for which there is significant demand. Specific feature requests that recur can help shape the software’s development roadmap for everyone’s benefit, not only to add popular feature enhancements, but to prioritize them and better define their requirements in advance.

3. Broaden the Ecosystem

In typical free software communities, adding more users broadens the ecosystem and its attendant market potential for additional goods and services built around the free software. This may include software add-ons and enhancements, support contracts, hosting, or other ancillary goods and services. Each of these support an economic case for ecosystem services apart from but built upon the availability of the free software.

4. Non-Code Contributions

With free software, free riders exist first because they may not have the software development skillset necessary to contribute to the code, which is the first presumed form of contribution. These users may still make significant contributions to the software project, such as with translations, documentation, or providing peer support to other users. Even if a free-rider-user doesn’t feel equal to any of these forms of contribution, simply promoting the use of the software in public or in private one-to-one exchanges has a non-measurable but genuine value, whether direct or indirect.

5. Deepen the Pool of Prospective Contributors

More often than not, contributors will start out as free riders. Even if they don’t make any direct contributions for a significant period of time, eventually they may for their own reasons and motivations decide to become contributors. Larger free software projects tend to have a very high number of one-time or infrequent contributors who participate only when a technical need arises for them, and having solved it, they contribute the solution to the project.¹³ Contributors may be casual or infrequent as well as regular ongoing participants. The latter group may be sponsored to contribute, or may offer a significant amount of volunteer time, but they are not the only types of contributor. With a wider range of users and use cases, the pool of prospective contributors also deepens. Even one-time or infrequent contributors offering features, revisions, or patches based on their own needs, the contribution benefits the software project and its user community in tangible ways.¹⁴

Evaluating Production Costs

Let’s return to our magical bus with an infinite number of seats. With FLOSS, we have a marginal cost that approaches zero in the addition of a single additional user, or seat on the bus. We say “approaching zero” because while it is nominally greater than zero, the cost of a single user is too low to effectively calculate. For free software, this might be the bandwidth cost for downloading a copy of the software,¹⁵ while for our magic bus, it might be the additional cost of fuel to haul around that one extra seat. In both, the cost will likely be less than the margin of error in its calculation.

On the other hand, calculating the cost of the first seat is a different matter entirely, as this is where all the R&D costs are accumulated. This is the intrinsic production cost to design and manufacture the first bus seat, perhaps requiring some capital costs like establishing a factory and building molds or tooling to manufacture the seat. None of these apply to the second seat, which is close to free, especially by comparison. This is even more true of software, and illustrates what we mean by “marginal cost”, referring to the cost of producing one more copy of the good or service. For software, with no labour or hard goods required, the marginal cost is negligible at best, sometimes incalculably small to the point of being effectively zero.

As we’ve seen, although FLOSS can be considered to be a commons, or CPR, it differs fundamentally from traditional CPRs because of its non-rivalrous or non-subtractive nature. In other words, the second copy of the software removes nothing from the first copy, either qualitatively or quantitatively, and this holds true through the 1,000,000^th and on to an infinite number of copies.

While other costs may increase with the addition of users, the marginal cost of producing one additional copy of the software itself does not. For example, support costs may increase. In a FLOSS project, and are typically handled in two ways, which often co-exist. The first is peer support between users, with no associated costs other than perhaps a platform cost for a user forum or similar mechanism, to which the same marginal cost rule would apply for adding a user. The second is a paid support model, which adds economic value (or potential) to the ecosystem by having the user pay the incremental cost of providing the ancillary service, often at a profit that helps fund other expenses of the project. A successful example of this model would be BIND, which has made DNS work since the mid-1980s. BIND is one of three products developed by a team of just 40 people working for the Internet Systems Consortium (ISC), which is funded through the sale of commercial support services.¹⁶

We’ll leave the intrinsic cost of producing the first copy of the software for another discussion, and focus here on the marginal cost, since that’s the focus in the free rider problem.¹⁷

FLOSS Community Network Value

Telecom users may be familiar with Metcalfe’s Law in communications, and may have applied it to the common example number of fax machines, or extrapolated it for use in other network examples, even where Sarnoff’s Law or Reed’s Law may have been more fitting, but without going into any of the nuance, suffice it to say that we have several eponymous laws we can use to calculate the value or utility of a network based on its size. Our fallback might be to pull out the well-worn Pareto Principle to suggest that if we need 2 more contributors, we just need to gain 10 users and all will be well — but that’d be something of an oversimplification.

Still, there’s a definite and quantifiable network effect for free software that as its community of users grows, so too does the value of the software and the ecosystem that it can support. Consider a free software project with 100 users, all of whom are contributors. The same software with 75 contributors and 1,000 users has a significantly higher network value. This is the gist of a discussion from August 2022 about the free rider problem for WordPress, where I suggest that free riders are an inherent part of the fabric of free software. They are less of a problem and more of a resource that can be tapped, and add value to the project simply by being users.

Free Software Network Economics

A lot has changed since Eric Raymond’s 1999 essay “The Magic Cauldron”. The biggest change is not in the economics of free software, but in our understanding of the subject. 25 years of “internet time”¹⁸ has seen a lot of FLOSS projects through various life cycles, providing far more examples of success and failure along with additional business case lessons through different phases of the global economy outside of FLOSS ecosystems. In short, the biggest change stems from the fact that we have a lot more data from which to draw our conclusions. And for the most part, we find that the additional data suggests that Eric Raymond, along with Richard Stallman, were right all along.

The network laws mentioned above establish that larger networks have greater intrinsic value, but make no effort to quantify that value in extrinsic terms. For that, we have Beckstrom’s Law, which attempts to assign economic value to the network through a set mathematical formulae. Regardless of what the outcome of the calculation turns out to be for any given network, the fact that you can express it at all in a meaningful manner is significant. The result is that we have a method of expressing the value of the network not just reflexively to itself, but objectively outside of itself. This is beyond what Raymond or Stallman had attempted, as they merely demonstrated that such value existed and could be monetized with certain business models.

More recently, a similar idea to the free rider problem has been described as “the maker-taker problem.” The gist of it is the same, but it is more nuanced and intended to be applied directly to free software.¹⁹ I don’t think the Maker-Taker discussion is fully addressed here, as the free rider problem is more about economics, whereas the maker-taker problem goes beyond that into concepts of “fairness”, and acknowledges differences between FLOSS and other CPRs, as well as the concept of anti-rival goods. The counter to the “fairness” question here is the perspective in DHH’s admonition to “capture less than you create“.²⁰

Anti-Rival Goods

We owe to Steven Weber the phrase “anti-rival goods” to describe CPRs that meet the test of being a common (shared) public good (or resource) by virtue of being non-excludable (anyone can freely access and use it) but do not meet the test of being rivalrous, meaning use by one does not deplete or diminish what remains available to others. By being anti-rivalrous rather than simply non-rivalrous, Weber’s term goes a step further to state that these goods are created for common benefit without (necessarily)²¹ altruistic motivations, because the work’s creator and all users will benefit not just from the contributions of others, but simply from their presence. This observation begins to recognize the effect of network value to the software and to its original creator, or contributor.

Legal luminary Lawrence Lessig expresses this understanding of anti-rival goods well in generalizing it as, “I am not only not harmed when you share an anti-rival good: I benefit.” As summed up in its Wikipedia entry, “The more people share an anti-rival good, the more utility each person receives.” Thus the phrase “anti-rival good” gives us the apt descriptor we need for free software, which we’ve accepted as a commons, (CPR) but contrasts it with a traditional commons by saying it “doesn’t work that way because it’s not that kind.” Weber’s neologism zeros in on the difference by recognizing how the network effect applies to the CPR itself; Rather than depleting its value as with a traditional rivalrous-goods commons, the addition of users actually increases its value.

All Aboard, Then!

Applied to the free rider scenario, far from the harm of exhausting the number of available seats, if the seats have an anti-rival nature by being infinite, the more people seated on our bus, the more valuable the bus becomes. The implication for free software is that free riders are not a problem, but a benefit.

In the context of FLOSS, referring to users as “free riders” becomes something of a pejorative label, since it fully discounts the network value they bring to the software and to its ecosystem. In fact, what we’ve seen here is that while the cost of adding that single “free-riding” user approaches zero, the value they add to the network actually has a formula with which it can be calculated. By implication, as the network of users grows, each additional user adds a calculable value to the network in exchange for the almost incalculably-small marginal cost of what they extract, simply by showing up.

As it turns out, open source software defies the economic theory that has fairly consistently been applied to it. While in traditional economic models of CPRs with rivalrous goods, free riders present a problem, when applying the scenario to free software with its anti-rival nature, free riders are transformed from a problem into a benefit.

Notes

1. The Free Rider Problem” in Stanford Encyclopedia of Philosophy (2003, 2020)⤷
2. Natural resources are the first and most obvious example of these, but CPRs can also be publicly-owned or commonly-held goods or shared services, from public roadways to drinking water and can include fishing stock, timber, community pastures, public parks, or public transit systems.⤷
3. The astute urbanist may object to the idea that the simple lack of tolls causes traffic congestion, as traffic management is a much more complex problem. The argument might imply that toll roads would either stop driving or that they would pay enough user fees to avoid congestion by constructing additional lanes to handle the traffic. The facts don’t quite bear this out, as the flow of traffic tends to expand to its point of congestion, even when more lanes are added to the roadway. This is well beyond our scope here, but is mentioned as it is one of the common examples in explaining the theory.⤷
4. I tend to use some of these terms interchangeably. Unless I’ve explicitly stated otherwise, free software, open source software, or acronyms like FOSS and OSS (Free & Open Source Software and Open Source Software) will be inclusive terms here. My favourite descriptor which I find to be most apt, has always been FLOSS, indicating Free and Libre Open Source Software to indicate the inclusion of both “free as in speech” and “free as in beer” forms of open source software. This is the intended meaning throughout, though quotations from third-party sources may intend a different nuance.⤷
5. Also see the companion piece on why it matters.⤷
6. Hardin’s motivations were not primarily economic, and picking up an article from a century before, he saw a case he could make for population control rooted in his eugenic views. With no testing beyond its own internal logic, the argument was picked up and promoted by economists whose philosophy of privatization was strongly bolstered by Hardin’s 1968 essay. Hardin later recanted, saying his essay should have been called “The Tragedy of the Unmanaged Commons.” Discredited, the university where Hardin was a faculty member disavowed his work and views upon his death. The SPLC maintains Hardin’s profile in their extremist files, noting his views have found new favour among the radical right.⤷
7. This is a paraphrase, intended to be a simplified but fully accurate one.⤷
8. Bruce Perens, “The Emerging Economic Paradigm of Open Source” (First Monday, 2005)⤷
9. Josh Lerner and Jean Tirole. “The Simple Economics of Open Source” Harvard Business School (February 2000) & National Bureau of Economic Research (NBER) Working Paper 7600, March 2000. Also see Lerner & Tirole, “Some Simple Economics of Open Source,” Journal of Industrial Economics 52 (June 2002), 197-234.⤷
10. Working in Public: The Making and Maintenance of Open Source Software, Nadia Eghbal (2020)⤷
11. O’Manony, Siobhán. “The Governance of Open Source Initiatives: What Does it Mean to be Community Managed?” (Journal of Management and Governance, 2007).⤷
12. FLOSS projects also feature non-traditional ways of organizing and establishing governance, but that’s outside our scope here.⤷
13. This also applies to bugfixes and security issues.⤷
14. As WordPress grew from the mid- to late 2000s, the available plugins were largely of this nature, being built by people for their own needs, and shared. Commercial plugins followed afterward. Both types of plugin further broadened the ecosystem, as in point 3 above.⤷
15. I remember when data transfer on a commercial internet connection was $40/GB or more on a 10Mbps connection; now it’s too low to properly factor into the calculation.⤷
16. See “A Brief History of the DNS and BIND“.⤷
17. We aren’t dismissing these costs, but they are addressed in a different manner. The free rider problem is specifically concerned with the number of users, which has no bearing on the cost to create the first copy. We’ll get to that.⤷
18. I use this phrase to refer to the time that seems to pass differently online, at some exponentially faster but pace that we can’t properly convert, but offer as proof the fact that we measure it in seconds (Unix Time) because far too much can happen in a minute to make it an appropriate unit of measure.⤷
19. Dries Buytaert, “Solving the Maker-Taker Problem“, October 4, 2024. and “Balancing Makers and Takers to scale and sustain Open Source“, September 19, 2019. Drupal project leader Dries Buytaert has considered this idea than most.⤷
20. David Heinemeier Hansson (“DHH”), “Capture less than you create“, October 14, 2024.⤷
21. My addition, not Weber’s.⤷

Further Reading (Including Works Cited)

• Benkler, Yochai. The Wealth of Networks (2006).
• Buytaert, Dries. “Solving the Maker-Taker Problem“ (October 2024).
• ______________. “Balancing Makers and Takers to scale and sustain Open Source“ (September 2019.)
• Castells, Manuel. The Rise of the Network Society (1996)
• Eghbal, Naida. Working in Public: The Making and Maintenance of Open Source Software (2020).
• Hardin, Russell. “The Free Rider Problem” in Stanford Encyclpedia of Philosphy, October 2020.
• Hansson, David Heinemeier, “Capture less than you create“ (October 2024)
• Hofstadter, Richard. “The Paranoid Style in American Politics“
• Lerner, Josh and Tirole, Jean. “The Simple Economics of Open Source” Harvard Business School (February 2000) & National Bureau of Economic Research (NBER) Working Paper 7600, March 2000. See also Lerner & Tirole, “Some Simple Economics of Open Source,” Journal of Industrial Economics 52 (June 2002), 197-234.
• Open Source and how we sustain ourselves – WordPress.org Project 
• O’Manony, Siobhán. “The Governance of Open Source Initiatives: What Does it Mean to be Community Managed?” (Journal of Management and Governance, 2007)
• Perens, Bruce. “The Emerging Economic Paradigm of Open Source” (First Monday, 2005).
• Raymond, Eric. “The Magic Cauldron” (1999).
• Shirky, Clay. “Here Comes Everybody: The Power of Organizing Without Organizations” (2008).