The internet runs on open source. Not metaphorically, literally. The TLS that secures your bank’s website, the kernel that runs most of the cloud, the package manager that built the app on your phone, the database under your customer records. Almost none of it is paid for by the companies that depend on it most.
This is not a new observation, but the gap between use and contribution is widening, and the consequences are starting to show.
The critical projects holding the stack up

Here is a non-exhaustive list of projects that, if they broke tomorrow, would cause global disruption:
- OpenSSL: the cryptographic library that secures most HTTPS traffic on the public internet. Maintained by a small team. Funded by donations and a handful of corporate sponsors.
- Linux kernel: powers most of the cloud, Android, embedded systems, and supercomputers. Maintained by thousands of contributors, but the bulk of long-term maintainer work comes from a small number of companies and individuals.
- curl: the command-line tool that moves data across the internet. Used in billions of devices. Maintained primarily by one person.
- NPM, PyPI, crates.io, Maven Central: the package registries. Their downtime takes down the build pipelines of nearly every software company on earth.
- Kubernetes, TensorFlow, PyTorch, React, Vue, Django, Rails, .NET, Postgres, SQLite, Redis: any of these going sideways would ripple through the industry for weeks.
- Log4j, OpenSSL, libxml2, glibc, zlib: the dependencies nobody thinks about until a CVE drops, and then everyone panics.
This is the floor of the modern economy. It is also, in most cases, two or three unpaid maintainers deep.
The sustainability problem
Open source sustainability is the gap between the value a project provides and the funding it receives. The value is enormous. The funding is often zero.
Why?
- Open source is a public good. Everyone benefits, no one is forced to pay. The standard free-rider problem, scaled to the global economy.
- The maintainers are often underpaid or unpaid. The people who fix the critical CVEs in your dependencies are, in many cases, doing it on weekends, after their day job, on a coffee budget.
- Corporate contributions are concentrated and uneven. A few large companies (Google, Microsoft, AWS, Red Hat, Intel) fund major projects heavily. Most companies pay nothing.
- Funding mechanisms are still immature. GitHub Sponsors, Open Collective, foundations like the Linux Foundation and Apache Foundation, direct corporate sponsorships. They all work, but they are not at the scale the problem requires.
The result is a software ecosystem where a maintainer burnout, a corporate layoff, or a personal health crisis can put a critical piece of infrastructure at risk.
How bad is it, really?
Bad enough that the US government has started asking. The 2022 White House summit on open source security, the 2023 OpenSSF roadmap, and the EU Cyber Resilience Act all reference “unsustainable open source funding” as a national security issue. It is no longer just a feel-good problem for activists.
The most concrete recent example: the xz utils backdoor attempt in 2024, where a single malicious maintainer nearly got a backdoor into a library used by SSH on most Linux distributions. It was caught by a sharp-eyed Microsoft engineer. The whole thing hinged on one volunteer maintainer, doing good-faith work, slowly being socially engineered into trusting the wrong person.
That was a near miss. The next one might not be.
What companies can do
If you are a company that uses open source (and you are, even if you do not know it), here is the to-do list. The actions are ranked by effort-to-impact ratio.
- Take a real inventory of what you use. Not just your direct dependencies. Transitive ones. SBOMs are not optional anymore. Several regulators require them.
- Identify the maintainers of your critical dependencies. Not the company that hosts the project. The actual humans.
- Pay the maintainers. GitHub Sponsors, Open Collective, direct invoicing. If your company cannot afford to sponsor the projects that keep you in business, the business is not viable.
- Contribute engineering time. Not just money. Allocate 1 to 5 percent of engineering capacity to upstream work. Send people to fix bugs in the dependencies you depend on, not just fork them.
- Participate in foundations. The Linux Foundation, Apache Foundation, OpenJS Foundation, CNCF, Eclipse Foundation, Python Software Foundation. Membership is not cheap but it is cheaper than the alternative.
- Adopt an internal policy. “We use this dependency, we contribute back.” Codify it. Make it a budget line, not a heroics exercise.
What individuals can do
Most of us are not at companies. Most of us are just users, hobbyists, and people who depend on open source daily. Here is the to-do list for the rest of us.
- Star the projects you use. Visibility matters for maintainers. It is free.
- Sponsor the projects you depend on. $5 a month to a maintainer is more than most companies give.
- File good bug reports. A clear repro saves hours of the maintainer’s time.
- Send pull requests. Even a typo fix is one less thing on the maintainer’s plate.
- Document. Maintainers are usually bad at documenting their own work. You can help.
- Be kind in issues. Maintainers burn out faster from toxic users than from technical work.
The bottom line
Open source is not free. It never was. The price was hidden, distributed across maintainers who absorbed it personally, and most of the industry did not notice. The bill is coming due.
It is not a question of whether the open source ecosystem needs more funding. It is a question of who steps up before the next xz utils, before the next Log4Shell, before the next maintainer walks away and a critical project goes unmaintained for a year.
Pay the maintainers. Send the engineers. Use the foundations. The internet you depend on is being held up by people who deserve better than the current deal.
