According to Manuel Hoffmann, Frank Nagle and Yanuo Zhou, in The Value of Open Source Software for the HBS Working Paper Series:
We estimate the supply-side value of widely-used OSS is $4.15 billion, but that the demand-side value is much larger at $8.8 trillion. We find that firms would need to spend 3.5 times more on software than they currently do if OSS did not exist. The top six programming languages in our sample comprise 84% of the demand-side value of OSS. Further, 96% of the demand-side value is created by only 5% of OSS developers.
This figures alone should alert us to the critical importance of open source software. But somehow, despite this incredible value, the open source ecosystem still faces major sustainability challenges that will impact its future, and us all.
Beyond the numbers, open source enables innovation, creates opportunities for global collaboration, and provides critical digital infrastructure relied upon by businesses, governments, and people around the world. Projects like the Linux kernel, Python, Kubernetes, Node.js, and countless others create the foundation for everything from cloud computing and AI to mobile apps and IoT devices.
Despite the advancements we've made via open source, we're still facing a crisis of sustainability. As Nadia Eghbal outlined in “Working in Public,” open source often suffers from a tragedy of the commons: while everyone benefits from open source software, the burden of maintaining it falls on a small group of often unpaid or underpaid individuals.
Understanding the Tragedy of the Commons
The tragedy of the commons originates from economics and ecology. It describes a situation where individual users, acting independently according to their own self-interest, deplete or use up a shared resource, even though it's not in anyone’s long-term interest for this to happen. The “commons” refers to resources available to all members of a society, like air, water, or, in this context, open source software.
Application to Open Source Software
In open source, the “commons” is the collective body of software that is freely available for anyone to use, modify, and distribute. While this model encourages innovation and reduces barriers to entry, it also presents challenges:
- Unequal Contribution to Benefit Ratio: Many organizations and individuals use open source software in their products and services, gaining significant benefits in terms of cost savings and faster development. However, the responsibility of maintaining and updating these projects often falls on a small group of maintainers who may not receive adequate compensation or recognition for their work.
- Maintenance Burden: As software projects grow in popularity, the demands on maintainers increase. They have to address bug reports, security vulnerabilities, feature requests, and support inquiries, which can become overwhelming without sufficient resources.
- Sustainability Challenges: Without proper funding or support, maintainers may experience burnout, leading to neglected projects. This can result in security risks, decreased software quality, and ultimately, a decline in the utility of the software for all users.
To learn more about what happens when maintainers leave a project, check out The Silent Crisis in Open Source: When Maintainers Walk Away.
Economic Implications
The difference between those who benefit from open source software and those who maintain it raises economic concerns as well:
- Free Riders: Companies often use open source software extensively without contributing back, either through code contributions, funding, or other support.
- Lack of Incentives: The traditional market mechanisms that incentivize product improvement and maintenance are weaker in open source projects, because the software is freely available.
The tragedy of the commons in open source software reflects an imbalance between widespread usage and concentrated maintenance responsibilities. While everyone benefits from the collaborative and open nature of these projects, without proactive measures to support maintainers, the sustainability of open source is at risk.
Let's think about this from another perspective. What if our fire departments were all volunteers. They spend the countelss hours training, they're often on call 24/7 to protect our communities from fires and other emergencies, and they aren't paid.
But we also need to recognize that companies build skyscrakers, factories, and complexes that are also protected by these unpaid firefighters. In this scenario, these companies also might be able to forego fire safety systems and insurance, while they still get the benefits of the volunteer labor of the firefighters.
The firefighters would probably have to find a way to bring in income to pay their own bills, so they may end up being exhausted from essentially working two jobs - including one that's incredibly physically demanding. So now, we're left with exhausted fire fighters who might end up making mistakes, having a slow response time, or may be burnt out and quit.
It's pretty clear that this is not a safe situation. And yet, this is what we're accepting in open source. We're creating an environment that's setting us all up for failure.
The Challenge of Funding and Recognition
Part of the sustainability problem is the funding crisis. The 2024 Tidelift State of the Open Source Maintainer Report reveals that 60% of maintainers remain unpaid for their work. Considering the importance maintainers play in maintaining the digital infrastructure that powers our world, this lack of financial support is problemmatic at best.
The Tidelift report also showed that maintainers overwhelmingly prefer predictable, recurring income over one-time payments to better manage their ongoing work. So even when funding is available, it may not be given in a way that best supports the maintainers who need it most.
In “Working in Public: The Making and Maintenance of Open Source Software,” Eghbal emphasizes how open source maintainers are often underappreciated and face burnout. She argues that maintaining a healthy ecosystem requires both financial support and community appreciation for those who contribute regularly. The invisible labor behind these projects keeps them operational and secure, but it often goes unrecognized.
The OSS Pledge: Sentry’s Model for Direct Impact
Sentry’s OSS Pledge serves as a model for how companies can take concrete steps to support open source sustainability. The Pledge calls for companies to pay a minimum of $2000 per year per full-time equivalent developer on their staff to open source maintainers of their choosing. This approach aims to create a new social norm in the tech industry of companies paying open source maintainers directly, addressing the one of the root causes of maintainer burnout and related security issues.
While other forms of support like hiring developers to work on open source or providing in-kind gifts are valuable, the Pledge emphasizes the importance of direct cash payments. This focus ensures that underpaid and overworked maintainers of critical open source projects can pay their bills, leading to a healthier, fairer, more stable, and more secure open source ecosystem.
Open Source and Sustainable Development
It's not just economic and technological impacts that make open source important; open source has the potential to play a major role in addressing global challenges. The Linux Foundation’s Open Source for Sustainability report examines how open source projects can significantly advance the United Nations Sustainable Development Goals (SDGs).
For instance, projects like AgStack help farmers make data-driven decisions to increase yields, contributing to goals like Zero Hunger and Responsible Consumption. Open standards, open AI models, and open data allow for more collaboration, reduce waste, and improve transparency across various sectors.
However, to be able to actualize this potential, we have to prioritize the sustainability of both the projects and their maintainers. According to Eghbal, the perpetual nature of open source development needs continuous support, because without it, these projects are at risk of stagnation or worse, abandonment.
The Security Imperative
The sustainability crisis in open source isn’t just about funding—it’s also a matter of security. The Tidelift report reveals that paid maintainers are significantly more likely to implement critical security practices. This is becoming more and more important as security threats continue to grow in sophistication. (Read more about new legislation to improve cybersecurity for NASA.)
The Log4j vulnerability heightened concerns, with many maintainers feeling less trustful of contributors. We need secure, well-maintained projects. Paid maintainers can generally spend more time on security improvements and maintenance.
Eghbal points out that many essential open source projects are maintained by individuals or small teams with limited resources. This fragile support system can make widely-used software vulnerable to security breaches, as maintainers may not have the bandwidth to address every vulnerability or request. Prioritizing financial and structural support is necessary to decrease these risks.
Solutions
So, what can be done? First, we need a paradigm shift in how we think about and support open source work. Companies that benefit from open source need to step up their financial support. The Linux Foundation’s work in creating funding models and governance structures for open source projects is a step in the right direction, but we need more widespread adoption is needed.
Governments also have a responsibility to consider the long-term impact of their dependence on open source. Recognizing open source as critical national infrastructure and providing funding and support could help ensure its long-term viability.
For individual developers and users of open source, consider contributing back—whether through code, documentation, or financial support. If you're in a position to influence your company's policies, advocate for supporting open source projects through consistent sponsorships or by creating employee time for contributions to the projects they use.
Take time to look at and understand your dependencies. Create an SBOM Workspace and look at the security ratings of your dependencies. Identify the lottery factor of the projects. If you see there's a high lottery factor, then those projects might need to be the priority for your support.
Takeaways
The open source model has created an amazing history of technological innovation and collaboration. But like any commons, it requires stewardship and support to thrive. The sustainability of open source is not just a technical issue — it’s a societal imperative. Working together — companies, governments, developers, and users — we need to make sure that the open source ecosystem continues to make progress.
Recognizing the “invisible labor” involved in open source is a first step toward making sure that the individuals behind these projects can continue their work without facing burnout. Let's elevate the status of maintainers and give them the recognition and support they deserve.
Top comments (8)
From my perspective as a Microsoft coder, one of the more interesting things I've seen is the socialization of code. Skipping over the crappy behavior of HashiCorp proprietizing (to apparently coin a phrase) it's code, Microsoft actually opened a lot of it's code. Like it or not .NET has had a renaissance of sorts because of open source, but it's managed by MS, which brings a stability to the ecosystem and encourages a balance of innovation and commerce. Personally I like the direction they and others have taken. My concern is that this positivity will be short lived and the world will turn into HashiCorp's model. (Seriously, screw HashiCorp.)
I think some of the nuance of that comes from the fact that Microsoft is a large organization with a dependable income stream. Facebook has similarly open sourced some of their AI offerings. They can afford to do that and it helps them to innovate and spread usage. Unfortunately, it's not really a solution for small-mid sized teams.
This is something I've been thinking about a lot recently as someone looking to get back into contributing to open source in a big way in the new year, but I kind of disagree with this statement:
In my experience, the opposite is true. The incentive for maintenance tends to be higher for open source projects which are often far more focused on providing stable, shared solutions than commercial projects are. Conversely, commercial projects often aren't about improving products - they're about increasing profit. Improving products can be one way to do that, but it often isn't the fastest way to do it and as a result in my experience isn't the path most often taken.
For things that can be shared like infrastructure and frameworks and the like, the incentives seem to align much more strongly with opensource development. But open source maintainers need to be paid so they can keep roofs over their head and food on their tables or otherwise almost nothing will get done on their projects towards any goal at all.
I'm by no means a big name in OSS, but I do have a few libraries with thousands of downstream dependencies including some from big companies. I firmly agree that the long term solution is companies injecting some of their money back into the the open source software they use. That said, small-time as I am, if everyone using my work was to donate a whole $1 per month per project, that'd be enough for me to refocus on my open source work and actually maintain and improve my own projects and take time to fix upstream issues in projects I use as well. A diversified income stream helps maintainers feel safer too, instead of one big main corporate sponsor who can pull the plug any time. Instead of either of these options though, I've been stuck working a day job with all my projects in maintenance mode instead. It's frustrating to say the least.
This already looks like an idea (new kind of OSS license): "$1 / month for commercial use".
Seriously, more open source projects should consider dual licensing model then - free for another OSS projects, non-commercial use and paid for commercial use...
There are certainly people doing that, and I will almost certainly add some notes to the readme and licence files soon with comments to the effect of "if you use this for commercial stuff, then please donate."
But dual licensing means getting lawyers involved to write the commercial license, something that's hard to do before you're being paid. It's also messy. Just as one example, I know for a fact that Auth0, a commercial entity, is using my packages. I know this because Github shows them as a dependent package. But Github only shows dependent packages for publicly available packages. Which means they're open source packages written by a commercial entity. Is this commercial use or open source use? It's arguably both.
Dual licensing also gets messy for things that are likely to end up as transitive dependencies. My two big packages at the moment are an input validation library and a DI library with features designed to be integrated into a build system. Both of these are likely to end up as transitive dependencies of something bigger.
This is why I tend to prefer things like Tidelift. I have my criticisms of Tidelift the company, but their goal and the way they're going about things in the ideal situation is where things seem to need to end up.
This is a really interesting breakdown and example. Thanks for sharing.
This article highlights a crucial issue in the open-source ecosystem. The comparison to volunteer firefighters is spot-on—while companies and developers benefit massively from open-source software, the maintainers often bear the burden without adequate recognition or compensation. It's alarming that 96% of the demand-side value comes from just 5% of developers, yet many remain unpaid. For OSS to thrive, we need companies and governments to step up and provide consistent funding and support to maintainers. Their work is the backbone of digital innovation, and without addressing this imbalance, we're risking the future of open source.
In this context you might find also interesting our CEO's point of view about fair code and opens source.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.