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, 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 in her seminal work, Governing the Commons, which offers a set of principles for “institutional analysis and design.”
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, 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.
In the SustainOSS network, through a series of workshops 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)
Silke Helfrich’s common-language translation of those principles (in italics)
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!
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 and the Governing Knowledge Commons’ 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). Your feedback is welcome! Leave a comment here or join us here in the SustainOSS Discourse forum.