Projects that make their rules explicit would see more participation

When we say that a something is "open," we generally highlight its transparency or visibility. But openness is also inherently linked with collaboration and, as such, with the way people work together. Collaboration involves dealing with issues such as the organization of work and the allocation of decision rights—in a nutshell, all that we normally call a "governance model."

For open communities and other organizations, making these governance models explicit is key for several reasons. First, it helps promote an organization's sense of transparency. One could know how much time a group takes to consider an issue, the chances contributions have of making an impact on the organization, or who is going to hear their voices when they speak up. Second, explicitly defining a governance model may also help one better understand and classify how open organizations are driven. In other words, governance models reveal clues about the particular distributions of power and authority inherent to an organization (e.g., democracy, meritocracy, (benevolent) dictatorship, etc.). For instance, the study of specific governance models could shed some light on the definition of meritocracy in the context of open source (a controversial topic still under discussion).

But that is what we could potentially achieve. Let's start from scratch: In this article, I'll review how real-world source code projects work. Are they transparent enough? Could someone easily understand how to collaborate with them? Are their governance models clear and explicit?

Diving in

I queried GitHub to collect the 25 most-starred open source projects of the platform. Then I analyzed each one by looking carefully at several dimensions, including:

• basic activity metrics (e.g., commits or watchers)
• collaboration metrics (e.g., issues and pull requests)
• documentation (e.g., contributing.md, code_of_conduct.md, license.md)
• labels (e.g., use of descriptive labels)

After collecting this information (which I am sharing), I studied the governance model in each project (if existing or noted). Some of the analyzed projects provided enough information to understand their governance models, but not many: Five projects detailed this kind of information, one of them provided limited information, and nineteen did not describe anything at all.

I did find some good examples of governance transparency. For instance, the Moby project clearly describes the development workflow using meaningful labels and the people involved in each phase of the process. The NodeJS project provides a detailed description of the main developer roles of the project, their responsibilities, and how they are elected. The React project links to a document which describes how pull requests are handled, which details how they are reviewed and prioritized.

Looking back

These results are clearly better than the ones I obtained two years ago. At that time, I also analyzed the top 25 starred projects and the results were pitifully worse: Only one of the projects I analyzed (Docker) was actually describing this kind of information, while seven of them only provided some partial clues, and the rest were not even saying a single word on governance.

It is also important to note that the sets of top 25 projects were different in both studies. Figure 1 below shows the results.

^{Figure 1 (Courtesy of Javier Cánovas Izquierdo, CC BY-SA)}

While comparing new data to results from my previous analysis, I also noted:

• A broader use of the code_of_conduct.md file, which clearly instructs people on how to contribute to the project. There are even initiatives to promote best practices.
• More resources to teach newcomers how open source works and how they can contribute. The contributing.md file is now a first class citizen in GitHub projects.
• Use of more descriptive techniques such as semantic versioning (which helps to understand the nature of new releases) or detailed labels, which promotes understanding of project purpose (with special attention to the broad use of labels like "help-wanted" or "good-first-issue," which encourage newcomer to contributions).
• An extensive use of social networks and development supporting tools (e.g., gitter)

 This comparison shows an improvement with regard to the results obtained two years ago. So we have an answer to this article's primary question.

However, I believe that much work has to be done yet. Fortunately, some movements and initiatives (like the ones I noted previously) currently aim to facilitate the explicit explanations of how governance is addressed in open source projects and communities. They provide templates for contributing, as well as newcomer or licensing guidelines.

Maybe the next step is to facilitate developers' easily creating and customizing these guidelines. New mechanisms to empower developers (and end-users) to express (and make explicit) the rules and norms that govern collaboration would help the open source movement and open organizations specifically. An extra step could even include the development of tools to check (or enforce) that the collaboration is following stated guidelines (e.g., bots that enforce specific governance rules such as contacting developers to help addressing issues on time).

I understand this analysis cannot be generalized, but given the importance GitHub has in the open source community, I believe that it may be a representative example. Moreover, the fact that these projects are part of the most important ones (at least, the most followed by the community) also helps to show how things are being done.

Subscribe to our weekly newsletter to learn more about open organizations.