How AI Is Changing Open Source

Jiří Eischmann works at Red Hat and maintains GNOME-adjacent projects. He wrote this for his Czech blog in July 2026 and translated it after the response, and it reads like a maintainer's field notes rather than a position paper. Three trends, none of them predictions: project inflation, review overwhelm, and a drop in the willingness to publish code at all.

Project inflation

GitHub is filling with repositories, and Eischmann's point is not that there are more of them but that a signal has stopped working. Finding a project with thousands of lines of code used to imply something about its author — that they knew the problem, had a personal connection to what they built, and were likely to keep maintaining it, because nobody invests that much effort casually. Generating several thousand lines now takes moments, so the inference is dead.

The distinction he insists on is between code on GitHub and an open source project. A project solves problems and use cases for its users; a repository can be one person's one-off need, dumped in public with no interest in the rest. He points at MeshCore, which has accumulated dozens of forks of everything imaginable: a feature is missing from the official firmware, so somebody forks it, vibe-codes the piece, and publishes MeshCore-UltimateEdition. The author has no relationship to it, gets bored in a month, and it becomes abandonware before it has a chance to age.

His speculative conclusion is that curated software sources may come back. Around ten years ago the consensus was that Linux distribution repositories had run their course — in the 2000s they were effectively the only source of Linux software, then projects multiplied faster than distributions could package them, and both users and authors learned to route around them. If publishing gets chaotic enough, he argues, being able to rely on something a human vetted and that will still be there in six months regains value. That reasoning is the same trade high-friction-commons and build-a-new-internet make on the content side, buying good-faith participation with a deliberately high barrier.

Review overwhelm

Writing code used to be a filter, because it cost effort and time. That filter is gone, and the review processes downstream of it are at capacity.

Two concrete cases carry the section. GNOME 50 dropped Google Drive support because nobody had maintained it for a long time; a user re-added it and submitted it upstream to gvfs. Eischmann's colleague, who maintains the project, is looking at a 4,000-line change that appears to work at a basic level and was clearly AI-generated, and has to go through it line by line before committing to maintain it for years. That contributor is responsive and genuinely interested in the issue, which Eischmann notes is now the rare case.

His own is worse. Someone opened a 9,000-line pull request against Meshy adding macOS support. One evening's quick review — an hour — turned up several thousand lines that were nothing but single-to-double quote replacements, unrelated code modified for no reason, and the overwriting of every change he had made in main over the preceding weeks. The author never responded to his comments. His takeaway is that the hour itself was too large an investment, and that next time he will reject faster.

Flathub's decision to reject AI-generated apps drew criticism as self-sabotage, and Eischmann defends it on capacity grounds: several thousand apps, more arriving daily, three people doing the reviews. The process is heavily automated but still thorough, aiming at code hygiene rather than merely catching the worst slop — he submitted two apps in six months and says the review improved both. The inclusion request template asks a few questions and a short video demonstrating the app, maybe fifteen minutes of work, and that turned out to be more effort than slop authors would spend. Some called the policy an attack on Linux's freedom and vibe-coded an open-to-everyone alternative, FlatFree, which lasted about a month.

The loss he cares about most is not throughput. Review was the mechanism by which maintainers grew contributors and eventually successors, and a submission that cost its author nothing and that they don't understand offers nothing to mentor. Open source was never only about the result; it was about a process in which people built a relationship with a project and passed it on. That is exactly contributor-poker's framing — you bet review time on the contributor rather than the contents of the first PR, and an LLM-authored PR cannot return the bet. code-review-throughput-limits supplies the numbers behind the capacity ceiling, and reviewing-ai-code is the case against "just review it like an intern's". i-dont-want-your-prs is the same maintainer rethink from the other side, asking what a contribution is even for now that writing code is cheap.

Declining motivation to publish

Eischmann reaches for Fukuyama here: democracy and liberal economics were declared the end-state winners in the 1990s and that has aged badly, and open source was similarly declared the winning development model a few years ago. He is asking whether a comparable correction is due, and he collects four arguments he hears for not publishing.

The first is review load. For some projects the cost of being buried in AI slop outweighs the value of community contributions, so they keep publishing source for transparency but stop developing in the open. Projects that care less about transparency close the source outright.

The second is license circumvention, and it is the argument with real teeth. LLMs train on source code regardless of license, and can then produce a similar solution that ships under whatever license the user prefers. Permissive licenses are unaffected — the author already accepted that. Copyleft is not: the GPL exists to guarantee that improvements come back, and a model trained on years of your work that emits a close equivalent under a proprietary license routes around the guarantee without ever violating it. llm-enshittification makes the copywashing case at more length; control-the-ideas-not-the-code is the argument from the other direction, that the design rather than the lines is what's worth owning.

MeshCore returns as the illustration. Its protocol and firmware are open while the clients are closed, and the community learned that a core team member had quietly applied for the MeshCore trademark and started vibe-coding his own closed-source products from the available code. Founder Scott Powell cited it as confirmation that keeping the client source private was right:

So, I see open source, in the age of AI, as offering up your blood, sweat and tears for others to rip-off, but in innumerable ways.

Eischmann does not endorse the position but reports it as increasingly common, and says he watches lifelong advocates who used to publish every helper script now keep them back and share on request. The trademark grab is also a governance failure of the kind maintainer-governance-ambiguity describes, where unclear roles leave the community unable to tell a takeover from a disagreement.

The third argument is that the need to share is itself weakening. Open source grew out of the cost of writing and maintaining code: implementing the same thing separately was waste, so people pooled. When you need 10% of a library's functionality and a model can reproduce that 10% after learning from the original, the dependency stops being worth it — and once you have your own copy, contributing improvements upstream has no obvious reason to happen. This is the mechanism port-not-patch-contribution documents at the scale of a whole library, where fork-and-port becomes cheap enough that the upstream fix loop weakens. Eischmann pushes back on the strongest version of the claim — the "WordPress is dead because I can generate my own CMS" opinion badly underestimates what a project provides beyond code, and swapping a dependency on an open source project for a dependency on an LLM may not pay off.

The fourth is security, an argument he has heard for two decades but never this loudly. The classic exchange is that open code helps attackers hunt vulnerabilities, answered by security through obscurity not being security and enough eyeballs making bugs shallow. What is new is the flood of AI-generated vulnerability reports, at a volume that makes closed code feel safer. He notes the asymmetry in coverage: headlines count the bugs AI found and not the ones it fixed, because fixing still needs deep understanding of the codebase and is still done by humans, whose capacity is the same bottleneck as review.

This last one he expects to pass. Projects will work through the reports, maintained open source will end up more secure, and everyone benefits. About the other three he is explicitly not optimistic.