Writing Code Was the Filter. Flathub Rebuilt One for Fifteen Minutes.

“Previously, writing code acted as a natural filter because it required a non-trivial amount of effort and time investment. That is now gone.” That is Jiří Eischmann, a GNOME-adjacent contributor and maintainer of Meshy, writing from Brno on 23 July 2026. It is the most useful sentence published about AI and open source this month, and almost nobody is reading it as a control statement.

Read it as one. The cost of producing a patch was doing governance work. It was not designed to, nobody voted for it, and no maintainer listed it in a CONTRIBUTING file. But it sat at the entrance of every project and did the one job that no downstream process can do: it made the arrival rate of contributions roughly proportional to the amount of human attention available to judge them. A person willing to spend two evenings on a patch had, by that act alone, demonstrated intent, some grasp of the codebase, and a reason to answer questions afterwards. Review capacity was never sized to the size of the problem space. It was sized to the cost of entry.

Remove the cost of entry and every process built on top of it starts operating outside the range it was calibrated for. That mechanism, not the volume, is the thing worth arguing about, because it determines which fixes can work.

Capacity Cannot Be Restored Downstream

We have written the volume story from several angles already: the report flood hitting curl, maintainer governance after the Bun incident, and verification becoming the actual job. Every one of those pieces, ours included, reaches for the same class of answer: expand the capacity to judge. More reviewers. Better triage. Review agents. Faster CI.

Look at what that answer implies about the arithmetic. A submitter with a model can produce a 4,000-line patch in an afternoon. Eischmann describes exactly that: a gvfs pull request re-adding Google Drive support, clearly AI-generated, functional at a basic level, and still requiring line-by-line review because functional at a basic level is not a standard anyone ships against. Google Drive support had been removed in GNOME 50 for lack of a maintainer in the first place. The patch did not supply the missing maintainer. It supplied more work for the maintainer who was already absent.

The second example is sharper. A Meshy pull request adding macOS support: 9,000 lines changed, of which “several thousand lines were just completely useless replacements of single quotes with double quotes.” Eischmann spent an hour reviewing it. The submitter never responded.

That hour is the number that matters. Production cost fell by something like two orders of magnitude. Review cost fell by zero, because review is a judgment about whether unfamiliar code is correct, and no tool has changed the price of that judgment much. Any strategy that only touches the review side is trying to close a hundredfold divergence with linear effort. It will not close. Restoring proportionality has to happen where proportionality lived, which is at the gate.

Flathub Priced the Gate at Fifteen Minutes

Flathub carries “several thousand” apps. Eischmann’s count of the people handling submission reviews: three. By the arithmetic above, that should be a catastrophe. It is not, and the reason is one design decision that almost nobody has copied.

To get an app into Flathub you open an inclusion ticket. The ticket asks a short set of questions and requires a video demonstrating the app actually working. Eischmann’s assessment: “It really isn’t demanding, and anyone can put it together in 15 minutes. Yet even that is too much effort for creators of AI slop.”

Fifteen minutes of irreducibly human effort, applied at the entrance, defended a queue that three people can drain. That is the cheapest anti-slop control anyone has published, and it works for reasons worth being precise about:

It cannot be delegated to the thing causing the volume. A model can write the patch. It cannot record a screen capture of software running on a machine, which requires building it, installing it, and looking at it.
It is priced below the threshold of legitimate contributors and above the threshold of automated submitters. Fifteen minutes is nothing to someone who wants their app distributed. It is fatal to a workflow whose entire economics depend on zero marginal cost per submission.
It produces evidence a reviewer can use. The demo is not a hoop. It is the first line of the review, already done, by the only party who should be doing it.
It fails loudly. No video, no ticket. The rejection needs no diff reading and no argument.

Contrast that with the response most organizations are building, which is a policy document asking contributors to disclose AI use and explain their code. Kubernetes went that route, and we covered it in the contribution accountability piece. Disclosure rules are worth having. They are also self-reported, unverifiable, and cost the submitter nothing to satisfy. An effort floor is verifiable by construction: either the artifact exists or it does not.

Generalize It: Internal Contributions and Vendor Submissions

The pattern transfers directly, and two places in a normal company need it this quarter.

Internal contribution policy. Pick the repositories where a bad merge is expensive and attach an effort floor to the pull request template. Not a longer checklist. A short questionnaire (what breaks if this is wrong, what did you run to convince yourself it works) plus a recording or a terminal transcript of the change working against something real. Two minutes of video from the author saves the reviewer twenty minutes of reconstructing intent, and it is the one artifact a person who did not read their own diff cannot produce.

Vendor and contractor submissions. Any deliverable arriving as a pull request from outside the payroll should carry the same tax, written into the statement of work. Vendors are the population with the strongest incentive to inflate line counts and the weakest incentive to keep them reviewable.

Eischmann also hands reviewers a usable smell list for the diffs that do arrive. Mass style churn unrelated to the stated goal. Edits outside the stated scope. Changes overwriting recent work on the main branch. Any one of those justifies closing a pull request in under a minute, and maintainer authority to reject fast is half of the control. The effort floor reduces arrivals; fast rejection keeps the remainder from consuming attention it has not earned.

The Curated Repository Is Coming Back

Eischmann’s forecast is the part that should make anyone who has spent a decade on package ecosystems sit up: “it is possible that curated software sources, like Linux distribution repositories, will make a comeback.” We treated curation as a solved and abandoned problem. Distro repositories lost to language package managers and app stores precisely because curation was slow, opinionated, and expensive. That cost is now a feature. A gatekeeper who says no is worth paying for when the alternative is unbounded submission.

Two second-order effects point the same direction. Dependency behavior is shifting toward vendoring and rewriting, on the logic Eischmann names: “why depend on a large external library when you don’t even need 10% of its functionality.” And copyleft’s enforcement mechanism weakens when a model launders a GPL implementation into a proprietary codebase, since the obligation was always triggered by traceable copying. We took a first pass at that in free software’s governance under agents. The trend line all three share is a retreat from open, low-friction sharing toward smaller trusted perimeters.

The succession problem is the one with the longest tail. Eischmann: “Open-source software was never just about the end result; it was also about the process. This stands in sharp contrast to the world of AI, where it’s all about the result.” Review was how maintainers were made. A contributor learned the codebase by being corrected in public over months. A pipeline processing anonymous 9,000-line patches from submitters who never reply produces no successors. MeshCore founder Scott Powell, quoted by Eischmann, put the sentiment plainly: “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’s own forecast is not gloomy, and it deserves quoting alongside the rest: “the general security of maintained open-source software will improve, and the ecosystem will benefit in the end.” Maintained is doing the work in that sentence. It is a claim about projects that still have someone at the gate.

Do This Now

Take your three most consequential repositories. For each one, answer a single question: what does a submitter have to spend before a human spends anything?

If the answer is “nothing,” add the floor this week. A five-question form and a mandatory recording of the change working, roughly fifteen minutes of the submitter’s time, enforced as a merge requirement rather than a request. Put the same clause in the next vendor statement of work you sign. Then give reviewers explicit written authority to close, without discussion, any pull request that shows mass unrelated churn, edits outside the stated scope, or overwrites of recent main-branch work.

Fifteen minutes at the entrance is not a heavy control. It was the only one that ever worked, and for thirty years nobody had to install it deliberately.

This analysis synthesizes How AI Is Changing Open Source (Jiří Eischmann, July 2026) and The Pulse: New trend, concern about massive increase in code review load (The Pragmatic Engineer, July 2026), which names the same rising concern about review workload from the engineering leadership side.

Victorino Group helps engineering organizations design contribution gates and review controls that survive machine-speed submission volume. Let’s talk.