An open and shut case?

What's left for open source when software is almost free to make?

Back in the mid-to-late 1990s I was working for a commercial software company. Back then most software was closed source; source code was fiercely protected. There was some open source (or free software as it was known back then) available, but it invariably ran on Unix - and Unix only ran on pricey proprietary hardware. Commodity x86 hardware was a fraction of the price of these Sun, HP, SGI, IBM machines - but it wasn’t considered serious enough to run Unix.

But in the late 90s things started changing. Netscape released the source code for its browser and the Open Source Initiative was founded in February 1998.

The seeds had been sown earlier - GCC in 1987 and Linux in the early 90s - the latter built by a team distributed around the globe and connected via the new-fangled internet - showed that large critical pieces of software could be built as open source. Combined with the rise of commodity x86 hardware, things moved rapidly to drop the cost of computing.

Intel helped too. The PC market was growing rapidly and Intel was selling hundreds of millions of chips. R&D costs could be spread across all those chips; Intel poured money into R&D. It was no surprise that x86 price/performance outpaced all other processors in the 90s.

All of a sudden a $3k PC running Linux could do everything that a $30k Sun box used to. Parts of the commercial world started to panic: who would pay for software when they could get it for free?

As we know now that fear was misplaced; there is a lot of money to be made in support (hello Red Hat) or in integrating open source pieces together or in developing the pieces open source doesn’t provide.

The last thirty years

Over the last thirty years open source has settled into a comfortable groove. There are the flagship packages - Linux, PostgreSQL, Kubernetes. Then there are many mid-tier packages - SQLite, libcurl, xz. And then there’s a lot of smaller packages that never gain any traction - they appear and disappear at will.

The flagship packages have official maintainers - teams of people who ensure these critical packages remain up-to-date. If the package is sufficiently important they’ll be funded (often by commercial software houses that rely on the software). But many mid-tier packages are labours-of-love; single maintainers doing it out of the goodness of their hearts. And many smaller packages are unmaintained. That’s the risk with open source - it’s free - there are no guarantees. If the worst happens you need to be prepared to maintain it yourself.

But, by and large, it works well. I’ve worked on countless projects using countless open source packages. It’s part of the reason we’re able to go so fast today - there are many massive building blocks available.

The times they are a-changin

But times are changing. AI has arrived. And as ever it brings good and bad.

On the positive side, it now becomes far easier to contribute back to the community. I’ve open sourced four major projects in the past six months, along with half a dozen Rust crates. These are not rapidly vibe-coded things; they have architectures. They have all been tested for hundreds of hours. They are things I use in other projects, so I want - need - them to work. I’m not claiming they are perfect - they are not - but they are at a level of quality that exceeds a lot of commercial software.

This is exciting, amazing. Awesome, even. A lone maintainer can do so much more than before.

But…

Many maintainers of existing packages report being deluged by slop. Take Daniel Stenberg of curl and his reports of a deluge of AI-generated bogus reports. Each of which costs time to debunk. And reviewing was already the constraint on labour-of-love projects.

Then there’s a question of whether to even allow AI generated PRs. If the maintainer’s Claude can generate a fix just as easily as the PR raiser’s Claude - and the maintainer can produce a better fix because they have better context & experience - then do PRs retain any value? Maybe raising the issue is sufficient?

The development workflow I’m currently using is exactly this - I get bug reports, diag bundles, suggestions from the test team (human + multiple Claudes). But it’s the engineering team (me + multiple Claudes) that makes the fixes. It’s much easier for me to make the fix rather than try to review and merge in a fix that’s been made against a much earlier version of the codebase.

But the pushback from maintainers has started in earnest. curl shut down its bug-bounty programme at the end of January, drowning in AI-generated slop reports. OCaml's maintainers rejected a 13,000-line AI-generated PR on the grounds that reviewing AI code is more taxing than writing it. Ghostty's Mitchell Hashimoto restricted AI contributions to pre-approved issues. As they put it, "It's the people, not the tools, that are the problem."

Then there’s the question about smaller packages. Do they have any value any more? If Claude or Codex can easily create the exact thing I need why bother with an open source package? Of course Claude and Codex also reduce the risk of using such a package - if the maintainer disappears they reduce the cost of maintaining it yourself. But why even bother?

At the moment this only works for the smaller packages - it’d be a brave person who decided to replace OpenSSL - but it seems inevitable AI will start eating its way up the stack. Will we get to the point where a self-developed version of OpenSSL written in Rust becomes lower risk than using the open source legacy C OpenSSL? I remain sceptical - OpenSSL has decades of battle hardening that AI will find it hard to replicate. Then again, the current ability of Codex and Claude would have seemed like magic just a year ago. The answer is not as obvious as it might seem.

There are other problems. Take Tailwind CSS. Their money came from one-time lifetime licences for their component libraries. It was a clever model: developer hits problem, googles it, lands on the docs, discovers the paid products, buys. But AI breaks the model; it fixes problems without needing the docs. Tailwind CSS is more popular than ever but revenue is down ~80%. In January 2026 the team laid off three of their four engineers - 75% of the engineering team.

Copyleft copyright laundering

Then there’s copyleft - and its descendants. The principle: anyone can use the code, but modify it or offer it as a service and you must share your code - or pay for a commercial licence. This model was pioneered by MySQL; it’s also been used by MongoDB, Grafana, Redis and many others.

In the past there’s been tension between the companies producing this software and the cloud providers; the latter offer these open source products as managed services. Good for the cloud providers; not so good for the developers who get little back in return. The result was many companies reaching for more restrictive licences to fight back, often later u-turning when they discovered the restrictive licence approach made things even worse for them as their communities splintered and forks appeared.

Sadly AI makes this worse. Suddenly it is cheap to do clean-room re-implementations. All you need is the spec, a test suite (where the original makes a fantastic oracle) and some tokens. Hello "copyright laundering".

People have argued this only works because the LLMs were trained on the original source. But the models are so good now that no longer matters. It’s pretty clear now that the spec/oracle pattern is all you need. The real problem is the licence guards the code, not the behaviour. And the code no longer has much value.

Which is why one team (half-jokingly) decided to de-open-source their tests - the test suite is one of the oracles making it easy for AI reimplementations.

And so?

Open source is changing. In the long run it seems likely there will remain a place for trusted versions of major pieces of infrastructure. Despite Google claiming the latest version of Gemini wrote an OS from a single prompt, we are likely to continue using Linux for many years to come. It embeds too many hard-won battle-scars.

But the descendants of models like Mythos might change that - maybe it does become feasible to build replacements that are hardened from the start.

Actually… It seems daft to write that. But then consider how far we’ve come in the past 12 months. A year ago building a kloc counter from a single prompt was state of the art…

I suspect we’re heading for a world with a small number of key packages. And an explosion of lightly used packages - people building exactly what they need and leaning on the open source infra (crates.io, npm, PyPI) because it is convenient.

And will maintenance become automated? Maybe. If Mythos and its descendants really can outpace humans at finding and fixing exploits then automated maintenance is just a matter of time.

Thirty years ago we panicked because software looked set to become free. Now? It looks like the cost of producing software is heading towards zero. I see it every day - I’ve built compilers, emulators, games, tools - years of software for the price of a few Claude and Codex subscriptions.

Where does this lead? If the AIs do become so powerful they can recreate everything from scratch on demand then the discussion about open source is moot. We might just be rearranging deckchairs. But I hope not; the ability to share software is part of the reason the pace keeps accelerating.

We were wrong to panic last time. And maybe we're wrong to panic now - but ladders don’t always have another rung.