When a highway is built with public funds, the state maintains it. When a bridge collapses, the engineers are licensed and accountable. When a critical piece of software underpins the global financial system, healthcare infrastructure and national security, its maintenance is often the unpaid labor of a single developer in a basement. The Open Source Definition, ratified by the Open Source Initiative in 1998, established that open source means freedom to use, modify and distribute. It did not establish who pays for the maintenance, the security audits, or the burnout recovery. That gap is now the defining crisis of the ecosystem.

The Dependency Debt No One Is Pricing

The Synopsys Open Source Security Report 2024 found that open source components constitute 70-90% of modern codebases, yet most organizations lack inventory of what they are using, let alone who maintains it. The Log4j vulnerability of December 2021 exposed this reality: a logging library maintained by volunteers, used by millions of applications, contained a critical flaw that took days to patch because the maintainers were overwhelmed. The response was a flurry of government advisories and corporate panic. The structural problem — that critical infrastructure depends on uncompensated labor — remains unaddressed. Organizations that treat open source as "free" are not saving money; they are externalizing maintenance costs onto individuals who cannot afford to provide them.

Maintainer Burnout Is a Supply Chain Risk

The Linux Foundation's 2023 report on open source sustainability found that 60% of maintainers report feeling burned out, and 40% have considered leaving their projects. This is not a human resources issue; it is a supply chain risk. When a critical dependency is maintained by a single individual who quits, the downstream impact is immediate and unmitigated. The xz Utils backdoor attempt in March 2024 demonstrated this: a malicious actor spent years building trust with a maintainer to gain commit access, exploiting the reality that maintainers are isolated, under-resourced and eager for help. Security is not just about code quality; it is about whether the people maintaining the code can sustain the work.

Corporate Capture and the Open Core Trap

The dominant business model for open source companies is "open core": release a community edition under an open source license, then charge for enterprise features, support or managed services. This model has funded successful companies — GitLab, Elastic, MongoDB — but it creates a structural tension. The community edition receives minimal investment, while the enterprise edition captures all the revenue. Maintainers who contribute to the community edition find their work is a loss leader for a commercial product they do not control. When Elastic changed its license from Apache 2.0 to a proprietary Server Side Public License in 2021, the community forked it as OpenSearch. The lesson is that open source licenses do not guarantee community governance; they guarantee freedom to fork, which is a different thing entirely.

Counter-Argument: Corporate Investment Is the Only Scalable Model

The strongest case for the open core model is that it is the only mechanism that has scaled open source to enterprise adoption. Pure community governance, as seen in projects like Apache or the Linux kernel, works when the maintainers are employed by corporations that benefit from the work. When Linus Torvalds was hired by the Linux Foundation, it was not because the community could pay him; it was because corporations using Linux needed a neutral steward. The counter-argument is that expecting volunteers to maintain critical infrastructure is not sustainable, and that corporate employment of maintainers — even within an open core structure — is the only realistic path to professionalization. The community may not control the roadmap, but at least the code gets maintained.

The Mozilla Precedent: Foundation Governance as a Compromise

When Netscape released the Mozilla codebase as open source in 1998, it created the Mozilla Foundation to steward the project. The Foundation is a non-profit that employs developers, receives corporate donations, and governs the Firefox browser. This model — a foundation with corporate backing but community governance — has been replicated by the Apache Software Foundation, the Linux Foundation, and the Cloud Native Computing Foundation. The lesson is that pure community governance rarely works at scale; some institutional structure is necessary to handle legal liability, financial management and strategic direction. The Mozilla model is not perfect — it still depends on corporate donations, and its governance can be opaque — but it demonstrates that open source can be professionalized without being captured.

What the Founders Actually Said

Bruce Perens, co-author of the Open Source Definition, stated in a 2020 interview:

"We thought the license would be enough. We thought that if the code was free, the community would sustain it. We were wrong. The license protects freedom, but it doesn't pay for maintenance." — Bruce Perens, interview with The New Stack, 2020

That admission matters. The open source movement succeeded in its technical and legal objectives: open source won, and proprietary software is now the exception in infrastructure. But it failed to solve the economic problem: who pays for the work? The answer, so far, has been "no one, until something breaks."

Counter-Argument: The Tragedy of the Commons Is Inevitable

Economists have long understood that common-pool resources — resources that are non-excludable but rivalrous — are subject to overuse and under-investment. Open source code is a common-pool resource: anyone can use it, but maintenance is finite. The tragedy of the commons predicts that without exclusion mechanisms, the resource will be depleted. The counter-argument is that open source is not a tragedy; it is a gift economy, where contributors give labor in exchange for reputation, skill development or altruistic satisfaction. But gift economies work at small scale; they do not scale to global infrastructure. The xz Utils incident demonstrated that when the stakes are high, gift economies are vulnerable to capture. The question is not whether open source can remain a gift economy; it is whether it can transition to a sustainable economic model without losing its openness.

What Organizations Should Do This Quarter

  • Inventory your dependencies. Use software composition analysis tools to identify every open source component in your stack. You cannot manage what you have not measured.
  • Budget for maintenance. Identify the critical dependencies in your stack and contribute to their maintainers, either through direct sponsorship, corporate membership in foundations, or employee contributions. Treat this as infrastructure cost, not charity.
  • Review your licenses. Understand the difference between permissive licenses (MIT, Apache 2.0) and copyleft licenses (GPL). The license determines your obligations when you distribute modified code. Legal review is not optional.
  • Release your own code strategically. If your organization builds internal tools that could benefit the community, release them under an open source license. This builds goodwill, attracts talent and reduces duplication. But do not release code you cannot maintain; abandoned open source projects are worse than proprietary ones.

The Six-Month Test

Open source won the technical battle. The economic battle is just beginning.