A critical open-source library used by thousands of companies, including several Fortune 500 firms, is maintained by one person in their spare time. This is not a hypothetical. It is a description of dozens of projects that form the foundation of modern software infrastructure. The maintainers of these projects are volunteers. The companies that depend on their work generate billions of dollars in revenue from that dependence.

The open-source sustainability problem is not new. But the AI era has made it more acute, because AI systems depend on open-source software at every layer — from the operating systems that run training clusters to the frameworks that orchestrate model training to the libraries that handle data preprocessing. The AI industry is built on open-source infrastructure, and the people who maintain that infrastructure are, in most cases, uncompensated.

The free rider problem at scale

Open-source software creates a classic free rider problem. The benefits of the software are non-excludable — anyone can use it. The costs of producing and maintaining the software fall on the maintainers. When the software is used by individuals and small companies, the free rider problem is manageable because the maintenance burden is small. When the software is used by large enterprises at scale, the maintenance burden grows with the user base, but the compensation does not.

The asymmetry is stark. A company that saves millions of dollars annually by building on open-source infrastructure contributes nothing to the maintenance of that infrastructure. The maintainer fixes bugs, reviews pull requests, handles security vulnerabilities, and manages community dynamics — all without compensation. When the maintainer burns out and abandons the project, the company that depended on it discovers, suddenly and expensively, that the “free” software they were using was subsidized by someone else’s unpaid labor.

This dynamic plays out repeatedly. The left-pad incident in 2016, where one developer’s removal of a small npm package broke thousands of projects, was a visible demonstration of the fragility. The Log4j vulnerability in 2021 showed the security consequences of undermaintained critical infrastructure. The xz utils backdoor attempt in 2024 showed what happens when a critical project is maintained by a single person who becomes a target for social engineering.

AI’s compounding dependency

AI systems deepen the open-source sustainability problem in three ways.

The dependency stack is deeper. A typical AI application depends on an operating system, container runtime, orchestration platform, programming language runtime, ML framework, data processing library, serving infrastructure, monitoring tools, and dozens of smaller libraries. Each layer of this stack includes open-source components maintained by people who are not compensated by the companies running AI workloads on their software.

The performance demands are higher. AI workloads push infrastructure to its limits, which means they expose edge cases and performance bottlenecks that casual users do not encounter. Maintainers of infrastructure software receive bug reports and feature requests from AI companies that are using their software at scales the maintainers never anticipated and cannot test against. The maintenance burden increases with the most demanding users, and the most demanding users are often the least likely to contribute.

The talent drain is accelerating. The same companies that depend on open-source infrastructure are hiring open-source maintainers away from their projects. When a maintainer joins a company, their open-source maintenance typically decreases or stops. The project loses its most experienced contributor. The company gains an employee who understands the project but is now paid to work on the company’s internal systems, not on the open-source project the company depends on.

Models that partially work

Several models for sustaining open-source development have been tried. None has solved the problem completely, but each offers lessons.

Corporate sponsorship. Companies like Google, Microsoft, and Meta fund significant open-source development. This works for high-profile projects that align with the sponsor’s strategic interests. It does not work for the long tail of critical-but-unsexy infrastructure projects that do not have a corporate champion.

Open-core licensing. Projects offer a free open-source core and a paid commercial version with additional features. This works for projects where the commercial features are valuable enough to justify the cost. It does not work for libraries and frameworks where the core functionality is what everyone needs and there is no natural boundary between free and paid.

GitHub Sponsors and donation platforms. Individual developers receive small recurring donations from users of their software. This works for developers with large, engaged communities. It does not work for maintainers of critical-but-invisible infrastructure — the kind of project that everyone uses but no one thinks about until it breaks.

Venture-funded open source. Companies build open-source products with venture capital, intending to monetize through cloud services, support, or enterprise features. This works for the venture-backed company. It often does not work for the open-source community, because the venture investors’ incentives eventually diverge from the community’s interests — typically around the point where the company needs to show revenue growth and starts restricting the open-source offering.

What organizations should do

If your organization depends on open-source software — and it does, whether you know it or not — you have a responsibility to contribute to the sustainability of that software. The contribution can take several forms.

Fund the maintainers. Identify the critical open-source dependencies in your stack. Determine who maintains them. If those maintainers have sponsorship programs, contribute. If they do not, reach out and offer support. The cost of maintaining a dependency is a fraction of the cost of replacing it when the maintainer burns out.

Contribute engineering time. Assign engineers to contribute to critical open-source projects. Not as a side project during free time, but as a formal allocation with management support and performance evaluation. This benefits both the organization — which gains influence over the projects it depends on — and the project — which gains additional maintenance capacity.

Contribute to foundations. Organizations like the Apache Software Foundation, the Linux Foundation, and the Python Software Foundation provide governance, legal support, and funding for open-source projects. Contributing to these foundations is an efficient way to support the open-source ecosystem without needing to evaluate individual projects.

Do not extract without contributing. This is the ethical minimum. If your organization generates revenue from software that depends on open-source infrastructure, the open-source ecosystem is a supplier. Treat it like one. Negotiate sustainable terms, which in the open-source context means funding or labor contributions proportional to your dependence.

The provocation

The open-source sustainability problem will not be solved by appeals to generosity. It will be solved when organizations recognize that open-source infrastructure is not free — it is subsidized by maintainers’ unpaid labor, and that subsidy has a limit. When the subsidy runs out — when maintainers burn out, when critical projects go unmaintained, when security vulnerabilities go unpatched — the cost falls on the organizations that benefited from the subsidy.

The organizations that will be least affected are the ones that invested in sustainability before the crisis. The organizations that will be most affected are the ones that treated open-source as a costless input to their business. The difference between these two positions is not luck. It is a choice that every organization using open-source software is making, whether it acknowledges the choice or not.