Burnout in the Bazaar: When AI-Generated Code Broke the People Who Maintain It
If you kept infrastructure running in the 1990s and early 2000s, you know the particular quiet of a service that survives on less than it needs. I spent years in that quiet, at ICONZ and around linux.co.nz, in an era when a mail server or a mirror or a piece of the country's early internet plumbing was often held together by one person's evenings and a budget line nobody had ever approved. It works, right up until the day the one person is unwell, or moves on, or simply stops. Nothing announces the fragility in advance. The service just runs, and everyone downstream assumes it always will, because it always has.
That assumption broke in public three times this year, at three projects that share almost nothing except the shape of the flaw underneath them.
Three projects, one pressure
On 19 July 2026 Jellyfin, the free media server that a large self-hosting community runs in place of Plex, lost its project leader Joshua Boniface and a long-serving core member, Anthony Lavado, within days of each other. Co-founder Andrew Rabert had stepped away two days earlier. The three departures had three different causes, and it matters that they stay separate. Boniface named his plainly: "I simply could no longer provide the effort (mental or time-wise) that the role demanded... facing severe burnout, and risks to my mental health" [1]. Lavado's was a life change after nearly eight years, not burnout [1]. Rabert's was friction over the desktop client, which he moved outside the project rather than an AI-volume story at all [1][2]. One leadership shake-up, three human reasons, and only one of them the pressure this episode is about.
But that one pressure the project had already named itself. Two months earlier, in a status post dated 24 May 2026, Jellyfin wrote that "we have been inundated with AI-authored pull requests of varying quality," that "the increased support requests, combined with the AI code submissions, have led to burnout at various levels of the development and admin team," and that abuse from users when a change was not accepted "only increases the loss of motivation" [3]. The project's response was a contribution policy: use AI if you like, but "you must understand HOW it does what it does," and stop acting as a "go-between between your AI and our questions" [3]. A volunteer project was, in effect, asking to be spoken to by a person.
The volume is the point
Jellyfin is not an isolated case, and the second example is sharper because the maintainer measured it. In January 2026 Daniel Stenberg, who created curl and still leads it, closed the project's six-year bug-bounty programme. His reason was arithmetic. "Previous years we have had a rate of somewhere north of 15% of the submissions ending up confirmed vulnerabilities," he wrote. "Starting 2025, the confirmed-rate plummeted to below 5%." Of the AI-generated reports specifically: "Not even one in twenty was real" [4]. The programme had paid out over one hundred thousand US dollars and confirmed 87 real vulnerabilities across its life; what ended it was the cost of reading everything that was not real. Stenberg described "a serious mental toll," and was blunt that curl is "just a small single open source project with a small number of active maintainers" that had to "make moves to ensure our survival and intact mental health" [4].
There is an honest complication here that I want to keep in view rather than tidy away. Three months later, Stenberg reported that the problem had changed shape more than it had gone away: the low-quality flood eased, but AI-assisted reports of genuine quality began arriving faster than a small team could review them, which he judged made maintainer overload worse, not better [5]. I am treating that follow-up as his own reading of a still-moving situation rather than a settled number, and it points the same direction: the constraint is not the quality of any single report, it is the rate.
The third case is the control. On 11 November 2025 the Kubernetes project announced it was retiring Ingress NGINX, one of the most widely deployed pieces of cloud-native plumbing anywhere, with best-effort support ending in March 2026 [6]. The stated cause had almost nothing to do with AI. The component had "always struggled with insufficient or barely-sufficient maintainership," with "only one or two people doing development work, on their own time, after work hours and on weekends," and the project's own public plea for help "failed to generate additional interest" [6]. That is the pre-AI version of the same disease. It tells you the fragility was already there. AI volume is an accelerant on an existing weakness, not the origin of it, and that is a stronger claim than blaming the tools.
I should be careful about how I describe the machines in all of this. AI tooling has lowered the cost of producing plausible-looking code and plausible-looking vulnerability reports, and the resulting increase in volume is documented, in their own words, at three separate projects. That is a description of a consequence, not an accusation of intent. Nobody set out to exhaust these maintainers. The volume did it without anyone deciding to.
This is not a new fragility
The idea that the internet rests on a few unpaid people is more than a decade old and has a canonical case. In April 2014, Heartbleed, a critical flaw in OpenSSL, exposed that the cryptographic library protecting a large share of the world's encrypted traffic had been maintained by a handful of largely unpaid volunteers, with contemporaneous coverage summarising the situation as "the Internet is being protected by two guys named Steve" [7]. The picture that stuck was not a headline but a cartoon: XKCD's "Dependency," which draws the entire modern digital edifice as a tottering tower of blocks balanced on one small piece "a project some random person in Nebraska has been thanklessly maintaining since 2003" [8]. Everyone in this field has seen it. Most of us have been the block near the bottom at some point.
The economics have been measured too, though the measurement is older than it looks in 2026. Tidelift's 2024 State of the Open Source Maintainer survey found that 60% of maintainers were unpaid, that 60% had quit or considered quitting, and that 44% of unpaid maintainers would like to be paid [9][10]. Those figures are still being cited this year as if fresh; on a direct check they trace to that 2024 survey, with no 2025 or 2026 edition behind them. I am flagging the date deliberately. The precarity is not new information, which is precisely the point. What changed between 2024 and now is not that maintainers became unpaid. It is that the volume of work an AI-accelerated contribution pipeline generates has grown faster than the volunteer base available to review it.
The sharpest irony is Jellyfin's own
Jellyfin exists because a community once refused an enclosure. It was created in December 2018 as a fully open-source, GPL-licensed fork of Emby, after Emby moved its next major release closed-source and put core functionality behind a paywall [11]. The founders were, by contemporaneous accounts, reacting to the licensing change and to what they saw as a loss of respect for the free-software ethos [11]. Eight years on, this is not a niche protest project. A direct check of its repository shows more than fifty-four thousand stars and over five thousand forks, a piece of infrastructure at a scale many commercial products would envy, and still no paid tier, no telemetry, and no central account requirement [12].
Hold those two facts together and you get the episode's uncomfortable thesis. Jellyfin was the bazaar's answer to a cathedral's enclosure. Its volunteers are now burning out, not because a corporation captured them from the outside, but because the openness that made the project possible has become the channel through which more work arrives than a finite, unpaid team can absorb. I will put this as my own frame rather than a finding, because it is an interpretation and not a measurement: the bazaar can be worn down from the inside by its own openness, not only captured from the outside by a paywall. That is a different failure mode from every prior episode in this series, and a harder one to legislate against, because the thing straining the system is the same thing that makes it worth defending.
A model, elsewhere
There is at least one structural answer already running, and it is worth describing precisely because it is easy to over-read. Germany's Sovereign Tech Fund, since renamed the Sovereign Tech Agency and founded in 2021, has put more than twenty-four million euros into critical open-source projects, funding maintainers of systemd, PHP, FFmpeg, GNOME, and Servo through direct grants that demand no equity and no control, with a fellowship programme placing individual maintainers on contracts from 2026 [13][14][15]. It is the clearest institutional attempt in motion to treat maintenance as infrastructure worth paying for. I am describing it as an existing model, elsewhere, and nothing more than that. It is not a recommendation about what any other country should fund, and I am not offering it as one; it is simply the counter-example that shows the volunteer-exhaustion problem is not a law of nature.
Strip the three ruptures back and the open-source question underneath them is not licensing. Jellyfin, curl, and Kubernetes Ingress NGINX are all freely licensed and freely available; the code was never the scarce resource. The scarce resource is the finite, mostly unpaid human attention that reviews a pull request, triages a vulnerability report, and decides what ships. The funding experiments now in motion, direct maintainer grants of the kind Germany has been running, treat that attention as infrastructure rather than goodwill to be spent. The provenance and Software Bill of Materials work of the last few years tells an organisation which open-source components it depends on. Neither tells it whether anyone is still awake behind those components. Openness guarantees you can read the code. It has never guaranteed that someone is there to maintain it.
The dependency runs into places that cannot afford it to fail. The United States Department of Defense issued guidance in 2009 clarifying that open-source software is eligible for the same consideration as proprietary commercial software [16], and open source has been a routine part of allied defence and infrastructure stacks ever since. curl sits in essentially every internet-connected device. A cloud-native ingress controller routes traffic through data centres that governments and militaries rent or run. So when a bug-bounty programme closes because two people can no longer read the reports, or a widely deployed component is retired because one or two volunteers ran out of weekends, that is not only a hobbyist's inconvenience. It is a question about the maintenance state of components sitting beneath systems that quietly assume someone, somewhere, is still watching. The layer you do not fund is the layer you do not control.
You ran services on thin margins and volunteer effort long before anyone called it open-source sustainability. Was there a point in your own career when the free or underpaid labour holding something critical together very nearly gave out, and what actually saved it: more people, less scope, or someone finally deciding to pay for it?
The views expressed in this article are entirely my own, informed by more than 30 years of professional experience in architecture, security, and technology leadership in New Zealand. They do not represent the views of my employer, any government agency, or the New Zealand government. My commentary on legislation and policy is analytical, drawing on publicly available sources and my professional expertise in architecture, security, and AI governance. I follow the Public Service Commissioner's Code of Conduct for the Public Sector and social media guidance.
About the Author: Andreas Hamberger is a New Zealand-based enterprise architect and technology strategist. Over 30 years, he has moved from compiling kernels on a 486 to leading cloud, cyber, and AI transformation programmes across government, banking, transport, and aviation. He founded Yoper Linux, served as a technology specialist for Novell during the Linux Wars, and is the author of "Generative AI: Skynet or Heaven" and "Space Mafia." He can be reached at linux@linux.co.nz. A Concise History of Linux chronicles the operating system that changed the world and the lessons it holds for the AI era.
I use AI tools, including Sudowrite, Claude, Perplexity AI, DeepSeek AI, ChatGPT, Grok, Copilot, Openart and Gemini, as deliberate production tools, not ghostwriters. This is consistent with my position: AI amplifies human judgement; it does not replace it. The frameworks, arguments, and editorial decisions in this series are original work. AI accelerated the process. The thinking is mine.
References
[1] Jellyfin Project. "Project Leadership Changes." Jellyfin community forum. July 2026. https://forum.jellyfin.org/t-project-leadership-changes
[2] Linuxiac. "Jellyfin Loses Project Leader and Core Team Member in Major Shake-Up." July 2026. https://linuxiac.com/jellyfin-loses-project-leader-and-core-team-member-in-major-shake-up/
[3] Jellyfin Project. "State of the Fin." jellyfin.org. 24 May 2026. https://jellyfin.org/posts/state-of-the-fin-2026-05-24/
[4] Stenberg, D. "The end of the curl bug-bounty." daniel.haxx.se. 26 January 2026. https://daniel.haxx.se/blog/2026/01/26/the-end-of-the-curl-bug-bounty/
[5] Stenberg, D. "High-Quality Chaos." daniel.haxx.se. 22 April 2026. https://daniel.haxx.se/blog/2026/04/22/high-quality-chaos/
[6] Kubernetes contributors (SIG Network and Security Response Committee). "Ingress NGINX Retirement: What You Need to Know." kubernetes.dev. 12 November 2025. https://www.kubernetes.dev/blog/2025/11/12/ingress-nginx-retirement/
[7] CSO Online. "The Heartbleed bug: How a flaw in OpenSSL caused a security crisis." csoonline.com. https://www.csoonline.com/article/562859/the-heartbleed-bug-how-a-flaw-in-openssl-caused-a-security-crisis.html
[8] explainxkcd. "2347: Dependency." explainxkcd.com. January 2020. https://www.explainxkcd.com/wiki/index.php/2347:_Dependency
[9] Socket. "The Unpaid Backbone of Open Source." socket.dev. 2026 (citing Tidelift's 2024 State of the Open Source Maintainer Report). https://socket.dev/blog/the-unpaid-backbone-of-open-source/
[10] Business Wire. "Tidelift Study Reveals Paid Open Source Maintainers Do Significantly More Critical Security and Maintenance Work Than Unpaid Maintainers." 17 September 2024. https://www.businesswire.com/news/home/20240917030299/en/Tidelift-Study-Reveals-Paid-Open-Source-Maintainers-Do-Significantly-More-Critical-Security-and-Maintenance-Work-Than-Unpaid-Maintainers/
[11] Linux Uprising. "Jellyfin: Free Software Emby Media Server Fork Is Announced After Emby Becomes Proprietary." December 2018. https://www.linuxuprising.com/2018/12/jellyfin-free-software-emby-media.html
[12] Jellyfin Project. "jellyfin/jellyfin." GitHub repository (star and fork counts as of 24 July 2026). https://github.com/jellyfin/jellyfin
[13] HeroDevs. "EU's Sovereign Tech Fund: Securing Open-Source Sustainability and Why It Matters." herodevs.com. https://www.herodevs.com/blog-posts/eus-sovereign-tech-fund-securing-open-source-sustainability-and-why-it-matters/
[14] SPRIND. "Sovereign Tech Fund." sprind.org. https://www.sprind.org/en/actions/projects/sovereign-tech-fund/
[15] Sovereign Tech Agency. "Fellowship." sovereign.tech. https://www.sovereign.tech/programs/fellowship/
[16] United States Department of Defense, Office of the Chief Information Officer. "Clarifying Guidance Regarding Open Source Software (OSS)." Memorandum. 16 October 2009.