You were your patch

On 24 August, GitHub added a block button to security advisories.

It is a small feature, announced in a few paragraphs. From the three-dot menu on an advisory description or comment, a maintainer can now remove a user from the conversation while leaving the advisory itself readable. The stated reason is worth quoting exactly, because it is doing more work than its authors probably intended: security advisories are "an important collaborative surface and an increasingly common source of spam."

Sit with the shape of that sentence. A security advisory is the one channel in a project whose entire value depends on a stranger with no standing being able to reach the maintainers quickly. It is not a place you earn your way into. The person who finds the flaw in your TLS handling is, by construction, someone you have never met, and the whole apparatus — the private reporting form, the coordinated disclosure window, the credit in the changelog — exists to make it easy for that person to arrive unannounced and be taken seriously. That is the design. And it has now acquired a moderation surface, because the arrivals became too numerous to read.

This is the fourth gate in nine months, and the sequence is the story.

In February, GitHub shipped two settings that would have been unthinkable as defaults a decade ago: a repository can now turn pull requests off entirely, so the tab disappears, or restrict their creation to collaborators only. The announcement is careful and generous in tone — maintainers "shape your communities, your project's scope and technical direction" — and it notes that more granular pull request permissions had been "one of our most consistently requested features." In June came pull request limits: a cap on how many open pull requests a person without write access may have at one time, with a bypass list for contributors you trust and draft pull requests excluded from the count. Later that month, issue creation joined the list, restrictable to people with write access, to give maintainers "more control over your issue workflow" and help "reduce unwanted noise." Then, in August, advisories.

Read those four announcements in order and a single engineering decision emerges, taken four times against four different surfaces. Every inbound path by which an unknown person could reach a maintainer has been fitted with a control, and in three of the four cases the control is the same one: write access. Not quality. Not evidence of good faith. Membership.

I want to be careful here, because the coverage of this has been sloppy in a way the primary record does not support. Not one of these four announcements says "AI". They say spam, abuse, and unwanted noise. I went looking for the widely repeated claim that GitHub shipped anti-slop controls on 27 August and found no such thing: the actual dates are 13 February, 12 June, 29 June and 24 August, and the actual language is about volume, not provenance. What a platform ships is strong evidence; what commentators say it shipped is not. So take the following as my argument rather than GitHub's: the platform is describing a volume problem without naming a cause, and the cause is not especially mysterious.

Here is the argument. Open source never had admission control. It had a price.

Writing a pull request that looked plausible enough to open used to cost something real — hours of reading unfamiliar code, a working build, some grasp of what the project was for. Filing a vulnerability report that survived thirty seconds of a maintainer's attention cost more. Those costs were never chosen, never written down, never tuned. They were a property of the world, and they performed the function that in any other system we would build deliberately: they bounded the arrival rate to something a small number of unpaid people could serve. The queue was unbounded and it did not matter, because producing an item for it was expensive.

Every architect has met this pattern and most of us have been burned by it. A system's real limits are frequently not the ones in the design document. They are incidental properties of the environment — a slow upstream, an expensive client library, a manual approval step someone put in for unrelated reasons — that turn out to be load-bearing precisely because nobody knew they were bearing load. You discover them by removing them. The removal always looks like an improvement right up to the moment the queue depth goes vertical.

Generation removed this one. The cost of producing a plausible-looking contribution fell to roughly nothing, while the cost of determining whether a contribution is any good did not move at all, because that cost is a human reading code and deciding. An asymmetry that had held for thirty years inverted in about two, and it inverted on the side that was doing the rationing.

So the gates are not surprising. What deserves more scrutiny is which gate was chosen.

Identity is the cheapest admission control available, and it is the one you reach for when you cannot afford to assess the request itself. That is a coherent engineering choice under load: when triage costs more than rejection, stop triaging. But it has a property that ought to bother anyone who has run a system with a load-shedding policy. Shedding by identity does not degrade gracefully — it degrades categorically. Every non-collaborator is shed, and every collaborator is served, and there is no gradient between them. And unlike a rate limit, it has no natural reopening condition. A rate limiter relaxes when arrivals fall. A collaborators-only setting relaxes when a human decides to relax it, and that human's experience of the closed state is uniformly good: the noise stopped, the queue is legible, the project ships. The signal that would tell you to reopen is precisely the signal the gate is designed to suppress.

Systems that close under load and lack a reopening condition do not oscillate. They latch.

The strongest objection to all of this is not really an objection to the analysis, and I think it is largely right. Maintainers are unpaid. They did not ask to become the reviewers of a machine-generated firehose, and telling them that their new intake policy has poor queue-theoretic properties is a remarkably comfortable thing to say from outside the queue. Any gate beats burnout, and burnout is the failure mode that actually ends projects. GitHub did not impose this; the February announcement is explicit that granular permissions were among the most requested features it had. The people closest to the damage asked for the door, repeatedly, and got it. There is also a fair case that the on-ramp being mourned here was already mostly ceremonial — that the drive-by pull request seldom produced a lasting contributor, and that the projects with functioning mentorship never relied on anonymous arrivals to find people.

I agree with the remedy and I dispute the accounting. As triage, closing the door is correct and probably overdue. The error is booking an emergency measure as a settled architecture, which is what happens by default when a setting ships, works, and is never revisited. Nothing in this design measures what the gate costs. The contributor who would have become a maintainer, the outsider who noticed the flaw that insiders had stopped seeing, the fork that started as a rejected patch — none of these register as a metric, and their absence is indistinguishable from their never having existed. Cost that lands outside the system is not saved. It is only unbilled.

The advisory case is where this bites hardest, and it is why the August item is the one I keep returning to. A project that restricts pull requests loses contributions, which is bad. A project that becomes hard for unknown people to report vulnerabilities to loses reports, which is worse, and it loses them silently, and it finds out from somebody else's incident. Blocking is not the same as closing, and GitHub's feature is narrow and defensible. But it establishes the surface, and surfaces get used at the level of pressure their operators are under.

None of this is confined to open source, which is why it is worth an architect's attention on a Monday morning rather than a maintainer's sympathy. Every organisation runs intake paths that were never given an admission policy because they never needed one: the architecture review board, the exception request, the internal platform's ticket queue, the RFC process, the bug bounty. Each was rate-limited by the effort of writing a coherent submission. That effort is now optional. The queues that will fail first are the ones whose owners believe they have a process, when what they have is a toll that recently went to zero. Finding those before they invert is ordinary architectural work, and almost nobody has a list.

Open source made a genuinely radical claim about standing: you needed no institution, no credential and no introduction, only a patch that worked. Merit was legible in the artefact, so the artefact was allowed to speak for you. That arrangement was affordable for as long as producing the artefact was proof of something. It no longer is. Standing will have to come from somewhere else now — reputation, attestation, some ledger of who you have been before — and every one of those is an identity system, which is the apparatus open source was built to make unnecessary.

The door is closing for good reasons. It is worth being clear about what is on the other side of it.