The Danger of "Modern" Open Source

The Danger of "Modern" Open Source

Kris is a software developer. They’ve worked at a medium-sized company for three years. On weekends, they maintain a small open-source project as a hobby. They do that because their work doesn't use their skills fully. They review pull requests. They fix bugs. They answer questions.

The project sits in the dependency tree of half of the Fortune 500 companies in US. Millions of users rely on it. The previous maintainer handed it off in 2003 and moved on.

Kris is not paid for this work

Tell this story to a security analyst. They’ll laugh or say "WTF" out loud. A single unpaid developer, living in Nebraska, holding up infrastructure that billion-dollar companies depend upon. It sounds like a crazy joke. Except it's not =/

Kris is fictional. The situation is not.

The web depends on many people in Kris’s position. Most of them mean no harm, but someone could exploit their access. There is no contract, no legal precedent, and no accountability framework that covers unpaid open-source maintainers. They receive nothing for their work. Holding them accountable for the outcome is hard to justify.

I was also one of these contributors.

More than a decade ago, I authored what became one of the most depended-upon open-source libraries in the world. I co-maintained it with Klaus Hartl, the original author of jquery-cookie and jquery UI Tabs. Today, in 2026, js-cookie is over 14 years old. It has 20 million weekly downloads on npm. For context, jQuery has 18 million. It receives more than 23 billion uncached hits per year on jsDelivr. Millions of websites include it. More than 9000 npm packages and over 1.3 million GitHub repositories depend on it.

Neither of us have any contractual relationship with the companies that use it.

The reputation of open source was earned by a different system than the one running today

Companies built themselves on top of Linux. Linux was developed by programmers with decades of experience. The total number of programmers in the world at the time was small. Those developers created the first positive reputation for open source. A much larger, much less experienced population now borrows that reputation to publish packages on centralized registries.

Eric Raymond’s The Cathedral and the Bazaar argued that a distributed development model produces better outcomes at lower cost than a closed one. His core claim: “given enough eyeballs, all bugs are shallow.” More maintainers means bugs get caught before they reach users.

Raymond wrote that essay in a different era. Contributions lived on individual machines. There was no centralized repository. You proposed a change by emailing a diff to another developer. They were the ones who decided to pull it or not. There was no account to hack. There was no registry to poison.

The distributed Open Source model is gone. Since a long long time ago.

The incidents tell the story better than any argument can. Are you ready? 👇

On 22 March 2016, a developer removed the left-pad package from npm. Eleven lines of code. It broke build pipelines across the internet and made to the news.

In November 2018, a user named right9ctrl emailed the burned-out maintainer of event-stream, a library with 1.5 million weekly downloads. The maintainer handed over commit access. right9ctrl spent weeks making small, legitimate fixes. Then they injected encrypted malware targeting Bitcoin wallets. It ran undetected for two months.

In October 2021, an attacker hijacked the npm account behind ua-parser-js, a library with 8 million weekly downloads used by Google, Amazon, Facebook, and Microsoft. The compromised versions deployed cryptominers and password stealers. They were live for four hours.

On 9 December 2021, a Log4J vulnerability opened nearly every Java-based system on the web to remote code execution.

In January 2022, Marak Squires, the maintainer of colors.js and faker.js, sabotaged his own packages. He pushed an infinite loop to colors (23 million weekly downloads) and wiped faker’s codebase. His stated reason: Fortune 500 companies were profiting from his unpaid work. Amazon’s CDK, Facebook’s Jest, and thousands of other projects broke overnight. No attacker was involved. The threat came from the maintainer.

In March 2022, the maintainer of node-ipc shipped code that detected Russian and Belarusian IP addresses and attempted to overwrite files on disk. Geopolitical sabotage, distributed through a package manager.

In February 2022, Microsoft Research found 2,818 npm accounts with expired email domains. An attacker could register those domains and take over 8,494 packages without writing a single line of code.

In March 2024, a social engineering attack nearly compromised xz Utils, a core compression library across Linux distributions. A contributor spent two years building the maintainer’s trust, then injected a backdoor. A single developer caught it by accident after noticing a 500-millisecond performance regression in SSH logins.

On 31 March 2026, a few weeks from writing this, a North Korean state actor compromised the npm account of Axios’s lead maintainer through social engineering. Axios has 100 million weekly downloads. The attacker published two malicious versions containing a cross-platform remote access trojan. The malicious dependency had been staged 18 hours in advance. Three separate payloads were pre-built for macOS, Windows, and Linux. Both the 1.x and 0.x release branches were hit within 39 minutes. The compromised versions were live for almost three hours. Given Axios’s download velocity, that window was enough.

These are not edge cases. Many of the biggest security incidents in the past 10 years are the predictable result of how a "modern" centralised open source operates.

Millions of packages exist today, maintained by developers with wildly uneven skill levels. Most live on GitHub and npm. A username and password is all that separates each project from an attacker. Most of these developers haven’t contributed to Linux. They’ve never seen how the original open-source model worked. They just built something that developers of some companies decided to start using.

A developer hits a common problem. They search for a package. They find one and install it. Their colleagues see it, adopt it, carry it to their next company. The dependency tree grows. Others see the huge dependency tree, creates social trust, everybody installs it.

Most companies are not software companies

They don’t care how the work gets done. Software is not what they produce, just means to an end. They care if the objective was reached, and only the developers understand how.

For large, well-maintained projects like Linux or curl, this reliance makes sense. For a 12-line utility that trims whitespace, it does not. Building the piece specific to your domain is simpler. It requires less testing than importing a general package with its own dependency tree.

Sadly, that’s not what happens.

It breaks, it gets fixed, and life goes on. That cycle is the industry inertia

Companies have relied on unpaid open-source software for decades. Something breaks. Someone patches it. The cost of the next incident is assumed to be lower than the cost of changing how software gets built. Most organizations prefer to absorb the occasional crisis over paying for a future where software costs more because you have to build it.

The response to left-pad, Log4J, and xz Utils followed the same pattern: fix the immediate problem, write some blog posts, hold a few conference talks, build some security tooling, move on. The structural conditions that caused each incident never change.

There is another layer to this problem that few people talk about.

Large language models were trained on the open web. That includes open-source code, documentation, blog posts, Stack Overflow answers, and the collective output of millions of developers who published their work for free. The companies that built these models did not ask permission. They did not compensate the authors. They sell the output as a product.

The result is a tool that generates code for developers who may not understand what the code does. The LLM produces plausible output. The developer ships it. The dependency tree grows. The number of people who can read and reason about the code shrinks.

This is the part that concerns me. Open source was built on the assumption that developers would read, understand, and improve the code they used. LLMs invert that assumption. They make it possible to build software without understanding software. Every line of generated code that a developer ships without reading is another piece of infrastructure that nobody owns and nobody audits.

The open web gave its knowledge away. Companies packaged that knowledge into products that reduce the need to learn. The people who wrote the original code are not paid. The people who use the generated code are less equipped to fix it when it breaks. And it will break. It’s a palace of cards!

Kris maintains a project that Fortune 500 companies depend on. Kris does it for free, on weekends, with no obligation. If Kris burns out, walks away, or gets compromised, the blast radius reaches millions of users.

Whether that’s a flaw in open source or just how open source works, I can’t say for certain.

I built js-cookie.

I still don’t know…

If you liked this, you might like readplace.com, built for exactly this kind of reading.

Thanks for reading. If you have some feedback, reach out to me on LinkedIn, Reddit or Github.