To me, it is difficult to talk about governance (more explicit rules and practices for separating work, making decisions, and resolving disputes) without having a shared understanding of common beliefs and principles. I believe that a common understanding of the vision is most important, and then being explicitly flexible in the details of how we work toward that vision together.
Or, to put it a different way, making decisions becomes much more easy when there is general agreement on the “rules of thumb” of a shared vision. The exact manner in which decisions are made matter less, since there is a good likelihood that anyone who understands the shared tenets would act similarly.
As an advocate for being intentional about writing down core principles, and using that as a tool in building a community of like-minded people to collaborate together in building (see my closing thoughts in this OSCON 2019 panel), I welcome this. Thank you for pushing for it. For me, these are the things to debate robustly, to the point where you reach a general consensus and satisfaction that they are going to be relatively durable through time, yet not chiseled in stone.
Meanwhile, I think the specific practices that can be used to organize a project, and make decisions, might necessarily need to change over time. During the early phases of a project, it may make sense to have a designated initial project leader. As a project grows, the work put on a single leader may exceed what any one person can do, and it then makes sense to find a way to divide up the work. (These phases may not directly map to the situation at hand, since this software project is already meaningfully large in size, with many people interested in joining in.)
If you are able to look at it that way, @dawnfoster, what decisions about governance (the specific norms and practices used to make decisions and resolve disputes) would you want to be able to generally answer with the assistance of written-down principles?
I do think that your feedback on the use of “we” in the draft (which, for background, I wasn’t involved in drafting or reviewing) is helpful, since it raises the question about who is “we” and who is “other.” I think that partially boils down to the question about roles, responsibilities, authority, role assignment, and so on. I think that it is very important for people of diverse backgrounds and affiliations to be able to assume roles that have defined responsibilities to be stakeholders in the effort. “We” should be each person involved in the overall effort.
So, let me propose my own set of tenets that might could be used when faced with decisions about governance. These are based on things that I’ve observed to work well in practice with other open source community-focused projects in many sizes. I am writing only as an individual here, and I have not passed these around internally for any discussion or feedback, which I think needs to happen here in the open.
- Trust is fundamental. Lasting communities are built on trust, which builds slowly over time and is easy to lose. Trust is earned through establishing a shared vision, clearly setting expectations, being transparent, making promises to one another, and then keeping those promises. We mindfully reject proxies and shortcuts that may be substitutions for building trusting relationships between all stakeholders in this effort.
- Shared stewardship. Each participant in this effort is a stakeholder, and partial owner. We mindfully establish policies and practices that re-enforce the continued growth of a diverse group of stakeholders in the project, such as adopting the Developer Certificate of Origin rather than a Contributor License Agreement that aggregates rights to a single party that are not available to everyone.
- Permissionless Innovation. Through the use of open source licenses, well understood core principles, and shared norms, permissionless innovation conditions are supported by this effort. It is expected that some stakeholders that collaborate in the effort will also compete with one another. Permission is not required to innovate or to compete. All of the necessary permissions to do so are provided ahead of time through open source licenses and open, non-discriminatory policies.
- Designed for speed and scale in making decisions. Federation of responsibility and decision-making authority scales better than coordination. Modularity and extensibility in the design of the software, and the community that produces it, reduces the need for coordinated decision making. Through the use of written principles and clear areas of responsibility, rapid high quality decisions are made locally by those who are most familiar with a situation. Only decisions that are difficult or impossible to reverse require more extensive deliberation.
- Roles and responsibilities need not be equal. When federating responsibility, different layers of responsibility form with increasing scope. On points of the timeline of a project, some responsibilities may not be easily delegated (for example, trademark enforcement when a company is acting as the steward), or performed in the public (like handling reports of Code of Conduct violations, or addressing embargoed security vulnerabilities). Each stakeholder needs to act as a steward within their area of responsibility, making decisions that are in the best interest of all stakeholders. Disputes can often be resolved cooperatively by engaging with individuals that have a different role in the project.
- Growing a community requires welcoming all. Investments made by some stakeholders will be variable through the long-term timeline of this effort. Mindfully creating leadership opportunities for newcomers that show interest in the effort means that historic contribution metrics should not be a primary component of a formula to allocate areas of ownership and responsibility, or to establish a stake as a stakeholder. Stakeholders come in all shapes and sizes, and every newcomer starts small.
- We all wear multiple hats. Stakeholders in the project have different interests, and those interests are valuable to consider when making decisions, as it can provide multiple perspective. When participating in discussions, it is helpful to declare if you are trying to represent the interest of your employer or sponsor, stakeholders that have similar interests, or if you are providing an opinion as an individual. When an individual holds a role with responsibility to the community at large, they may find it helpfully to declare that they are wearing their “upstream hat” to avoid misunderstanding about who’s interest they are trying to represent. Some hats come with real or perceived authority, and wearing small hats is recommended.
- Forks and Distributions are welcome. While a goal of this project is to produce high quality software that can be directly useful for a wide range of users, it is also a goal to produce one shared component of a diverse supply chain of software used to build products and services. Innovation and building value that is “downstream” of this effort is encouraged, as is “upstream first” collaboration to enable innovation that is generally useful. We adopt open, non-discriminatory policies that enable downstream consumption of the software produced by this effort in a “distribution” model to correctly identify its origin, and to also market products using a common name. We ask forks to rename their effort to avoid confusion, and we avoid introducing artificial impediments to do so. An exit should always be an option for someone that fundamentally disagrees with a decision.
- Special hooks are not welcome. Maintaining significant special functionality that does not generally benefit multiple stakeholders in the project causes undue collective burden on the community as a whole. Stewards and stakeholders of the project should not ask for the community to take on that work.
Hopefully these provide some raw material for further discussion. I’m not particularly attached to these, but I think they’re relatively sound.
–msw