John-David Dalton once poured his days into Lodash, the JavaScript utility library that now registers more than 100 million npm downloads daily. What started as a side project in 2012 grew into invisible infrastructure powering countless applications. Then life intervened. The loss of his mother shifted his priorities. An amicable divorce in 2019 demanded time to rebuild. Development slowed. The rhythm that had sustained the project for years broke.
Dalton stepped back. He estimates it took roughly five years and several false starts before contributing again felt sustainable. Therapy helped. Exercise helped. So did hobbies outside coding. One change stood out. He stopped treating programming as a hobby when both his job and open source revolved around the same activity. Balance mattered more than output. Long term sustainability, he concluded, beats constant production.
His story, shared in a conversation turned blog post by the OpenJS Foundation, captures a wider pattern. Maintainers of critical open source projects face mounting pressures. Many work without pay. Expectations rise as adoption explodes. Issues pile up. Security reports flood in. And the personal cost accumulates quietly until it doesn’t.
But Dalton’s experience isn’t isolated. Data paints a stark picture. A 2024 survey of more than 400 open source maintainers found 60% had quit or considered quitting. In Intel’s annual open source community survey, 45% of respondents named maintainer burnout their top challenge. These numbers come from real projects that billions of lines of code depend on. They signal trouble ahead for the software supply chain.
Miranda Heath, a psychologist, spent months interviewing developers, reviewing academic papers, and analyzing community writing. Her November 2025 report identified six factors driving burnout in open source. Difficulty getting paid tops the list. Unpaid work often means double shifts alongside day jobs. Workload and time commitment follow closely. Solo maintainers handle user requests, bug reports, and documentation with no backup. Maintenance itself feels unrewarding. Repetitive tasks replace the creative coding that drew people in. Toxic community behavior adds another layer. Entitlement, insults, and rudeness wear down even dedicated contributors.
Hyper-responsibility creates its own trap. Maintainers feel the weight of entire user bases. One failure could break downstream projects. Pressure to prove oneself compounds everything. GitHub stars, contributor counts, and professional identity blur together. These elements reinforce each other. Lack of pay increases workload. Toxicity amplifies isolation. The result? Exhaustion that leads to reduced motivation, cynicism, and in some cases complete withdrawal.
Quotes from maintainers illustrate the strain. “I don’t feel like working on [it] anymore. It went from being one of the most fun experiences in my life to making me feel terrible everyday,” one developer named Kyle said. Another, Jacob Kaplan-Moss, described burning out after open source consumed more hours than his paid job with nothing in return. “I was doing nights and weekends, it was wrecking my health,” said Nolan Lawson. These accounts repeat across forums, blogs, and surveys.
The problem has grown more acute. AI tools now democratize vulnerability discovery. What once required expertise can be automated at scale. The result is a deluge of reports, many low-quality or duplicate. Maintainers already stretched thin must triage noise before addressing real threats. ActiveState’s 2026 predictions warn this pressure will intensify. More than half of npm packages are maintained by a single contributor. These individuals balance day jobs and critical infrastructure. When legitimate vulnerabilities surface, delayed patches leave users exposed longer. The human element remains finite even as automation scales attacks and defenses.
Industry voices echo the concern. Craig McLuckie, CEO of Stacklok and Kubernetes co-founder, called burnout a “substantial and existential threat to the way that we consume technology.” He advocated for better tooling, additional contributors, and targeted support. “We need to find that lone developer in Nebraska and bring them the support that they need,” McLuckie said in an Intel discussion. Not just money. Practical help that shares the load.
Matt Butcher, co-founder of Fermyon and former Helm maintainer, recalled when his team felt the drag. “It had gotten to the point where, for a little while, it wasn’t so much that we weren’t motivated to work on new features. It was really like, how do we just keep the lights on right now and feel OK?” Their response included simple changes. Every pull request review started with gratitude. “Thank you so much for contributing this.” It de-escalated emotions on both sides. Kaslin Fields of Google and Kubernetes stressed building teams with checks and balances. Frederick Kautz urged peers to check in directly. “Hey, are things OK?” Small conversations can prompt real change.
Security adds another dimension. Adolfo García Veytia, creator of OpenVEX, noted that CVE responses demand quick action for thousands of users. That work isn’t feature development. It piles on. Burned-out maintainers can’t protect codebases effectively. The risk extends beyond individuals to the entire software supply chain.
Yet solutions exist. Heath’s report recommends four paths forward. Pay developers through decentralized models that preserve autonomy. Foster recognition and respect by modeling positive behavior and educating users. Grow the contributor base through mentoring to distribute workload. Advocate for structural changes, including better platform tools and even policy measures around liability.
Projects have begun to adapt. Lodash itself moved under OpenJS support. A technical steering committee and dedicated security triage group now share responsibility. Continuous integration returned. Modern tooling and documented workflows reduced single points of failure. Governance shifted from one person to a community. Other efforts like Maintainer Month offer perks and resources, though they represent only partial relief.
Companies that profit from open source face growing scrutiny. Many use these projects daily yet contribute little back in time or funds. Some sponsors step up. Others treat maintainers as free labor. This imbalance can’t hold. As ActiveState noted, ecosystem bifurcation may emerge with verified tiers for high-security packages. Registries could add more protections. But without addressing the human bottleneck, fragmentation risks rise.
The conversation has gained traction. Intel’s survey and Heath’s psychological analysis add weight to what maintainers have long described anecdotally. Burnout isn’t a personal failing. It’s structural. It stems from mismatched expectations, inadequate support, and the invisible labor of keeping critical code alive.
Dalton eventually found his way back. Not through sheer willpower but by resetting boundaries and priorities. His case shows recovery is possible. But it shouldn’t require years away or personal crisis. The open source community runs on goodwill. When that goodwill erodes under unsustainable conditions, projects stall. Security slips. Innovation slows.
So what now? Respect boundaries. Contribute code or documentation instead of just filing issues. Companies can fund dedicated time or hire maintainers directly. Platforms can improve tools that reduce administrative burden. Individuals can simply say thank you. And check in on colleagues showing signs of strain.
The foundation of modern software depends on these people. They aren’t replaceable cogs. They are the reason libraries work reliably across environments. Ignore their burnout and the code we all rely on will suffer. Support them and the entire ecosystem gains resilience. The choice belongs to everyone who benefits from open source. Which is nearly everyone writing software today.
WebProNews is an iEntry Publication