The email arrived on a Tuesday, which somehow made it worse. A terse note in the issues tracker of a logging library that roughly forty thousand projects had listed as a dependency: "I'm done. No more releases, no more reviews. Good luck." No drama, no farewell thread. Just a person — a name most users had never bothered to learn — walking out of a room they had built with their own hands and quietly closing the door behind them.
I spent the better part of that afternoon reading the maintainer's commit history. Three years of work. Thousands of issues triaged. Comments written with patience that bordered on the saintly, explaining the same edge case to a rotating cast of strangers who never said thank you and occasionally said quite a lot worse. The last commit message read: "fix: one more time, I guess." Four words that contained an entire autobiography.
This is what open source burnout looks like from the outside. From the inside, I'm told, it looks like a Sunday afternoon when you open your laptop and realize you simply cannot make yourself care anymore.
The Invisible Labor Underneath the Software Stack
We have built the modern internet on a foundation of unpaid enthusiasm. That is not an exaggeration or a metaphor — it is a description of the supply chain. The average enterprise application sits atop hundreds of open source dependencies, many of them maintained by one or two people who started the project because they had a problem to solve and the itch to solve it elegantly. The corporate world took that gift and industrialized it. The maintainer got a GitHub star and, if they were lucky, a mention in a conference talk they weren't invited to attend.
The labor is invisible in the specific way that all infrastructure labor is invisible: you only notice it when it stops. A road crew is unremarkable until the pothole opens. A maintainer is background noise until the CVE lands and the Slack channels light up demanding a patch by morning. The dependency graph that makes a CTO's quarterly review look efficient is also a map of human attention that was never compensated, never budgeted for, and never honestly accounted for.
What makes open source burnout distinct from ordinary job burnout is the absence of a social contract. An employee who is overworked can, at minimum, point to a paycheck and call it an exchange. A maintainer who is overworked has nothing to point to except the gap between what they were promised — the romantic notion of collaborative software built by a community — and what they received, which is an inbox and a set of expectations that compound interest without anyone's explicit consent.
The Moment the Fun Leaves the Room
Every maintainer I have read about or spoken with describes a version of the same inflection point. There is a before, when the project feels like play — when a clever pull request is a small joy and a good issue report is a puzzle worth solving. And there is an after, when the project has become a second job with worse hours and no HR department.
The transition is rarely dramatic. It is the accumulation of small indignities: the user who files a bug report written in the tone of a complaint to a customer service department; the company whose entire product depends on your library and who has never once contributed a line of code or a dollar; the well-meaning contributor whose pull request requires three rounds of careful, diplomatic feedback before it can be merged, and who then disappears, leaving the maintainer to either merge something half-finished or close the PR and absorb the social cost of seeming unwelcoming.
There is a particular cruelty in the open source social economy: the more successful your project becomes, the worse the ratio gets. Success means more users. More users means more issues. More issues means more triage, more context-switching, more of your Saturday mornings. The reward for doing good work is more work, delivered by strangers, with urgency attached.
This is not a bug in the system. It is the system.
What Sustainability Efforts Get Wrong
The open source community has not ignored this problem. Platforms like GitHub Sponsors, Open Collective, and Tidelift represent genuine attempts to route money toward the people doing the work. Some maintainers have found real relief there. Most have not.
The failure mode is structural. Donations are voluntary, and voluntary systems tend to underfund public goods — this is one of the oldest findings in economics, and software is not exempt. The companies that extract the most value from open source are also the ones least likely to contribute back, because contributing back is optional and quarterly earnings are not. Individual developers who want to sponsor a maintainer are often more willing than their employers, but they are also the ones with less money to spare.
There is also a subtler problem with the framing of sustainability as primarily a financial question. Money helps. Money is not the whole answer. A maintainer who is paid a modest stipend but still receives a hundred hostile issues a week has not had their burnout addressed — they have had it monetized. What many maintainers describe wanting is not just income but legitimacy: the acknowledgment that what they do is real work, that their time has value, that the boundary they draw around their weekend is a reasonable one and not a betrayal of the open source ethos.
The most corrosive thing the industry ever did to open source maintainers was convince them that wanting to be treated like professionals was somehow ideologically suspect.
The Quiet Exits and What They Cost
When a maintainer quits, the departure is rarely loud. There is no press release, no severance package, no exit interview. There is a repository that stops updating, a changelog that stops moving, a person who stops answering. The software doesn't break immediately — that's what makes the situation so easy to ignore. The library still installs. The tests still pass. The rot is slow.
And then, one day, a security researcher finds a vulnerability. Or a new version of Node drops and the package throws an error that nobody knows how to fix because the person who understood the internals left eighteen months ago and archived the repo on their way out. The forty thousand downstream projects discover, at roughly the same moment, that they have been building on a foundation that nobody has been maintaining.
This is not a hypothetical. It has happened, more than once, in ways that made headlines. The open source burnout problem is not just a human welfare issue, though it is certainly that. It is a systemic risk that the industry has chosen, collectively, to treat as someone else's problem.
The someone else, in every case, is the maintainer.
What a More Honest Relationship Might Look Like
I don't think there is a clean resolution here, and I am suspicious of anyone who offers one. The economics of open source are genuinely hard. The cultural norms were set decades ago by people who could not have anticipated what the software supply chain would become, and norms are slow to change even when everyone agrees they should.
But I think the beginning of a more honest relationship looks like companies auditing their dependency trees and asking, seriously, what it would cost to fund the humans behind the critical ones. It looks like treating a maintainer's decision to limit their availability as a reasonable professional boundary rather than a community failure. It looks like users who remember that a GitHub issue is a message to a person, not a ticket submitted to a system.
Mostly, I think it looks like the industry stopping the performance of surprise every time a maintainer burns out and quits. We know why it happens. We have known for years. The question open source burnout keeps asking us — the one we keep declining to answer — is not why do maintainers quit but what are we prepared to change so that they don't have to?
That Tuesday email is still sitting in the issues tracker. The repository has 847 open issues and no one assigned to any of them. The software still installs fine.