Recording the keynotes and the panel and engineering sessions at open-source conventions has become the new normal over the last couple of years. For me it doesn’t matter whether these records are all-encompassing live streams or curated archives of selected videos – I’m hooked on using this communication method to keep up with the changes in the industry.

In fact, I have gone from all too rare occasions of “putting my brain into neutral” binge-watching on Netflix to viewing the highly engaging and rich set of technical and strategic information recorded at these events.

Having had opportunity to contribute to the very productive OpenDaylight Summit recently, I was happy to see that the Linux Foundation released all 102 (!) videos of sessions at the summit. Those of you who were at the event know that, with the multitude of high-energy discussions going on at the same time, it simply became impossible to participate everywhere. So, here was my chance to catch up!

The OpenDaylight Summit had so many great sessions that it was quite a challenge for me to select one that stood out. Today I’ll focus on Neela Jacques’s “Focus & the Big Tent: Models of Collaboration” panel, partly because it is a quite a hard and sensitive topic to define, analyze and resolve, and partly because it ended up with such a compelling question from panelist Guru Parulkar of the Open Networking Research Center.

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 sets 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. This is true for both 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 among groups of people, 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 characteristics – both quantitative and qualitative – that are indicators as to whether a project is more or less well governed. Together, these characteristics can form a composite view that will 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:

1. 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 must include 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.
2. 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 its position cast in stone, and involuntarily starts to set higher and higher benchmarks for new contributors to get into more coveted committer roles.One way to determine whether this is happening is to check the company affiliations of the project committers and their contributions over the last 12 months. For example, nine committers out of a total of 11 all coming from the same organization and having been in place for several years is generally problematic. 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.
3. Good governance is public. Key decisions affecting 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.
4. 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 to ensure that each contributor has 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 types of company. If the project has a large set of commercial solution vendors, is there also meaningful 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 cover niche application areas. 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 to provide input into the technical direction of the project. It may not mean that the project’s artifact is poor, just that the leaders are not governing their inputs as well as they could.
5. Well-governed projects have systems of checks and balances and are 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 and user groups all have the ability to not only do their part, but also to 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 about whether the quality and acceptance of the code from a project is a reflection of good governance or vice versa. To me, this is a bit of a chicken-and-egg question. 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 it’s worthwhile for every project lead to invest the time to get it right. A good starting point is to watch the “Focus & the Big Tent” video or to review the governance models of some of the more successful open-source projects that I mentioned above.