The Commons and the Committee  ## Metadata - Author: [[iconick]] - Full Title: The Commons and the Committee - Category: #articles - Document Note: --- tags: [open-source, wordpress, governance] author: iconick source: iconick.io reference: [https://iconick.io/the-commons-and-the-committee/] date created: 2025-11-28 00:00 --- # 🏷️ Title: The Commons and the Committee ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - Include links cited in or relevant to the article. ## 📝 Summary - A metaphorical village commons represents the original freedom-focused vision of free software and WordPress’s GPL-licensed ecosystem. - Over time, well-intentioned rules and committees have added friction between creators and users, drifting from that vision. - Stakeholders: WordPress core team, plugin/theme reviewers, developers, site owners, and end users. - Risks: stifled innovation, contributor burnout, and misalignment with GPL freedoms; tradeoff vs. safety and quality. - Bottom line: prune preference-enforcing rules, keep genuine safety guardrails, and re-align practice with the GPL’s trust in the commons. ## 📖 Main Content - The article opens with a fable: a thriving village commons slowly burdened by rules and committees until it becomes effectively inaccessible to newcomers. - It maps this onto software freedom, grounding itself in the Free Software Foundation’s four freedoms and Richard Stallman’s intent behind the GPL: minimal restriction and maximal trust in users and communities to assess quality. - WordPress adopted the GPL, but its plugin and theme review processes have grown heavy: long guideline documents, strict aesthetic and architectural preferences, and an approval-based directory model that can reject fully GPL-compliant code simply for not matching committee taste. - The author contrasts “guardrails” (rules preventing real harm: malware, security failures, license violations, broken code) with “committees” (rules enforcing subjective preferences: design, style, architecture). - Using Poul-Henning Kamp’s “bikeshedding” concept, the article argues that process tends to accumulate around trivial, opinionated issues, discouraging contributors while leaving essential work under-served. - Eric Raymond’s “Cathedral vs. Bazaar” metaphor is applied: WordPress speaks the language of the Bazaar but operates key infrastructure (plugin/theme directories) like a Cathedral with strong gatekeeping. - Other ecosystems (npm, PyPI, crates.io) are shown as examples of trust-based models: no pre-publication design review, focus on legal and safety concerns, and reliance on community evaluation to surface quality amid inevitable “junk”. - The article proposes intentional pruning of rules: keep those that prevent harm and uphold the GPL’s freedoms, and question those that simply encode committee preferences and add friction without improving safety. - It closes by emphasizing that the commons still exists in principle; the task is to reduce bureaucratic obstacles and restore lived alignment with the radical, simple, trusting philosophy of free software. ### 🗒️ Notes - Opening parable of a village commons illustrates “permissionless innovation”: anyone can build, and others can learn from and extend what’s built. The only rule is that creations remain learnable and extensible. - Over time, accidents, ugliness, and distaste lead to inspectors, review committees, and aesthetic gatekeeping; each new rule has a story, but only rules remain, leaving the commons empty. - The Free Software Foundation’s four freedoms define software freedom: run, study/change, redistribute, and redistribute modified versions. The GPL encodes trust and deliberately avoids putting friction between sharers and users. - Stallman explicitly warns that additional restrictions on distribution and modification undermine free software, even when motivated by seemingly good reasons. - WordPress, licensed under the GPL, originally shared this open commons philosophy. - The article points out a “gap between license and process”: GPL-compliant plugins and themes can be rejected from official directories for subjective reasons—design opinions, architectural judgments, or misaligned aesthetics. - This introduces a two-step gate: the license says “you’re free to share this,” while the committee says “after we review it.” - The concept of “bikeshedding” from Poul-Henning Kamp describes how communities fixate on trivial, accessible issues (like bike-shed color) while serious, complex work passes with little scrutiny—leading to contributor fatigue and deterrence. - The FreeBSD community’s response was to codify a principle of restraint: you don’t block someone’s bike shed over color preferences. WordPress, the article argues, lacks an equivalent norm, allowing rules to keep accumulating. - Eric Raymond’s “Cathedral vs. Bazaar” is invoked: the Bazaar model trusts volunteer-driven, open contribution; the Cathedral model centralizes authority and releases artifacts only after internal approval. - WordPress markets itself in Bazaar terms (community, democratization) but runs official directories in Cathedral fashion: every submission must pass extensive review, effectively making gatekeepers central. - Ecosystems like npm, PyPI, and crates.io are used as counterexamples; they emphasize openness, automatic publication, and only minimal constraints around safety, legality, and conduct—not code style or subjective quality. - These ecosystems accept that there will be low-quality or “junk” packages but rely on community usage, discovery systems, and norms to elevate high-value software. - The author distinguishes “guardrails” (rules that prevent clear harm—malware, security holes, license violations, broken packages) from “committee preferences” (rules about aesthetics, design patterns, or architecture). - A practical test is proposed: if only this rule were violated, would anyone be harmed? If not, the rule likely enforces preference, not protection. - The article emphasizes that committees often emerge and grow without malice: each rule once had a reasonable justification, but institutional accretion slowly turns freedom-focused ecosystems into bureaucratic ones. - The recommended path forward is not abolition of review but “intentional, principled pruning” of rules, guided by alignment with the GPL’s four freedoms and a focus on real harm. - The conclusion reframes the challenge as rediscovering and living up to the original radical trust at the heart of free software and WordPress: no hidden asterisks in the freedoms, no “subject to committee approval” clause. ## 📚 References - Free Software Foundation – “What is Free Software?” (four freedoms) - GNU General Public License (GPL) - Richard Stallman’s writings on software freedom and copyleft - Poul-Henning Kamp’s “bike shed” (color of the bikeshed) email to the FreeBSD community - Eric S. Raymond – “The Cathedral and the Bazaar” - npm Terms of Use and documentation - Python Package Index (PyPI) policies - crates.io (Rust) policies and guidelines - WordPress.org plugin and theme review guidelines ## 🗣️ Paraphrase - The article argues that WordPress’s plugin and theme ecosystems have drifted from the GPL’s trust-based, freedom-first philosophy toward a committee-driven model that conditions distribution on subjective preferences. This evolution mirrors a fable about a once-open commons slowly choked by rules that were each individually reasonable but collectively stifling. - By contrasting WordPress with other package ecosystems and foundational free software texts, the author calls for a careful pruning of non-essential rules. The goal is to keep necessary - Summary: 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: wh - URL: https://iconick.io/the-commons-and-the-committee/ 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., The Commons and the Committee, iconick, 01kb5e18nj1702menzrmbky04w.