An August 17 post from Ryan Cheley makes a quiet observation about the Tidelift maintainer survey: when developers explain why they quit or considered quitting open source projects, "loss of interest" came in at 51%. Burnout came in at 44%. "Competing life and work priorities" was first at 54%.
We've been talking about the open source burnout crisis for years. The second-ranked cause isn't burnout.
This matters because burnout and disengagement are different conditions. They look similar from the outside — reduced output, withdrawal, visible decline in enthusiasm — but they have different origins, different trajectories, and different responses. Treating disengagement as burnout is like prescribing rest to someone who isn't tired. The treatment doesn't match the diagnosis.
What the Distinction Actually Is
Burnout is depletion. You've run the tank down past reserve. You're still pointed at the work; the problem is that there's nothing left to drive it. The hallmarks are well-documented: physical and emotional exhaustion, cynicism that wasn't there before, a sense that what you're doing doesn't matter even when you know it does. Rest is the relevant intervention. Given time and reduced demand, the capacity to care and engage typically returns.
Disengagement is directionlessness. You have capacity. You could do the work. You don't know why you would. The maintainer quotes that show up in the 2025 research — "it starts feeling less like building and more like running unpaid support for strangers" — sound less like exhaustion and more like a tank running fine, pointed at nothing.
Cheley's framing is precise: loss of interest is when "someone can still do the work but doesn't know why they're doing it anymore." That's not burnout. That's a meaning problem. And meaning problems don't resolve with rest. They resolve with honest reassessment of whether the work still fits the person, and whether there's a version of the work that would.
The practical difference is significant. Someone burned out often needs the simplest possible answer: stop for a while. Someone disengaged often needs the hardest possible question: is this the right thing to be working on?
Why We Default to the Burnout Frame
The burnout diagnosis is more comfortable to offer and receive. It's medical in tone — sympathetic, not judgmental. It implies that the developer did good work, gave too much, and got depleted. That's a narrative about dedication.
Loss of interest implies something different. It raises the question of whether the work was worth doing in the first place, or whether the person's interests have shifted in ways that make the current project a poor fit. That's harder to say and harder to hear, even when it's obviously true.
There's also a documentation asymmetry. Burnout has clinical frameworks, symptoms checklists, and intervention literature going back decades. Disengagement in open source specifically is harder to operationalize. It shows up in survey write-ins and community anecdotes more often than in structured research. The Tidelift survey is an exception — it actually asked the question, broke out the reasons, and captured a number that turns out to be larger than the burnout number. But the resulting conversation is still mostly "maintainer burnout crisis," because that's the frame people arrived with.
This framing problem has consequences. The conversations about how to help open source maintainers tend to focus on reducing workload (valid for burnout), improving tooling (valid for both, but mostly for burnout), and better triage systems (mostly for burnout). The question of whether the work is still meaningful — which would matter more to the 51% — comes up less.
The Behavioral Signature in Your Data
The distinction is useful partly because it's observable if you track your own activity patterns. Burnout and disengagement produce different behavioral signatures in the kind of data a time tracker captures.
Burnout tends to compress everything. Coding sessions get shorter, less frequent, and less focused across the board. Your weekly hours drop. The projects you were energized by stop consuming your attention. You're not avoiding your open source work specifically — you're avoiding most effortful cognitive work because the resource that drives it is depleted.
Disengagement typically shows up as selective withdrawal. Hours don't necessarily drop. You're still working, still producing, still in the flow on some things. The project you're disengaged from gets avoided specifically, while adjacent work remains active. You open your editor and spend time on the side project or the client work or the new thing, and the repository you've maintained for three years sits untouched at the bottom of your tab stack.
If you track application-level time across projects, you can see this directly. A disengaged maintainer looks like a fully functional developer who happens not to open that specific repo. A burned out developer looks like someone whose editor doesn't open much at all.
This is more than a diagnostic curiosity. If you're a maintainer trying to understand your own state, the question "am I avoiding this specific thing or avoiding everything?" produces different answers and should point toward different responses. The calendar and the commit graph won't tell you this clearly, because both measure a single project. Cross-project activity data does.
What To Do With the Right Diagnosis
If it's burnout, the answer is rest and reduced load. That's real and the advice is widely available. Make the resting possible.
If it's disengagement — if the problem is directionlessness, not depletion — rest doesn't help in any durable way. A month away from the repository doesn't resolve the question of whether you want to maintain it anymore. It just delays it.
The useful question for disengagement is: is there a version of this project you would care about? Not "can you force yourself to keep going," but "does this thing still match who you are and what you want to be doing with your time?" Sometimes the answer is yes, with some scope changes or co-maintainers or a clearer articulation of what success looks like. Sometimes the answer is no — and the honest exit is more respectful to the community that depends on the project than years of degraded, reluctant maintenance.
Kubernetes retiring Ingress NGINX in November 2025 — citing maintainer burnout — produced a cleaner outcome than the projects that keep technically existing while the person who built them has already left in every meaningful sense. The community got a clear signal and could adapt. The slow, ambiguous withdrawal produces the worst outcome for everyone: no definitive transition, degrading response times, users unsure whether to rely on the thing or find alternatives.
The Tidelift number is 51% to 44%. Loss of interest beats burnout. The crisis is real. The diagnosis might not be.