The case for gatekeeping, or: why medieval guilds had it figured out
Every open source maintainer I've talked to in the last six months has the same complaint: the absolute flood of mass-produced, AI-generated, mass-submitted slop requests have turned their repositories into a slush pile. The contributions look like contributions, they have commit messages, they reference issues and they follow templates etc.
But they are, almost uniformly, garbage.
A high PR count on a repository used to actually mean something. If strangers were showing up to fix your edge cases, you'd built something people cared about. Now a high PR count signals that your repo has become a target for resume-padding bots, grifters and AI-assisted contribution farmers who need their GitHub activity graph to glow green for recruiter eyeballs or just want to swamp a project in pursuit of vulnerabilities. Open source, in other words, has an open slop problem.
And I think the solution is one that would've been perfectly obvious to a thirteenth-century Florentine weaver.
The guild system solved exactly this problem
The medieval guild system gets a bad rap. It's usually remembered as a protectionist racket // a cartel of craftspeople colluding to keep prices high and competition low. And that critique isn't entirely wrong. The guilds did restrict entry. They did maintain monopolies. Adam Smith hated them, and he had reasons.
But the guilds also solved a problem: how do you maintain quality standards in a decentralized production environment when you can't personally verify every participant?
A master weaver in the Arte della Lana couldn't inspect every bolt of cloth produced in Florence. But he could verify that the person producing it had spent years as an apprentice, passed through the journeyman stage, and demonstrated competence to other masters who staked their own reputations on the assessment. The guild was, at bottom, a web of trust backed by skin in the game. You vouched for people. If they turned out to be frauds, you were fucked, too.
The open source ecosystem used to have something like this, but it was organic. You'd show up on a mailing list. You'd lurk. You'd file a good bug report. You'd submit a small patch and wait. Over time, established contributors would come to recognize your handle and your judgment. You'd build a reputation the slow way, through repeated interactions with people who were paying attention. Linus Torvalds didn't need a credentialing system for the Linux kernel because the community was small enough, and engaged enough, that trust emerged from the social fabric itself.
That fabric is shredded now.
What "open" was supposed to mean
Richard Stallman's vision for free software was rooted in an ethical claim about user freedom. When Stallman argued that software should be free, he meant free as in speech: users should be able to study, modify, and redistribute the code that runs their lives. The model that Eric Raymond championed in The Cathedral and the Bazaar added the empirical claim "many eyes make all bugs shallow," but even Raymond assumed those eyes belonged to people who could actually see.
The "open" in open source was always about access to code, not the abolition of all quality filters on human participation. But the culture developed an allergy to gatekeeping so severe that suggesting contributors should meet any bar at all became politically radioactive. And that allergy made perfect sense when the failure mode was "talented person gets excluded by arbitrary social dynamics." It makes considerably less sense when the failure mode is "thousands of LLM-generated PRs that change variable names to slightly worse variable names fuck absolutely everything for absolutely everyone."
What a modern guild would actually look like
We need a verified not-shit-person badge. Some mechanism, ideally decentralized, ideally reputation-based, that lets maintainers distinguish between "human who has demonstrated basic competence and good faith" and "entity or bot submitting or causing to be submitted auto-generated changes to mass repositories for credential farming."
This is, functionally, a guild. And before the libertarian-leaning contingent of Hacker News has a collective aneurysm, let me be specific about what I mean:
I don't mean you need a certificate to write Python. I mean something closer to what the Debian project has done with its Web of Trust model for decades: existing trusted contributors vouch for new ones. Your vouching carries weight proportional to your own standing. If you vouch for someone who turns out to be a spam vector, that costs you something. The system works because it makes reputation legible without making it bureaucratic.
You could imagine this layered onto GitHub or GitLab with relatively modest infrastructure. Contributor rings, where the inner rings are people vouched for by other inner-ring people. Maintainers could then filter PRs by trust level. Not blocking anyone from forking or submitting, but giving maintainers a signal they desperately need.
Chaucer's pilgrims each carried letters of introduction from their parishes; the principle is old enough that it shows up in The Canterbury Tales as an assumed feature of civilized travel.
TL:DR: Every mass-generated PR a maintainer has to review is time stolen from actual development. Every fake contribution that gets merged degrades the codebase. Every green-square farmer who pads their profile with AI-generated commits makes the GitHub contribution graph less useful as a signal, which ironically makes the farming less valuable too, which means they need to do more of it.
Would a guild system be perfect? Obviously not. Would it create new forms of exclusion? Probably. Would medieval Florentine weavers recognize the problem we're dealing with? I suspect they'd find it eerily familiar.
And there is no need // reason to re-invent the wheel.