Open Source Maintainers Are Crashing Out

Open source is a safe, sustainable development model.

Right?

What if I told you that, despite everything you’ve heard, it isn’t. At least, not always.

The history of open source software is checkered. Even recently, we’ve seen scandals, betrayals, and genuinely weird decisions that I don’t think Richard Stallman would have predicted. Not that I know what he’s thinking.

But who doesn’t love open source?

I do.

Ethically and practically speaking, open source has a lot of advantages. Free and open software isn’t just about getting access to free stuff as a software user. The Open Source Initiative defines open source through licensing criteria like the freedom to redistribute the software, access the source code, modify the software, and use it within your own software, even your own proprietary software.

But not everyone has the same definition of open source, and “free” doesn’t always mean “free forever.”

We’re going to look at four of the most famous open-source maintainer crashouts in recent history. We’ll dissect the decisions made by maintainers, the aftermaths for the community, and the biggest problem facing open source development today: the same problem that caused these meltdowns to happen in the first place.

Maybe open source isn’t as sustainable and financially viable as investors and founders would like to believe. It turns out, it takes serious work to do it right.

And when done right, open source is beautiful, obviously.

Note: This post is a blog-style adaptation of our video on open source maintainer crashouts.

The npm ad fiasco

Our first stop is the npm ad fiasco of 2019.

Back in August of that year, a developer named Feross Aboukhadijeh announced an experiment he mysteriously called “funding”. Feross, at the time, maintained over 100 npm packages, including the then-ubiquitous StandardJS, a JavaScript style guide, linter, and automatic code fixer. His packages were being downloaded over 100 million times per month.

He wasn’t some random guy. By every meaningful metric, he was a pillar of the JavaScript ecosystem.

And he had decided that the sustainability crisis in open source had gotten bad enough that he was going to take matters into his own hands.

Here’s how “funding” worked: during npm install, it printed a sponsor message to the terminal. For example, an advertisement for Linode or LogRocket. The messages were big ASCII banners, and they landed right in the middle of your install output.

It sounds crazy, and it absolutely was to developers at the time. The terminal is generally a sacred place, not somewhere you expect to be fed ads. Not even Boot.dev ads, which as we all know, are everywhere these days.

You didn’t get banner ads in your ls output. You didn’t get sponsored results in your git log. The terminal was the last ad-free space in your digital experience.

Well, until you npm installed StandardJS.

Feross was explicit about his reasoning. In his announcement post, he wrote that “the current model of sustaining open source is not working” and that ethical, non-tracking ads might be a way to finally put some money into maintainers’ pockets. He also pointed out that funding did no data collection whatsoever. It was, in his own words, a fancy console.log.

The response?

Developers hated it.

Which seems fair. People don’t install Node packages to be advertised at. Beyond the aesthetic objection, a lot of developers pointed out that letting packages run arbitrary post-install scripts to display commercial messages in the terminal was not great from a supply-chain perspective.

Sponsors felt the heat and quickly retreated. Linode issued a statement saying they were reconsidering after reflecting on the developer community’s reaction. Ad-blocker packages for npm started appearing on GitHub within days. And npm itself announced that packages showing ads in the CLI would be banned under updated policies.

Feross ended the experiment himself a couple weeks later and wrote a recap, landing on a sentiment that is worth talking about:

Approximately 100% of the Fortune 500 use open source code. Maintainers are just starting to wake up to our own power.

Feross was getting at something that becomes a theme in all of these stories. Maintainers create astronomical value for the global economy, but have almost no way to capture even a small fraction of that value monetarily.

When maintainers are expected to provide industrial-grade reliability on a hobbyist’s budget, some of these crashouts start to look a bit more understandable.

In retrospect, maybe the funding experiment ended up being a pretty good publicity stunt. It drew attention to the broken economics of open source software.

Either way, there’s a happy ending to this story: Feross eventually founded Socket, a company focused on detecting the exact kind of supply-chain shenanigans that funding turned out to be.

The LIBERTY incident

The funding affair set a pattern: a popular maintainer gets frustrated, the maintainer does something drastic, the community rebels, a corporate entity steps in and lays down a rule, and the question of how maintainers are supposed to make a wage remains unanswered.

Which brings us to January 8th, 2022.

A bunch of developers started noticing that their apps were printing garbage text into their consoles. No, their computers weren’t haunted. What they were looking at was the word “LIBERTY” three times, followed by glitchy Zalgo text and, in the case of colors.js, an infinite loop.

If you don’t know what Zalgo text is, it’s that glitchy distorted font where every character has a bunch of squiggly marks coming off of it. It looks like the text is possessed. Which, given what had just happened to these developers’ codebases, was kind of appropriate.

The culprit was a new version of the colors.js npm library, helpfully labeled 1.4.44-liberty-2, and pushed by the package’s sole maintainer, Marak Squires. That same day, Marak did the same thing to another one of his packages, faker.js, bumping it to version 6.6.6 and stripping out most of the actual functionality.

He replaced the README with a single sentence: “What really happened with Aaron Swartz?”

For context, colors.js was being downloaded over 20 million times a week. faker.js was close to 3 million. Between them, they were dependencies of roughly 20,000 other packages, including Amazon’s Cloud Development Kit.

So when Marak sabotaged his own libraries, he didn’t just break his own projects. He broke thousands of other people’s projects. Including at least one very large, very public cloud company’s.

Why would he do this?

Marak had actually been warning people for over a year. In November 2020, he wrote a now-infamous GitHub comment titled “No more free work from Marak - Pay Me or Fork This”. In it, he said he was done supporting Fortune 500 companies with his free labor, and that the only acceptable paths forward were either a six-figure yearly contract or someone else forking the project and maintaining it themselves.

Nobody sent him a six-figure contract. Nobody forked it either. Everyone just kept using it for free.

It’s open source, after all.

Think about it from the perspective of any company. You get to use this powerful tool without paying anyone for it. That’s value.

When the maintainer shows up and asks for money, the industry’s honest answer has typically been: no thank you, we’re good, please keep working for free.

So, fourteen months later, Marak did what he felt justified to do. Cue the eerie Zalgo text.

That Aaron Swartz reference in the README was interesting. Swartz was the programmer and activist who coauthored RSS, worked on Creative Commons, co-founded Reddit, and helped shape Markdown’s syntax. He was prosecuted by the federal government for downloading academic papers from JSTOR and died by suicide in 2013 while the case was still pending.

He’s a kind of patron saint for people who feel like the corporate internet has stolen something sacred. Invoking him in a deliberately broken npm package was no accident.

GitHub and npm’s reaction was genuinely unprecedented. They suspended Marak’s account entirely, cutting him off from hundreds of his own public and private repos. npm removed the malicious packages and reverted at least one of the affected libraries to a prior state. GitHub later restored his access, but the damage to the packages’ trust was done.

This led to an interesting debate: is it his code, or GitHub’s?

One software engineer, Sergio Gomez, called the suspension “a kidnapping” and said the community needed to start decentralizing the hosting of free software source code.

The other view, articulated by commenters across the internet with varying levels of politeness, was: look, if you didn’t want commercial entities using your libraries, pick a license that prevents that. Don’t use MIT.

The community’s actual resolution was to fork. A new community-maintained package, @faker-js/faker, emerged as the successor. The old faker sits there, basically abandoned. Marak lost his leverage the moment the fork shipped.

Both Feross and Marak were driven by the same underlying problem: open source doesn’t pay the rent, and the companies using it aren’t inclined to either.

The 11 lines that broke the internet

Now let’s talk about the 11 lines of code that brought the software supply chain to its knees.

March 2016. A developer named Azer Koculu had published a package to npm called kik. It was a small utility, nothing fancy. The name was also used by Kik, the messaging app company.

Kik’s lawyers asked Azer to give up the name. Azer declined. The lawyers escalated to npm itself. And npm sided with the corporation under its package-name dispute policy, deciding that the package name kik ought to be maintained by Kik.

Azer was, to put it mildly, not pleased.

So he made a decision. If npm didn’t respect him as a contributor, he didn’t want to be on npm at all. He unpublished all 273 of his packages simultaneously.

Most of those 273 packages, nobody actually used. Kind of like most of mine.

But one of them, crucially, was left-pad.

left-pad was just 11 lines of simple code. You gave it a string and a length, and it padded the left side of the string with spaces, or whatever character you asked for, until it hit the length you wanted. That was the entire library.

Here’s the crazy part: Node and Babel were among the projects hit by the fallout. So were countless other major projects that the JavaScript world was built on in 2016. Usually not directly, but through transitive dependencies. A package depended on a package that depended on a package that depended on left-pad.

But transitive dependencies are still dependencies.

So when Azer yoinked it, builds around the world started failing in a cascading, spontaneous, and deeply embarrassing way. Builds that worked yesterday suddenly didn’t. The error messages were all about a tiny utility module that nobody had thought about in years.

Engineers everywhere started doing the thing engineers did back then when they ran into trouble: they searched for their error on Stack Overflow. They found forty other people with the same problem from the last hour and slowly, collectively realized that the problem wasn’t in their code.

The problem was that a guy they had never heard of had deleted an 11-line package from a repository they had never visited, and this had somehow caused their production deployment to fail.

The coverage was brutal.

npm’s response was to do the thing they had promised they would never do.

They un-unpublished left-pad. Without Azer’s consent, npm restored an old version of the package to extinguish fires across the internet. Then, shortly after, they changed their policy: unpublish() on an old, widely depended-on package was effectively no longer a thing you could just do.

The broken code was recovered, but I don’t think we, as the software engineering community, deserve to recover from the embarrassment.

The internet went down because nobody could be bothered to write 11 lines of code themselves. This was peak dependency hell.

Any React project in the world could have inlined this function in thirty seconds. Any beginner JavaScript developer could write an equivalent version in a couple of minutes.

But instead, everyone imported it. Because that’s what the culture was. npm install the thing. Move on with your day. Ship the product.

Until one day, the guy who maintains the thing doesn’t feel like maintaining it anymore, and the house of cards built on top of his eleven lines comes down.

The left-pad story is the cautionary tale the JavaScript ecosystem absolutely should have learned from. We did not. Modern node_modules folders are still heavier than neutron stars. You still pull down 400 transitive dependencies to render a button.

But at least npm won’t let you unpublish them anymore. So that’s something.

The WordPress holy war

Three crashouts in, the pattern is clear. Each time, a single person has enormous leverage over a critical piece of shared code. Each time, something triggers them: money, respect, maybe both. And each time, a corporate gatekeeper steps in, patches the specific failure mode, and moves on.

The underlying problem of how to sustainably fund open source maintainers remains completely unaddressed.

Which sets us up for the biggest, messiest, and most fascinating crashout of them all: WordPress.

Or more specifically, the civil war between a WordPress co-creator and one of the biggest hosting companies that uses it.

Some context first. WordPress runs somewhere around 40% of all websites on the internet. It’s free, it’s open source, and it has been for over twenty years. The project started in 2003 as a fork created by Mike Little and Matt Mullenweg, and for years it has been closely associated with Mullenweg, who also co-founded Automattic, the for-profit company behind WordPress.com.

Open source project, with a for-profit company that uses the open-source software.

For years, Mullenweg’s answer to the open source sustainability question has been Five for the Future, a program where companies profiting off WordPress are encouraged to contribute time or sponsor resources back to the project.

Then there’s WP Engine, a big WordPress hosting company. According to Mullenweg, it does roughly half a billion dollars in revenue and is owned by private equity firm Silver Lake. He thinks they’re not contributing enough back to the project relative to their size. Automattic was clocking around 3,915 hours per week of contributed time, while WP Engine was closer to 40 hours per week.

On September 20th, 2024, at the WordCamp US conference, Mullenweg took the stage and called WP Engine “a cancer to WordPress.”

Not in a tweet or a Slack channel. On stage. At the official annual WordPress event.

Things accelerated quickly from there.

Automattic demanded that WP Engine pay tens of millions of dollars a year for a trademark license covering use of the word “WordPress.” WP Engine said no, and said they didn’t need a license anyway, because their use of the name fell under fair use. Mullenweg, privately and via text message, had apparently been threatening a “scorched earth nuclear approach” if WP Engine didn’t pay up before the keynote. Cease-and-desist letters flew in both directions.

Then Mullenweg did something nobody really thought he would do.

He used his personal control over WordPress.org, the central plugin and theme repository that many WordPress sites rely on for updates, to block WP Engine from accessing it. WP Engine customer sites lost the ability to pull down updates through normal channels. Then he added a wild checkbox to the WordPress.org login page requiring users to confirm they weren’t affiliated with WP Engine.

Literally a loyalty check to access the free software.

Then he seized control of a popular plugin called Advanced Custom Fields, which WP Engine maintains, and forked it into a new plugin called Secure Custom Fields, hosted on WordPress.org.

This is, to put it lightly, not normal open source governance. This was a man on a mission to take revenge on, in his mind, the worst offenders of open source abuse.

WP Engine sued, alleging trademark abuse, attempted extortion, and anti-competitive conduct. In December 2024, a federal judge granted a preliminary injunction ordering Mullenweg and Automattic to restore WP Engine’s access to WordPress.org, hand back the ACF plugin, remove the login checkbox, and take down a tracker site they had set up to publicly list WP Engine customers who had left.

The judge noted that over 40% of all websites run on WordPress and that the uncertainty was harming the broader ecosystem.

Automattic responded that the injunction was a preliminary order designed to maintain the status quo and said it looked forward to prevailing at trial.

The fight also made painfully clear how much control Mullenweg personally exercised over WordPress.org, even though the WordPress Foundation is the nonprofit charged with protecting WordPress trademarks.

This WordPress debacle is still unfolding. A class action complaint against Automattic was dismissed with leave to amend, WP Engine is still filing complaints, and Automattic is still promoting alternatives to some WP Engine-linked projects.

Funding and governance

What can we take away from this mess?

All four of these stories are about funding. Feross ran ads because nobody was paying maintainers. Marak sabotaged his code because nobody was paying maintainers. Azer yanked 273 packages because he believed npm didn’t respect maintainers. Mullenweg went to war because he felt a corporation was getting rich off his work without giving enough back.

Every single crashout, at the end of the day, is a funding story.

And every single one is also a governance story.

When things fell apart, the thing that stepped in wasn’t the community. It was a company or the government. npm banned terminal ads. GitHub suspended Marak. npm reversed Azer’s unpublish. A federal judge issued an injunction against Mullenweg to keep the broader website ecosystem stable.

The “open” part of open source survives, barely, by the system that runs on top of it.

Of course, I don’t want anyone to walk away thinking open source is bad.

Open source is awesome. Practically every piece of software you’ve ever used has been touched by it. Linux runs the internet. Git helps manage nearly every piece of code on earth. Thousands of incredible libraries are freely available right now because some person, somewhere, decided to share them.

But it’s important to remember that you get what you pay for.

We’ve built most of the modern software industry on top of code that almost nobody pays for. The people maintaining it are often doing it on nights and weekends, on volunteer time, for free, for the benefit of companies with market caps in the trillions. And occasionally, one of those maintainers snaps, and we all get a reminder of exactly how fragile it can be.

Every crashout we just talked about ended with the community finding a way through. faker got forked. left-pad got restored. StandardJS stopped showing ads. WordPress will survive the current drama, even if the trust damage doesn’t fully heal.

But the crashouts will keep coming until we figure out how to actually compensate the people who are holding up the internet, or until we at least stop expecting them to.

So the next time you submit a pull request or an issue to an open source project, ask yourself: am I making the maintainer’s life easier or harder?

Do your best to make it easier.

Open source maintainers owe you nothing. After all, you’ve paid them nothing.

And by the way, don’t be the person that depends on 11 lines of code for all your software to work and then doesn’t know how to fix it when something goes wrong.

Check out Boot.dev to learn how to code. It’s not a crash course, but a deeply fundamentals-first curriculum. Use code BOOTSTUBE for 25% off your first year.

Bibliography

1. “The Open Source Definition.” Open Source Initiative, last modified February 16, 2024. https://opensource.org/osd
2. Feross Aboukhadijeh, “Introducing funding.” Feross.org, August 19, 2019. https://feross.org/npm-install-funding/
3. “feross/funding: Let’s get open source maintainers paid.” GitHub. https://github.com/feross/funding
4. Thomas Claburn, “Developer reconsiders npm command-line ad caper after outcry.” The Register, August 30, 2019. https://www.theregister.com/2019/08/30/npm_command_line_ads/
5. Bruno Couriol, “Npm Bans Packages Which Display Ads via Its Command Line Interface.” InfoQ, August 31, 2019. https://www.infoq.com/news/2019/08/npm-bans-package-ads/
6. Feross Aboukhadijeh, “Recap of the funding experiment.” Feross.org, August 28, 2019. https://feross.org/funding-experiment-recap/
7. “Redefining Supply Chain Security.” Socket. https://socket.dev/about
8. Ax Sharma, “Dev corrupts NPM libs ‘colors’ and ‘faker’ breaking thousands of apps.” BleepingComputer, January 9, 2022. https://www.bleepingcomputer.com/news/security/dev-corrupts-npm-libs-colors-and-faker-breaking-thousands-of-apps/
9. “Infinite loop causing Denial of Service in colors.” GitHub Advisory Database, January 10, 2022. https://github.com/advisories/GHSA-5rqg-jm4f-cqx7
10. Thomas Claburn, “JavaScript dev deliberately screws up own popular npm packages to make a point of some sort.” The Register, January 10, 2022. https://www.theregister.com/2022/01/10/npm_fakerjs_colorsjs/
11. Kevin Poulsen, “Aaron Swartz, Coder and Activist, Dead at 26.” WIRED, January 12, 2013. https://www.wired.com/2013/01/aaron-swartz/
12. Marak Squires, “No more free work from Marak - Pay Me or Fork This.” faker.js issue #1046, archived by the Internet Archive, November 8, 2020. https://web.archive.org/web/20210704022108/https://github.com/Marak/faker.js/issues/1046
13. John Gruber, “Markdown.” Daring Fireball. https://daringfireball.net/projects/markdown/
14. EditorDavid, “Open Source Developer Intentionally Corrupts His Own Widely-Used Libraries.” Slashdot, January 9, 2022. https://developers.slashdot.org/story/22/01/09/2336239/open-source-developer-intentionally-corrupts-his-own-widely-used-libraries
15. Chris Williams, “How one developer just broke Node, Babel and thousands of projects in 11 lines of JavaScript.” The Register, March 23, 2016. https://www.theregister.com/2016/03/23/npm_left_pad_chaos/
16. Isaac Z. Schlueter, “kik, left-pad, and npm.” npm Blog Archive, March 23, 2016. https://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm
17. Ashley Williams, “changes to npm’s unpublish policy.” npm Blog Archive, March 29, 2016. https://blog.npmjs.org/post/141905368000/changes-to-npms-unpublish-policy
18. “Usage statistics and market share of WordPress.” W3Techs, April 23, 2026. https://w3techs.com/technologies/details/cm-wordpress
19. “About.” WordPress.org, last modified April 13, 2026. https://wordpress.org/about/
20. “Five for the Future.” WordPress.org, last modified January 16, 2026. https://wordpress.org/five-for-the-future/
21. Matt Mullenweg, “WP Engine is not WordPress.” WordPress.org News, September 21, 2024. https://wordpress.org/news/2024/09/wp-engine/
22. Thomas Claburn, “WP Engine hits back after Automattic CEO calls it ‘cancer’.” The Register, September 24, 2024. https://www.theregister.com/2024/09/24/wp_engine_claims_automattic_ceo/
23. “WP Engine.” Silver Lake portfolio page. https://www.silverlake.com/portfolio/wp-engine/
24. Rae Morey, “Judge Grants WP Engine Injunction, Orders Mullenweg to Reinstate WordPress.org Access.” The Repository, December 11, 2024. https://www.therepository.email/judge-grants-wp-engine-injunction-orders-mullenweg-to-reinstate-wordpress-org-access
25. Matt Mullenweg, “Secure Custom Fields.” WordPress.org News, October 12, 2024. https://wordpress.org/news/2024/10/secure-custom-fields/
26. “About.” WordPress Foundation. https://wordpressfoundation.org/
27. Deepak Ness, “WordPress vs WP Engine Dispute Timeline: Complete History.” WP vs WPE Report, updated March 17, 2026. https://wpvswpe.report/