Who Pays for the Code the Internet Runs On?

There's a dependency somewhere in your production stack — probably several — being maintained by a person who has a day job, answers GitHub issues at night, and hasn't taken a real vacation in two years. You almost certainly don't know their name. Your company almost certainly hasn't paid them anything.

This is not a new problem. It's a structural one, and it's getting harder to look away from.

The Math Doesn't Work

The scale of the mismatch is genuinely staggering when you look at it directly. A single developer maintaining a widely-used npm package might have their code running inside applications worth billions of dollars. A small team keeping a critical cryptography library alive might be operating on donations that amount to less than a junior engineer's monthly salary at one of the companies depending on their work.

The log4shell vulnerability in 2021 was a useful stress test for how the industry thinks about this. A critical flaw in a library maintained largely by volunteers, embedded in thousands of enterprise systems, caused a global scramble that cost companies enormous amounts in emergency patching. The maintainers who'd been keeping log4j alive for years received... significantly less attention before the crisis than after it.

The post-incident conversation was mostly about patching timelines and corporate risk. The conversation about what it actually takes to maintain critical open-source infrastructure — and who should fund it — was shorter and quieter.

What Burnout Actually Looks Like

Maintainer burnout isn't usually dramatic. It rarely ends with a public manifesto or a viral post. It's more often a gradual withdrawal — issues going unanswered for longer, releases slowing down, the maintainer's name disappearing from commit history over the course of a year.

Sometimes it ends with a project being abandoned. Sometimes the maintainer transfers ownership to someone they barely know because they just want it off their plate. Occasionally, that someone has bad intentions, which is how supply chain attacks happen.

The emotional labor component gets underestimated. Maintaining a popular open-source project means fielding feature requests from people who treat you like a vendor, bug reports from people who are frustrated and sometimes rude, and security disclosures that require immediate all-hands attention regardless of what else is going on in your life. All of that, typically, for free.

One maintainer of a popular JavaScript utility library described the experience as running a customer support operation for a product you're not allowed to charge for. The entitlement from some users is real, and it compounds over time.

The Models That Are Actually Working

The encouraging part is that the industry has been quietly running experiments on sustainable funding models for several years now, and some clear patterns are starting to emerge.

GitHub Sponsors and direct patronage work better than most people expected for maintainers who have built genuine community relationships. It's not a solution at scale — the amounts rarely replace a full-time income — but for part-time projects or maintainers willing to treat it as a supplement, it's real money that wasn't there five years ago. The friction of actually setting it up and asking for support is still a barrier a lot of maintainers underestimate.

Dual licensing has become a serious model for projects that serve both individual developers and enterprise customers. The basic approach: free for open-source and non-commercial use, commercial license required for companies. HashiCorp's controversial move to the Business Source License sparked a lot of debate, but the underlying tension it exposed — enterprises extracting value without contributing — is legitimate. Projects like Elasticsearch, MariaDB, and others have navigated versions of this tradeoff with varying results.

Commercial support and managed services is probably the model with the most proven track record. Red Hat built an entire company on it. The pattern works when the open-source project is genuinely complex to operate and enterprises genuinely need help running it. Confluent with Kafka, Elastic with Elasticsearch, MongoDB (controversially) with its own database — these are all variations on the same basic idea: the software is free, but running it reliably at scale is a service worth paying for.

Open-source foundations with corporate membership tiers have had mixed results. The Linux Foundation, Apache Foundation, and others provide structure and sometimes funding, but the money doesn't always flow to the individual maintainers who need it most. A lot depends on how the specific project's governance is set up.

The Corporate Contribution Gap

Worth naming directly: many large technology companies have formal open-source programs and talk extensively about their commitment to the ecosystem while systematically undercontributing to the specific projects their products depend on.

There are genuine exceptions. Google, Microsoft, and Meta have contributed significant engineering resources to foundational projects. Some companies have started paying maintainers directly through sponsorship programs. But the gap between corporate rhetoric about open-source and actual resource contribution remains large.

The companies most likely to contribute meaningfully tend to be the ones that have experienced the consequences of a critical dependency going unmaintained. It's a reactive model, and it means the funding often arrives after the damage is done.

What Early Adopters Can Actually Do

For developers reading this who want to be part of the solution rather than part of the problem, the actions are pretty concrete.

If your company uses an open-source project in production, bring it up in your next budget conversation. Not as charity — as operational risk management. An unmaintained dependency is a liability. Funding the maintainer is a reasonable hedge against that risk, and it's a conversation most finance teams can understand.

If you're an individual developer, GitHub Sponsors and Open Collective make it easy to send even small amounts to projects you rely on. $10 a month across three or four projects isn't going to change anyone's life, but it signals that the work has value — and those signals accumulate.

If you're a maintainer considering your options, the dual-license and commercial support models are more viable than they were even three years ago. The tooling and legal infrastructure for implementing them has improved significantly. You're allowed to build a sustainable business around your work.

The Bigger Question

Underneath all the funding models and sustainability conversations is a question the industry hasn't fully answered: do we treat open-source infrastructure like a public good that deserves collective investment, or like a free resource to extract from until it runs out?

The honest answer right now is mostly the latter, with some encouraging exceptions. The encouraging exceptions are worth studying and scaling.

The code the internet runs on deserves better than hoping the people who write it never get tired.