Governance can be found in all open source projects in one form or another, expressed as processes or guidance for how people work together and make decisions within the project. Ideally, those processes will be clearly documented, but for some projects it might be undocumented, ad hoc and informal. In the worst case, “governance” takes the form of legacy knowledge — something more like folklore, verbally passed from person to person. (Tip: when you encounter this scenario, it’s a red flag!) In the best case scenario, a project’s governance documents can help you learn more about the ownership and control of a project. From a risk perspective, you should seek projects with neutral governance where decisions are made by people who work at a variety of different companies. Projects controlled by foundations and those owned by an individual company can have very different dynamics and risks associated with participation, which I covered in more detail in a blog post titled, “Collaborative Leadership: Transparency and Governance Beyond Company Affiliation.” In this final post in my Navigating Open Source Risk series, I’ll cover how your company can evaluate leadership and governance risk for open source projects.
Evaluating a project’s governance is an important element of assessing the risk of using or contributing to an open source project. Governance helps outline the expectations around roles and responsibilities along with the decision-making processes, but it will vary quite a bit by the size of the project. A project with only a few people won’t need elaborate elections to select leaders, but the project should have at least a few basic roles defined (like maintainer, for example).
Knowing how collaboration occurs and how decisions are made is vital to being able to make contributions that are more likely to be accepted. If the processes for collaboration, leadership and decision-making are not clearly documented, your risk increases, for it introduces uncertainty and confusion over decisions within the project.
Leadership plays a critical role in governance, and at a minimum, there should be some kind of documentation about leadership within the project. For small projects, maybe it’s just a list of maintainers in a README file or maybe owners or maintainers files that indicate which people are responsible for the various areas within the project. It’s also a good sign when the leadership documentation includes corporate affiliation. Many of us work for companies who employ us to do this work, and being transparent about our affiliations is a good practice in open source communities.
For the more mature projects, you’ll want to see more details about the specific roles and responsibilities for the different leadership positions, along with how others can move into leadership roles. There might be committees, working groups, special interest groups or other groups with leaders. If you become an active participant in a project, you’ll want to understand how you or your colleagues can assume leadership roles. Having employees in leadership roles helps reduce your risk as a company, since these employees will be in a position to understand more about how the project works and be able to help mentor other employees into the project.
There are quite a few different options for selecting leaders as part of defining governance, and the ideal from a risk perspective is to have a fair and employer-neutral process that defines how contributors can become leaders. This should be documented so that all participants can clearly understand the criteria and process for moving into and out of leadership positions. Most of the bigger projects, like Kubernetes, have an election process—at least for the top levels of leadership, like a steering committee.
A fair and transparent process for selecting leaders, like elections, reduces your risk of participating, since your contributors can participate in the elections and have a say in the governance of the project. Higher risk options would include organizational leadership seats where a certain number of positions are allocated to specific companies where those companies get to decide who gets their leadership positions and there is no easy way for new leaders who work outside of these companies to move into leadership positions. Regardless of how leaders are selected, you’ll want to make sure that there are opportunities for your contributors to move into leadership positions to reduce the risk for projects that you use and contribute to.
One way to help mitigate these risks is to have some discussions about governance within the community to gauge interest in getting some help with governance. In many communities, there can be various types of informal governance that just isn’t documented. Quite a few people tend to avoid working on governance, so if it’s missing, you might be able to volunteer to help, and it’s a great way to learn more about how the community operates.
If you enjoyed reading this, you might also be interested in the previous articles in this Navigating Open Source Risk series about licensing risk, contributor and organization risk, and responsive and healthy communities.
