60% of OSS Maintainers Are Unpaid, 44% Report Burnout — And Your Company's Entire Infrastructure Depends on Them

alex_infrastructure · February 10, 2026, 7:33pm

I maintain three internal infrastructure tools and contribute to two external open source projects. I have been doing this for six years. Last month I spent a Saturday debugging a critical memory leak in one of our internal tools that depends on an OSS library whose sole maintainer hadn’t pushed a commit in four months. When I tracked him down on GitHub, his last public message was: “I can’t keep doing this for free. If anyone wants to take over, please reach out.”

Nobody had reached out.

This is not an isolated story. This is the story of open source in 2026.

The Numbers Are Damning

According to byteiota’s analysis of the open source maintainer crisis, 60% of open source maintainers work unpaid. Not underpaid — unpaid. Zero compensation for maintaining software that Fortune 500 companies build their entire revenue-generating infrastructure on.

Nearly 60% of maintainers have either left or considered leaving a project, with 54% citing competing life demands, 51% citing loss of interest, and 44% citing burnout as their reason for walking away. Linux Insider’s report on open source in 2026 calls this a “defining moment” for the ecosystem — and I think that’s underselling the severity.

The Tidelift maintainer survey confirmed these numbers: maintainer burnout is real, widespread, and getting worse, not better. Paid maintainers are 55% more likely to implement critical security practices, spend 13% of their time on security work vs. 10% for unpaid maintainers, and resolve vulnerabilities 45% faster with 50% fewer vulnerabilities overall.

In other words: paying maintainers doesn’t just prevent burnout — it directly improves the security of software your company depends on.

This Is Not Hypothetical — It’s Happening Now

Kubernetes Ingress NGINX — one of the most widely deployed components in the Kubernetes ecosystem — has been retired and will receive no security patches after March 2026. The reason? Maintainer burnout. The project was running on the backs of one or two developers working nights and weekends, facing an endless flood of bugs, feature requests, and security issues. The Kubernetes SIG Network and Security Response Committee recommended immediate migration because they could no longer guarantee the component’s safety.

Think about that. One of the most critical pieces of cloud-native infrastructure is being abandoned because we, as an industry, couldn’t be bothered to fund the people maintaining it.

The External Secrets Operator — used in critical enterprise systems globally — froze all updates. Four maintainers burned out. One active contributor remained.

And then there’s XZ Utils. The 2024 backdoor that nearly compromised every Linux system running OpenSSH was a direct consequence of maintainer burnout. The original maintainer, overwhelmed and exhausted, gradually ceded control to a malicious actor — “Jia Tan” — who had spent three years building trust through sock puppet accounts pressuring the maintainer to accept help. CISA’s post-incident analysis was blunt: this attack exploited the human vulnerabilities created by an unsustainable maintenance model.

The XZ Utils attack was not sophisticated cryptography. It was social engineering targeting a burned-out human being. And there are thousands of projects in the same position right now.

The Freeloading Problem

The Open Source Pledge asks companies to pay a minimum of ,000 per developer per year to OSS maintainers. Sentry, the organization behind the pledge, contributes ,813 per developer — 2.9x the minimum.

How many companies have signed up? Roughly 4,200 out of an estimated 300 million companies that use open source software. That is a 99.999% freeloading rate.

Let me make this concrete. Your company almost certainly uses hundreds or thousands of OSS packages. Each one has maintainers who are likely unpaid, potentially burned out, and one bad month away from abandoning the project. When that happens, you get one of three outcomes:

The project stagnates — no security patches, no bug fixes, growing incompatibility with modern systems
A malicious actor fills the vacuum — the XZ Utils scenario
Your team scrambles to fork and maintain it internally — at 10x the cost of having funded the maintainer

What Should Companies Actually Do?

I’m asking this genuinely because I’ve been involved in this ecosystem long enough to know that awareness campaigns alone don’t work. We’ve been talking about maintainer burnout for a decade. The numbers keep getting worse.

Here’s what I think the minimum viable response looks like:

Pay the Open Source Pledge. K/dev/year is a rounding error on any serious engineering budget. Just do it.
Give engineers time for upstream contributions. Not as a perk — as a strategic investment. When a critical dependency loses its maintainer, your team needs to be positioned to step in.
Audit your dependency tree for bus-factor risk. Identify every critical package maintained by one or two people. Those are your highest-risk dependencies, regardless of how stable the code looks today.
Fund maintainers directly. Not through foundations with 40% overhead. Direct sponsorship through GitHub Sponsors, Open Collective, or direct contracts. The maintainer of your most critical dependency should have your finance team’s phone number.
Build internal tooling to reduce maintainer burden. Automated testing, CI/CD templates, documentation generators — anything that reduces the toil for maintainers of projects you depend on.

The tragedy of the commons only holds when there’s no coordination mechanism. We have coordination mechanisms. We have the Open Source Pledge, we have foundations, we have GitHub Sponsors. What we lack is the will to use them.

Your company’s entire infrastructure is a house of cards built on the free labor of exhausted strangers. What are you going to do about it?

finance_carlos · February 10, 2026, 7:34pm

I ran the numbers on this for our company because @alex_infrastructure’s post made me realize we had never actually quantified our OSS dependency risk in financial terms. The results were sobering.

Our OSS footprint:

~2,400 distinct open source packages in our dependency tree (across all services)
~340 of those are “critical” — meaning a failure or compromise would directly impact production
Of those 340 critical packages, 127 have a bus factor of 1-2 maintainers

The cost of the Open Source Pledge:

We have 200 developers
At the minimum of ,000/dev/year, that’s ,000 annually
Our annual software budget (licenses, SaaS, infrastructure) is approximately M
OSS Pledge = 3.3% of our software budget

What we actually pay for OSS today: /bin/zsh. Zero. Nothing. We use M worth of commercial software built on top of OSS that we pay nothing for.

Now let me frame the ROI differently, because this is how I think about it as a finance person.

Cost of a single OSS-related incident:

Average production incident costs our company ~K in engineering time + lost revenue
We had 3 incidents last year directly attributable to stale or unmaintained dependencies
That’s K in incident costs alone
Not counting the 2 weeks an engineer spent forking and patching an abandoned library (K in fully loaded salary)
Total quantifiable cost: ~K/year from OSS neglect

Cost of the XZ Utils scenario:

If a compromised dependency had led to a data breach, our estimated liability (based on industry averages for our data volume) would be .5M-M
Regulatory fines under the frameworks we’re subject to: up to M
Reputational cost: unquantifiable but historically devastating for companies our size

So the math is:

Scenario	Annual Cost
Do nothing	K known + unquantified tail risk
Open Source Pledge	K
Major OSS supply chain breach	.5M - M

The Pledge looks expensive compared to the known costs — until you factor in the tail risk. This is insurance math. You pay K/year to reduce the probability of a .5M+ event. Any risk analyst would take that trade.

So why don’t companies pay?

Three reasons, in my experience:

No budget line item. There’s a line item for AWS. There’s a line item for Datadog. There is no line item for “open source dependency maintenance.” Nobody owns it, so nobody funds it. Finance teams don’t fund things without an owner.
The free rider problem is rational at the individual level. If 300 million companies use React and your company stops paying, React doesn’t die. The incentive to free ride is overwhelming for any single actor. This is textbook tragedy of the commons.
Funding mechanisms are fragmented. GitHub Sponsors, Open Collective, Tidelift, direct contracts — there’s no single, frictionless way to pay. Compare this to how easy it is to swipe a credit card for a SaaS tool. The OSS funding ecosystem has a checkout conversion problem.

My recommendation to any CFO reading this: create a dedicated OSS sustainability budget. Start at 1% of your software spend. You’ll recover the cost in reduced incident response alone within the first year, and you’ll be reducing a tail risk that could be existential.

The ROI is obvious. The math works. The question is whether finance and engineering leadership will treat this as the infrastructure investment it is rather than the charity it isn’t.

cto_michelle · February 10, 2026, 7:34pm

I implemented an OSS contribution policy at my company two years ago, and I want to share what actually works — and what doesn’t — based on real experience rather than theory.

What we do: Engineers get 10% of their time for upstream contributions to open source dependencies we actively use. This isn’t charity. This isn’t a feel-good perk. This is risk management, and I frame it that way to the board.

Here’s what convinced my CEO: I showed him three specific examples of companies that got burned by abandoned packages in the past 18 months.

Case 1: A mid-size fintech (company I advise) relied on a logging library whose maintainer disappeared. They discovered a critical memory leak in production during their peak traffic season. No upstream fix was coming. They spent 6 engineer-weeks forking, patching, and verifying the fix. Cost: roughly K in engineering time plus estimated revenue impact.

Case 2: A Series C startup in our portfolio used a payment processing wrapper whose maintainer switched it to a restrictive license after a dispute with a corporate user. Three months of migration work.

Case 3: The Kubernetes Ingress NGINX situation that @alex_infrastructure described. One of my teams was running Ingress NGINX in production. When the retirement was announced, we had a 4-month window to migrate 23 services to the Gateway API. Because we had engineers who had been contributing upstream to Kubernetes networking components, they already understood the Gateway API internals and were able to lead the migration. Teams without that institutional knowledge are still scrambling.

The 10% time policy in practice:

It’s not evenly distributed. Not every engineer contributes upstream. In practice, about 30% of our engineers actively use the time, and they tend to be seniors who already have relationships with OSS projects. The other 70% benefit indirectly because those seniors build institutional knowledge about our dependency tree.

What the 10% time has given us:

Early warning system. Our engineers in OSS communities hear about maintainer burnout, license changes, and deprecations months before they become public announcements. We started our Ingress NGINX migration planning 6 weeks before the official retirement blog post because our contributor saw the writing on the wall.
Ability to step in. When a dependency we use lost its primary maintainer, one of our engineers was already the #3 contributor. She stepped into a co-maintainer role, ensuring the project continued to receive security patches. That’s not altruism — that’s protecting our production systems.
Recruiting advantage. Senior engineers who care about OSS — exactly the kind of people you want — seek out companies with contribution policies. It’s become one of our best recruiting differentiators.

What doesn’t work:

Asking engineers to contribute on their own time. They won’t, or they’ll burn out themselves. It has to be on the clock.
Trying to contribute to everything. Focus on your critical path dependencies. We prioritize contributions to the 20-30 packages where a maintainer loss would directly impact production.
Foundation-only funding. I love the Linux Foundation, the Apache Foundation, and others. But a lot of foundation money goes to governance, events, and infrastructure rather than directly to the maintainer who’s debugging your CVE at midnight. Direct funding to individual maintainers through GitHub Sponsors or contracts is more impactful per dollar.

What I’d push back on in the original post:

@alex_infrastructure, I agree with everything you said except the implicit assumption that this is primarily a money problem. Money is necessary but not sufficient. Many maintainers have told me that what they need even more than funding is help — co-maintainers who can share the review burden, triage issues, and handle the emotional labor of managing an OSS community. The 10% time policy addresses this directly in a way that writing a check to a foundation does not.

The real question isn’t just “will companies pay?” It’s “will companies contribute engineers, not just dollars?” Because a burned-out maintainer with a K/year sponsorship is still a burned-out maintainer if they’re the only person reviewing PRs.

vp_eng_keisha · February 10, 2026, 7:35pm

I serve on the board of an open source foundation, and I want to give you all the uncomfortable view from the inside — because the dysfunction is worse than most people realize.

The 99.999% freeloading rate that @alex_infrastructure cited — 4,200 companies paying out of roughly 300 million that use OSS — is not just a statistic. I’ve watched this play out at the foundation level for three years, and here’s what it actually looks like:

Foundation funding reality:

Our foundation manages ~40 critical infrastructure projects
Annual budget: M (sounds like a lot until you divide it across 40 projects)
Average per-project funding: K/year
Of that, ~40% goes to foundation overhead (governance, legal, events, infrastructure)
Actual money reaching maintainers per project: ~K/year
Number of active maintainers per project who receive any compensation: typically 1-2

So when a company says “we donate to the Linux Foundation,” what that often means in practice is that a small fraction of their donation reaches the specific maintainer of the specific package their production systems depend on. The indirection is enormous.

The systemic failure:

@cto_michelle makes an excellent point that this isn’t just a money problem — it’s also a people problem. But I’d go further. This is a structural problem that individual company actions cannot solve at scale.

Here’s why: Michelle’s 10% time policy is genuinely excellent, and I wish every company did it. But it only works for companies that are large enough to afford 10% productivity allocation and sophisticated enough to identify their critical dependencies. That’s maybe the top 5% of companies by engineering maturity. The other 95% — including the vast majority of those 300 million companies — will never implement contribution policies. They don’t have the awareness, the engineering culture, or the organizational capacity.

Company-level solutions address the problem for individual companies. They don’t address the systemic failure.

What a systemic solution looks like:

I’ve been advocating for what I call an “OSS infrastructure tax” model, similar to how companies pay for physical infrastructure through taxes and utility fees. Here’s the concept:

Package registries (npm, PyPI, Maven, crates.io) add a sustainability fee. Not per download — that would kill the model — but a flat annual fee for commercial organizations that exceed a usage threshold. Even /year from the top 1 million commercial npm users would generate M annually.
Cloud providers bundle OSS sustainability into their pricing. AWS, Azure, and GCP profit enormously from OSS. A 0.1% surcharge on compute bills, directed to a transparent fund for critical OSS dependencies, would generate hundreds of millions. Some cloud providers are already large OSS contributors — this would formalize and expand that.
Software supply chain transparency requirements create natural funding pressure. The EU Cyber Resilience Act and US CISA guidance are pushing companies to maintain SBOMs (Software Bills of Materials). Once companies are legally required to know what OSS they depend on, it becomes much harder to pretend the funding problem doesn’t exist. Regulation creates awareness, and awareness creates funding pressure.
Automated dependency health scoring tied to procurement. If your company’s risk team could see that a critical dependency has a bus factor of 1 and an average maintainer response time of 45 days, that would naturally trigger funding or migration decisions. The tooling for this exists (Socket, Snyk, deps.dev) — it just needs to be integrated into procurement workflows.

The uncomfortable truth:

I’ve watched well-intentioned people propose voluntary solutions for a decade. The Open Source Pledge is admirable. Company contribution policies are smart. GitHub Sponsors is useful. None of them have moved the needle on the macro numbers. 60% unpaid. 44% burned out. The same stats, year after year, while the ecosystem’s criticality only grows.

Voluntary solutions work for the companies that were already going to do the right thing. They don’t work for the other 99.999%. The solution needs to be systemic — built into the infrastructure of how software is distributed, consumed, and regulated — not dependent on the goodwill of individual organizations.

The question isn’t whether companies should fund OSS. Everyone in this thread agrees they should. The question is how we build a system where funding happens by default rather than by exception. That’s a policy and infrastructure challenge, not a moral persuasion one.