Ask a code agent to fork an open source project, rename it, restructure it, and adapt it to your preferences, and it will hand you the result before the coffee has cooled down. What used to take a motivated engineer three months of evenings now takes one prompt and an afternoon of review. The instinctive conclusion is that open source is about to explode, because if anyone can build anything, surely we get more of everything.
I think the instinctive conclusion has the mechanism backwards, and to see why, you have to look at what the cost of writing code was actually doing inside the open source system all along.
I should say where I am standing to make this bold argument: I have spent most of the last decade in companies whose entire business rests on Apache projects: first Aiven, which runs managed Kafka, Flink, ClickHouse, PostgreSQL and others; and now Ververica, the original creators of Apache Flink and a big part of the team incubating Apache Fluss. I am not a committer on any of these projects, but I am one of the people whose job depends on them staying healthy, which turns out to be a useful vantage point for noticing what health actually consists of.
Friction was doing a job
Open source worked because writing the code was expensive, even though taking it was free. That expense acted as a filter. When forking a project meant committing months of your own time, you only forked if you genuinely meant it: you had a grievance worth months of work, a technical vision worth defending in public, or a community behind you that justified the split. The cost of acting on a disagreement forced you to ask whether the disagreement was worth acting on, and most of the time the honest answer was no, so you stayed, argued your case, and the project held together.
Take the cost away and the filter goes with it. When a fork costs an afternoon, people fork for convenience, for ego, or because they prefer a different naming convention, and none of those forks arrive with a maintainer attached or any commitment to still exist in year two. Search for any common utility today and you already get a graveyard of near-identical repositories with no way to tell the living from the dead. Agents will turn the graveyard into a landfill, and the work of figuring out which version is real gets pushed onto every person who arrives later trying to choose.
The maintainer crisis gets worse, not better
Here is the part that worries me most, and it follows from a fact that predates agents entirely: building was always kind of the cheap part of open source. The top OS contributors are some of the most efficient, productive and passionate software developers in the planet - how else would they find the ingenuity and energy to do this on top of their day jobs? The expensive parts were reviewing pull requests, handling security disclosures, writing documentation a human can actually follow, managing the expectations of a community, and making judgment calls about what the project should refuse to become. That work was the real cost of open source, and code agents make none of it cheaper.
The asymmetry is brutal when you write it down. A contributor spends five minutes prompting an agent and submits the result. A maintainer spends an hour reviewing it, because the maintainer cannot delegate the judgment of whether this code belongs in the project, what it breaks, and who will carry it for the next decade. That asymmetry always existed, but agents have widened it from an annoyance into a structural problem. The curl project has already gone public about AI-generated security reports that look plausible, cite nothing real, and burn days of expert attention to disprove. That pattern will repeat in every project large enough to matter.
We have spent years talking about open source sustainability as a funding problem, and money does help. But money does not review pull requests, and what is running out now is not cash. It is the attention of the small number of humans qualified to say yes or no.
Agents will not sit on the PMC
Anyone who has spent time around the Apache Software Foundation learns quickly that a project is far, far more than a repository. A project is a Project Management Committee that votes on every release, a security process with named humans who own disclosures, committers who earned their status through years of reviewed work, and a thick set of norms about how disagreement gets argued out on a mailing list instead of settled by whoever pushes first. Flink has all of this. Kafka has all of this. Fluss is building all of this right now as it moves through incubation, and watching that process up close has made one thing very clear to me: the governance is the project. An agent can write a Flink connector in an afternoon, and increasingly it can write a good one. What it will not do is sit through a three-week release vote, take ownership of a CVE on a Saturday night, mentor a committer candidate from a competing vendor, or argue patiently on a dev list about whether a feature belongs in the project at all. Agents do not hold opinions about a project's direction that they are willing to defend for years, and they do not care whether the project exists next year, because caring about that was never something we built into them. Every one of those activities is what keeps a project like Kafka or Postgres coherent across decades and across the commercial interests of the dozen companies betting on it. The code output of open source is about to grow enormously. The governance capacity is not growing at all.
The judgment is still human
There is a second thing agents do not bring, and it sits even further upstream than governance. Kafka exists because engineers at LinkedIn looked at their data integration mess and decided that the distributed commit log was the right abstraction to build everything else on. Flink exists because a group of researchers in Berlin bet that stateful stream processing with exactly-once guarantees was achievable when most of the industry had settled for less. ClickHouse came out of Yandex needing to answer analytical queries at a speed nobody believed was reasonable, and Postgres has been refined for 40 years by people with strong opinions about how a database should treat your data. Fluss exists because people who had spent years operating both streaming systems and lakehouses concluded that the storage layer between them was the problem worth solving next.
None of those projects began with code. Each one began with an opinionated act of judgment: a decision about which problem was worth years of effort and what shape the answer should take, made by people who had earned their opinions through production pain. That kind of ideation, the genuine architectural creativity and the taste to know which problems matter, remains so far the exclusive domain of trained, experienced humans. Agents are getting remarkably good at the layer below it. Give an architect an agent and the prototype that used to take a quarter now takes a week, which genuinely changes how fast a good idea can be tested. But the agent did not have the idea, and nothing in how these systems work today suggests it would have known the idea was worth having.
The counterargument worth taking seriously
There is a version of this story where open source comes out stronger, and I want to give it real weight rather than just a polite nod. In a world where most software is generated by models and shipped as opaque services, auditable code becomes rare, and rare things become valuable. You cannot really inspect the model that wrote your vendor's black-box product, and you cannot subpoena its reasoning. You can read the Flink codebase, trace any decision through years of mailing list archives and FLIP discussions, and see exactly who approved what and why. When nothing else is verifiable, community governance and a public audit trail become the verification layer for the entire stack, and for the regulated industries I spend my working days with, that is not an abstract virtue. It is the difference between software you can deploy and software you cannot.
In that world the moat moves. It was never honestly "we have the code," and now that the code costs nothing, the pretense drops away. What remains is the community, the trust, and the accumulated record of decisions, which is to say everything the agent did not and cannot produce. I made a related argument in an earlier post about Sulci: when production gets cheap, context becomes the moat. Code is now the cheapest artifact in the whole system. The history of why it looks the way it does, the people who hold that history, and the governance that decides what it becomes next are the scarce parts, and they were the scarce parts all along.
Where this leaves us
I do not think code agents kill open source. I think they end the version of it where the code itself was the point, and they expose what the real product was the whole time: maintainership, governance, trust, and the slow human work of deciding what software should be. We could not see that layer clearly while the code was still expensive, because the cost of the code hid the value of everything wrapped around it. Now the code is free, and the price tag has moved to where the value always lived.
I find that more reassuring than alarming. The projects I have built my career around are not held together by their repositories, and they never were. They are held together by people with earned opinions and the patience to govern, and that part of the work just became more visible. If you are one of those people, thank you. The typing was never the hard part, and now everyone can see it.