I have to admit, I’m very interested in the open source movement - to the point that I sometimes binge-watch videos of keynotes, panels and engineering sessions from open source summits and conventions that are posted on YouTube. I’m thankful that posting these videos has become the new normal over the last couple of years.
Having had opportunity to contribute to the very productive ODL Summit recently, I was happy to see that the Linux Foundation released all 102 (!) videos of sessions at the summit. Those of you that were at the event know that, with the multitude of high energy discussions going on at the same time, it simply became impossible to be participate everywhere. So, here was my opportunity to catch up!
The ODL summit had so many great sessions but it was ODL Executive Director Neela Jacques’ “Focus and Big Tent: Models of Collaboration” panel where the question of good governance was raised. The panel got started on the topic thanks to a compelling question from Open Network Research Center’s Guru Parulkar.
He asked: “… I would like to know…how do you define ‘good’ governance?”
To be clear, I would argue that the scope and implementation of governance in an open source project is generally reasonably well defined. One can just take a look at the governance structures defined within well-known Open Source Foundation based projects – from Linux, to Apache and the Eclipse Foundation – and find a set of documents (bylaws, IP policy, membership policies, board composition, etc…) that aid in governing a project.
These documents aim to assist a combination of individuals that fill executive and management roles to organize program oversight functions into structures and policies that define management principles and decision making. The same is true for well-established unaffiliated open source projects such as OpenStack and rapidly growing ones like Docker.
Guru preceded his general question by asking for metrics for good governance. From my point of view, this is the wrong approach to take. Like almost all initiatives that involve a fluid set of relationships between groups of people, any assessment of the governance quality of an open source project cannot be abstracted in one or several numbers.
Instead, I would like to suggest that there are project characteristics – both quantitative and qualitative – that are indicators as to whether it is more or less well governed. Together, these characteristics can form a composite view that can provide a reasonably accurate picture of the degree of good governance.
When I first brainstormed the list of characteristics for good project governance I came up with 20+ points. Deciding on the top five was surprisingly hard but here goes my personal checklist:
A project’s governance structure is unambiguously written down. There is no doubt that tribal knowledge can be valuable in a project, but a sign of good governance is that there are clear procedures and norms to transfer governance between individuals. This also includes an expression of the responsibilities and privileges of individuals contributing to a project or teams of people collaborating on specific areas of subject matter expertise (marketing, integration testing, docs etc…) within a project.
Good governance has a defined process that is consistently meritocratic. Unfortunately, I have seen project governance culture deteriorate because a small team of leads adopts a “we are more equal than others” attitude, has their position cast in stone and involuntarily starts to set higher and higher benchmarks for new contributors to get into more coveted committer roles.
One Litmus test to determine whether this is happening is to check the company affiliation of the project committers and their contributions over the last 12 months. For example, 9 committers out of a total of 11 all coming from the same organization and having been in place for several years is generally concerning. Good governance means that leadership is earned, not once, but all the time and that generally means a healthy churn rate in the leadership teams.
Good governance is public. Key decisions impacting the community, whether they are technical (e.g. new sub-project acceptance or denial), or scope related, need to be discussed and shared publicly. Period. Clearly, there are some exceptions (e.g. litigation), but even then, a sign of good governance is the ability of a project’s leadership to openly articulate those exception areas.
Good governance is broad. Representatives from no single company should be allowed to call the shots. Even projects that follow a BDFL (benevolent dictator for life) approach to making final decisions generally have mechanisms that ensure that contributors have an equal chance to influence the acceptance of a particular piece of code. Don’t just look out for a large number of companies, also check for diversity in the type of company. If the project has a large set of commercial solution vendors, is there also impactful representation from their customers?
Good governance generally is a result of a broad set of inputs, not a single organization or person driving a specific agenda. Now, of course, this can be hard for smaller communities – those just starting out or those that by their nature cover more of a niche application area. Still, even a small community made up of five people with three developers from three different companies and two representatives from different customers generally has better governance procedures than five people all from the same organization.
Broad governance also means that there are functioning input flows from different teams within a project such as user and advisory groups. One sign of poor governance is a project that spawns many user groups that do not have any ability (or capability) to provide input into the technical direction of the project. It does not mean that the project’s artifact is poor, just that the leaders are not governing their inputs as well as they could.
Well-governed projects have a system of checks and balances and have been able to work through disagreement, conflict and change. This is not different from any democratic institution. The board of a project generally determines “what” needs to be done. The technical steering committee determines the “how.”
Good governance means that marketing teams, advisory boards, user groups all have the ability to not only do their part, but also publicly question the other teams in the project within its review framework. On the flip side, poor governance means that one group is able to completely grind a project to a halt. Differences of opinion on technical direction are an innate part of open source projects. Check for evidence of successful issue resolution as a proof-point for good governance.
There was some discussion on the panel whether the quality and acceptance of the code from a project is reflection of good governance or vice versa. To me, this is a bit of a chicken and egg question. Personally, I have seen more evidence that well-governed projects, such as ODL, have the capability to generate higher quality code over time when compared to projects that do not exhibit my top five good governance characteristics.
Governance is a key, defining issue of open source projects and its worth it for every project lead to invest the time to get it right. A good starting point is to watch the “Focus and the Big Tent” video or to review the governance models of some of the more successful open source projects that I mentioned above.