The Maintainer at 2 AM: The Human Cost of Free Software

The Night the Lights Went Out

This is episode seventeen of Git Good, Season Two.

On the fifth of January, two thousand twenty-two, builds started failing. Not a few builds. Not one company. Thousands of projects, all at once, all over the world. Continuous integration pipelines turned red. Applications that had been running perfectly for years printed nothing but the same three words, over and over, in an endless loop. Liberty. Liberty. Liberty. Then garbage characters. Then the loop again. No crash. No error message. Just an infinite scroll of the word liberty, consuming memory and CPU until someone killed the process.

The cause was not a hack. It was not a vulnerability. It was a maintainer named Marak Squires, and he had decided he was done.

Squires maintained two JavaScript libraries. One was called colors.js, a tool that added colored output to terminal applications. Twenty-three million downloads per week. Baked into nearly nineteen thousand other packages. The other was faker.js, which generated realistic fake data for testing. Two and a half million downloads per week. Together, they touched more software than most developers will write in a lifetime.

On that January night, Squires pushed a new version of colors.js. Version one point four point four four, with the suffix liberty-2. Inside, he had added an infinite loop that printed those three words forever. For faker.js, he went further. He deleted the functional code entirely. Replaced the readme file with a single question. What really happened with Aaron Swartz?

Aaron Swartz co-founded Creative Commons and helped build RSS and Reddit. He was prosecuted for downloading academic papers from a digital library to make them publicly available. He died by suicide in two thousand thirteen, at the age of twenty-six, after years of legal pressure. The reference was not random. It was a statement about what happens when systems grind people down.

Squires had been warning people for over a year. In November two thousand twenty, he posted on GitHub.

I am no longer going to support Fortune 500 companies with my free work. Take this as an opportunity to send me a yearly contract of six figures, or fork the project and have someone else work on it.

Nobody sent a contract. Fourteen months later, he burned it down. The version number he chose for the sabotaged faker.js release was six point six point six.

GitHub suspended his account. npm reverted the sabotaged versions within hours. The community forked faker.js under a new namespace, maintained by a team of volunteers instead of one person, and the JavaScript ecosystem moved on. Within a week, most of the immediate damage was repaired. Within a month, the incident had become a footnote in most developers' memory. The builds were green again. The dependency had been replaced. Problem solved.

Except it was not solved. The fork fixed the code. It did not fix the condition that created the crisis. A single person, maintaining software used by thousands of companies, compensated with nothing, warning for over a year that he could not continue, ignored until he did something impossible to ignore.

The reaction split cleanly in two. To some, Squires was a saboteur who violated the trust of everyone who depended on his code. The open source license gave him the right to stop contributing. It did not give him the right to inject malicious code into software running in production. The infinite loop was not a resignation. It was an attack. And the people whose builds broke at 2 AM, the on-call engineers paged out of sleep, the companies that lost hours of productivity, they did not deserve to be collateral damage in one person's grievance.

To others, Squires was the first maintainer who said out loud what hundreds of others were thinking. That the deal was broken. That maintaining critical infrastructure for free, while the companies profiting from it paid nothing, was not sustainable. That the only way to make anyone listen was to demonstrate exactly what "free" means when the person providing it decides to stop.

Both readings are true. That is what makes the story uncomfortable. And that discomfort is the point. Because the conditions that created Marak Squires have not changed. They have gotten worse.

The Four Hundred Dollar Maintainer

If Marak Squires is the maintainer who burned it down, Denis Pushkarev is the maintainer who kept going. The question is which story is sadder.

Pushkarev created core-js in two thousand fourteen. It is a JavaScript polyfill library, the kind of invisible infrastructure that makes modern web applications work across different browsers. If you have used the internet in the past decade, core-js has probably run on your machine. Over thirteen million developers are listed as using it on GitHub. It gets more than forty-three million downloads per week from the npm registry. More than nine billion downloads in total. More than half of the top ten thousand websites depend on it.

One person maintains it. Denis Pushkarev, working alone. He has been maintaining it alone for a decade.

Pushkarev's personal history is complicated, and it matters. In two thousand nineteen, he was involved in a motorcycle collision that killed a pedestrian. He served about ten months in a Russian prison. When he was released, he went straight back to maintaining core-js. Not because anyone asked him to. Because nobody else could.

When Pushkarev started maintaining core-js full-time, he could count on about twenty-five hundred dollars a month from donations. That was already far below any reasonable salary for maintaining software used by half the web. But the number kept falling. By two thousand twenty-three, it was down to about four hundred dollars a month. Less than minimum wage in most countries. Less than what a junior developer earns in a day in Silicon Valley.

The reasons were complicated. Pushkarev lives in Russia, and after the invasion of Ukraine, western financial services largely stopped processing payments to Russian accounts. The donation channels that had been trickling in dried up almost completely. But even before the sanctions, the donations were pitiful relative to the value his work provided. Billions of page loads. Billions of dollars in commerce. Four hundred dollars a month for the person holding it all together.

Pushkarev tried to draw attention to the situation. He added a small notice to the core-js installation output, a line that appeared in the terminal when you installed the package, with a link to his donation page. The response was immediate and brutal.

A continuous stream of hate. Hundreds of messages, posts, and comments per day.

Not sympathy. Not donations. Hate. Developers were angry that a package they installed for free had the audacity to ask for money during installation. The messages were not constructive criticism. They were insults, threats, demands that he remove the donation notice. As if asking for compensation for work that powered half the internet was an act of aggression.

Pushkarev wrote an eleven-thousand-word essay on GitHub, a document that read like a last will and testament for open source idealism. He wrote that free open source software is fundamentally broken. He wrote that he could stop working on it silently, but he wanted to give open source one last chance. He considered changing core-js to a closed source license. He considered walking away entirely.

I could stop working on this silently. But I want to give open source one last chance.

As of this recording, Pushkarev is still maintaining core-js. The donations have not meaningfully improved. The web still depends on his work. And the people who depend on it still, overwhelmingly, pay nothing.

Episode twenty of this season will talk about the economics of open source, the funding models, the structural reasons the money does not flow to the people who need it. This episode is not about the money. It is about what it costs to be Denis Pushkarev. To maintain something used by billions, to be paid less than a fast food worker, and to be told you are greedy for mentioning it.

The Pause That Shook Kubernetes

On August thirteenth, two thousand twenty-five, the maintainers of External Secrets Operator announced they were pausing all releases. No new features. No patches. No updated container images. No support.

External Secrets Operator, known as ESO, is a Kubernetes tool that manages secrets, the passwords, API keys, and certificates that applications need to function securely. It connects to external secret management services and syncs them into Kubernetes clusters. If you run cloud-native infrastructure, there is a good chance ESO is part of it. It is a CNCF project, meaning it falls under the umbrella of the Cloud Native Computing Foundation, the organization that stewards Kubernetes itself.

And it had come down to one person. One maintainer, working quasi full-time, while everyone else had moved on to other things.

The announcement was blunt. Too many open source projects are quietly dying because they have been taken for granted. The maintainers described a pattern that will sound familiar by now. Users filing issues as demands. Expecting immediate fixes for a project that existed on a strictly volunteer basis. Treating the maintainers not as people donating their time, but as a support desk that happened to be free.

People do not always respect our time, our effort, our anything.

The ESO pause was different from the Marak Squires story in one crucial way. Squires burned it down in anger. The ESO team did not sabotage anything. They simply said, publicly and clearly, that they could not continue. They framed it not as protest but as honesty. We are burned out. We cannot maintain this at the level you expect. If the community wants this project to survive, the community needs to contribute engineering time, not just open issues.

What happened next was genuinely surprising. More than three hundred people from around the world signed up to contribute. Organizations that had been using ESO in production without ever contributing a line of code stepped forward. The maintainers voted to resume releases, with a tentative date of September twenty-second. ESO survived. But it survived because the maintainers did something that most burned-out maintainers never do. They asked for help publicly, clearly, without shame. And three hundred people showed up because the alternative, losing the project, was worse than doing the work.

Most maintainers do not get that response. Most maintainers just go quiet. Their commit history trails off. The issues pile up. And nobody notices until something breaks.

Death by a Thousand Slops

If you want to understand what pushed maintainer exhaustion from a slow crisis to an acute emergency, you have to talk about what started flooding their inboxes in two thousand twenty-five.

Daniel Stenberg created curl in nineteen ninety-eight. It is one of the most widely deployed pieces of software in the world, used in everything from smartphones to servers to cars. Stenberg has maintained it for more than twenty-seven years. He is, by any measure, one of the most experienced and resilient open source maintainers alive.

In July two thousand twenty-five, he published a blog post titled Death by a Thousand Slops.

Death by a thousand slops.

The title adapted an old expression. Death by a thousand cuts. No single wound is fatal, but the accumulation kills you. Stenberg was describing what had happened to curl's bug bounty program. Researchers, or people who called themselves researchers, were submitting vulnerability reports generated by AI tools. The reports looked professional. They used the right terminology. They described plausible-sounding attack scenarios. And almost none of them described real vulnerabilities.

In two thousand twenty-five, AI-generated submissions consumed twenty percent of all vulnerability reports to curl's bug bounty program. Of those, only five percent described actual security issues. The rest were what Stenberg called slop. Plausible nonsense, generated in seconds, that took hours to evaluate and dismiss.

In January two thousand twenty-six, Stenberg ended curl's bug bounty program entirely. A program that had existed to improve the security of one of the most critical tools on the internet, killed not by attackers but by the volume of AI-generated noise.

The bug bounty problem was a symptom of something larger. Across open source, maintainers were reporting the same pattern with pull requests. AI-generated contributions that looked reasonable at first glance but contained subtle misunderstandings that took significant expertise to identify. By one estimate, only one in ten AI-generated pull requests met the standards required to be considered legitimate. The other nine consumed maintainer time, created noise in the issue tracker, and produced nothing of value.

The asymmetry is the cruelest part. An AI-generated pull request takes minutes to create. Reviewing it properly, understanding the context, testing the changes, explaining why the contribution does not work, that takes hours. The person generating the slop bears no cost. The maintainer bears all of it.

On February thirteenth, two thousand twenty-six, GitHub quietly shipped a new repository setting. The ability to disable pull requests entirely. The fact that the largest code hosting platform on earth felt the need to build a kill switch for contributions tells you everything about where things stand.

The Ghostty project went further. Zero tolerance. AI-generated pull requests on accepted issues only. Drive-by contributions closed immediately. Repeat offenders permanently banned. Other projects followed. Some added explicit notes to their contribution guidelines stating that AI-generated submissions would be rejected on sight. Not because the maintainers were hostile to contributions. Because the flood of low-quality AI-generated submissions had made the normal process of accepting contributions impossible.

Think about what that means. Open source was built on the idea that anyone can contribute. That a stranger's pull request, judged on its merits, could improve the project. The AI slop flood did not just waste maintainer time. It poisoned the well. It made maintainers suspicious of every contribution from an unfamiliar name. Was this written by a person who cares about the project, or by someone who pointed an AI at the repository for fifteen minutes to farm a green square on their contribution graph? The default posture shifted from welcome to wary. And the cost of that shift falls entirely on the genuine first-time contributors who now have to prove they are human before their work will be considered.

The Inbox at 2 AM

There is a pattern to how maintainers describe their experience, and it sounds less like a job and more like a chronic illness.

Forty-six percent of professional open source maintainers report experiencing burnout. For maintainers of widely used projects, the number is fifty-eight percent. Sixty percent have considered leaving entirely. Not taking a break. Leaving.

The emotional pattern is remarkably consistent. It starts with enthusiasm. You build something useful. People find it. They use it. They thank you. The stars on your repository climb. The download numbers feel like validation.

Then the issues start. Not bugs, necessarily. Requests. Demands. Messages that begin with "this is broken" and contain no reproduction steps, no context, no acknowledgment that a human being will read this and try to help. Messages that demand features on a timeline, as if the maintainer were an employee who had been assigned a task. Messages that arrive at 2 AM because the person filing them is in a different time zone and sees no reason to wait.

Maintainers describe every critical bug report as feeling like a personal attack. Every feature request carries an implicit accusation. Why have you not done this already? Every issue that goes unanswered for a week generates follow-up messages asking if the project is dead. The person who wrote the code, who documented it, who reviewed the pull requests, who answered the questions, who did all of this for free, is now being asked to justify why they have not done more.

It is like being chained to your own generosity. You created something useful, people depend on it, and now you cannot walk away without feeling guilty.

The guilt is load-bearing. It is the mechanism that keeps burned-out maintainers working long after they should have stopped. They know that if they stop, things will break. Not abstract things. Real systems. Real companies. Real people's jobs. The infrastructure they built has become too important to abandon and too exhausting to maintain. So they keep going, at 2 AM, answering issues from people who do not know their name and would not care if they did.

In Season One, we saw how a burned-out maintainer of a compression library was targeted by a patient, sophisticated attacker who spent two and a half years earning trust before inserting a backdoor. That story was terrifying because it showed what happens when burnout creates a vulnerability. But the XZ story was exceptional. What is not exceptional is the burnout itself. The XZ attacker exploited a condition that exists in thousands of projects, maintained by thousands of people, right now.

The Bus Factor

There is a term in software engineering for this vulnerability. The bus factor. How many people would need to be hit by a bus before the project cannot continue? For a disturbing number of critical open source projects, the answer is one.

One person maintains core-js. One person maintained ESO when it paused. One person has maintained curl for twenty-seven years. Marak Squires was the only person with publish access to colors.js and faker.js. In each case, the entire world's relationship with that software ran through a single human being.

This is not a staffing problem. It is a structural one. Open source was built on the premise that anyone can contribute. But contributing to an established project requires understanding the codebase, the conventions, the history, the design philosophy. It requires trust from the existing maintainers, who are often the only people with the context to review contributions properly. The barrier to becoming a meaningful contributor to a mature open source project is enormous. And the barrier to becoming a maintainer, someone trusted enough to merge code and cut releases, is even higher.

So the bus factor stays low. Not because nobody cares, but because the knowledge required to maintain a complex project accumulates in very few heads. When those heads burn out, or get angry, or simply get tired, the project does not smoothly transfer to new leadership. It stalls. Or it breaks. Or it gets exploited.

Consider the failure modes. When Marak Squires decided to act, he did not need anyone's permission. He had publish access. He pushed the code. The world found out when the builds broke. When the ESO maintainer paused, there was no deputy to step in. When Pushkarev's donations dried up, there was no organization behind core-js to absorb the loss. In each case, the resilience of software used by millions depended on the personal circumstances of one person. Their health. Their finances. Their patience. Their willingness to keep going.

Git makes this visible in a way that other tools do not. Run git log on a project and count the unique committers. For thousands of critical libraries, you will find one name, maybe two, stretching back years. The commit timestamps tell the rest of the story. Late nights. Weekends. Holidays. A pattern of work that no employer would demand and no contract requires, sustained entirely by a sense of obligation that nobody asked for and everyone depends on.

The ESO story had a hopeful ending. Three hundred people showed up. But even that story contained a warning. Those three hundred people signed up after the crisis. Not before. The pattern, across open source, is that communities mobilize only when something visibly breaks. The slow, invisible grind of a maintainer losing the will to continue does not trigger the same response. By the time anyone notices, the damage is done.

The Invisible People

Every dependency in your project has a person behind it. Or had one. Some of those people are employed by companies to maintain the software. Some are volunteers who started a project in their spare time and watched it become critical infrastructure. Some are somewhere in between, maintaining code that millions depend on while working a day job that pays the rent, because the code itself pays nothing.

These are the people holding up the invisible infrastructure that modern software runs on. They do not appear in your company's vendor list. They do not have service level agreements. They do not have on-call rotations, except the ones they impose on themselves out of a sense of responsibility. When they burn out, there is no ticket to file, no support line to call, no contractual obligation that forces anyone to step in.

There is just silence. A commit history that trails off. Issues that stop getting answered. Pull requests that sit unreviewed for months, then years. And somewhere, in a bedroom or a home office or a kitchen table, a person who finally closed the laptop at 2 AM and did not open it again.

The next time you run an install command and watch the dependencies scroll past, hundreds of packages, thousands of packages, consider this. Behind some of those names is a person like Denis Pushkarev, earning four hundred dollars a month to maintain something half the web depends on. Behind others is a person like the ESO maintainers, working for free and being told they are not working fast enough. Behind a few is an empty chair where someone like Marak Squires used to sit, before they decided that if nobody would pay for the work, nobody would get the work.

That is the human cost. Not a line item in a budget. Not a sustainability metric on a slide deck. A human cost. Paid in exhaustion and resentment and guilt by people whose names you will never know, for software you use every day, at 2 AM, alone.

Every episode in this season has been about what Git's victory produced. The walls, the workflows, the platforms, the power structures. This episode is about the people underneath all of it. The ones who do not get episodes named after them. The ones whose contribution is measured not in features shipped but in disasters that did not happen, because someone was awake at 2 AM making sure everything still worked.

That was episode seventeen of Git Good, Season Two.

git log --format="fuller"

The fuller format shows both author and committer, with timestamps for each. It is git log's way of saying that every piece of code passed through at least two pairs of hands. The author wrote it. The committer accepted it. In a healthy project, those are different people. In too many open source projects, they are the same person. Every night. At 2 AM.