Open source is dying. From one seat. Not from mine.

Jeff Geerling's February post opens with a screenshot of a GitHub inbox. Theo Browne's March video opens in front of one too. Both talk about the same thing: the weight of reviewing AI-generated pull requests into repos where the author never slept easy again. A month later the phrase "open source is dying" is a position you have to take or deflect.

I have watched that debate unfold from a seat almost nobody in it describes. The seat of the engineer who opens 40 tabs of library source, patches two of them, and ships the Monday release on top of the rest. Not a maintainer of anything with stars on it. A consumer of other people's libraries, daily, at scale, for money. The maintainer pain is real. The view from here is also real. It is not the same view.

The narrator seat

Geerling is specific, which is why the post lands. He names the review burden on attention-magnet repositories — curl, Ansible, Drupal — where AI-generated contributions now arrive faster than any human maintainer can triage them. He names the harassment, the hostile resubmissions, the strangers who treat a maintainer's inbox as a support desk. He names a repo he has stopped merging pull requests into because the signal-to-slop ratio is no longer worth his evening.

That is a real thing. That is a thing I believe. If you sit on the merge button for a project with 40,000 stars in April 2026, your queue has changed shape in a way that is not recoverable by working harder.

Triaging a bad contribution costs the maintainer roughly as much attention as writing the fix would. The economics of open-source review presumed the contributor had a minimum bar — they had at least tried to run the code. The bar is now lower than zero, because the contributor didn't necessarily read the code they submitted either.

Theo's framing is the next layer out. If AI can regenerate the code, open source loses its edge as the cheapest distribution channel for offensive-security tooling — the breakdev.org argument, narrowed to a specific niche. Also true inside that niche. Also a narrator-side observation, written from a specific seat that has a specific view of the repo graph.

Both camps make the same move. They name the pressure from where they sit, and the headline generalises the pressure to all of open source. The counter-takes do the mirror version — "AI will amplify open source" — and generalise the other way. Both are narrator-side. Both are describing the PR queue. Neither is describing the node_modules directory of a production app shipping on Monday.

The consumer seat

Here is what a recent month on the stack has looked like.

A streaming bug in one of our production pipelines took 12 hours to resolve. The bug touched five layers. Three of them were open-source libraries — an agent framework, a content renderer, a view layer. None were doing the wrong thing. The bug lived in the gap between their contracts, a class of bug that only exists because each library is doing a hard job well. A decade ago the same investigation would have been four closed-source SDKs, a support ticket, and a week of waiting. The difference now: read the source, name the gap, ship.

The same month, an MDX pipeline for a publishing surface came together on three libraries — a renderer, a syntax highlighter, a component base. All open source. All actively maintained. All composed cleanly enough that the whole pipeline fit in a single Monday. Parser, highlighter, component registry — all off-the-shelf. What remained was the bits nobody else could write — the editorial palette, the frontmatter contract, the loader.

Open-source libraries do break in production. The specific patches are not the interesting part. The interesting part is that when one breaks you in 2026, you can still open the repo, find the line, write the patch, and keep shipping the same day. That is the property that makes open source load-bearing for a production stack. Not the brand. Not the maintainer's review queue. The ability to read the source and fix it.

The reason this matters: the posts in the "dying" thread are written by people for whom the patch goes back upstream. A PR has to be opened, reviewed, merged, released. That workflow is the one under pressure. The consumer workflow is fork, patch, pin, ship, and maybe upstream the fix when there is time on a Friday afternoon. That workflow is not under pressure. That workflow has never been faster.

This is not a "we have moved fast and accepted tech debt" line. The opposite. The libraries available for a production stack in 2026 are measurably better than the ones available in 2022. The APIs are cleaner. The types are stricter. The maintainers who are still there are still shipping. The surface area the consumer has to own has shrunk, not grown. If open source were dying from the consumer seat, the direction of that trend would have flipped by now. It hasn't.

Both camps are narrator-side

The debate, as it stands, is two groups of people looking at the same ecosystem from the same seat, disagreeing about what the weather is like. Neither of them is describing the second half.

The mistake is not that Geerling is wrong. Geerling is right about the queue. The mistake is that the queue is not the whole ecosystem. The queue is the narrator's slice. The millions of production apps quietly consuming the same repositories never showed up to the debate, because the debate was structured around the question "how does it feel to be the one being asked?". That is a maintainer's question. The consumer side has a different question, and when I try to answer it honestly, the answer is that open source in 2026 is the most useful it has ever been for the work I actually do.

A retail chain runs on a stack that is end-to-end open source underneath the application layer. A hedge-fund due-diligence platform runs on another. An enterprise data platform on a third. In every case, the libraries that carry the weight are mid-tail — not the attention-magnet repos in Geerling's post. The mid-tail repos are quieter. They are not getting slopped, because they do not have the attention surface for slop to be worth generating. They are being consumed by a small number of people who actually ship with them, and those people are not the ones writing blog posts about whether the model is dying. They are writing the next migration, or the next integration, or the next patched fork, and then closing the laptop. The ratio of silent users to loud reviewers in the mid-tail is skewed enough that the mid-tail never features in a "state of open source" article, no matter which camp the article belongs to.

There is a selection effect hiding in this. The people who post about open source are disproportionately the people who maintain it. The people who consume it without drama — pinning a version, patching a contract, reading the source at 11pm — have no reason to post, because nothing is currently on fire for them. The debate inherits that bias. It always has. AI did not cause it. AI just made the narrator seat louder.

One counter-camp is arguing that AI is amplifying open source — more contributors, more documentation, more translation. Fair. Not the argument here. The argument here is that the debate itself is narrator-shaped. Both sides of it. The ecosystem has two halves and the discourse has been polling one.

The question is not whether open source is dying. The question is whose open source, and whose queue. If you sit on the merge button for an attention-magnet repo, the shape of your week has changed in a way you have every right to be furious about. If you ship production code on top of those same repos, the shape of your week has quietly got easier. Both are real. The debate has only been polling one of them.