The FOSS governance hit parade

In a previous blog post, I explained how valuable I think documenting the governance of FOSS projects is and wondered if there existed some sensible templates out there to get started. I asked around but did not find a lot of them.

Over the past few months, I’ve been working on a closely related question: what are the most used governance models in FOSS projects? I had some intuitions about the most used licenses or code of conduct documents, but not about governance models. So I have been trying to get such a picture, and want to give you an early-stage overview of what it looks like. This is ongoing work with Théo Zimmermann, Stefano Zacchiroli and occasional feedback from Marc Jeanmougin. We plan to publish a research paper with more details about our approach, but would already welcome feedback on those intermediate results.

Method #

We gathered a dataset of all GOVERNANCE.md files in repositories archived on Software Heritage. This GOVERNANCE.md filename is emerging as a standard location to document the team structure of a project. Our dataset also includes variants on this filename (including different capitalization or file extension), and records all versions of such documents in the archived projects. It’s worth noting that many FOSS projects document their governance in other locations and formats (such as on their website), so those don’t appear in our dataset.

From this dataset, we then identified which documents have been highly cited (or copied, potentially without attribution) across the ecosystem. We used the winnowing algorithm, a standard technique for plagiarism detection, and manually reviewed the 50 documents reported as being the most reused, filtering out spurious cases where the reused fragments were too short or generic to be likely to correspond to an actual reuse.

Highly reused governance models #

Here’s the leaderboard we currently have. The “source” column shows the likely location of the original document (which is sometimes outside our dataset, but can be recovered by following source acknowledgments). The “reusing projects” is an approximation of the number of projects in our dataset whose governance contained (at least at some point in time) some text fragments first introduced in the source.

How do governance models get reused? #

From this list of reused documents we identify three broad categories of inspiration sources for governance models:

1. governance documents in use in other FOSS projects
2. templates which stem from the legal entity hosting the project (also called “fiscal sponsor” or foundation)
3. generic governance templates, not linked to a particular legal entity, and designed for broad reuse.

Reuse of governance models of other projects #

Governance documents are often drafted by relying on significant inspiration from other projects’ own documentation. Out of the 16 sources we identified in our dataset, 12 of them are concrete governance documents of specific projects. Their reusers often copy the document without making much more changes than changing the references to the project name, but cases of reuse with significant adaptations are also common.

There are obvious advantages to reusing parts of the governance document of an existing project. It is presumed to be tried and tested, fit for purpose in an existing project, rather than stemming from the wishful thinking of a governance consultant. The participants of the reusing project might have experience working in the reused project, giving them a concrete understanding of the ways of working prescribed by the governance document.

We observe that the reused and reusing projects often belong to the same technical domain, are written in the same programming language, or are hosted by the same institutions. For instance, NodeJS’ governance has influenced the governance of other Javascript-related projects such as ExpressJS (an application framework using Javascript) or Rome (a developer toolchain for Javascript). Similarly, we observe governance reuse between projects related to scientific computing in Python, often affiliated to NumFOCUS (Jupyter seems to have inspired projects such as NumPy, Scipy or Pandas).

The area with the highest degree of reuse in our dataset is that of cloud computing, represented in particular by projects hosted by Cloud Native Computing Foundation (CNCF). Projects such as Kubernetes, Jaeger, Envoyproxy, Harbor or CoreDNS have seen their governance imitated by many other projects from the same ecosystem.

Foundation-specific governance templates #

This reuse of governance models within the CNCF ecosystem was likely accelerated in 2020 by CNCF starting to offer governance templates for its projects, based on three popular governance models of their projects. The most reused one, GOVERNANCE-maintainer.md, defines a self-appointing group of maintainers who are responsible for the entire project. Another template, GOVERNANCE-elections.md, is meant for larger projects, which develop multiple components spread on various repositories. It defines an elected steering council, holding the more strategic and administrative responsiblities and delegating the development responsibilites to groups dedicated to various components of the project. The third model, GOVERANCE-subprojects.md, is similar but puts more emphasis on the subgroups being able to define their own governance, defining the overall project more as a federation of projects. Those three templates were inspired from the governance Jaeger, Kubernetes and Konveyor. Our corpus shows significant reuse of those templates both within and outside of CNCF.

Our corpus surfaced another case of a foundation offering governance templates to their projects. The Academy Software Foundation is a subdivision of the Linux Foundation which hosts projects relevant to the motion picture industry. They offer a sample repository implementing the best practices they recommend for their hosted projects, which includes a GOVERNANCE.md file. This governance document includes excerpts from NodeJS’ governance document and defines three roles: that of contributor, committer and lead, the latter being the point of contact between the ASWF and the project. This template is used in various ASWF projects, such as OpenImageIO, OpenRV or rez.

To understand to what extent foundations influence the governance of the projects they host, we reviewed the guidelines of 47 foundations hosting open source projects¹. After excluding foundations which were only centered around a single project, 26 foundations remained.

Only four of those foundations propose governance templates to the project they host: CNCF, OASIS Open, Commonhaus and the Commons Conservancy². But this doesn’t mean that other institutions are agnostic about the governance of their projects.

The Apache and Eclipse Foundation impose a fixed, predetermined governance model to all their hosted projects. The adoption of this model is part of the onboarding process of the project in the foundation. Since their governance model is imposed, those projects tend not to document this inherited governance in their own repository, meaning that they are not present in our dataset.

For 9 other institutions, we were able to find mentions of some governance requirements or guidelines. Some of those can be quite minimal, such as asking projects to have a publicly documented governance (NumFOCUS), or to designate a person as point of contact between the institution and the project, with an agreed on process to replace this person (Software in the Public Interest).

Instead of stating governance guidelines publicly, some foundations help projects improve their governance while onboarding them. We found 4 such foundations: the Software Freedom Conservancy, the Linux Foundation, the Open Source Geospatial Foundation (OSGeo) and the OpenJS foundation.

Finally, for 7 of our surveyed foundations, we couldn’t find any governance guidelines in their project onboarding documentation. It can of course be that we missed them. Here’s the list of such foundations: Free Software Foundation, KDE e.V., Open Bioinformatics Foundation, LF Charities, OW2, OWASP and Interalia.

Generic governance templates #

Generic governance templates are documents advertised as a sensible basis for FOSS projects to adopt. They are designed independently of any particular project and are meant to be applicable to a broad range of communities.

We only identified three generic governance templates being reused in GOVERNANCE.md documents, in order of decreasing prevalence:

1. The "meritocratic governance model" proposed by OSS Watch (a training center from the University of Oxford), which is inspired from the governance model used in projects hosted by the Apache Software Foundation. It features a two-level system with write access being grated to Committers and higher-level project management being the responsibility of a Project Management Committee (PMC). It also describes expectations around users and contributors. The number of reuses of this template as estimated by our heuristics is 122, and its URL is found in the governance documents of 39 repositories in our dataset.

2. The OSS Watch organization offers a second governance template for projects centered around a benevolent dictator. This document has a significant overlap with the previous one, in its description of users, contributors and committers. It replaces the PMC by a benevolent dictator and simplifies the decision procedures by emphasizing that the benevolent dictator has the final word. Our heuristics detect 113 reuses of this template, and its URL is found in 28 projects in our dataset.

3. GitHub proposes a set of documents documenting a Minimal Viable Governance (MVG). One of those documents is a GOVERNANCE.md document and goes hand in hand with a CHARTER.md. While GOVERNANCE.md is meant to document the administration of a repository, CHARTER.md documents the administration of the containing GitHub organization. Our heuristics identify 48 projects with significant overlap with the GOVERNANCE.md, including 16 of them which explicitly mention "Part of MVG-0.1-beta" (an acknowledgment included in the footer of the template).

We were surprised not to identify more of such templates in our dataset. Do you know of more? Do let us know!

Do we need more governance templates? #

Despite our efforts to surface governance templates, we identified remarkably few such documents, be they generic or tailored to a specific fiscal host. This contrasts with licenses or code of conduct documents, for which many off-the-shelf models exist and are widely adopted.

We suspect this is due to multiple factors. First, there simply isn’t a lot of demand for governance templates. Documenting governance is often considered a waste of time by maintainers, even in large projects. Maintainers know how their projects operate, since they are the ones deciding about this mode of operation, so they do not need such documentation themselves. In addition, they might see written governance as an unwelcome bureaucratic overhead or a threat to their autonomy.

Second, governance documents are only useful if they closely match the operational reality of a project. Providing a template bears the risk that projects adopting the template do not take the time to adapt it to their practices and update it as they evolve. A maintainer’s willingness to use a template for a governance document might be a signal that they are not particularly interested in its contents but may be motivated by other factors instead, such as wanting to satisfy the requirements of a funder or fiscal host for instance.

The most common type of governance document reuse is that of a project taking inspiration from another project, without relying on governance templates. We suspect that having first-hand experience of participating in a project with documented governance is very helpful to understand the social dynamics created by certain mechanisms, helping determine whether those mechanisms are worth retaining in another project. Beyond this, we suspect that this first-hand experience is also necessary to understand the benefits of documenting governance in the first place.

What’s next? #

The starting point of this research was our interest in supporting FOSS projects to make their governance practices more explicit. If offering more templates isn’t the way to go, we can still consider other measures.

Instead of offering a template, one could offer a list of topics or questions that should ideally be answered by such a document. Or a library of patterns, with links to some projects which use them. Or even a library of anti-patterns, with some pointers to the detrimental effects they can have.

Beyond this, I’m also working on improvements to forges and I am experimenting with documenting the governance of existing projects together with their participants. More on that in a later post.

Let us know what you think, for instance on the Fediverse.