Code was the easy part all along. What's next for Open Source? | LBP

All posts<br>AI & SocietyJune 11, 20269 min read<br>Code was the easy part all along. What's next for Open Source?

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.<br>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.<br>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.<br>Friction was doing a job<br>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.<br>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.<br>The maintainer crisis gets worse, not better<br>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.<br>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.<br>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.<br>Agents will not sit on the PMC<br>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...