Suddenly Responsible: The Quiet Crisis Facing Open Source Maintainers Propping Up Enterprise Tech

The Call Nobody Prepared For

Imagine you built a small utility library a few years back. Nothing fancy — just a tool that scratched your own itch, posted to GitHub because why not. You answered a few issues here and there, pushed updates when you felt like it, and mostly forgot about it between sessions.

Then one afternoon you get a message. A company you've never heard of is telling you their entire payment processing pipeline depends on your project, and a bug you introduced two versions ago just took down their production environment. They need a patch. Now.

Welcome to what some in the open source world are calling the maintainer's dilemma — a slow-building crisis where individual developers, often unpaid and working in their spare time, find themselves holding up systems they never agreed to support.

It's more common than most people realize, and it's quietly reshaping how we think about the sustainability of open source software.

How a Hobby Becomes Infrastructure

The path from personal project to critical dependency usually isn't dramatic. It's gradual, almost invisible. A developer at a startup finds your library and drops it into a requirements file. That startup gets acquired. The acquiring company has dozens of services, and your code spreads through them like roots. Nobody audits the dependency tree. Nobody asks if you're okay with any of this.

The event-stream incident from 2018 is probably the most cited cautionary tale here. A widely-used npm package, maintained essentially by one person, was handed off to a stranger who injected malicious code targeting a cryptocurrency wallet. Millions of projects were exposed. The original maintainer hadn't been paid a cent. The community's response was mostly to ask why he hadn't been more careful.

More recently, the XZ Utils backdoor discovered in early 2024 sent shockwaves through the Linux world. A lone maintainer, exhausted and under-resourced, had been socially engineered over the course of nearly two years by a bad actor who embedded a sophisticated backdoor in compression software baked into countless Linux distributions. The maintainer wasn't negligent — they were human, and they were alone.

These aren't edge cases anymore. They're symptoms.

The Psychological Weight of Accidental Ownership

There's a particular kind of stress that comes with being responsible for something you never signed up to be responsible for. Developers who've found themselves in this position describe it in strikingly similar terms: a creeping sense of obligation, guilt when they take time off, and a fear that stepping back means letting people down.

"It stops feeling like your project," one maintainer of a popular Python data-processing library told us. "You start answering to people who treat you like a vendor. They open issues like support tickets. They get angry when you don't respond within 24 hours. And you're sitting there thinking — I have a full-time job. I have kids. This was supposed to be fun."

The emotional labor is real and often invisible. Triaging hostile issue threads, managing competing feature requests from enterprise users with zero budget for contributions, and carrying the ambient anxiety of knowing that somewhere, someone's production system is running your code — it adds up. And burnout, as we've covered before on NetBux, doesn't just hurt maintainers. It puts the entire downstream ecosystem at risk.

What Makes It Worse: The Expectation Gap

Part of what makes this dynamic so corrosive is the expectation mismatch baked into how enterprises consume open source. Many companies treat free software like a free service — complete with implied SLAs, assumed backward compatibility, and an expectation of indefinite support. The license says "use it freely," and some legal teams seem to read that as "use it without consequence."

To be clear: that's not how open source licenses work. MIT, Apache, GPL — none of them obligate a maintainer to fix your bugs, answer your questions, or keep the project alive. But the cultural expectation persists, and it puts enormous informal pressure on individuals who have no legal obligation and no compensation.

Some larger companies are starting to get this. Google, Microsoft, and a handful of others have made meaningful investments in open source security and maintainer support through initiatives like the Open Source Security Foundation (OpenSSF). But for every well-funded foundation project, there are thousands of critical dependencies maintained by people who've never received a dollar for their work.

Practical Frameworks for Drawing Lines

So what can a maintainer actually do when their project outgrows them? A few frameworks have emerged from the community that are worth knowing.

Define your scope in writing — publicly. A SUPPORT.md file or a clearly written README section that spells out what you will and won't do changes the conversation. "This project is maintained on a best-effort basis. It is not suitable for production use without independent evaluation." That one sentence can reset expectations before they calcify.

Adopt a tiered contribution model. Tools like GitHub Sponsors, Open Collective, and Tidelift let maintainers offer differentiated levels of engagement. Some maintainers have started offering paid support tiers for enterprise users while keeping the project itself free and open. It's not a perfect solution, but it creates a sustainable feedback loop between the people who depend on your work and your ability to keep doing it.

Build a governance document before you need one. When a project is small, governance feels like overkill. When it's big, it's already too late to build it without drama. Even a simple document that outlines how decisions get made, who can commit, and what happens if the lead maintainer goes dark is better than nothing.

Give yourself permission to say no. This sounds obvious, but it isn't. Many maintainers struggle with the idea that declining a feature request or closing an issue as out-of-scope is somehow a betrayal of the community. It isn't. Healthy boundaries are what keep maintainers in the game long-term.

Collective Responsibility Looks Like Something

At NetBux, we believe that open tech only works when the whole community takes responsibility for its health — not just the people writing the code. If your company depends on an open source project, ask yourself: Are we contributing back? Are we funding the maintainer? Are we adding to their load or helping carry it?

The infrastructure of the modern internet is held together by an enormous amount of invisible labor. The least we can do is see it clearly — and act accordingly.

The maintainer's dilemma isn't going away on its own. But it is solvable, if enough people decide it's worth solving together.