How to govern a project on the scale of OpenStack

No readers like this yet.
Organizations coming together like a puzzle

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.

User profile image.
Jason was an staff member and Red Hatter from 2013 to 2022. This profile contains his work-related articles from that time. Other contributions can be found on his personal account.


Great article Jason! I am currently active in my second 'large' global open source project (not counting, as board member of a community board which is responsible for governing the project.

Your article gives me some new insights, but also confirm some of what I/We already apply in terms of governance. It's also interesting to see how OpenStack has organized this within their foundation. What specifically appeals to me are those Technical and User Committees.

I agree with you some form of control is necessary, especially to bring such projects to an enterprise level. The challenge for a project will be to find the balance in the level of control, put capable people in the right functions/roles, and the form in which they apply this governance at their organizational level.

Great article, OpenStack is really powerful

Indeed, nice high level overview. It would be interesting to compare the governance structure to two related organizations, Apache and Eclipse.

Apache governance is strictly by merit, and is independent from direct corporate influence. Between the project independence, and the breadth of 149+ top level projects, Apache allows the maximum self-governance for projects within the overall foundation structure.

Eclipse seems to very closely mirror OpenStack: can anyone discuss the relative responsibilities of the TC and project leads at OpenStack versus how the same roles at Eclipse? On the surface it feels very similar, but I'm wondering if there's a slight shift here in terms of which positions are earned by individual merit, versus companies essentially buying seats.

Separately, while I've found the board's meeting minutes, does the TC have a homepage for meeting minutes and email lists yet? Showing as much as possible of the governance process in public thru forums or publicly archived lists is a key way to draw in new interested contributors.

Shane, those are all great questions, and such a comparison would make a great followup post. (Maybe I can pursue it after I've recovered a bit from Summit!)

As per your last question about TC transparency, these links might help:
* Mailing List:
* Meeting Minutes:

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.