What Happens When Code Stops Being Scarce
Open source never ran on generosity. It ran on scarcity. The bottleneck was never ideas, it was the number of people who could sit down, understand a problem deeply enough, and produce a correct implementation fast enough that it existed before the need evaporated. AI collapses that gap to near-zero for any well-understood problem. Which turns out to be most problems. The danger isn't theft. It's flooding, a river that used to flow at a human rate, now increased by three orders of magnitude, drowning the attention pipeline that gave your project value. Value migrates from implementation to curation. The maintainer of 2030 doesn't write much code; they maintain position in the graph, staking their reputation on selections rather than productions. That was always the real work. We just couldn't see it because the implementation layer was thick enough to obscure it.
I want to talk about the thing nobody in open source wants to say out loud.
Not the supply chain problem. Not the maintainer burnout problem. Not the regulatory compliance problem, or the funding problem, or the governance problem. Those are real, and serious, and armies of people are working on them. The one I’m after doesn’t. It’s the problem that wakes me up at 3am, and it has nothing to do with whether open source survives. It’s about whether the act of writing it still matters.
Here it is: an AI can reproduce your project in seconds. Not a rough sketch. Not a skeleton that needs weeks of filling in. A working, tested, documented reimplementation, functionally equivalent, often cleaner, sometimes better. Every model cycle narrows the gap. Every release shaves another month off what used to be differentiated work.
You spent two years building something. Someone prompts their way to the same thing in an afternoon. And the version they got is under no license at all because it was generated, not authored. It exists in a legal vacuum that the open source definition never anticipated.
The question isn’t whether this is theft. The question is whether it matters that it isn’t.
The Standard Takes (And Why They Miss)
The industry has settled into three comfortable positions on this, and all three are wrong in the same way: they answer a different question than the one being asked.
The Booster. “AI supercharges open source! It lowers the barrier! More people can contribute!” True, and irrelevant. AI does lower the barrier to producing code. That’s the problem. The barrier to production was the only thing that gave the production value. When you remove the bottleneck, you don’t get a trickle. You get a flood.
The Legalist. “We need new licenses! AI training rights! Source-available with AI clauses!” A lawyer’s answer to an economics problem. You cannot copyright a function signature. You cannot patent an algorithm that’s been described in a textbook. You can litigate about training data until the sun burns out and it will not change the underlying physics: intelligence applied to a well-understood problem produces equivalent solutions. Independently. Defensibly. At scale.
The Denier. “AI code isn’t good enough. Real engineering requires taste, judgment, experience. Machines can’t do that.” This was true eighteen months ago. It’s less true every quarter. The trajectory is visible. Anyone drawing confidence from the current gap is drawing confidence from a shrinking asset.
All three answers dodge the actual structural question. Here it is:
What gave open source projects their value in the first place?
The Scarcity Illusion
Open source never ran on generosity. It ran on scarcity.
Not code scarcity, there’s always been more code than anyone could read. Production scarcity. The bottleneck wasn’t ideas. It was the number of people who could sit down, understand a problem deeply enough, and produce a correct implementation fast enough that the implementation existed before the need evaporated.
That bottleneck was the entire economic foundation of open source’s cultural capital. When you shipped a library that solved a real problem, you got downloads, stars, users, credibility, not because you were generous, but because you had done something hard that most people couldn’t do quickly. The value was in the gap between “problem identified” and “solution shipped.” You owned that gap. It was your proof of work.
AI collapses that gap to near-zero for any problem that is well-understood. Which turns out to be most problems. The novel architecture, the genuine systems innovation, the thing nobody has quite figured out yet, that’s still human. But the vast majority of what gets published as open source every day is not that. It’s the thousandth REST client, the hundredth ORM wrapper, the fiftieth CLI argument parser. Competent, necessary, unglamorous implementation work that used to require a human sitting at a keyboard for weeks.
That work is now a commodity.
Not theoretically. Not in five years. Now. Today, August 2026, a determined developer with access to a frontier model can reproduce most non-trivial open source libraries in an afternoon. The result won’t have the battle scars, the edge case handling, the community-contributed fixes for platforms you forgot existed, but it will work for the common case, and the common case is where 80% of users live.
The Flood, Not the Theft
Here’s where the standard framing goes wrong. The fear is framed as theft, as if the danger is someone copying your project specifically. That’s not the danger. Your specific project is irrelevant to the mechanism.
The danger is flooding.
Imagine a river. For twenty years, new projects entered the river at a human rate, hundreds per day, thousands per week. The ecosystem’s attention, its review bandwidth, its dependency graph positioning, its trust accumulation, was calibrated for that flow rate. A new project had time to be noticed, evaluated, adopted, integrated. It moved through the attention pipeline at human speed, and that was fine because the pipeline was built for human speed.
Now imagine the same river with the flow rate increased by three orders of magnitude. Not a thousand new projects a week. A million. Generated. Plausible. Individually unremarkable but collectively overwhelming. The attention pipeline doesn’t scale. The review bandwidth doesn’t scale. The trust heuristics, “500 stars, three years of commits”, stop meaning anything, because stars can be farmed and history can be fabricated.
This is the actual mechanism. AI doesn’t kill your project. It drowns the ecosystem in alternatives until your project’s specific value, the trust, the testing, the community, the dependency graph position, is one voice in a stadium of a million voices saying the same thing.
The scarcity that gave your project value was never really code scarcity, production scarcity was just the mechanism that kept attention scarce. And AI breaks the production bottleneck that kept attention scarce.
What Remains Valuable
If implementation is commoditized, what retains value? Three layers. And they’re the same three layers that always mattered, just visible now that the noise floor has dropped.
Discovery. Identifying a problem before it’s well-understood. The person who says “this is a thing nobody has solved yet” and is right, that person’s labor is not reproducible by a machine, because the machine doesn’t know what’s unsolved. It knows what’s been solved, which is the training data. The frontier is always human. The person who names the problem owns the problem. That hasn’t changed.
Trust. A generated implementation is worth nothing until someone runs it in production, finds the edge cases, reports the bugs, and builds the social proof that this thing actually works under load. That’s months of work. It’s boring, it’s expensive, and it can’t be automated because it requires real systems, real users, real failure modes. The npm package with a thousand stars and three years of bug reports is not equivalent to the Claude-generated reimplementation with zero downloads, no matter how clean the code is. Trust is the moat. It always was.
Proof of work. The commit history, the CI pipeline, the review process, the security audit, these are artifacts of someone having cared enough to do the boring parts. AI generates the artifact. It doesn’t generate the caring. And in a flooded ecosystem, the ability to demonstrate sustained human attention is the strongest signal available. Not because humans are inherently better, but because sustained attention is the one thing that can’t be faked at scale.
The Migration
What this means in practice: value migrates from implementation to curation.
The open source contributor of 2020 was valued for writing code. The open source contributor of 2028 will be valued for selecting code, for the judgment to say “this generated implementation is correct, this one isn’t, and here’s the evidence.” The maintainer becomes less of an author and more of an editor. Less Hemingway, more Maxwell Perkins. The skill shifts from production to discrimination.
This is already happening. The projects that are gaining traction in 2026 are not the ones with the most code. They’re the ones with the clearest signal about which code matters. Opinionated frameworks that make choices. Curated dependency lists. Security audits of generated code. Trust registries. Proof-of-life attestations.
The future belongs to the people who can tell the difference between a good implementation and a great one, and who are willing to stake their reputation on the distinction. That was always the real work. We just didn’t know it because the implementation bottleneck hid it.
Where the Line Is
The question that started this: up to which point does open source retain value?
Here’s the uncomfortable answer: most of what we called “open source contribution” was implementation labor, and that layer is now commodity. The specific code you wrote, the function bodies, the test cases, the error handling, that’s the layer AI commoditizes. It was also the layer most contributors spent most of their time on. It felt like the work. It wasn’t. It was the last mile of work, built on top of the actual value: the problem identification, the architectural decision, the trust accumulation.
Open source retains value at exactly the layers where scarcity still exists. The problem frontier. The trust surface. The sustained attention. Everything below that, the implementation of well-understood patterns, the boilerplate, the glue code, the thousandth library that does a thing everyone already knows how to do, that’s all commodity now. Not tomorrow. Now.
The size of the commodity layer grows with every model release. The size of the scarce layer doesn’t, human attention is finite and isn’t getting larger. So the ratio shifts. What was 90% implementation and 10% architecture becomes 30% implementation, 70% judgment. The open source “contributor” who only knew how to write code is being priced out. The one who knows how to read code, to evaluate it, to select it, to stake their name on it, that’s the one who survives.
What It Looks Like in 2030
Not utopia. Not doom. Restructuring.
The dependency graph of 2030 will have far more nodes than today, most of them machine-generated, most of them transient. A small fraction will carry trust attestations, human-maintained, audited, battle-tested. The enterprise consumers won’t choose based on stars or license. They’ll choose based on signal: which nodes have sustained human attention, which have security audits, which have proof-of-life.
The maintainer of 2030 doesn’t write much code. They maintain position in the graph, they’re the human in the loop who says “this generated implementation is sound, I’ve reviewed it, I’m staking my reputation on it, and I’ll be here to fix it when it breaks.” That’s the value proposition. It was always the value proposition. We just couldn’t see it because the implementation layer was thick enough to obscure it.
The projects that die won’t be the ones that get “copied by AI.” That framing implies a specificity that doesn’t exist. The projects that die will be the ones that offered nothing but implementation, clean code solving a well-understood problem, with no trust layer, no community, no proof of sustained attention. Those projects were always fragile. They just had a production moat protecting them. That moat is gone.
The projects that thrive will be the ones built on the scarce layers from day one: opinionated architecture, active curation, human trust as the product. Some of them won’t have much code at all. They’ll have judgment. And judgment, for now, remains stubbornly, defiantly human.
I don’t think open source dies. I think it grows up, the same way it’s been growing up, not gracefully, not by choice, but by being dragged into maturity by forces it can’t control. The childhood where writing a useful library was enough to earn credibility is over. What replaces it requires more judgment, more taste, more willingness to stake your name on the quality of your selections rather than your productions.
That’s not a tragedy. That’s a promotion.
Whether most contributors are ready for it is a different question. I suspect many aren’t. The ones who are, the ones who always knew the real value was in the thinking, not the typing, they’ll be fine.
The rest will have to learn a new skill. Not how to write code. How to read it.
Markus Maiwald, August 13, 2026. Munich.