For a more transparent governance of open source

The long-term sustainability of FOSS is a complex and multi-dimensional problem (technical, economical, social, political, etc.). We believe more transparency in how projects are governed would be a significant improvement to all such dimensions. And one that it is easy to implement. This is the gist of our opinion paper For a More Transparent Governance of Open Source just published at the Communications of the ACM (you can also read the free, unedited version, here), co-authored by Javier Luis Cánovas and myself. In this post, we give you the TL;DR version (refer to the full post for a more nuanced version and supporting references).

Introduction

The lack of key governance information deters potential contributors, as they may feel the onboarding process would be too time-consuming or may fear there are hidden power relations in the project that could limit their impact. The same goes for end-users, which may decide among similar projects based on how healthy and transparent the community behind them is.

To address this, FOSS projects should be more transparent and explicitly publish how they are governed in an easy-to-find and easy-to-read file acting as the single source-of-truth for the project. This file should, at least, cover aspects such as the project’s:

1. contribution workflow,
2. decision process to accept new contributions or prioritize features,
3. timeline for making these decisions, and
4. steps to climb the ladder in the project internal organization.

We are not there yet, as our analysis data shows.

How transparent is FOSS governance? Looking at the data

To evaluate the transparency of current OSS projects in GitHub, we conducted ourselves three preliminary different analyses. Each one narrows down the number of analyzed projects but widens the depth of the analysis.

We first queried the over 200 million repositories in GitHub for any mention of the word “governance” in their readme file. Only 21,114 (a tiny 0,01%) were a hit. Next, we focused on four specific software development ecosystems to run our analysis on more homogeneous sets of projects, namely: NPM packages, R packages, Laravel packages and WordPress plugins. We gathered all repositories from 2017 to now, and searched for governance information. To broaden the search, we looked for specific governance files but also looked into contributing and code of conduct files that could include governance aspects. We collected information from a total of 13,937 repositories. None of them included a governance.md file. And the presence of contributing and code of conduct files was also low.

We performed a final, more in-depth, analysis of the top 25 starred GitHub software projects. We looked for key governance information (recall previous section) in contributing guidelines, code of conduct, readme and project metadata (exploring and following any links that may be provided). 60% of the analyzed projects did not include any governance information while 32% partially discussed governance but only covering two or three aspects, not all of them. This is NOT an improvement over previous analysis.

Towards a more transparent governance

What could we do to improve the transparency of open source projects? Some ideas:

• Identify and learn from the best. Transparency is not common, but this does not mean that there are no projects that do an outstanding job in explaining in detail their governance. Well-known projects such as Node, Drupal or Debian, to mention a few, can be used as inspiration.
• Agree on a single place to keep the governance model. If the governance rules are part of the implicit community “know-how”, and scattered in many places (or too difficult to find), it is as good as if they were not existing. We propose to place all governance info in a md file in the root folder of the project.
• Be precise with the definition of the governance policies by using a Domain-Specific Language (DSL) created for this purpose. This has the added benefit that then the governance description can be automatically processed.
• Offer predefined templates for the most common governance models. This way, new projects do not need to start from scratch. Instead, they just customize the template to their specific situation.
• Collectively pushing for projects to add this information. If there is no governance information, ask for it!

But what would be the best governance model?

If we agree on the importance of defining an explicit governance model for FOSS projects, the immediate follow-up question is whether there is an ideal governance model for FOSS. We do NOT think so. . The idiosyncrasy of FOSS projects  is so varied that there is no one-size-fits-all model. Even, so-called, “benevolent dictator for life” models are tolerated and seem to work well for some projects.

While there is no ideal governance model, we believe there are a few general recommendations to consider when deciding it.

• Dictatorships should be the exception and restricted to the beginning of the project. Otherwise, there is a high risk of the project being forked and the community splitting. Instead, evolve towards more democratic models (keeping in mind that there are many democratic models, it doesn’t necessarily mean that all votes have the same value)
• Include all types of profiles, not only technical ones, are part of the governance model. Having a voice increases perceived fairness.
• Consider external factors in your decision. As an example, if you aspire to join a certain foundation or attract certain types of contributors, the openness of your model could be a factor to entice them.