Community leadership charts course for OpenStack

Last week, about 40 people from the OpenStack Technical Committee, User Committee, Board of Directors and Foundation Staff convened in Boston to talk about the future of OpenStack. We candidly discussed the challenges we face as a community, but also why our mission to deliver open infrastructure is more important than ever.

To kick things off, Mark Collier opened with a state of the union address, talking about the strength of our community, the number of users running OpenStack at scale across various industries and the progress we’ve made working across adjacent open source projects. OpenStack is one of the largest, global open source communities. In 2016 alone, we had 3,479 unique developers from dozens of countries and hundreds of organizations contribute to OpenStack, and the number of merged changes increased 26 percent year-over-year. The size and diversity of the OpenStack community is a huge strength, but like any large organization, scale presents its own set of challenges.

Allison Randal, who had done a lot of work beforehand to organize the strategy session, then laid out topical categories which present a unique set of challenges and opportunities for OpenStack. Each workshop participant was then challenged to define the first, most important action we should take to make progress in each category.

The five topical categories were: 1) how we communicate about ‘What is OpenStack,’ 2) unanswered requirements in OpenStack, 3) interacting with and supporting adjacent technologies, 4) changes to the technology and 5) community health. Throughout the day, we developed a plan of action for each category that will help focus community efforts and allow us to make significant progress over the next six months.

OpenStack Board / TC / UC Meeting

Six-month Community Roadmap TL;DR Version

Over the next six months, we’ll be focusing community efforts on:

Better communicating and categorizing projects within the OpenStack landscape currently known as “the big tent” to help users understand what is OpenStack and the state of different projects
Bringing together developers/users/product teams at the Forum in Boston to improve our process for turning requirements into code
Making individual OpenStack projects like Cinder block storage or Keystone identity service easier to consume by adjacent technology communities like Kubernetes (breaking the perception that you must use all of OpenStack or nothing)
Simplifying the existing projects by reducing the number of supported configurations and options
Growing the next generation of community leaders and helping them rise up

Each action also has a specific owner, and will be fleshed out over the next few weeks so we can talk about progress in the April 11th board meeting. For now, I’ll dive into more detail around each category, including the context, conversations in the room and different ideas for those who want to dig in.

How we communicate about ‘What is OpenStack’

Today, any related open source project can add themselves to the OpenStack git, communication tools and infrastructure for testing. The general community has witnessed this through an explosion of new programs and innovative ideas. While such growth and interest is an immensely positive result, retaining a process to define trademark use, official projects, core capabilities and code requirements has challenged the basis of what is OpenStack

Over the last two years, there have been a series of changes in how we communicate about the projects that make up OpenStack. Previously, new projects would often start in Stackforge and once they wanted to become an official part of OpenStack, they would apply to the Technical Committee (TC) to become incubated until they met criteria to become part of the integrated release.

To solve growing pains, about two years ago the TC implemented two different policies: 1) adopted a new framework commonly referred to as “the big tent” (now a somewhat controversial name) and 2) stopped using the Stackforge branding. The combination of these changes essentially laid the groundwork for a two-tier model (official/unofficial projects) rather than three-tier model (Stackforge/incubated/integrated). The Interop Working Group defines “core” as capabilities and code requirements with testing to validate commercial products, and the concept of the “integrated release” no longer exists. To provide more visibility into the state of official projects, the TC and User Committee also define “tags” expressing varying states of maturity, development processes, etc.

Proposals to improve the current state included better communicating the value and position of different projects, defining “constellations” or deployment patterns consisting of groups of projects for different use cases (e.g. OpenStack for NFV), and better categorizing the existing OpenStack official projects. There was a lot of discussion about subjective versus objective judgments in how to achieve this goal. Ultimately, it was decided that better mapping projects within OpenStack is the first, most important step. Thierry Carrez, chairman of the TC, will be spearheading these important efforts with a cross-community team of volunteers.

Adjacent Technologies

We’ve been talking as a community about building the LAMP stack of the cloud, thinking of OpenStack as programmable infrastructure and recognizing the important technologies above, around and below it that people are combining for different use cases. How we better integrate and collaborate with these different technology communities was a key topic of conversation in Boston.

Proposals ranged from more focus on cross-community engagement, including upstream work and technical collaboration in adjacent communities to making sure we avoid “not-invented-here” syndrome and consume technologies outside of OpenStack. Ultimately, the group decided that cross-community work was critical and efforts were underway, but one of the first, most important things we need to do is make individual OpenStack services like Cinder block storage and Keystone identity service easily consumable on their own, alongside these other technologies. We need to change the mindset that you have to consume all of the common OpenStack services and demonstrate that each project is valuable on its own and will be combined with different technologies in unique and valuable ways. Chris Price, recently elected to the Board by the Gold Members as part of Ericsson and who also participates in OPNFV, will be coordinating these efforts. It was also one of the more popular teams for volunteers.

Unanswered Requirements

While we’ve done a great job building a community of users and operators who participate and contribute directly in OpenStack, optimizing the feedback loop for a project of this scale has been an ongoing challenge. We now have an elected User Committee that oversees 11 working groups, including a Product Working Group that helps create user stories and communicate the road map for key projects. However, the challenge discussed in the strategy workshop was bridging the user stories created by the Product Working Group to real blueprints (with applied resources) for the technical contributors, which require more in-depth gap analysis and community buy in.

Discussions ranged from how we prioritize requirements to how we reduce the number of new requirements and focus on refactoring / embracing adjacent technologies to focusing on scale, but the group ultimately decided to bring the primary stakeholders (User Committee/TC/Product WG) together at the Boston Summit Forum to collaborate/communicate around user stories, gap analysis, what fits in the current state of tech, prioritize what would have the greatest impact in reducing pain for users. Melvin Hillsman, a newly elected member of the User Committee, will be wrangling this effort.

Changes to the Technology

Changes to the technology was added as the fifth category after we realized some of the proposals for change didn’t quite fit into ‘Communicating about OpenStack’ or ‘Unanswered Requirements.’ In order to address user feedback around complexity, proposed ideas in this category included culling official projects that may not be strategic or meet our quality standards, welcoming competing implementations within the OpenStack umbrella to enable greater change and innovation, converging the number of deployment tools (especially container-based deployment tools) and recording tribal knowledge. Ultimately, the group decided the first, most important action we need to take is simplifying existing OpenStack projects, including reducing the number of configuration options. Mike Perez, who works as a cross-project development coordinator at the OpenStack Foundation and is also an elected member of the TC, will be taking the lead on this effort working closely with the TC.

Cultivating Community Health

Our goal is to create a sustainable and productive community where diversity is valued and leadership opportunities are successful. There were several different proposals around improving community health, including on-boarding efforts, improvements to processes and tools and recognizing relevant contributions to adjacent communities and growing leaders in the community. The vote was very close between on-boarding and growing leadership, but it was generally recognized there are a number of on-boarding efforts like Upstream University already in place, while growing leadership was a new important focal point. Steven Dake, who works at Cisco and is an individually elected member of the Board of Directors, volunteered to lead the group defining the next steps toward that goal.

Get Involved!

Throughout the day, there was lively participation and discussion about all of the topics. A broad consensus emerged that we’re entering an exciting and important phase for OpenStack that presents new challenges but also huge opportunities. If you want to help drive the future of OpenStack in any of these areas, please email the Foundation mailing list, contact one of the team leaders directly (their names are linked to their unique OpenStack profile in each section) or join the next open board meeting on April 11.

Tags: OpenStack community