Who's Keeping the Lights On? The Hidden Cost of Maintaining Open Source Software

Somewhere right now, a developer is staring at a GitHub notifications badge showing 847 unread issues. Most of them are feature requests. A few are angry. Several are duplicates of conversations that were closed two years ago. None of the people filing them are offering to help fix anything.

This is the unglamorous reality of open source maintenance—and it's been quietly breaking people for years.

The open source ecosystem is foundational infrastructure for modern software. The libraries, frameworks, and tools that power everything from Fortune 500 enterprise apps to your favorite indie startup's backend were largely built by individuals or small groups who published their work freely. That generosity created enormous value. It also created an unsustainable expectation.

The Myth of the Joyful Volunteer

The romantic image of open source is a community of passionate contributors collaborating for the love of it. And for a lot of projects, especially in their early days, that's genuinely true. The initial energy of building something useful and sharing it is real.

What the mythology skips is what happens three, five, ten years later, when that project has become load-bearing infrastructure for thousands of production systems and the original creator is still the one triaging issues at 11pm on a Tuesday.

Burnout in open source isn't a new story, but the conversation around it has sharpened considerably. The Log4Shell vulnerability in 2021 was a watershed moment—a critical flaw in a widely-used Java library maintained by volunteers who had no obligation to anyone and no resources to respond to a global emergency. The companies whose products were exposed scrambled. The maintainer community watched and felt something between vindication and despair.

"I had companies emailing me directly demanding patches within 24 hours," one long-time open source maintainer based in the Pacific Northwest told us. "These are companies making millions of dollars off software that includes my work. I've never received a dollar from any of them."

The Emotional Ledger

Beyond the economics, there's the psychological weight. Maintainers often describe a particular kind of exhaustion that's different from regular job stress. It's the combination of high visibility, low support, and a user base that defaults to entitlement.

Public repositories attract public criticism. A poorly-worded issue can turn into a thread of pile-on complaints. Decisions about deprecating features or changing APIs—choices that any software team makes routinely—become community flashpoints when made in open source contexts. Maintainers absorb this without the buffer of a PR team, a manager, or even a paycheck to offset the friction.

Some step back entirely. Others set their repositories to "maintenance mode" and stop responding to issues. A few have written long, honest posts about the toll the work took on them before walking away. The loss isn't just personal—when a critical project goes unmaintained, every downstream dependency becomes a quiet liability.

Money Is Finally Entering the Conversation

For a long time, discussing payment in open source felt almost taboo—like it violated some purity of the gift economy. That norm is eroding, and good riddance.

GitHub Sponsors launched in 2019 and gave maintainers a direct way to accept contributions from individuals and organizations. Adoption has been real, if uneven. A handful of high-profile maintainers have built meaningful income streams through sponsorships. Many more collect a few hundred dollars a month—meaningful but not transformative.

Open Collective has become a popular structure for projects that want more transparency and community governance around how money flows. Maintainers can publish budgets, pay contributors, and give sponsors visibility into where funds go. It's not perfect, but it formalizes something that used to be entirely informal.

Then there's the dual-licensing model, which some projects have adopted to create a commercial tier alongside the open source version. HashiCorp's controversial switch to the Business Source License last year ignited a fierce debate about where the line sits between sustainable business and breaking open source promises. The resulting OpenTofu fork showed that the community will push back hard when it feels that line has been crossed.

Corporate Sponsorship: Necessary but Complicated

Some of the most impactful funding for open source now comes from large corporations—Google, Microsoft, Amazon, and others who have a direct stake in the health of the ecosystem they depend on. The OpenSSF (Open Source Security Foundation) and similar initiatives channel real money into security audits, developer time, and project sustainability.

But corporate sponsorship comes with its own tensions. Companies have priorities that don't always align with community interests. Funded projects can drift toward serving their largest sponsors. And smaller, less glamorous projects—the ones doing essential but unglamorous work—often get ignored entirely in favor of high-profile frameworks.

Maintainers who've navigated corporate relationships describe it as a delicate negotiation. You need the resources. You also need to protect the independence that makes the project worth anything in the first place.

Setting Limits as a Form of Sustainability

Perhaps the most powerful shift happening right now isn't about money at all—it's about maintainers explicitly defining what they will and won't do.

README files that used to say "contributions welcome" are now sometimes accompanied by clear scope statements: what the project is for, what kinds of issues will be addressed, and what response time users can realistically expect. Some maintainers have added explicit statements that this is a hobby project maintained in personal time, not a commercial product with a support obligation.

This boundary-setting has been polarizing. Some users push back, feeling entitled to more. But within maintainer communities, it's increasingly seen as not just acceptable but necessary—a form of self-preservation that ultimately keeps projects alive longer than burning out and disappearing would.

The open source world built the internet as we know it. The people who maintain it deserve better than a thank-you in a blog post and a stack of unpaid support tickets. The models that treat sustainability as an afterthought are starting to give way to something more honest—and the developers who've been keeping the lights on deserve that shift more than anyone.