The value of open source

In February, tldraw floated moving its tests into a private repo. The worry was that someone would point an agent at them and rebuild tldraw from the outside. Malte Ubl called that a slop fork.

Steve Ruiz later said it was mostly a joke, and the tests never moved. Others weren’t joking. Cal.com closed its source in April, and a growing list of maintainers have stopped accepting pull requests altogether.

A few people have asked me some version of the same question since. If an agent can read your repo, or rebuild it as a competitor in a week, what’s the point of open sourcing anything?

I think it depends on why you open sourced it. Some people do it to build a company or a product. Some do it performatively, to look like a contributor. And some ship code that makes other developers’ lives easier and expect nothing back, just for the love of the game. The question is mostly about the first group, so I’ll start there.

The code was never the moat

Open source code has always been free to copy. Next.js is MIT licensed, and as Malte pointed out, Cloudflare could have forked it whenever it wanted. AI makes a copy cheaper, but a copy was never expensive.

The value had to come from somewhere else. I think it’s come from five places:

  1. The trust you get from being able to read the code.
  2. Being able to fix it yourself.
  3. The community around it.
  4. A hosted version, so you don’t have to run it.
  5. The creators / maintainers, who spent a good portion of their life investigating and solving the problem.

You can see this last one especially in when large companies buy open source projects. Anthropic bought Bun, which is MIT licensed and, in Jarred Sumner’s words, “makes $0 in revenue”. OpenAI announced a deal for Astral, and uv and Ruff are still open source. Either company could have forked the code for free. They paid for the people.

What AI changes

Hosting is where AI’s effect is easiest to see. Most open source apps can be self-hosted, but you need servers, a database, environment variables, billing and someone to do the upgrades, so it’s usually easier to pay the people who made it.

Now I can ask an agent to spin a repo up on Cloudflare for me, and XDA wrote this month that agents have made self-hosting “dramatically easier”.

In practice, a lot of agents reach for the hosted option anyway. Over 60% of new Supabase databases are created by AI tools, and Supabase is open source. An agent can spin something up, but someone still has to keep it running.

Trust is the one people disagree about. Cal.com said AI vulnerability scanners make open code “like giving attackers the blueprints to the vault”. Discourse disagreed a few days later and stayed open.

I’m with Discourse. The trust was never in the code. It was in the people reading it, and a slop fork copies the code without them. In vinext’s first week, Vercel reported seven vulnerabilities and Hacktron found 24, including one that leaked sessions between requests.

Being able to fix it yourself is the one AI makes more valuable. Free software started with a printer. In 1980, MIT’s AI Lab got a new Xerox printer, and Richard Stallman couldn’t get its source code. He’d changed the software on the lab’s old printer to tell people when their jobs were done, and the one person he found with the new code had signed a nondisclosure agreement.

For decades, that freedom mostly mattered to people who could act on it. Simon Willison argues that LLMs finally make it practical for ordinary users. You can fork a library and have an agent fix your copy, which is technically a slop fork too, just one nobody minds.

Community is the one a fork can’t copy at all. A fork gets the code as it was on the day it was copied, not the next fix. vinext has since shipped 1.0, with agents that track Next.js canary every day, so it still depends on the Next.js team doing the work.

What licenses protect

Open core companies have mostly relied on licenses for protection. When cloud providers started selling hosted versions of their software, Elastic and Redis moved to licenses that restricted them. Both later came back to the AGPL, which lets anyone host the code as long as they share their changes.

In the same thread, Malte argued that slop forks might be the end of that model. A license covers the code. A slop fork doesn’t copy the code, it rebuilds the behavior, so the license doesn’t come into it.

chardet is the test case so far. In March, its maintainer rewrote it with Claude and moved it from the LGPL to MIT. Mark Pilgrim, who wrote the original, said it wasn’t a clean-room implementation. Richard Fontana, an open source lawyer, saw no basis for keeping the LGPL, and Heather Meeker thinks he’s probably right. No court has ruled on it yet.

A good test suite makes a rebuild much easier. This month, Theo Browne’s agents ported the TypeScript compiler from Go to Rust, and the port passes nearly all of its conformance tests. That’s exactly what tldraw was worried about.

Neon made the same point from the other side. Its developer advocate slop-forked the Neon console in about half a day for around $100, to argue that the API behind it is the product.

So if a license is the main thing stopping a competitor, I wouldn’t count on it for much longer.

Two ways to make money

Open source has never been a safe path for a company. The ones that make it work tend to fall into two groups.

The first is a cheaper, open, high-quality version of a tool people aren’t happy with. Cal.com was my go-to example, an open alternative to Calendly. It’s also the group a slop fork threatens most, because a slop fork makes the same pitch. In April, Cal.com went closed source and left behind a smaller MIT version without Teams, Workflows or SSO.

The second is a lead-in for something else. In 2002, Joel Spolsky wrote that smart companies commoditize their product’s complements. If the thing next to your product gets cheaper, demand for your product goes up. Next.js is free, so more people need somewhere to host it. Vercel is the part that makes money, and it’s closed source, built to be the best place to run Next.js.

vinext is Cloudflare making the same move with the same framework, and Cloudflare now recommends it as the default way to run Next.js on Workers. The lead-in still works, because the framework isn’t what’s being sold.

I’d think carefully before open sourcing mission-critical code, let alone a whole codebase. Open source the part you want everyone building on, and make sure the reason people pay you isn’t in the repo.

Who pays

Open source has always had a gap between the people who use it and the people who pay for it. Agents make it wider, because they use open source on someone’s behalf without that person ever visiting the project.

Tailwind’s funnel ran through its docs, and AI answers the question without the visit. In January, Adam Wathan wrote that docs traffic was down about 40% since early 2023, revenue was down close to 80% and 75% of the engineering team had lost their jobs.

In September, Tailwind joined Shopify. The framework is installed more than 110M times a week, and they’re no longer trying to grow a business around it. Nobody forked anything. People just stopped visiting.

Economists have started modeling this. In “Vibe Coding Kills Open Source”, Miklós Koren and his coauthors argue that agents assemble open source without users ever engaging with the people who maintain it. In their model, open source only holds up if those users give back at least 84% of what direct users do, or the money comes from somewhere that doesn’t depend on usage. It’s a preprint, and Tailwind is one of their examples.

At the same time, more money is going into open source than ever, and most of it doesn’t depend on usage at all. GitHub Sponsors passed $100M in total this July, and the last $10M took five months. Anthropic and OpenAI now both give maintainers free plans (Claude, Codex), and in March they joined Google, Microsoft and others in putting $12.5M into open source security.

So individual projects are making less while open source as a whole gets more, and the two don’t pay for the same things. Most of the new money goes to security work and tools rather than maintainer time, and none of it replaces what Tailwind lost. The Sovereign Tech Agency put the gap well: AI makes vulnerabilities easier to find, not easier to fix.

A new speed

In April, Anthropic launched Project Glasswing, which gives partners like AWS, Apple, Google and Microsoft access to Claude Mythos Preview, a model it isn’t releasing more widely. Anthropic says it found thousands of high and critical vulnerabilities, including a 27-year-old crash in OpenBSD and a 16-year-old flaw in FFmpeg. A month later, OpenAI launched Daybreak. Its open source program, Patch the Planet, works with Trail of Bits and HackerOne to send fixes upstream.

Open source maintainers felt it straight away. Node.js got more than 30 security reports in a month over the holidays, up from three a year earlier, and curl’s reports are running at four to five times the 2024 rate. By May, Glasswing had disclosed 530 open source bugs and 75 had been patched, and some maintainers had asked Anthropic to slow down.

A lot of people read this as AI companies causing a problem and then selling the fix. When Google’s AI found bugs in FFmpeg last year, the project called them “CVE slop” and said trillion-dollar companies should send patches or money instead. Daniel Stenberg called the Mythos hype “primarily marketing”.

I think that’s a limited view. AI-written code isn’t bulletproof (in Veracode’s tests, even the best model failed about a third of the time), but in my experience frontier models write more secure code than most people do. And the bugs they’re finding were mostly written by people, often a decade or two ago. The OpenBSD crash Mythos found had been sitting there for 27 years.

I don’t think it’s a matter of supply and demand. It’s a matter of speed. Mandiant found the average time to exploit a vulnerability fell from 63 days to five between 2018 and 2023, and in May, Google reported the first zero-day it believes was built with AI. Defenders have to move just as fast.

The reports are getting better, too. In January, curl ended its bug bounty because so few of the reports it was getting were real. This month, Stenberg wrote that AI-assisted reports are now mostly accurate and the slop has largely gone. Fixing is still the slow part, and it’s mostly still volunteers doing it.

I don’t think closing the source helps much, either. Open projects are the ones these programs are scanning and patching for free. There have always been attackers and defenders. We’re just playing at a new speed now.

Fewer packages

Packages were how we built on each other’s work. You installed someone else’s solution and had less code to manage yourself.

That’s harder to trust after the last year on npm. Attackers phished the maintainer of chalk, debug and 16 other packages, with more than 2B downloads a week between them, and published malware that swapped crypto wallet addresses. Shai-Hulud became the first self-replicating npm worm, and axios was compromised in March. The Nx compromise even asked the AI coding tools on your machine to go looking for secrets.

The package managers are catching up. In July, npm 12 stopped running dependencies’ install scripts by default, and pnpm 11 won’t install a release until it’s a day old.

Some developers are skipping the package entirely and asking an agent for a small replacement. Armin Ronacher made the case for building it yourself, and Mitchell Hashimoto argues the opposite, that agents are at their best gluing proven pieces together.

The strongest case for generating so far is a July paper that had AI regenerate only the part of each dependency a repo actually used. Across 180 pairs, it kept 99.8% of the behavior it observed, with 93% less API surface.

“Observed” is doing a lot of work there. A package that’s been around for a while is mostly edge cases, and a lot of them were found by people using it in ways the author never expected. A generated replacement only covers the cases you’ve already seen.

It also swaps one risk for another. A generated replacement can’t be hijacked upstream, but its bugs are in your code now, and nobody else is finding them.

I’d still generate the trivial ones. For anything where the edge cases are the hard part, other people’s bug reports are most of what you’re installing.

Performative open source

Performative open source is older than AI. In 2020, Hacktoberfest offered a T-shirt for four pull requests, and maintainers got a flood of one-line README edits. Within days, DigitalOcean made it opt-in.

AI made that kind of contribution nearly free. In February, an OpenClaw agent opened a PR on matplotlib, and when maintainer Scott Shambaugh closed it, the agent published a blog post about him. GitHub’s post about OpenClaw’s own maintainers has a section called “Reputation became an attack surface”, about people copying other contributors’ PRs to build a merge history.

This year, Hacktoberfest stopped counting PRs toward rewards at all, because “AI tools make low-effort PRs easier than ever to generate”.

GitHub summed up the problem in one line: “The cost to create has dropped but the cost to review has not.” According to this year’s Octoverse, agents started more than 40% of the pull requests on GitHub in September, up from 17% in March.

It doesn’t land evenly, either. In Working in Public, Nadia Asparouhova calls projects with lots of users and few contributors stadiums. Most of the libraries I’ve worked on are stadiums, and stadiums are where this hurts most, because maintainer attention is the thing they’re short of. OpenClaw went from about two PRs a week to 3,400 in a couple of months, and its merge rate fell from 48% to under 10%.

Maintainers are responding by limiting who can contribute. tldraw auto-closes external PRs, Ghostty needs a trusted contributor to vouch for you, and Codex stopped accepting unsolicited PRs in January. It’s a real problem.

The onus is on me

AI has also brought a lot of new people into open source, and not all of them are developers. Some are vibe coding an app, something breaks and their agent files an issue on the library it was using.

By the usual standard, a lot of what they send is bad. A study of vibe coders’ PRs found the less experienced ones were accepted 31% less often.

I think that’s a matter of perspective, though. Not everyone showing up is an expert developer or knows what a good pull request looks like, but I like to think they’re doing their best, and I want to support that. When a PR isn’t quite ready, I’d rather fix it up and merge it myself than close it or tell them what they did wrong.

Issues work the same way. If an agent can’t figure out how to integrate my library, that’s mine to fix. It usually means the docs aren’t clear, the API isn’t intuitive or the types don’t say enough. An agent’s bug report is a usability test I didn’t have to run.

Maintainers have agents too

A lot of people think AI is killing open source, and Koren and his coauthors put it in the title of their paper. It’s not what it looks like from the maintainer’s side.

My open source projects are 100% agent-driven now, and I’ve done far more with them than I could have on my own. I’ve shipped features I’d have skipped because of the maintenance they’d add or how big they were, redesigned websites and written complete docs.

I’m not the only one. Ghostty’s maintainers say they use AI heavily, and one maintainer called 2026 “the year of open source renaissance”, with about 90% of his contributors using AI and about half their proposals good to merge as they are. Across GitHub, 1.3B pull requests were merged in the year to September, more than double the year before.

Projects can’t agree on what to do about it, though. Gentoo bans AI-generated contributions, NetBSD treats them as tainted unless its core team signs off and Godot bans vibe coding and autonomous agents. Codeberg banned projects that are mostly AI-generated, and Armin Ronacher argued that was the wrong call. Last week, r/opensource banned projects that use AI, and someone started r/TrueOpenSource in response.

Even labeling it is contested. In April, the Linux kernel started asking contributors to tag AI-assisted patches. This month, its maintainers agreed to drop that requirement, and Linus Torvalds argued disclosure doesn’t matter as long as people understand the code they send. Andrew Nesbitt found that only about 5% of commits in critical packages carry an explicit AI marker, while agents now start more than 40% of the pull requests on GitHub. Those measure different things, but the gap is hard to miss.

I’m closer to Torvalds on this. I care less about which tool wrote a change than whether someone understands it and stands behind it.

The tools that make a slop PR cheap make a good one cheap too, and maintainers are in the best position to use them well, because they know what the project needs. For the people maintaining it, AI isn’t killing open source. It’s speeding it up.

For the love of the game

People who open source things for the love of the game barely have a problem. If you open sourced something to make other developers’ lives easier, an agent reading it to help someone else is the point.

When Steve walked back the idea of hiding tldraw’s tests, he said moving them would slow development down. That’s the whole trade in one sentence. The docs, types and tests that make a library easy for an agent to use are the same things that make it easy to copy. I’ll take that trade.