The Principles of Governing Open Source Commons  ## Metadata - Author: [[Greg Bloom]] - Full Title: The Principles of Governing Open Source Commons - Category: #articles - Document Note: 📝 **(tags)** - #open_source_governance - #commons_design - #Ostrom_Principles Author: Greg Bloom Source: SustainOSS / PubPub Reference: Release #1 – "The Principles of Governing Open Source Commons" (published June 11, 2020) date created: 2025-08-08 15:00 # Title: The Principles of Governing Open Source Commons ## Table of Contents: - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#-notes) - [🗣️ 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 & DARVO Analysis](#-logical-validity--darvo-analysis) - [💻 SEO Evaluation](#-seo-evaluation) - [🎯 Conclusion](#-conclusion) --- ## ​ Summary: Greg Bloom’s “The Principles of Governing Open Source Commons” is a living document translating Elinor Ostrom’s institutional governance principles—via Silke Helfrich’s accessible language—into a framework for sustainable open source community governance. It offers clear guidance for community decision-making, evolution, conflict resolution, and resource stewardship. :contentReference[oaicite:0]{index=0} ## ​ Main Content: The document adapts Ostrom’s design principles into practical governance language: - Principle 1: **Clearly Defined Boundaries** – articulate project purpose, scope, and values to clarify responsibilities. - Principle 2: **Appropriate Rules** – ensure balanced expectations between contributions and benefits. - Further principles (not fully listed here) likely cover conflict resolution, monitoring, graduated sanctions, etc. :contentReference[oaicite:1]{index=1} ### ​​ Notes - **Translation of institutional principles** from Ostrom, through Helfrich, then adapted by SustainOSS for open source. - Offers usable language for community governance. :contentReference[oaicite:2]{index=2} - **Use cases**: ideal for drafting governance docs, guiding community evolution, conflict mediation, and informing funders and policy. :contentReference[oaicite:3]{index=3} - **“Living document”**: open to feedback, evolution, fostering collaborative refinement. :contentReference[oaicite:4]{index=4} - **Ostrom’s insight on “tragedy of the commons”** adapted to free-rider issues in digital infrastructure. :contentReference[oaicite:5]{index=5} ## ​​ Paraphrase: **Original excerpt:** “As Nadia Eghbal wrote … ‘digital infrastructure has a free rider problem. ...’” :contentReference[oaicite:6]{index=6} **Paraphrase:** Nadia Eghbal highlights that digital infrastructure suffers from the free-rider dilemma—anyone can benefit freely, so there's little motivation to contribute, risking collapse if contributors default. **Original excerpt:** “This is a living document. We’re eager to continue receiving feedback...” :contentReference[oaicite:7]{index=7} **Paraphrase:** The document is iterative—crafted to grow through community feedback and engagement, not as a final framework but as an evolving guide that improves with participation. ## ​ Newsletter: Here’s the WordPress-friendly blurb for your upcoming newsletter: > **Hey WordPress champions!** > This issue dives into crafting *sustainable and inclusive open source communities* using a powerful, evergreen tool—SustainOSS’s **Principles of Governing Open Source Commons**. Adapted from Ostrom’s timeless institutional design rules, these principles help clarify boundaries, balance contributor benefits, handle conflicts, and scale governance with purpose. > Whether you’re crafting governance docs, mentoring newbies, or building inclusive contributor pathways, these living guidelines have your back. > **Want to go deeper?** Check out the full draft and join the discussion on PubPub: it’s a living resource you can shape with us. Let’s keep building better, together! ## ​ Action Items: This prompt supports your developer advocacy focus, including your OSPO ambitions: - Outline how each principle supports **open source advocacy**, **contributor engagement**, and **education**. - Show how **clearly defined boundaries** and **appropriate rules** empower newcomers and improve transparency. - Demonstrate how building governance literacy supports your **OSPO director** goals and strengthens community inclusivity and sustainability. - Encourage integration into workshops, training, or OSPO frameworks. ## ​ Hypotheses: - Applying Ostrom-based governance improves contributor retention. - Transparent rules correlate with faster conflict resolution. - Governance literacy increases newcomer onboarding rates. ### ​ Methodology: - **Data sources:** Contributor activity logs, surveys, onboarding metrics. - **Design:** Comparative study between projects using principles vs. controls. - **Analysis:** Statistical comparison, thematic analysis of surveys, longitudinal tracking. ### ​ Questions: - Do clear governance docs improve newcomer trust? - How do communities adapt the principles over time? - Which principle yields the strongest impact? ### ​ Future Research: - Test principle efficacy across diverse project types (themes, plugins, core). - Explore adaptation for global/local WordPress communities. - Investigate links with funding sustainability and contributor diversity. ### ​ Implications: - Could inform WordPress Foundation OSPO models. - Strengthen educational training materials. - Guide funders on effective governance investments. ### ​ Learning Styles Assessment: | Style | Present? | Improvements | |-------|----------|--------------| | Visual | No diagrams | Add governance flowcharts, matrix visuals | | Aural | No audio | Offer audio summaries or podcasts | | Verbal | Yes, rich description | Could add more storytelling or analogies | | Physical | No hands-on tasks | Include exercises: draft your governance document | | Logical | Yes, structured principles | Add checklists or decision trees | | Social | Limited | Encourage group workshops or peer reviews | | Solitary | Minimal reflection prompts | Add journaling prompts or personal notes | | Naturalistic | None | Use analogies from ecological commons | ### ​ Accessibility Assessment: - **Screen readers**: Unknown—recommend semantic HTML and alt-text. - **Keyboard navigation**: Likely limited on PubPub—suggest accessible nav. - **Contrast/readability**: Encourage high-contrast visuals and resizable text. - **Text resizing**: Layout should be flexible—recommend responsive design checks. ### ​ DEIB Assessment: - **Cultural relevance**: Generic—add diverse case studies (e.g. regionally varied). - **Inclusive language**: Generally neutral—ensure jargon is explained. - **Neurodiversity support**: Long blocks—break into bullet points and subheadings. - **Representation**: Expand with examples from varied backgrounds and geographies. - **Psychological safety**: Encourage inclusive feedback and sensitivity tone. ### ​ Logical validity & DARVO Analysis: - **Strengths**: - **Deductive grounding** (Ostrom → Commons → Open Source) ensures coherent foundation. - **Analogical reasoning** applies natural governance to digital commons effectively. - **Balanced viewpoint** acknowledges limitations and invites feedback. - **Areas to watch**: - Missing details on how principles scale in practice—add case evidence. - **No DARVO detected**—content empowers communities, doesn’t deny or shift blame. ### ​ SEO Evaluation: - **Keywords**: Good (open source governance, commons principles), but could add long-tail like “governance for WordPress projects.” - **Meta description**: Not visible—add concise 150-160 character summary. - **Title tag**: Clear, but could include “Open Source Governance.” - **Headers**: Present (H1, H2) but could integrate keywords. - **Content length**: Mod - Summary: A living document about the design of sustainable open source communities - URL: https://sustainoss.pubpub.org/pub/jqngsp5u/release/1 A living document about the design of sustainable open source communities ### Preamble: About these Principles Each open source software project is unique, but many face common challenges. For open source communities to be both successful and sustainable, they need to make decisions about how they will work together. As Nadia Eghbal wrote in *[Roads and Bridges](https://www.fordfoundation.org/about/library/reports-and-studies/roads-and-bridges-the-unseen-labor-behind-our-digital-infrastructure/)*, a report on challenges in open source infrastructure maintenance: “Fundamentally, digital infrastructure has a free rider problem. Resources are offered for free, and everybody (whether individual developer or large software company) uses them, so nobody is incentivized to contribute back, figuring that somebody else will step in. Left unchecked, this will lead to a tragedy of the commons.” Fortunately, there is a vast body of knowledge about the various ways in which communities have learned to effectively steward resources while avoiding the tragedy of the commons. This knowledge was most prominently synthesized [by Elinor Ostrom](https://www.youtube.com/watch?v=Qr5Q3VvpI7w) in her seminal work, [Governing the Commons, which offers a set of principles for “institutional analysis and design.”](https://en.wikipedia.org/wiki/Elinor_Ostrom#Design_principles_for_Common_Pool_Resource_(CPR)_institution) *Governing the Commons* is a scientific and highly technical text about the governance of natural resource systems (like watersheds, woodsheds, fisheries, etc). Recent scholarship, such as *[Governing Knowledge Commons](http://knowledge-commons.net/gkc/)*, has applied this analytical framework to digital resources like data and code. Meanwhile, commons scholar Silke Helfrich has helped [translate Ostrom's ‘design principles’ into a de-jargonized, accessible form](https://commons.blog/2012/08/18/how-commons-can-flourish/). In the [SustainOSS](https://sustainoss.pubpub.org/pub/jqngsp5u/release/sustainoss.org) network, through [a series of workshops](https://sustainoss.org/events/) and other dialogues, we drafted this translation of Helfrich’s translation of Ostrom’s principles — in hopes that this language may help these principles more clearly apply to open source communities. We hope **these Principles for Governing Open Source Commons** can help open source software communities (as well as communities that produce other digital commons) to cope with the dilemmas that come with growth and other changes over time. These guidelines might be useful in the process of drafting community guidelines, facilitating the evolution of existing projects from one phase to another, informing the work of conflict resolution within communities — and even in guiding the decisions of funders, policymakers, and corporations whose resources and regulatory structures might support (or constrain) all of the above. NOTE: this document weaves three sets of statements together: * Elinor Ostrom’s original principles of institutional design (in plain text) * Our draft of principles specific to open source community development (**in bold**) ***This is a living document.*** We're eager to continue receiving feedback that can clarify these principles and elaborate on their potential usefulness. Please share your perspective! ### The Principles of Open Source Community Governance #### 1. Clearly Defined Boundaries: Individuals who have rights to appropriate resources must be clearly defined, as must the boundaries of the resource itself. *As a commoner I clearly understand for which resources I need to care for and with whom I share this responsibility. Commons resources are those that we create together, that we maintain as gifts whose use has been guaranteed to everyone.* **We clearly articulate the purpose of our project (i.e. our vision, mission, and scope) as well as our values and principles (i.e. the good we manifest in the world, and the way we do our work). We are guided by our purpose and principles in all that we do.** #### 2. Appropriate Rules Rules are appropriately related to local conditions (including both regarding the appropriation of common resources — restricting time, place, technology, quantity, etc; and rules related to provision of resources — requiring labor, materials, money, etc.) *As a commoner I am satisfied that there is a fair relationship between my contributions and the benefits I receive.* **We make agreements that establish fair relationships among contributors, users, our products, and the project itself. We assign licenses that align with our purpose and values. We set clear expectations for contributors regarding the nature of their contributions.** #### 3. Rule-making processes **Collective-choice arrangements allow most resource appropriators to participate in the decision-making process.** *We enter into or modify our own rules and commitments, and every commoner can participate in this process. Our commitments serve to create, maintain, and preserve the commons to satisfy our needs.* **We make it clear who can participate in what kind of decision-making, under which circumstances. Our decision-making processes are transparent, and account for the diverse perspectives of our community.** #### 4. Monitoring Effective monitoring by monitors who are part of or accountable to the appropriators. *We monitor the respect of these commitments ourselves and sometimes we mandate others whom we trust to help reach this goal. We continually reassess whether our commitments still serve their purpose.* **We monitor our adherence to our principles, values, and purpose. We engage in regular testing — of code as well as our assumptions. We share information about the status of our work with the community, and we are committed to improvement when we find it to be needed.** #### Sanctions There is a scale of graduated sanctions for resource appropriators who violate community rules. *We work out appropriate rules for dealing with violations of our commitments. We determine whether and what kinds of sanctions shall be used, depending on the context and severity of a violation.* **When people act in ways that are out of line with our project’s stated principles and purpose, we use a range of methods to encourage re-alignment — from gentle admonishment up to removal from the community of those who can’t or won’t abide by our stated expectations.** #### Conflict resolution Mechanisms of conflict resolution are cheap and of easy access. *Every commoner can make use of a space and means for conflict resolution. We seek to resolve conflicts among us in an easily accessible and straightforward way.* **We are committed to fair resolution of disagreements when they arise. The ability to resolve disagreements is distributed and accessible, so that** ***all*** **participants feel like they can participate in the process of resolving conflicts that they are a part of.** #### Self-governance The rights of a community to devise and govern its own institutions is recognized by external authorities. *We regulate our own affairs, and external authorities respect that.* **Our projects have autonomy to organize ourselves. We make decisions about how we structure our work and our communities as it is appropriate to our projects’ principles, values, and purpose.** #### Nestedness/Subsidiarity/Polycentricity Appropriation, provision, monitoring, enforcement, conflict resolution, and governance activities are organized in multiple layers of nested enterprises. *We realize that every commons is part of a larger whole. Therefore, different institutions working at different scales are needed to coordinate stewardship and to cooperate with each other.* **We embrace the complexity of our projects, which involve multiple parties and various scales, and so we engage in decision-making at various scales with various parties. Modules exist within broader projects, which might exist within organizations, which might use one or more platforms, which themselves exist within technological ecosystems, such as the broader free/libre open source software community, and so on. Our governance systems coordinate and cooperate across these levels, and we assume that whenever feasible and appropriate, decisions should be made by people who are ‘closest’ to the matter at hand.** # ### Questions to Ask Frequently (QAF) in Open Source Communities For the next iteration of this document, we aim to apply these principles in the form of questions that community leaders and participants might ask about how decisions are made in their community. *(This is inspired by both [Fabriders’ QAF](https://www.fabriders.net/qafs-research-resources/) and the [Governing Knowledge Commons’ research framework](http://knowledge-commons.net/research-framework/).)* * What is the purpose of this community? What principles guide our community? What are our values? What are our assumptions? * What is the history of how this community came to be? * Who should be welcome in this community? What should be the criteria for membership in this community? What are they key roles in this community? * What are the resources we are stewarding? Why are these resources valuable, and under what circumstances? How are these resources produced and maintained? What skills and tools do we need to create, maintain, and use these resources? What challenges do our members face in producing and/or using the resources? How will we educate members of our community about the nature of these resources — their challenges and benefits? * In what ways are the resources fragile or vulnerable? * What potential harms can we anticipate from mis-use of these resources? How might we mitigate the risk of those harms? How might we redress any harms that occur? * How will we monitor the production and use of these resources? How will we share the information from that monitoring process? * Under what circumstances should which people be able to produce and/or use these resources? How might people who are not members of our community relate to and interact with these resources, if at all? In what way, if at all, should we govern such interactions? * How will we identify, engage with, and resolve conflicts? How will we deal with members of our community that have acted at odds with our principles and violated our trust? * Where should this community gather to discuss this work? Where do we document our work? * Who should make what decisions? How do we decide who should make what decisions? How will such decisions be communicated? How will the decisions be enforced? * How will we ask these questions, and act upon any new answers that emerge over time? We may structure these questions in a matrix that applies each principle listed above to each the various layers of an open source community ([as per this draft here](https://docs.google.com/spreadsheets/d/1ya_flgj83ki46genn2b-QiXPxMrDrqjmTgmKIWJgLu4/edit#gid=0)). ***Your feedback is welcome! Leave a comment here or [join us here in the SustainOSS Discourse forum](https://discourse.sustainoss.org/t/principles-of-open-source-institutional-design/62/16).***, The Principles of Governing Open Source Commons, Greg Bloom, 01k2598azehj9sxz2b6wjs9j49.