How to govern a project on the scale of OpenStack | Opensource.com
How to govern a project on the scale of OpenStack
How an open source project is governed can matter just as much as the features it supports, the speed at which it runs, or the code that underlies it. Some open source projects have what we might call a "benevolent dictator for life." Others are outgrowths of corporate projects that, while open, still have their goals and code led by the company that manages it. And of course, there are thousands of projects out there that are written and managed by a single person or a small group of people for whom governance is less of an issue than insuring project sustainability.
Control matters. Too little, and a project flounders without direction. Too much, or the wrong kind of direction, and a project can lose support or fork over minor issues, potentially leading to a fractured community. While not all forking is bad, when forking happens because developers can't get along and resolve their differences, it's probably not a good thing.
So how do you manage a global project encompassing the work of thousands of people working at hundreds of companies worldwide? For big projects like this, a foundation model sometimes makes more sense to ensure fair and equitable representation while keeping the project on track to meet the needs of everyone who uses it. The foundation model is used by OpenStack and helps create a governance structure that keeps any one party from taking too much control.
OpenStack hasn't always been run this way. It started out as a collaboration between NASA and Rackspace when the two organizations realized they were working toward similar goals and would benefit from collaboration. Recognizing the value in what they had created, and that broader participation would lead to faster development and a more versatile project though wide participation, Rackspace created the OpenStack Foundation as a nonprofit organization to manage the project, to be governed by broad coalition of companies with similar interests in open cloud infrastructure. Started in 2011, it was September of 2012 when the reigns were officially passed over.
The OpenStack governance structure allows participation from a wide group of organizations and individuals and is subdivided into various committees to ensure that the right people are in charge of the right parts. Primarily consisting of three committees—a board of directors, a technical committee, and a user committee—the OpenStack Foundation has roles for many different types of contributors in their structure. The Board of Directors oversees financial decisions and long-term strategy, while the technical committee—not surprisingly—gives technical direction, and the user committee helps ensure the project is meeting the needs of organizations working with the software on the ground.
But OpenStack isn't really a single project, it's a group of several tightly integrated projects providing services that together give lift to a cloud. Each of these projects is headed by a program team lead (PTL) who maintains plans through each development cycle. Other key functions within OpenStack that aren't themselves software components (documentation, quality assurance, and release cycle management, for example) also elect PTLs. As OpenStack is on a twice-yearly release schedule, these leaders are likewise elected two times a year to oversee their individual component through one cycle.
All of this brings us to tomorrow, April 11, which marks the end of the most recent PTL elections. As the Icehouse release of OpenStack nears completion for a planned release on April 17, and the Juno Design Summit sits just around the corner, these elections will help set the direction for the work done over the next six months. Fittingly, the electorate for PTL elections are the contributors to each project. Did you have code in a recent release? Then you're eligible to participate.
Of the twenty-one projects which are electing PTLs, six are contested. While some might see contests as signs of troubling disagreement, they're actually a healthy part of the process. They ensure that projects are headed in the direction that contributors want to see them go, that each project is managed by someone deemed capable to do the job (and being a project team lead is definitely a job), and they help facilitate a robust discussion on what needs to be done in the coming release cycle. Everyone in the OpenStack community should be excited to see the results and find out where things will be headed in the next six months.
For more on the PTL elections or the candidates running, see the OpenStack wiki.