The Commons and the Committee 🔗 **Source:** [The Commons and the Committee](https://iconick.io/the-commons-and-the-committee/) > [!note]+ Document Notes > 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 > <!-- deep-read:sections start --> ## 🧭 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 safety guardrails while removing preference-based gatekeeping so that WordPress can again operate like an open commons aligned with the GPL’s four freedoms. ## 📰 Newsletter In this week’s WordPress ecosystem spotlight, we’re revisiting the foundations of our plugin and theme “commons.” A thoughtful new essay, “The Commons and the Committee,” challenges us to ask: have well-meaning rules and review processes drifted away from the GPL’s radical trust in developers and users? For builders, it’s a prompt to reflect on how much friction we tolerate before innovation suffers. For reviewers and leaders, it’s an invitation to differentiate between essential guardrails (security, licensing, basic safety) and subjective preferences that might be better left to users and market signals. If you’re designing workflows, contribution guidelines, or new DevRel programs, this is a great companion to: - Clarifying what truly needs review vs. what can ship and be judged in the wild. - Rethinking educational resources to empower developers to self-evaluate security and quality, instead of relying solely on committees. - Exploring lighter-weight plugin scaffolds and automated checks that catch genuine harm without blocking experimentation. As the WordPress community explores AI tooling, performance initiatives, and new governance models, returning to the spirit of the GPL—freedom with accountability—may be the most important update we ship. ## ✅ Action Items #### DevRel - Reframe DevRel content to explain GPL freedoms and the distinction between “guardrails vs. committee” in the context of WordPress plugins/themes. - Design workshops or office hours helping developers understand directory guidelines and how to navigate or challenge preference-based requirements. - Improve developer experience by automating safety checks (security, licensing) while simplifying or documenting the minimal human-review steps. - Run campaigns explaining how to safely experiment in the WordPress ecosystem without being blocked by unnecessary gatekeeping. - Survey developers about friction points in current review processes and feed anonymized insights back to reviewers and leadership. - Align DevRel, core teams, and review teams on a shared understanding of “harmful vs. merely different” code. #### OSPO - Clarify internal policies that distinguish license/safety requirements from aesthetic or architectural preferences for WordPress-related projects. - Ensure license compliance checks prioritize GPL compatibility and actual legal risk, not stylistic adherence. - Integrate security management practices that focus on real vulnerabilities rather than opinionated implementation patterns. - Maintain an accurate software inventory of WordPress extensions with metadata about review status, security posture, and licensing. - Offer consultation hours for teams distributing WordPress extensions to interpret GPL obligations vs. directory guidelines. - Consider upstream contributions or funding for efforts that streamline WordPress review processes in line with GPL freedoms. - Track KPIs around time-to-approval, rejection reasons, and contributor retention related to directory policies. #### Community - Host community discussions or panels on the tradeoffs between safety and openness in plugin/theme reviews. - Provide maintainers with governance templates that encode “guardrails, not preference” as a principle. - Offer contributor onboarding that sets clear expectations about review timelines, common pitfalls, and appeal processes. - Encourage sponsors to fund efforts that prune unnecessary rules, improve automation, or enhance documentation around the review pipeline. - Facilitate cross-project dialogues (e.g., with npm/PyPI/crates.io communities) on best practices for trust-based commons. #### WordPress - Core: Review how directory policies influence core adoption and extension innovation; streamline any coupling between core changes and directory rules. - Core Performance: Ensure performance recommendations in guidelines are advisory, not hard blockers, unless they clearly prevent user harm. - Core AI: Define responsible AI policies that protect users (e.g., data misuse) without over-constraining experimentation with AI-powered plugins. - **Core Program Team:** Coordinate with plugin/theme review teams on periodic policy reviews and pruning cycles; schedule retrospectives focused on contributor experience. - Mobile: Consider how mobile app experiences reflect extension ecosystem openness and ensure no hidden gatekeeping in mobile-specific integrations. - Playground: Use WordPress Playground as a safe sandbox to test “more open” publishing approaches and study user evaluation of quality. - Community: Update meetup/WordCamp content to include sessions on GPL freedoms, governance, and practical strategies for reducing unnecessary review friction. - Training: Develop learning paths on “shipping safely in the commons,” covering security basics and GPL compliance for plugin and theme authors. - Marketing: Align messaging about “democratizing publishing” with concrete examples of reduced friction in directories and contributor workflows. - Support: Track user support issues that might justify genuine safety rules vs. those that reflect personal taste, and feed that into guideline revisions. - Design: Encourage diversity of design in the ecosystem; position official design standards as patterns, not mandatory requirements, unless tied to accessibility or usability harm. - Documentation: Clarify which directory rules protect users from harm and which reflect preferences; document the rationale and revisit regularly. - Photos: For .org assets, define simple, safety-focused policies (licensing, inappropriate content) while avoiding over-specific style rules that stifle contributions. - TV: Publish talks and interviews on governance, open source freedom, and lessons from other ecosystems regarding gatekeeping vs. guardrails. - Polyglots: Ensure translation workflows and glossaries cover governance and GPL concepts so all locales can discuss these issues meaningfully. - Accessibility: Keep accessibility standards as non-negotiable guardrails (real harm prevention) and communicate them clearly as such. - Meta: Improve contributor-facing tools for tracking review status, reasons for rejections, and appeals to reduce the sense of opaque committee control. - CLI: Consider CLI helpers to validate common safety requirements locally before submission, reducing avoidable review friction. - Hosting: Collaborate with hosts on defaults that respect GPL freedoms while maintaining strong security baselines for users installing plugins/themes. - Tide: Focus Tide’s scoring and outreach on meaningful quality and security signals, not aesthetic conformity. - Openverse: Keep Openverse’s content policies safety and rights-focused, not taste-policing; document that clearly. - Themes: Reassess theme review queues and criteria; separate “must-have” safety/usability requirements from opinionated design rules. - Plugins: Similarly, split plugin requirements into “harm prevention” vs. “preferences,” making the latter advisory or optional where possible. #### The WPOCC - Programs: Support fellows who work on governance simplification, rule pruning, and contributor-experience improvements. - Projects: Sponsor documentation sprints to clarify which rules are essential guardrails and which are candidates for removal. - Funding experiments: Pilot grants focused on automating harmful-behavior detection (security, licensing) while reducing human gatekeeping on subjective matters. ### FAIR - Technical independence: Encourage local validation of GPL compliance and security (e.g., signed releases, provenance checks) without central committees dictating design. - Policies and covenants: Advocate for transparency in funding and governance for review bodies, with sunset clauses and regular rule audits to prevent ossification. - Productized governance artifacts: Create reusable charters and scorecards that encode “freedom-preserving, harm-focused” review principles. ## 🧪 Hypotheses - H1: Reducing preference-based review rules for WordPress plugins/themes will increase the number and diversity of submitted extensions without significantly increasing harmful outcomes. - H2: Automated guardrails targeting security, licensing, and basic functionality can substitute for many manual review steps while maintaining or improving user safety. - H3: Clear separation of “harm-prevention rules” from “style/preferences” will improve contributor satisfaction and retention in the WordPress ecosystem. - H4: Ecosystems with minimal pre-publication gatekeeping (npm, PyPI, crates.io) experience faster innovation cycles than heavily curated directories, controlling for ecosystem size. ### 📊 Methodology - Comparative study: Analyze submission, rejection, and incident data from WordPress directories before and after targeted rule pruning; compare with metrics from npm/PyPI/crates.io. - Surveys and interviews: Collect qualitative data from plugin/theme authors, reviewers, and users on perceived friction, trust, and safety. - A/B experimentation: Pilot a “lightweight review lane” where only guardrail rules apply, then compare incident rates and adoption to the standard lane. - Automated tooling evaluation: Implement and measure the effectiveness of static analysis, vulnerability scanners, and license checkers as partial replacements for manual review. ### ❓ Questions - Which existing WordPress directory rules clearly prevent user harm, and which primarily encode committee preferences? - How much user risk is acceptable in exchange for faster innovation and lower contributor friction? - What governance mechanisms ensure that new rules do not silently accumulate into de facto gatekeeping? - How can WordPress communicate the GPL’s freedoms in ways that are actionable for plugin and theme authors? ### 🔮 Future Research - Longitudinal studies on the relationship between governance strictness and ecosystem health in open source platforms. - Experiments with reputation systems, discovery algorithms, and user feedback as alternatives to centralized pre-publication approval. - Frameworks for periodically auditing and pruning rules in mature open source projects. - Analysis of how different governance models affect security outcomes in plugin/theme ecosystems. ### 💡 Implications - Practice: Maintainers may need to re-tool review pipelines to emphasize automated safety checks and post-hoc monitoring over pre-hoc preference policing. - Policy: Governance documents and charters should encode the principle that software freedoms are primary, and non-harm rules require strong justification. - Security: A sharper focus on concrete harm could improve security posture by redirecting attention from cosmetic issues to real vulnerabilities. - Education: Training materials can prioritize teaching developers how to self-assess for harm (e.g., security, licensing) rather than how to appease committee tastes. - Funding models: Resources might shift from manual review headcount toward tooling, documentation, and ecosystem health initiatives. ### 🧠 Learning Styles Assessment - Reading level estimate: Approximately upper high school to early college, based on Flesch-Kincaid–style assessment (complex sentences, domain-specific terminology like “GPL,” “bikeshedding,” “Cathedral and Bazaar”). #### 👀 Visual learners - Present: Conceptual metaphors (commons, cathedral vs. bazaar) that can be mentally visualized. - Improve: Add diagrams contrasting “guardrails vs. committee,” flows of plugin review, and ecosystem comparisons. #### 🔊 Aural learners - Present: None explicitly. - Improve: Provide an audio narration or podcast discussion of the essay. #### 🗣️ Verbal learners - Present: Strong analogies, clear definitions of GPL freedoms, and references to well-known open source essays. - Improve: Include a short glossary of terms and key quotes summarized in simpler language. #### 🧩 Kinesthetic learners - Present: Implicit prompts to examine one’s own governance processes. - Improve: Add step-by-step exercises (e.g., “audit your rules using the harm test”) and checklists. #### 🧠 Logical learners - Present: Clear distinctions (license vs. process, guardrails vs. committees) and if-then style reasoning. - Improve: Add tables summarizing rule types, decision trees for whether a rule should stay, and metrics examples. #### 🧑‍🤝‍🧑 Social learners - Present: Framing around community, contributors, and committees. - Improve: Provide discussion prompts or recommended formats for community governance workshops. #### 🧘‍♀️ Solitary learners - Present: Reflective framing about beliefs in freedom, trust, and governance. - Improve: Include explicit reflection questions at the end of each section. #### 🌿 Naturalistic learners - Present: The commons metaphor loosely invokes shared environmental resources. - Improve: Develop the metaphor further with ecosystem analogies (biodiversity, resilience) and sustainability of communities. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Article-style prose with headings. - Improve: Ensure semantic HTML headings, landmarks, and descriptive link text in the original publication. #### Keyboard navigation - Present: Standard article page likely navigable by keyboard. - Improve: Confirm focus order, provide skip links, and avoid any interactive elements that trap focus. #### Contrast and readability - Present: Depends on the site’s theme; likely modern and readable. - Improve: Verify contrast ratios, font sizes, and line spacing against WCAG 2.2 AA. #### Text resizing and reflow - Present: Responsive design likely present. - Improve: Test zoom up to 200% and ensure no clipping; optionally support reduced motion preferences. #### Media and captions - Present: Mostly text; minimal media. - Improve: If images or embeds are added, provide alt text, captions, and transcripts. #### Forms and interactions - Present: Minimal interactive components. - Improve: If comments or signups exist, ensure labeled fields, accessible error messages, and adequate target size. #### Standards reference - Map any gaps to WCAG 2.2 AA criteria, particularly for contrast (1.4.x), keyboard accessibility (2.1.x), and structure (1.3.x). ### 🌍 DEIB Assessment #### Cultural breadth - Present: Focused on open source culture, mainly Western-origin exemplars (FSF, FreeBSD, Rust, npm). - Improve: Include examples from non-Western FOSS communities and multilingual projects. #### Inclusive language - Present: Generally neutral and respectful, with minimal jargon. - Improve: Add short explanations for specialized terms (“GPL,” “bikeshedding”) and avoid assuming deep prior context. #### Neurodiversity support - Present: Clear structure and repeated distinctions aid comprehension. - Improve: More subheadings, bullet lists, and consistent patterns could support skimming and re-reading. #### Representation - Present: Abstract discussion of roles (traveler, committee, village); no explicit representation of diverse identities. - Improve: Use examples that highlight diverse contributors and user groups across regions and abilities. #### Psychological safety - Present: Critiques systems, not individuals; acknowledges good intentions. - Improve: Offer explicit norms for respectful disagreement and governance change processes. ### ✅ Logical Validity #### Strong reasoning - The core analogical argument (commons → GPL → WordPress directories) is consistent and grounded in shared principles of freedom and trust. - The guardrails vs. committees distinction is a clear causal framework: rules that prevent harm are necessary; those enforcing taste risk unjustified restriction. - Comparative examples (npm, PyPI, crates.io) provide inductive support that less gatekeeping doesn’t necessarily collapse ecosystems. #### Fallacies - Potential selection bias: focuses on successful open ecosystems without deeply engaging with their failure modes or high-profile incidents. Could be strengthened by acknowledging counterexamples and explaining why they don’t falsify the thesis. #### Tone of voice - Thoughtful, critical-but-constructive; acknowledges volunteers’ good intentions and history while firmly arguing for change. ### 🛡️ DARVO Analysis - Deny: The article does not deny harm; it explicitly recognizes safety needs and real risks (malware, security). - Attack: It avoids personal attacks; criticism is directed at structures and processes, not individuals. - Reverse victim/offender: No attempt to portray gatekeepers as victims of developers; instead, it frames everyone as caught in institutional drift. - Overall, the rhetoric is not DARVO-like; it’s more of a systemic critique urging collective course correction. ## 🎯 Conclusion The essay contends that WordPress’s plugin and theme processes have drifted from the GPL’s freedom-centric ethos into preference-based gatekeeping, much like a once-open commons overtaken by committees. The practical next step is a principled pruning of rules: keep those that prevent real harm, question those that merely encode taste, and realign governance and tooling so that the lived experience of the WordPress ecosystem matches its founding philosophy of trust in the commons. ## 🧱 Refactor Appendix (append after 🎯 Conclusion) ### 📚 Literature Split Pad - Purpose: Stage Konik CEE units that become per-source Literature notes. - Split level: **H3**. - Include verbatim quotes under 25 words and a [view highlight] link. ### [H1] 5–10-word present-tense claim > [!quote] [{Title or entity}]({ARTICLE_URL}) by [[{Author or [MISSING]}]] via [[{Site or [MISSING]}]]. Published {DATE_OR_[MISSING]}. Accessed . > “Short quote, verbatim, ≤25 words.” Two lines: context and use. Cite data if relevant. [view highlight]({ARTICLE_URL}#H1) #xref #articleseed ID:rw_[MISSING] ### [H2] 5–10-word present-tense claim > [!quote] [{Title or entity}]({ARTICLE_URL}) > “Short quote, verbatim, ≤25 words.” Two lines: context and use. [view highlight]({ARTICLE_URL}#H2) #xref ID:rw_[MISSING] --- ### 🔖 Atomic Split Pad (Zettel Candidates) - Purpose: Promote reusable claims into Atomic notes. - Split level: **H4**. - Each item: one idea, present tense, specific, testable. #### [Z1] 5–10-word present-tense claim - Scope/condition in one line. - Pointer to page/time or dataset. - Links: [[Parent-Concept]] [[Related-Idea]] #### [Z2] 5–10-word present-tense claim - Scope/condition in one line. - Pointer to page/time or dataset. - Links: [[Parent-Concept]] [[Related-Idea]] --- ### ✏️ Fleeting Queue (Extract by Selection) - Purpose: Capture quick actions or sparks for Fleeting notes. - Extraction: **Select one line** → “Refactor: Extract selection to new note (content only).” - Keep each line short and self-contained. - [F1] Short action — context/{ARTICLE_URL} #fleeting #inbox - [F2] Short action — context/{ARTICLE_URL} #fleeting #inbox - [F3] Short action — context/{ARTICLE_URL} #fleeting #inbox --- # 🏷️ 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 safety guardrails while removing preference-based gatekeeping so that WordPress can again operate like an open commons aligned with the GPL’s four freedoms. ## 📰 Newsletter In this week’s WordPress ecosystem spotlight, we’re revisiting the foundations of our plugin and theme “commons.” A thoughtful new essay, “The Commons and the Committee,” challenges us to ask: have well-meaning rules and review processes drifted away from the GPL’s radical trust in developers and users? For builders, it’s a prompt to reflect on how much friction we tolerate before innovation suffers. For reviewers and leaders, it’s an invitation to differentiate between essential guardrails (security, licensing, basic safety) and subjective preferences that might be better left to users and market signals. If you’re designing workflows, contribution guidelines, or new DevRel programs, this is a great companion to: - Clarifying what truly needs review vs. what can ship and be judged in the wild. - Rethinking educational resources to empower developers to self-evaluate security and quality, instead of relying solely on committees. - Exploring lighter-weight plugin scaffolds and automated checks that catch genuine harm without blocking experimentation. As the WordPress community explores AI tooling, performance initiatives, and new governance models, returning to the spirit of the GPL—freedom with accountability—may be the most important update we ship. ## ✅ Action Items #### DevRel - Reframe DevRel content to explain GPL freedoms and the distinction between “guardrails vs. committee” in the context of WordPress plugins/themes. - Design workshops or office hours helping developers understand directory guidelines and how to navigate or challenge preference-based requirements. - Improve developer experience by automating safety checks (security, licensing) while simplifying or documenting the minimal human-review steps. - Run campaigns explaining how to safely experiment in the WordPress ecosystem without being blocked by unnecessary gatekeeping. - Survey developers about friction points in current review processes and feed anonymized insights back to reviewers and leadership. - Align DevRel, core teams, and review teams on a shared understanding of “harmful vs. merely different” code. #### OSPO - Clarify internal policies that distinguish license/safety requirements from aesthetic or architectural preferences for WordPress-related projects. - Ensure license compliance checks prioritize GPL compatibility and actual legal risk, not stylistic adherence. - Integrate security management practices that focus on real vulnerabilities rather than opinionated implementation patterns. - Maintain an accurate software inventory of WordPress extensions with metadata about review status, security posture, and licensing. - Offer consultation hours for teams distributing WordPress extensions to interpret GPL obligations vs. directory guidelines. - Consider upstream contributions or funding for efforts that streamline WordPress review processes in line with GPL freedoms. - Track KPIs around time-to-approval, rejection reasons, and contributor retention related to directory policies. #### Community - Host community discussions or panels on the tradeoffs between safety and openness in plugin/theme reviews. - Provide maintainers with governance templates that encode “guardrails, not preference” as a principle. - Offer contributor onboarding that sets clear expectations about review timelines, common pitfalls, and appeal processes. - Encourage sponsors to fund efforts that prune unnecessary rules, improve automation, or enhance documentation around the review pipeline. - Facilitate cross-project dialogues (e.g., with npm/PyPI/crates.io communities) on best practices for trust-based commons. #### WordPress - Core: Review how directory policies influence core adoption and extension innovation; streamline any coupling between core changes and directory rules. - Core Performance: Ensure performance recommendations in guidelines are advisory, not hard blockers, unless they clearly prevent user harm. - Core AI: Define responsible AI policies that protect users (e.g., data misuse) without over-constraining experimentation with AI-powered plugins. - **Core Program Team:** Coordinate with plugin/theme review teams on periodic policy reviews and pruning cycles; schedule retrospectives focused on contributor experience. - Mobile: Consider how mobile app experiences reflect extension ecosystem openness and ensure no hidden gatekeeping in mobile-specific integrations. - Playground: Use WordPress Playground as a safe sandbox to test “more open” publishing approaches and study user evaluation of quality. - Community: Update meetup/WordCamp content to include sessions on GPL freedoms, governance, and practical strategies for reducing unnecessary review friction. - Training: Develop learning paths on “shipping safely in the commons,” covering security basics and GPL compliance for plugin and theme authors. - Marketing: Align messaging about “democratizing publishing” with concrete examples of reduced friction in directories and contributor workflows. - Support: Track user support issues that might justify genuine safety rules vs. those that reflect personal taste, and feed that into guideline revisions. - Design: Encourage diversity of design in the ecosystem; position official design standards as patterns, not mandatory requirements, unless tied to accessibility or usability harm. - Documentation: Clarify which directory rules protect users from harm and which reflect preferences; document the rationale and revisit regularly. - Photos: For .org assets, define simple, safety-focused policies (licensing, inappropriate content) while avoiding over-specific style rules that stifle contributions. - TV: Publish talks and interviews on governance, open source freedom, and lessons from other ecosystems regarding gatekeeping vs. guardrails. - Polyglots: Ensure translation workflows and glossaries cover governance and GPL concepts so all locales can discuss these issues meaningfully. - Accessibility: Keep accessibility standards as non-negotiable guardrails (real harm prevention) and communicate them clearly as such. - Meta: Improve contributor-facing tools for tracking review status, reasons for rejections, and appeals to reduce the sense of opaque committee control. - CLI: Consider CLI helpers to validate common safety requirements locally before submission, reducing avoidable review friction. - Hosting: Collaborate with hosts on defaults that respect GPL freedoms while maintaining strong security baselines for users installing plugins/themes. - Tide: Focus Tide’s scoring and outreach on meaningful quality and security signals, not aesthetic conformity. - Openverse: Keep Openverse’s content policies safety and rights-focused, not taste-policing; document that clearly. - Themes: Reassess theme review queues and criteria; separate “must-have” safety/usability requirements from opinionated design rules. - Plugins: Similarly, split plugin requirements into “harm prevention” vs. “preferences,” making the latter advisory or optional where possible. #### The WPOCC - Programs: Support fellows who work on governance simplification, rule pruning, and contributor-experience improvements. - Projects: Sponsor documentation sprints to clarify which rules are essential guardrails and which are candidates for removal. - Funding experiments: Pilot grants focused on automating harmful-behavior detection (security, licensing) while reducing human gatekeeping on subjective matters. ### FAIR - Technical independence: Encourage local validation of GPL compliance and security (e.g., signed releases, provenance checks) without central committees dictating design. - Policies and covenants: Advocate for transparency in funding and governance for review bodies, with sunset clauses and regular rule audits to prevent ossification. - Productized governance artifacts: Create reusable charters and scorecards that encode “freedom-preserving, harm-focused” review principles. ## 🧪 Hypotheses - H1: Reducing preference-based review rules for WordPress plugins/themes will increase the number and diversity of submitted extensions without significantly increasing harmful outcomes. - H2: Automated guardrails targeting security, licensing, and basic functionality can substitute for many manual review steps while maintaining or improving user safety. - H3: Clear separation of “harm-prevention rules” from “style/preferences” will improve contributor satisfaction and retention in the WordPress ecosystem. - H4: Ecosystems with minimal pre-publication gatekeeping (npm, PyPI, crates.io) experience faster innovation cycles than heavily curated directories, controlling for ecosystem size. ### 📊 Methodology - Comparative study: Analyze submission, rejection, and incident data from WordPress directories before and after targeted rule pruning; compare with metrics from npm/PyPI/crates.io. - Surveys and interviews: Collect qualitative data from plugin/theme authors, reviewers, and users on perceived friction, trust, and safety. - A/B experimentation: Pilot a “lightweight review lane” where only guardrail rules apply, then compare incident rates and adoption to the standard lane. - Automated tooling evaluation: Implement and measure the effectiveness of static analysis, vulnerability scanners, and license checkers as partial replacements for manual review. ### ❓ Questions - Which existing WordPress directory rules clearly prevent user harm, and which primarily encode committee preferences? - How much user risk is acceptable in exchange for faster innovation and lower contributor friction? - What governance mechanisms ensure that new rules do not silently accumulate into de facto gatekeeping? - How can WordPress communicate the GPL’s freedoms in ways that are actionable for plugin and theme authors? ### 🔮 Future Research - Longitudinal studies on the relationship between governance strictness and ecosystem health in open source platforms. - Experiments with reputation systems, discovery algorithms, and user feedback as alternatives to centralized pre-publication approval. - Frameworks for periodically auditing and pruning rules in mature open source projects. - Analysis of how different governance models affect security outcomes in plugin/theme ecosystems. ### 💡 Implications - Practice: Maintainers may need to re-tool review pipelines to emphasize automated safety checks and post-hoc monitoring over pre-hoc preference policing. - Policy: Governance documents and charters should encode the principle that software freedoms are primary, and non-harm rules require strong justification. - Security: A sharper focus on concrete harm could improve security posture by redirecting attention from cosmetic issues to real vulnerabilities. - Education: Training materials can prioritize teaching developers how to self-assess for harm (e.g., security, licensing) rather than how to appease committee tastes. - Funding models: Resources might shift from manual review headcount toward tooling, documentation, and ecosystem health initiatives. ### 🧠 Learning Styles Assessment - Reading level estimate: Approximately upper high school to early college, based on Flesch-Kincaid–style assessment (complex sentences, domain-specific terminology like “GPL,” “bikeshedding,” “Cathedral and Bazaar”). #### 👀 Visual learners - Present: Conceptual metaphors (commons, cathedral vs. bazaar) that can be mentally visualized. - Improve: Add diagrams contrasting “guardrails vs. committee,” flows of plugin review, and ecosystem comparisons. #### 🔊 Aural learners - Present: None explicitly. - Improve: Provide an audio narration or podcast discussion of the essay. #### 🗣️ Verbal learners - Present: Strong analogies, clear definitions of GPL freedoms, and references to well-known open source essays. - Improve: Include a short glossary of terms and key quotes summarized in simpler language. #### 🧩 Kinesthetic learners - Present: Implicit prompts to examine one’s own governance processes. - Improve: Add step-by-step exercises (e.g., “audit your rules using the harm test”) and checklists. #### 🧠 Logical learners - Present: Clear distinctions (license vs. process, guardrails vs. committees) and if-then style reasoning. - Improve: Add tables summarizing rule types, decision trees for whether a rule should stay, and metrics examples. #### 🧑‍🤝‍🧑 Social learners - Present: Framing around community, contributors, and committees. - Improve: Provide discussion prompts or recommended formats for community governance workshops. #### 🧘‍♀️ Solitary learners - Present: Reflective framing about beliefs in freedom, trust, and governance. - Improve: Include explicit reflection questions at the end of each section. #### 🌿 Naturalistic learners - Present: The commons metaphor loosely invokes shared environmental resources. - Improve: Develop the metaphor further with ecosystem analogies (biodiversity, resilience) and sustainability of communities. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Article-style prose with headings. - Improve: Ensure semantic HTML headings, landmarks, and descriptive link text in the original publication. #### Keyboard navigation - Present: Standard article page likely navigable by keyboard. - Improve: Confirm focus order, provide skip links, and avoid any interactive elements that trap focus. #### Contrast and readability - Present: Depends on the site’s theme; likely modern and readable. - Improve: Verify contrast ratios, font sizes, and line spacing against WCAG 2.2 AA. #### Text resizing and reflow - Present: Responsive design likely present. - Improve: Test zoom up to 200% and ensure no clipping; optionally support reduced motion preferences. #### Media and captions - Present: Mostly text; minimal media. - Improve: If images or embeds are added, provide alt text, captions, and transcripts. #### Forms and interactions - Present: Minimal interactive components. - Improve: If comments or signups exist, ensure labeled fields, accessible error messages, and adequate target size. #### Standards reference - Map any gaps to WCAG 2.2 AA criteria, particularly for contrast (1.4.x), keyboard accessibility (2.1.x), and structure (1.3.x). ### 🌍 DEIB Assessment #### Cultural breadth - Present: Focused on open source culture, mainly Western-origin exemplars (FSF, FreeBSD, Rust, npm). - Improve: Include examples from non-Western FOSS communities and multilingual projects. #### Inclusive language - Present: Generally neutral and respectful, with minimal jargon. - Improve: Add short explanations for specialized terms (“GPL,” “bikeshedding”) and avoid assuming deep prior context. #### Neurodiversity support - Present: Clear structure and repeated distinctions aid comprehension. - Improve: More subheadings, bullet lists, and consistent patterns could support skimming and re-reading. #### Representation - Present: Abstract discussion of roles (traveler, committee, village); no explicit representation of diverse identities. - Improve: Use examples that highlight diverse contributors and user groups across regions and abilities. #### Psychological safety - Present: Critiques systems, not individuals; acknowledges good intentions. - Improve: Offer explicit norms for respectful disagreement and governance change processes. ### ✅ Logical Validity #### Strong reasoning - The core analogical argument (commons → GPL → WordPress directories) is consistent and grounded in shared principles of freedom and trust. - The guardrails vs. committees distinction is a clear causal framework: rules that prevent harm are necessary; those enforcing taste risk unjustified restriction. - Comparative examples (npm, PyPI, crates.io) provide inductive support that less gatekeeping doesn’t necessarily collapse ecosystems. #### Fallacies - Potential selection bias: focuses on successful open ecosystems without deeply engaging with their failure modes or high-profile incidents. Could be strengthened by acknowledging counterexamples and explaining why they don’t falsify the thesis. #### Tone of voice - Thoughtful, critical-but-constructive; acknowledges volunteers’ good intentions and history while firmly arguing for change. ### 🛡️ DARVO Analysis - Deny: The article does not deny harm; it explicitly recognizes safety needs and real risks (malware, security). - Attack: It avoids personal attacks; criticism is directed at structures and processes, not individuals. - Reverse victim/offender: No attempt to portray gatekeepers as victims of developers; instead, it frames everyone as caught in institutional drift. - Overall, the rhetoric is not DARVO-like; it’s more of a systemic critique urging collective course correction. ## 🎯 Conclusion The essay contends that WordPress’s plugin and theme processes have drifted from the GPL’s freedom-centric ethos into preference-based gatekeeping, much like a once-open commons overtaken by committees. The practical next step is a principled pruning of rules: keep those that prevent real harm, question those that merely encode taste, and realign governance and tooling so that the lived experience of the WordPress ecosystem matches its founding philosophy of trust in the commons. ## 🧱 Refactor Appendix (append after 🎯 Conclusion) ### 📚 Literature Split Pad - Purpose: Stage Konik CEE units that become per-source Literature notes. - Split level: **H3**. - Include verbatim quotes under 25 words and a [view highlight] link. ### [H1] 5–10-word present-tense claim > [!quote] [{Title or entity}]({ARTICLE_URL}) by [[{Author or [MISSING]}]] via [[{Site or [MISSING]}]]. Published {DATE_OR_[MISSING]}. Accessed {{date:YYYY-MM-DD}}. > “Short quote, verbatim, ≤25 words.” Two lines: context and use. Cite data if relevant. [view highlight]({ARTICLE_URL}#H1) #xref #articleseed ID:rw_[MISSING] ### [H2] 5–10-word present-tense claim > [!quote] [{Title or entity}]({ARTICLE_URL}) > “Short quote, verbatim, ≤25 words.” Two lines: context and use. [view highlight]({ARTICLE_URL}#H2) #xref ID:rw_[MISSING] --- ### 🔖 Atomic Split Pad (Zettel Candidates) - Purpose: Promote reusable claims into Atomic notes. - Split level: **H4**. - Each item: one idea, present tense, specific, testable. #### [Z1] 5–10-word present-tense claim - Scope/condition in one line. - Pointer to page/time or dataset. - Links: [[Parent-Concept]] [[Related-Idea]] #### [Z2] 5–10-word present-tense claim - Scope/condition in one line. - Pointer to page/time or dataset. - Links: [[Parent-Concept]] [[Related-Idea]] --- ### ✏️ Fleeting Queue (Extract by Selection) - Purpose: Capture quick actions or sparks for Fleeting notes. - Extraction: **Select one line** → “Refactor: Extract selection to new note (content only).” - Keep each line short and self-contained. - [F1] Short action — context/{ARTICLE_URL} #fleeting #inbox - [F2] Short action — context/{ARTICLE_URL} #fleeting #inbox - [F3] Short action — context/{ARTICLE_URL} #fleeting #inbox --- <!-- deep-read:sections end -->