A village had a commons at its center. Anyone could use it. You could set up a stall, plant a garden, build a stage, host a market. The only rule was simple: whatever you create, others can learn from and build upon. That was it. The commons thrived.
One day, someone built something shoddy that collapsed and hurt a child. The village appointed inspectors to check for safety. Reasonable.
Then someone built something ugly. A committee formed to review proposals. Still reasonable.
Then someone built something the committee found distasteful. Then something redundant. Then something that worked perfectly well but didn’t match the aesthetic the committee preferred.
Each new rule had a reason. Each reason had a story. Nobody remembered most of the stories anymore—just the rules.
Years later, a traveler arrived. She’d heard of the famous commons where anyone could build. She found it easily enough—a beautiful open space at the center of town. But when she tried to enter, a clerk handed her a stack of forms.
“The commons is open to everyone,” he explained. “You just need committee approval. Submit your proposal, wait for review, and if everything meets our guidelines, you’re welcome to build.”
“How long does that take?”
“Six to eight weeks. Sometimes longer. Depends on the committee’s feedback.”
The traveler looked at the forms. She looked at the commons, mostly empty now. She left.
The commons never closed. The committee just made sure almost nobody used it.
What the Charter Actually Promised
The Free Software Foundation defines software freedom through four essential freedoms: “the freedom to run the program as you wish, the freedom to study and change the program, the freedom to redistribute copies, and the freedom to distribute copies of your modified versions.”
That’s it. That’s the whole philosophy.
Richard Stallman designed the GPL to encode a radical idea: trust. Trust users to evaluate software. Trust the community to surface quality. Trust that freedom works better than control. He wrote that “restrictions on distribution and modification of the program cannot facilitate its use”—that friction between people who want to share and people who want to use defeats the entire purpose.
The GPL asks almost nothing of developers beyond “share the source and preserve the license.” It doesn’t ask for design review. It doesn’t require aesthetic approval. It doesn’t condition distribution on satisfying a committee’s preferences.
WordPress adopted this license—and this philosophy—over twenty years ago. The commons was open.
The Gap Between License and Process
But over two decades, a committee grew up around the commons.
The plugin guidelines now span eighteen major sections with dozens of subsections. Theme requirements dictate everything from screenshot dimensions to which HTML elements may appear where. Each rule has a reason. Each reason has a story. Most of the stories are forgotten; the rules remain.
Here’s what we need to reckon with: fully GPL-compliant code—code that honors every freedom the license guarantees—can be rejected because it doesn’t satisfy the committee’s preferences. Design opinions. Aesthetic judgments. Architectural philosophies.
The GPL says: “You’re free to share this.”
The committee says: “After we review it.”
Stallman warned against exactly this. He wrote that free software means “you have the four freedoms” and that any system which restricts those freedoms—even for reasons that sound good—undermines the foundation. The GPL was deliberately minimal because Stallman understood that requirements accumulate, and accumulation becomes restriction.
The code is free. The distribution has become conditional in ways the license never contemplated.
How Committees Grow
Nobody sets out to build a committee that smothers a commons. It just happens.
Someone submits something that causes a problem. A rule gets added to prevent it. Someone else does something the reviewers dislike. Another rule. Easier to prevent than to debate.
In 1999, Poul-Henning Kamp described this dynamic in a now-famous message to the FreeBSD community. He called it “bikeshedding”—the tendency for trivial issues to attract disproportionate process because everyone feels qualified to have opinions on them. A nuclear reactor proposal passes without comment because it’s too complex to critique. A bike shed triggers endless debate about paint colors.
Kamp warned that this dynamic “chews up, spits out, and scares away” new contributors. Rules accumulate around the trivial while the essential gets neglected.
The FreeBSD community eventually codified a principle in response: just because you can have an opinion on someone’s bike shed doesn’t mean you should stop them from building it because you don’t like their color choice.
WordPress’s committee has no such principle. The rules keep growing.
The Bazaar Became a Cathedral
Eric S. Raymond’s “The Cathedral and the Bazaar” gave open source its founding metaphor. The Cathedral: code carefully crafted by wizards behind closed doors, released only when authorities deem it ready. The Bazaar: a bustling marketplace where anyone can participate, trusting that “given enough eyeballs, all bugs are shallow.”
Raymond argued that the Bazaar wins because it respects how open source actually works. “The principle of command,” he wrote, “is effectively impossible to apply among volunteers in the anarchist’s paradise we call the Internet.” You can’t run an open source project like a gated institution—not if you actually want the benefits of openness.
WordPress talks like a Bazaar. It celebrates community contribution, democratizing publishing, the power of open collaboration.
But the official directories have drifted toward Cathedral. Every submission requires approval from reviewers against extensive criteria before reaching users. The gate is open; you just need to satisfy the gatekeepers first.
Raymond’s insight was that the Bazaar works because it trusts freedom. Remove the trust, add the gatekeepers, and you’ve rebuilt the Cathedral using Bazaar rhetoric.
The Rest of the World Trusts the Commons
Most package ecosystems learned to resist the committee.
npm’s terms explicitly welcome “all manner of useful Packages… from hobby projects to competitive products, enterprise infrastructure and tooling to the latest fun hack or work of software art.” No pre-publication review. No aesthetic guidelines. Run npm publish and your package is live.
PyPI operates on automated upload with policies focused exclusively on “user safety, intellectual property, privacy, authenticity.” No mention of code style. No architectural requirements. No committee deciding whether your work matches their vision.
crates.io—Rust’s package registry—explicitly states they won’t police what counts as a “legitimate” package. First-come-first-served naming, removal only for legal violations or Code of Conduct breaches. Not design preferences. Not subjective quality.
Millions of packages across these ecosystems. No committees. Yes, there’s junk. The cream rises anyway. The ecosystems thrive.
These platforms made a bet: trust developers to ship, trust users to evaluate, intervene only for genuine harm. It’s the same bet the GPL made. They aligned their process with their philosophy.
WordPress says it believes in the GPL. The committee suggests otherwise.
Guardrails and Committees
Not all rules are committee creep. Some are essential.
Guardrails protect against genuine harm: malware, security holes, license violations, broken code. These enforce the commons—they keep it safe without restricting who can use it. Every healthy ecosystem needs guardrails. The GPL isn’t opposed to safety; it’s opposed to unnecessary restriction.
Committees enforce preferences: design opinions, aesthetic judgments, architectural philosophies. These restrict the commons. They substitute the committee’s taste for the community’s judgment. They add friction the GPL specifically avoided.
The test is simple: If something violated only this rule, would anyone be harmed?
Security failures cause harm. Malware causes harm. Broken code causes harm.
Design preferences? Those just differ from what the committee likes. That’s not harm. That’s variety—exactly what a commons should have.
Stallman put it directly: the four freedoms are the test. If a rule protects those freedoms, keep it. If a rule restricts them without preventing genuine harm, question why it exists.
Reopening the Commons
I’m not calling for abolition. The committee includes earnest volunteers doing difficult work. WordPress has thrived for twenty years under their stewardship. Nobody did anything wrong—this is just what happens to institutions over time. Rules accumulate. Committees grow. Process expands to fill available space.
But I am calling for pruning. Intentional, principled pruning.
Go through the rules. For each one, ask:
- Does this protect users from harm? Keep it.
- Does this enforce a preference? Question it.
- Does this align with the GPL’s trust in freedom? Keep it.
- Does this add friction the license avoided? Question it.
- Would Stallman recognize this as protecting freedom, or restricting it?
The GPL made a bet: trust the commons. Trust that openness beats gatekeeping. Trust that communities can judge quality without committees filtering everything first.
Twenty years later, we have a chance to ask whether we still believe that bet. If we do, the committee should shrink. The forms should thin. The commons should feel open again—not just in license, but in practice.
Conclusion
The commons is still there. The GPL still guarantees the freedoms it always guaranteed. WordPress still believes in open source.
But somewhere between the license and the directory, a committee grew. It grew with good intentions, one reasonable rule at a time, until the stack of forms became the thing people experience—not the commons behind it.
Nobody closed the commons. The committee just made it hard to use.
We can change that. Not by fighting, but by pruning. By asking which rules protect and which rules just prefer. By trusting the community the way the GPL trusts the community.
The four freedoms don’t include an asterisk. The license doesn’t have a “subject to committee approval” clause. The philosophy that built WordPress was radical, simple, and trusting.
Let’s be that again.
The commons is waiting.
