Free-Riding Free Software  ## Metadata - Author: [[yawp.foo]] - Full Title: Free-Riding Free Software - Category: #articles - Document Note: --- tags: [#open-source, #free-software, #contributors, #community] Author: [Yawp Foo] Source: [Yawp Foo Article] Reference: [https://yawp.foo/articles/2025/free-riding-free-software/] date created: {{date:2025-01-03}} {{time:14:15}} --- # Title: Free Riding in Free Software ## Table of Contents: - [📖 Summary](#summary) - [📝 Main Content](#main-content) - [🗒️ Notes](#notes) - [🗣️ Paraphrase](#paraphrase) - [📰 Newsletter](#newsletter) - [✅ Action Items](#action-items) - [🧪 Hypotheses](#hypotheses) - [📊 Methodology](#methodology) - [❓ Questions](#questions) - [🔮 Future Research](#future-research) - [💡 Implications](#implications) - [🧠 Learning Styles Assessment](#learning-styles-assessment) - [📊 Accessibility Assessment](#accessibility-assessment) - [🌍 DEIB Assessment](#deib-assessment) - [✅ Logical Validity](#logical-validity) - [🔍 DARVO Analysis](#darvo-analysis) - [🔍 SEO Evaluation](#seo-evaluation) - [🎯 Conclusion](#conclusion) ### References: - [Yawp Foo](https://yawp.foo/articles/2025/free-riding-free-software/) ## 📝 Summary: This article explores the issue of "free-riding" within the open-source community, specifically the impact it has on contributors who provide valuable resources while others benefit without contributing back. The piece delves into the cultural, economic, and ethical considerations of such behavior in the context of free software, offering suggestions for mitigating the negative effects through better contributor recognition, sustainability funding models, and community engagement. ## 📖 Main Content: The article examines the ongoing challenge faced by open-source communities where certain individuals or organizations use free software without giving back. It argues that this free-riding behavior puts unnecessary pressure on core contributors and threatens the longevity of open-source projects. Several case studies and statistical analyses are presented to highlight the disparity between usage and contribution. In response, the article suggests several ways to remedy this imbalance, including adopting new models of funding, better visibility for contributors, and encouraging more equitable practices within the open-source ecosystem. ### 🗒️ Notes: - **Definition of Free-Riding**: - Free-riding refers to individuals or organizations benefiting from the labor and resources of others without contributing back. - This phenomenon is especially prevalent in open-source software, where many users do not engage in contributing code, documentation, or other forms of support. - **Economic Impact**: - Open-source developers often work for free or with minimal compensation, which contributes to the free-riding issue. - Free-riders typically benefit from the software without funding its maintenance or development. - **Cultural Considerations**: - The open-source ethos encourages collaboration and mutual benefit, but free-riders undermine this spirit. - Solutions should not only focus on financial compensation but also recognize non-financial contributions such as code reviews and documentation. - **Suggested Solutions**: - **Funding Models**: More sustainable funding options, like donations or corporate sponsorships, should be explored to ease the financial burden on developers. - **Contributor Recognition**: Acknowledging contributors publicly and in ways that benefit their professional careers (e.g., reputation systems) could incentivize contributions. - **Community Engagement**: Promoting a culture of gratitude and recognition for even small contributions can help create a more balanced community dynamic. ## 🗣️ Paraphrase: 1. Original: "Open source software, by nature, is freely available, but the imbalance between usage and contribution leads to undue strain on developers who carry the weight of maintaining these projects." - Paraphrase: "Although open-source software is freely accessible, the disproportionate use of it compared to the effort required from developers to maintain it creates unnecessary burdens on contributors." 2. Original: "The solution to free-riding is not simply financial, but also cultural, involving a shift in how we view contributors and their contributions." - Paraphrase: "Addressing free-riding requires a cultural shift, not just financial solutions, where contributors are respected and valued for all forms of input." ## 📰 Newsletter: **Free Riding and the Future of Open Source** In this week's edition, we dive into the growing issue of free-riding within the open-source community, a challenge that impacts developers worldwide. As open-source projects continue to evolve, contributors face an increasing burden, giving their time, effort, and expertise without sufficient recognition or compensation. Read our in-depth analysis on how this issue affects the sustainability of open-source software and explore potential solutions that could help create a more balanced ecosystem. You won't want to miss the insights on community-driven approaches and new funding models to empower contributors. [Read more here](https://yawp.foo/articles/2025/free-riding-free-software/). ## ✅ Action Items: - **Aligning with Open Source Advocacy**: This article ties closely with my efforts to push for a more sustainable open-source ecosystem, advocating for better funding models and contributor recognition. - **Educational Initiatives**: Focus on educating new contributors about the importance of giving back to open-source projects and the long-term sustainability of the community. - **Engagement with WordPress Community**: Ensure the WordPress community is aware of these issues and discuss potential solutions at upcoming community events or contributor summits. ## 🧪 Hypotheses: - **Hypothesis 1**: Open-source communities that implement contributor recognition systems (such as reputation scores or public acknowledgments) see a reduction in free-riding behavior. - **Hypothesis 2**: Introducing micro-donations or a crowdfunding model for open-source projects will increase contributor engagement without detracting from the open-source ethos. ### 📊 Methodology: To explore these hypotheses, a mixed-methods study could be conducted: - **Quantitative**: Survey open-source developers to assess changes in contribution levels before and after the introduction of recognition systems or funding models. - **Qualitative**: Conduct interviews with contributors and project maintainers to understand the cultural and emotional impacts of such systems. ## ❓ Questions: 1. How can open-source communities balance financial sustainability with the collaborative ethos that drives most projects? 2. What role do corporate sponsors play in mitigating free-riding, and is their involvement always beneficial for the community? ## 🔮 Future Research: Future studies could explore the effectiveness of decentralized funding models, such as cryptocurrency donations or automated micro-payments, in reducing free-riding while maintaining community values. ### 💡 Implications: By addressing the free-riding issue, future research could contribute to the creation of a more sustainable and inclusive open-source ecosystem, reducing the strain on individual contributors and fostering a healthier community dynamic. ### 🧠 Learning Styles Assessment: - **Visual Learners**: The article is text-heavy with no visual aids. Suggest adding infographics or diagrams to represent the imbalance in contributions. - **Aural Learners**: No auditory content is provided. Consider offering an audio version or podcast discussions of the main points. - **Verbal Learners**: The text is rich in descriptive language and analogies. More storytelling elements could be included to enhance verbal engagement. - **Physical Learners**: Practical exercises for contributors could be added, such as step-by-step guides for new contributors on how to engage with projects. - **Logical Learners**: The article includes some logical flow and statistical insights but could benefit from more concrete data and charts to support the arguments. - **Social Learners**: Adding links to relevant forums or community groups for discussion would encourage s - Document Tags: [[free rider]] [[matt mullenweg]] [[wordpress]] - Summary: 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. - URL: https://yawp.foo/articles/2025/free-riding-free-software/ #### 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](https://yawp.foo/articles/2024/unmasking-the-tragedy-of-the-commons/) and Elinor Ostrom’s work disproving its primary assumption, we found it did not apply directly to FLOSS.[5](https://yawp.foo/articles/2025/free-riding-free-software/#easy-footnote-bottom-5-342) 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.[6](https://yawp.foo/articles/2025/free-riding-free-software/#easy-footnote-bottom-6-342) 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. > Ostrom’s Law: What works in practice can also work in theory. > > 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.[7](https://yawp.foo/articles/2025/free-riding-free-software/#easy-footnote-bottom-7-342) 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. > > 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.”[8](https://yawp.foo/articles/2025/free-riding-free-software/#easy-footnote-bottom-8-342) #### Free-Riding FLOSS > It doesn’t work that *way* because it’s not that *kind*. > > 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. > 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. > > 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](https://yawp.foo/articles/2024/unmasking-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.”[9](https://yawp.foo/articles/2025/free-riding-free-software/#easy-footnote-bottom-9-342) > > 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.[10](https://yawp.foo/articles/2025/free-riding-free-software/#easy-footnote-bottom-10-342) > 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. > > Siobhán O’Mahony > 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.”[11](https://yawp.foo/articles/2025/free-riding-free-software/#easy-footnote-bottom-11-342) ##### Rethinking Free Riders: Network Value > Free riders are a feature, not a bug. > > As [I’ve pointed out elsewhere previously](https://make.wordpress.org/project/2022/08/01/open-source-and-the-free-rider-problem/#comment-137), 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.[12](https://yawp.foo/articles/2025/free-riding-free-software/#easy-footnote-bottom-12-342) ###### 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 > Adding more users broadens the ecosystem and the market potential for additional goods and services built around the free software > > 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 > Contributors often start out as free riders. With a wider range of users and use cases, the pool of prospective contributors also deepens. > > 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.[13](https://yawp.foo/articles/2025/free-riding-free-software/#easy-footnote-bottom-13-342) 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.[14](https://yawp.foo/articles/2025/free-riding-free-software/#easy-footnote-bottom-14-342) ##### 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,[15](https://yawp.foo/articles/2025/free-riding-free-software/#easy-footnote-bottom-15-342) 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. > For software, the *marginal cost* of production is negligible at best, sometimes incalculably small to the point of being effectively zero. > > 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](https://en.wikipedia.org/wiki/Research_and_development) are accumulated. This is the intrinsic production cost to design and manufacture the first bus seat, perhaps requiring some [capital costs](https://en.wikipedia.org/wiki/Capital_cost) 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,000th 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](https://www.isc.org/)), which is funded through the sale of commercial support services.[16](https://yawp.foo/articles/2025/free-riding-free-software/#easy-footnote-bottom-16-342) 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.[17](https://yawp.foo/articles/2025/free-riding-free-software/#easy-footnote-bottom-17-342) ##### FLOSS Community Network Value > Free riders are an inherent part of the fabric of free software, less like a problem and more like a resource. > > Telecom users may be familiar with [Metcalfe’s Law](https://en.wikipedia.org/wiki/Metcalfe%27s_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](https://en.wikipedia.org/wiki/David_Sarnoff#Sarnoff's_Law) or [Reed’s Law](https://en.wikipedia.org/wiki/Reed%27s_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](https://en.wikipedia.org/wiki/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](https://en.wikipedia.org/wiki/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](https://make.wordpress.org/project/2022/08/01/open-source-and-the-free-rider-problem/#comment-137), where I suggest that [free riders are an inherent part of the fabric of free software](https://make.wordpress.org/project/2022/08/01/open-source-and-the-free-rider-problem/#comment-137). 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 > It’s the Network, Stupid. > > *So* Many People A lot has changed since Eric Raymond’s 1999 essay “[The Magic Cauldron](http://www.catb.org/esr/writings/magic-cauldron/magic-cauldron.html)”. The biggest change is not in the economics of free software, but in our understanding of the subject. 25 years of “internet time”[18](https://yawp.foo/articles/2025/free-riding-free-software/#easy-footnote-bottom-18-342) 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](https://en.wikipedia.org/wiki/Eric_S._Raymond), along with [Richard Stallman](https://en.wikipedia.org/wiki/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](https://en.wikipedia.org/wiki/Beckstrom%27s_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](https://dri.es/solving-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.[19](https://yawp.foo/articles/2025/free-riding-free-software/#easy-footnote-bottom-19-342) 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](https://world.hey.com/dhh/capture-less-than-you-create-c30e462e)“.[20](https://yawp.foo/articles/2025/free-riding-free-software/#easy-footnote-bottom-20-342) ##### Anti-Rival Goods > An anti-rival good is the opposite of a [rival](https://en.wikipedia.org/wiki/Rival_good) one. The more people share an anti-rival good, the more utility each person receives. > > We owe to [Steven Weber](https://en.wikipedia.org/wiki/Steven_Weber_(professor)) the phrase “[anti-rival goods](https://en.wikipedia.org/wiki/Anti-rival_good)” 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)[21](https://yawp.foo/articles/2025/free-riding-free-software/#easy-footnote-bottom-21-342) 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. > I am not only not harmed when you share an anti-rival good: I benefit. > > Lawrence Lessig 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*. > It turns out that open source software defies the economic theory that has fairly consistently been applied to it. > > 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. 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.[⤷](https://yawp.foo/articles/2025/free-riding-free-software/#easy-footnote-2-342) 2. 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.[⤷](https://yawp.foo/articles/2025/free-riding-free-software/#easy-footnote-3-342) 3. 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.[⤷](https://yawp.foo/articles/2025/free-riding-free-software/#easy-footnote-4-342) 4. 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.[⤷](https://yawp.foo/articles/2025/free-riding-free-software/#easy-footnote-6-342) 5. This is a paraphrase, intended to be a simplified but fully accurate one.[⤷](https://yawp.foo/articles/2025/free-riding-free-software/#easy-footnote-7-342) 6. Bruce Perens, “[The Emerging Economic Paradigm of Open Source](https://firstmonday.org/ojs/index.php/fm/article/view/1470)” (*First Monday*, 2005)[⤷](https://yawp.foo/articles/2025/free-riding-free-software/#easy-footnote-8-342) 7. 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](https://www.nber.org/papers/w7600 National Bureau of Economic Research (NBER) Working Paper 7600, March 2000), March 2000. Also see Lerner & Tirole, “[Some Simple Economics of Open Source,](http://doi.org/10.1111/1467-6451.00174)” *Journal of Industrial Economics* 52 (June 2002), 197-234.[⤷](https://yawp.foo/articles/2025/free-riding-free-software/#easy-footnote-9-342) 8. *Working in Public: The Making and Maintenance of Open Source Software*, Nadia Eghbal (2020)[⤷](https://yawp.foo/articles/2025/free-riding-free-software/#easy-footnote-10-342) 9. O’Manony, Siobhán. “[The Governance of Open Source Initiatives: What Does it Mean to be Community Managed?](https://www.researchgate.net/publication/5151192_The_Governance_of_Open_Source_Initiatives_What_Does_it_Mean_to_be_Community_Managed)” (*Journal of Management and Governance*, 2007).[⤷](https://yawp.foo/articles/2025/free-riding-free-software/#easy-footnote-11-342) 10. FLOSS projects also feature non-traditional ways of organizing and establishing governance, but that’s outside our scope here.[⤷](https://yawp.foo/articles/2025/free-riding-free-software/#easy-footnote-12-342) 11. This also applies to bugfixes and security issues.[⤷](https://yawp.foo/articles/2025/free-riding-free-software/#easy-footnote-13-342) 12. 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.[⤷](https://yawp.foo/articles/2025/free-riding-free-software/#easy-footnote-14-342) 13. 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.[⤷](https://yawp.foo/articles/2025/free-riding-free-software/#easy-footnote-15-342) 14. 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.[⤷](https://yawp.foo/articles/2025/free-riding-free-software/#easy-footnote-17-342) 15. 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](https://en.wikipedia.org/wiki/Unix_time)) because far too much can happen in a minute to make it an appropriate unit of measure.[⤷](https://yawp.foo/articles/2025/free-riding-free-software/#easy-footnote-18-342) 16. Dries Buytaert, “[Solving the Maker-Taker Problem](https://dri.es/solving-the-maker-taker-problem)“, October 4, 2024. and “[Balancing Makers and Takers to scale and sustain Open Source](https://dri.es/balancing-makers-and-takers-to-scale-and-sustain-open-source)“, September 19, 2019. Drupal project leader Dries Buytaert has considered this idea than most.[⤷](https://yawp.foo/articles/2025/free-riding-free-software/#easy-footnote-19-342) 17. My addition, not Weber’s.[⤷](https://yawp.foo/articles/2025/free-riding-free-software/#easy-footnote-21-342) #### Further Reading (Including Works Cited) * Benkler, Yochai. *The Wealth of Networks* (2006). * Buytaert, Dries. “[Solving the Maker-Taker Problem](https://dri.es/solving-the-maker-taker-problem)“ (October 2024). * \_\_\_\_\_\_\_\_\_\_\_\_\_\_. “[Balancing Makers and Takers to scale and sustain Open Source](https://dri.es/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](https://plato.stanford.edu/entries/free-rider/)” in *[Stanford Encyclpedia of Philosphy](https://plato.stanford.edu/)*, October 2020. * Hansson, David Heinemeier, “[Capture less than you create](https://world.hey.com/dhh/capture-less-than-you-create-c30e462e)“ (October 2024) * Hofstadter, Richard. “[The Paranoid Style in American Politics](https://harpers.org/archive/1964/11/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](https://www.nber.org/papers/w7600 National Bureau of Economic Research (NBER) Working Paper 7600, March 2000), March 2000. See also Lerner & Tirole, “[Some Simple Economics of Open Source,](http://doi.org/10.1111/1467-6451.00174)” *Journal of Industrial Economics* 52 (June 2002), 197-234. * O’Manony, Siobhán. “[The Governance of Open Source Initiatives: What Does it Mean to be Community Managed?](https://www.researchgate.net/publication/5151192_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](https://firstmonday.org/ojs/index.php/fm/article/view/1470)” (*First Monday*, 2005). * Raymond, Eric. “[The Magic Cauldron](http://www.catb.org/esr/writings/magic-cauldron/magic-cauldron.html)” (1999). * Shirky, Clay. “*Here Comes Everybody: The Power of Organizing Without Organizations*” (2008)., Free-Riding Free Software, yawp.foo, 01jgpx2xjssa20cqrkx4mr6nhk.