Open source maintainer burnout as a supply chain risk

I have eight-plus credible sources and four verified images. Writing the post now.

A half-second that saved the internet

In late March 2024, a Microsoft engineer named Andres Freund noticed that logging into a test machine over SSH was taking about half a second longer than it should. Most people would have shrugged. Freund did not. He pulled the thread, and what he found at the end of it was a backdoor buried inside XZ Utils, a small, unglamorous data-compression library that ships with nearly every Linux distribution on Earth. The malicious code, later catalogued as CVE-2024-3094 and rated the maximum severity score of 10.0, was engineered to let an attacker run commands on a target machine before authentication, by hijacking a function used by the SSH daemon. XZ Utils sat inside roughly 30,000 Debian and Ubuntu packages. Had the compromised versions reached stable releases, the attacker would have held a skeleton key to a large fraction of the world's servers.

The near-miss got told, understandably, as a story about a brilliant piece of malware caught by a sharp-eyed engineer. But that framing buries the more uncomfortable lesson. The attack did not break through a wall. It walked in through a door that a single, exhausted, unpaid volunteer had been holding open for years because he could no longer carry the weight alone. Open source maintainer burnout is not a wellness problem tucked away in the corner of the software industry. It is a live, exploitable weakness in the supply chain that runs almost everything.

The one-person dependency

Start with a misconception worth killing early: that the open source code inside your bank, your phone, and your government is maintained by well-resourced teams at large companies. Some of it is. A great deal of it is not. The clearest picture of this comes from the Census II study, published in 2022 by the Linux Foundation and Harvard's Laboratory for Innovation Science. Drawing on more than half a million observations of software running in production at thousands of companies, it catalogued the thousand-plus open source components the commercial world leans on most heavily. One of its stated goals was to find exactly the danger XZ later embodied: widely used projects running on outdated code, and popular components "maintained by overworked developers." The famous xkcd cartoon above, in which the entire edifice of modern digital infrastructure balances on a block that "a project some random person in Nebraska has been thanklessly maintaining since 2003," is not really a joke. It is an architecture diagram. XZ Utils was one of those blocks. For most of its life it was effectively a one-person project, maintained by a Finnish developer named Lasse Collin. That is the shape of the risk. When a dependency has a bus factor of one, meaning the number of people who would have to be hit by a bus before the project stalls, everything downstream inherits the fragility of that single human being: their time, their health, their morale, and their capacity to say no.

What burnout actually is

We throw the word "burnout" around loosely, so it helps to be precise. In the psychological literature, burnout is a work-related syndrome with three linked components, laid out most influentially by the researcher Christina Maslach: a motivational collapse (an intolerance of effort, an inability to make yourself do the things that need doing), an affective drain (feeling emotionally wrung out and easily frustrated), and a cognitive shift (growing cynical and mentally distancing yourself from the work). Crucially, burnout is not simply a matter of individual resilience. Research on the "job demands-resources" model finds that burnout rises with demands like excessive workload and conflict, and falls with resources like fair pay, recognition, autonomy, and support. Change the working conditions and you change the risk. Now map that onto open source. A 2023 JetBrains survey of 26,348 developers working across both closed and open source found that 73% had experienced burnout at some point in their career. Among maintainers specifically, the picture is worse. Tidelift's 2024 State of the Open Source Maintainer survey, which polled more than 400 maintainers, found that 60% had either quit or considered quitting their maintenance work, and 44% pointed to burnout as a reason. A November 2025 report on burnout in open source communities by the researcher Miranda Heath, funded through Sentry's Open Source Pledge, pulled together the academic literature and a close reading of what maintainers themselves say. It identified six mutually reinforcing causes: the difficulty of getting paid, crushing workload, maintenance work that feels unrewarding, toxic community behaviour, a sense of hyper-responsibility, and constant pressure to prove oneself. The quotes she collected read less like career grumbling and more like grief. "It went from being one of the most fun experiences in my life to making me feel terrible everyday," said one. "Open source was about sharing the code with fellow developers, learning new skills, and having fun," said another. "Somehow, it became for many a threat to their mental health, and an unpaid job."

Why the money doesn't reach them

The deepest of Heath's six causes, and the one that feeds the rest, is money. Sixty percent of maintainers in the Tidelift survey are unpaid hobbyists, a figure that did not budge from the year before. Because the work rarely pays, maintainers who cannot afford to do it for free take on what the report calls a "double-shift": a full-time job to cover the mortgage, then the open source work on nights and weekends out of obligation. That is a recipe for the exact working conditions the psychology literature flags as combustible: high demand, low resource, no off switch. The story of core-js shows how bleak the economics can get. The library is a foundational piece of the JavaScript ecosystem, downloaded more than nine billion times and pulled from the npm registry tens of millions of times every week. Its maintainer, Denis Pushkarev, watched his donation income fall from around $2,500 a month to roughly $400, even as usage climbed into the billions. Writing an 11,000-word post in 2023, he concluded that "free open source software is fundamentally broken." His case carries a second, grimmer twist: he served an 18-month prison sentence after a fatal motorcycle collision, leaving one of the internet's most-used libraries in limbo while its author was behind bars. The bus factor, made literal. The frustration does not always stay quiet. In January 2022 a developer named Marak Squires, angry at companies profiting from his unpaid labour, deliberately sabotaged his own libraries colors.js and faker.js, pushing updates that printed "liberty liberty liberty" followed by gibberish in an infinite loop. Colors.js alone was being downloaded around 27 million times a week and sat under roughly 19,000 dependent packages. Applications broke across the industry, including some built on Amazon's Cloud Development Kit, and GitHub suspended his account. His message, posted to the repo, was blunt: "Pay Me or Fork This." It was self-sabotage, not a foreign intrusion, but it exposed the same structural truth. A single embittered maintainer is a single point of failure, whether the failure comes from an outside attacker or from within.

From burnout to breach: the human attack surface

Here is where the welfare problem becomes a security problem, and the XZ case is the clearest illustration on record of how the two connect. The attacker did not start by writing code. They started by cultivating a person. Beginning around 2021, an identity using the name "Jia Tan" appeared in the XZ project and began submitting legitimate, helpful patches. Over roughly two years, this contributor built a track record and a reputation, the ordinary currency of open source trust. At the same time, a cluster of other accounts, later widely assessed to be sock puppets working in concert, appeared on the project's mailing list to apply pressure. Under names like "Jigar Kumar," they complained that patches were being accepted too slowly and pushed the idea that Lasse Collin needed to hand over more control. The messages leaned directly on Collin's evident overload. One told him the project needed "a new maintainer" if the current one lacked the time. Collin, by his own account, was dealing with limited time and long-term health issues. Worn down and short-handed, he did what an exhausted solo maintainer under a barrage of demands might reasonably do: he accepted the help. Jia Tan was granted co-maintainer status, then release authority. In early 2024, the backdoor went into versions 5.6.0 and 5.6.1, cleverly split so that the malicious payload lived in binary test files rather than the readable source, and only assembled itself during the build process. It was caught only because of Freund's half-second of latency. The attack surface, in other words, was not a memory bug or an unpatched CVE. It was a tired human being. Burnout produced exactly the conditions a patient adversary needs: a critical project, a single overworked gatekeeper, a visible desire for relief, and a community norm of welcoming anyone willing to shoulder the load. As one industry write-up put it, the compromise succeeded because "a patient attacker targeted a single overworked maintainer." No amount of static analysis or dependency scanning would have flagged a friendly, productive contributor over two years of good-faith commits. The ecosystem felt the aftershock. In the same Tidelift survey, 66% of maintainers said they had become less trusting of pull requests from people outside the core team following the XZ incident. That is a rational response, but it is also a tax. More suspicion means more review, which means more work, which deepens the very exhaustion that created the opening. The defensive reflex feeds the original disease. There is a newer accelerant, too. Nearly two-thirds of maintainers told Tidelift they are now less inclined to accept pull requests from contributors using AI tools, describing a flood of plausible-looking but low-understanding submissions that are draining to review. When the intrinsic reward of the work evaporates and the volume of low-quality noise rises, the motivational component of burnout, the intolerance of effort, sets in faster.

We have been here before

None of this is unprecedented, which is either reassuring or damning depending on your mood. Rewind to April 2014 and the Heartbleed bug, a flaw in OpenSSL, the library that underpins encrypted connections across the web. When the industry went looking for the team behind this piece of near-universal infrastructure, it found that OpenSSL was running on around two-thirds of all web servers while being maintained by essentially two people on donations of roughly $2,000 a year. The mismatch between how much the world depended on the code and how little it invested in the humans behind it was so stark that a coalition of technology giants, including Facebook, Google, Intel, and Microsoft, launched the Core Infrastructure Initiative that same month to funnel money into critical projects.

Heartbleed was a coding mistake rather than a deliberate implant, but the underlying condition was identical to XZ's: society-scale reliance resting on a starved, understaffed project. A decade apart, the same fault line produced two of the most serious security scares of their eras. The pattern is not bad luck. It is a predictable output of a system that treats the maintenance of shared infrastructure as a hobby to be done for free. And the problem is not shrinking. The 2026 Open Source Security and Risk Analysis report from Black Duck found that 93% of the commercial codebases it examined contained "zombie" components, dependencies with no development activity in the previous two years. Every abandoned or dormant project is a maintainer who already walked away, and a door left unattended.

The money is starting to move

The encouraging part is that the "throw money at the humans" idea, first tried after Heartbleed, is being taken more seriously and more structurally. Germany's Sovereign Tech Agency, funded by the federal government, invested more than €23 million in around 60 open source projects between 2022 and 2024, explicitly treating open digital infrastructure the way a state treats roads and bridges. Its Sovereign Tech Fellowship pays individual maintainers directly through a "maintainer-in-residence" model, aimed squarely at the human labour that funding usually ignores. On the corporate side, Sentry's Open Source Pledge, which financed Miranda Heath's burnout report, asks companies to pay a set amount per developer per year to the maintainers they depend on, trying to turn diffuse gratitude into a recurring line item.

Regulation is arriving alongside the money, and it cuts both ways. The European Union's Cyber Resilience Act introduces a new legal category, the "open source software steward," with duties to run a cybersecurity policy and report vulnerabilities; those obligations apply from 11 December 2027. The drafters tried to shield unpaid hobbyists, so individual maintainers who do not monetize their work are largely out of scope. But the line between a volunteer and a "steward providing sustained support" is exactly the kind of ambiguity that could pile fresh compliance anxiety onto people already at the edge. Handing new legal responsibilities to burned-out volunteers, without also handing them resources, would be a way of making the problem worse while believing you are fixing it.

What to watch

The tempting conclusion is that the fix is simply more money, and money is necessary. But the deeper finding in the research is that pay is one resource among several. Recognition, a functioning community, shared load, and the plain ability to say no all protect against burnout, and none of them arrive automatically with a cheque. A maintainer-in-residence who is well paid but still the only person who understands a critical codebase is still a bus factor of one. So the question worth holding onto is not whether the industry can afford to fund maintainers. Compared to the cost of a supply-chain compromise at the scale XZ threatened, the sums are trivial; Germany's entire multi-year program cost less than a mid-sized company's cloud bill. The question is whether the organizations that depend on open source can learn to read maintainer health as the security signal it plainly is: to notice, before an attacker does, when a critical dependency has quietly narrowed to a single tired person holding the door. Andres Freund noticed a half-second of latency. The harder thing to notice, and the more important, is the exhaustion that made the latency possible in the first place.

---

Sources

1. Akamai, "XZ Utils Backdoor: Everything You Need to Know, and What You Can Do", 2024.
2. The Register, "Open source maintainers underpaid, swamped by security, going gray" (Tidelift 2024 State of the Open Source Maintainer survey), 2024.
3. Miranda Heath, "A Report on Burnout in Open Source Software Communities", 2025.
4. Linux Foundation and Harvard LISH, "A Summary of Census II: Open Source Software Application Libraries the World Depends On", 2022.
5. The Stack, "Core-js has been downloaded 9B times. Its maintainer is broke and angry", 2023.
6. The Register, "Core-js maintainer complains open source is broken", 2023.
7. BleepingComputer, "Dev corrupts NPM libs 'colors' and 'faker' breaking thousands of apps", 2022.
8. Wikipedia, "Core Infrastructure Initiative" (Heartbleed, OpenSSL funding), 2014.
9. Socket, "The Unpaid Backbone of Open Source: Solo Maintainers Face Increasing Security Demands" (Black Duck OSSRA 2026 data), 2026.
10. Sovereign Tech Agency, official site and Fellowship program, 2024.
11. Open Source Security Foundation (OpenSSF), "EU Cyber Resilience Act", 2027 obligations.
12. Randall Munroe, xkcd 2347, "Dependency", 2020.