March 8, 2017 OpenStack Foundation Strategic Planning Workshop

The OpenStack Foundation Board of Directors met in-person for two days in Boston last week.

The first day was a joint workshop with the Technical Committee, User Committee, and Foundation staff. The workshop was planned in response to the "OpenStack Futures" discussion at our three previous board conference calls in November, December, and January.


We began the workshop with very brief personal introductions, followed by Alan, Thierry, and Edgar giving an overview of the roles and responsibilities of the Board of Directors, the Technical Committee, and the User Committee.

State of the Union

Next, Mark Collier presented his view of the state of OpenSack, with a particular emphasis on the four areas planned for discussion during the day. Mark began by talking about the exciting opportunity we had by having such breadth and depth of expertise in the room, and appealed to everyone to put aside their particular roles and work together as a single leadership team to talk about the work.

Evolving The Architecture

Mark spent some time trying to demystify the Big Tent change, describing how the previous Stackforge/Incubation/Integrated stages have been replaced by almost any project being welcome to use OpenStack infrastructure with the TC responsible for reviewing applications to join the set of official OpenStack projects known as "The Big Tent".

Mark then described one of the key changes happening in OpenStack right now as the containerization of the control plane, with projects like Kolla, openstack-helm, and TripleO all tackling this area. He also talked about the work happening around running containers on OpenStack itself with projects like Kuryr, Fuxi, Magnum, and Zun, but he also wondered aloud whether we're addressing all the right integration points. He also described some of the ongoing debates about the scope of OpenStack and our technology choices, with topics like the use of golang, the Gluon project, whether we welcome competition within the Big Tent, and community-wide goals.

Finally, Mark gave us a preview of the work happening around version 2 of the OpenStack Project Navigator and talked about how this will play a key role in helping people understand what OpenStack provides and how it can be used.

Unanswered Requirements

Mark talked briefly about the working groups under the User Committee and the transition from Design Summit to Project Team Gathering and Forum formats. These concepts are all important in understanding how OpenStack thinks about our requirements gathering, strategic long-term planning, and implementation planning.

Mark also gave a preview of some detractor quotes from our user survey, and emphasized a common theme - the perceived and actual complexity of OpenStack, both in terms of understanding and operating the software.

Adjacent Communities

Mark classified the various sets of adjacent communities that we are particularly interested in developing strong relationships with. Container technologies like Kubernetes, Docker, and Mesos. PaaS technologies like CloudFoundry and OpenShift. NFV projects like OPNFV and Cloudify. Provisioning technologies like Terraform, Puppet, and Saltstack. And specific ecosystem relationships, with companies like CoreOS.

Mark described the change in the Foundation's event strategy, targeting events like KubeCon, DockerCon, CoreOS Fest, etc. as key events where we should be positioning the OpenStack brand and developing relationships.

He also described particular focus areas of individual staff members which are relevant to the topic - Chris Hoge working with upstream Kubernetes and running OpenStack SIG meetings, David Flanders working on a report around the gaps when running platforms on OpenStack (like Cloud Foundry, OpenShift, Kubernetes, and Terraform), and how Ildiko Vancsa and Kathy Cacciatore are both working closely with OPNFV.

Finally, Mark talked about the Open Source Days event at the OpenStack Summit in Boston, as well as some very early stage discussions for an OpenDev event which would be a small, focused event around improving the integration between applications frameworks and open infrastructure.

Community Health

The final area of discussion was the subject of community health, and Mark first put out some statistics that he felt painted a very reassuring picture of the community's health. In 2016, we had 3,500 unique contributors, 1,850 of which were retained from 2015. In Ocata, we had fewer developers than Newton, most likely because it was a shorter cycle.

Mark contrasted challenges with projects like Trove and Designate losing contributors, while projects like Kuryr, Kolla, and Zun seeing the greatest number of new contributors.

Similarly, Mark talked about HPE laying off upstream developers, Cisco killing off intercloud, a small slowdown in Summit sponsorships, while we have also added 7 more Gold members, and many first-time corportate members and Summit sponsors.

Strategic Planning Exercise

The rest of the day was given over to a multi-stage strategic planning exercise prepared by Allison and Alan. The idea was to discuss these focus areas, gather everyone's ideas for improvement, summarize and categorize these ideas, vote on ideas in each focus area, and finally agree on how to proceed with concrete goals for the next 6-9 months.


The initial discussion covered a lot of ground. Allison introduced each focus area by describing the input we gathered via the etherpads and input she gathered through 1:1 interviews with a variety of people.

One topic of discussion related to how OpenStack can simplify how we describe OpenStack, particularly to reduce confusion introduced with the Big Tent change. Various ideas around categorization, tagging, vertical definitions, a concept of constellations, maturity ratings, and much more, were discussed.

We talked about the promise for the future that OpenStack provides. That there will be evolution over time, that we deliver the cloud solutions of today and will deliver the solutions of tomorrow. That the challenge of smooth upgrades is part of our challenge in delivering "future proof infrastructure".

We talked about the challenges of scalability, manageability, and complexity. The theme of containerized deployments, the need for vertically focused views of OpenStack, for example for Telco users. We discussed the need for OpenStack to be able to evolve over time, with refactoring or rewriting components being only one of the possible approaches we may see over time.

We talked at great length about how OpenStack could work more closely with adjacent communities. How the relationship with these communities should bring value to both communities. We particularly emphasized the need for a closer relationship with the CNCF and the Kubernetes community.

Gathering Ideas

Over lunch, everyone wrote their concrete, actionable ideas for improvement on sticky notes and put them on flipcharts for each of the areas of discussion. Later, Jonathan volunteered to group the ideas into themes, and summarized these themes for the group, facilitating further discussion before voting on which theme in each area we should particularly focus on.

On the subject of communicating about "what is OpenStack", the main themese were marketing activities, various categorization ideas, and idea Allison talk about earlier referred to as "constellations". We later voted to focus on the categorization area and formed a group of interested parties:

Communicate about OpenStack: Categorize (objective data) and map (subjective approach) OpenStack projects as base versus optional (within a specific use case), integrated versus independent release, emerging versus mature, stability, adoption metrics, what works together, services versus consumption (operational tools/client libraries), and other criteria

Names: Thierry Carrez [lead], Alan Clark, Allison Randal, Jon Proulx, Melvin Hillsman, Lauren Sell, Tim Bell, Mark Baker, Kenji Kaneshige

For unanswered requirements, we discussed how to prioritize, ideas around a solution focus, scalability challenges, and a list of specific features that people felt were important. A counter-point was made that rather than focusing on any of these ideas, perhaps the focus should be on working with adjacent communities. Later, we discussed the need to grow the connection between the Product Working Group, the TC, and individual projects. The outcome and group for this was:

Requirements: Bring different groups (UC/technical/etc) together at Forum to collaborate/communicate aroud user stories, gap analysis, what fits in the current state of tech, prioritize what would have the greatest impact in reducing pain for users.

Names: Melvin Hillsman [lead], Yih Leong Sun, Jon Proulx, Rob Esker, Emilien Macchi, Doug Hellmann, Tim Bell, Shamail Tahir

On the topic of adjacent communities, we observed that by far the most dominant area of discussion was the need to create better connection with the Kubernetes community. The themes were community engagement, technical engagement, OpenStack consuming technology from the Kubernetes and containers world, and making OpenStack technology more consumable by Kubernetes. In the end, there was strong consensus to focus on the consumability of OpenStack technologies:

Adjacent Technologies: Make our technology more consumable (independently) by other communities/projects.

Names: Chris Price [lead], Alan Clark, Dims, Rob Esker, Mark Collier, Steven Dake, Mark McLoughlin, Shamail Tahir

For changes to the technology, we discussed simplifications, making containers first class citizens, recording tribal knowlede, culling failed efforts, converging deployment tools, and welcoming emerging or competing projects. The theme we voted to focus on was:

Changes to the Technology: Workstream to simplify existing projects, reduce dependency options, reduce config options.

Names: Mike Perez [lead], --> TC project

Finally, on the subject of community health, we talked about onboarding contributors, reworking our processes, community tools, growing leaders, corporate involvement in the project, and recognizing work with adjacent communities. We voted to focus on the leadership theme:

Community Health: Grow next generation of leadership/experts/cross-project devs within the community

Names: Steven Dake [lead], Chris Price, Jeremy Stanley, Dims, AlanClark, Joseph Wang

Next Steps

For each of these focus areas, the lead person in the group committed to organizing a kick-off meeting by March 22nd. The real work will begin there!

January 24th OpenStack Foundation Board Meeting

The OpenStack Foundation Board of Directors met for a two hour conference call on Tuesday. The usual disclaimer applies - this my informal recollection of the meeting. It’s not an official record. Jonathan Bryce has posted an official summary of the meeting.

The 2017 Board

This was the first meeting of the board since the recent Individual and Gold member director elections. As such, Alan asked each of our new directors to introduce themselves:

  • Brad Topol
  • Brian Stein
  • ChangBo Guo
  • Christopher Price
  • Joseph Wang
  • Junwei Liu
  • Russell Bryant
  • Steven Dake

Alan also thanked our outgoing board members for their contributions:

  • Alex Freedland
  • Edgar Magana
  • Manju Ramanathpura
  • Monty Taylor
  • Roland Chan
  • Raj Patel
  • Todd Moore
  • Van Lindberg

Since it's a new year, we took the opportunity to review the various policies which apply to board members:

  1. Antitrust policy
  2. Code of Conduct
  3. Transparency policy
  4. Board communication channels, including webex, foundation mailing ... list, foundation board open and confidential mailing lists, IRC, ... etherpad, and wiki.

We also took the time to review the list of board committees and invite board members to volunteer to join these via the etherpad.

Finally, we reviewed the board meeting schedule for the year, including 6 conference calls and 4 in-person meetings.

Staff Update

Mark Collier then presented an update to the board. Reflecting on our strategy, he talked about three forces that need to be in alignment - the ecosystem, the software, and our users. The slide deck gives a good view into the discussion.

Commitee Actions and Updates

Next up, the compensation gave a brief summary of their review of Jonathan's performance in 2016, which had been shared in advance with the board.

The Interop Working Group also talked through their January 2017 report and the board voted to approve the 2017.01 guideline.

Strategic Discussions

Finally, the board spent some time discussing the strategic planning discussions that started at the November meeting and continued during the December meeting. Our hope is to have a joint meeting with the Technical Committee in March to spend significant time on the topic. Allison Randal discussed various options to prepare for the meeting, including conducting one-to-one interviews or a public survey.

December 6th OpenStack Foundation Board Meeting

The OpenStack Foundation Board of Directors met for a two hour conference call yesterday. The usual disclaimer applies - this my informal recollection of the meeting. It’s not an official record. Jonathan Bryce has posted an official summary of the meeting.

Executive Director Update - 2017 Budget

After taking a roll call and approving minutes from two previous meetings, Jonathan gave a presentation on the 2017 Foundation budget.

Jonathan described a number of goals under a "One Platform" theme for 2017. He talked about how OpenStack should (a) make sure containers are first class citizens within OpenStack, (b) ensure workload portability across interoperable public and private OpenStack clouds, and (c) reinforce OpenStack position as the standard platform for NFV.

Jonathan went on to remind the board that in 2016 we had planned for a 2016 loss, the idea being to invest some of the cash reserves that the Foundation had built up in order that we could take on some new activities. In 2017, the proposal is to aim for a break even budget so as to avoid not further depleting the reserves. However, with the addition of new Gold Members, we will be able to maintain the increased investment from 2016 while still breaking even. Mark Collier noted that China is a key growth area, given that much of this new funding is from new Gold Members from China.

Jonathan then presented the budget itself, showing quarter-by-quarter income and expenses in a number of high level buckets like "Corporate Fees", "Events", "G&A", "Community Development", and "Community Infrastructure". One particularly striking aspect of OpenStack Foundation budgets is that much of the financial activity comes in Q2 and Q4 with the OpenStack Summit events in those quarters, accounting for $10.5M and $6.5M activity in Q2 and Q3 respectively out of the total $22M budget.

A discussion followed the presentation around what level of financial detail the board would like and expect to have available. Roland Chan expressed a concern that he was unable to tell how the strategic decisions the board had made were impacting the budget. For example, you could compare the 2016 and 2017 high-level budgets and make a good guess as to the impact caused by the addition of the PTG, but it would be nice to understand that in more detail. Some debate ensued as to whether this was information that was already available to the Finance Committee, whether the board should be supplied with a more detailed budget breakdown, or whether we instead need some analysis and commentary about the financial impact of key changes.

Jonathan took an action to prepare some further information which should help address the question. Alan also took an action for the Finance Committee to consider how to address this more structurally. Finally, the 2017 budget was approved by a vote of board members.

User Committee Proposal

Next up, Edgar Magana presented some proposed by-laws changes around the structure of the User Committee and related changes to the UC charter.

Since these changes had been previously discussed by the board, they were put to a vote after some short discussion. The board approved a motion to replace section 4.14 of the by-laws with the text above, along with adding a new UC member policy appendix.

OpenStack Futures

The board then turned its attention to a discussion started at the previous board meeting about the future of the project and some key questions it was felt the board should be considering.

Allison Randal lead the discussion by talking through some of the information the board had gathered in an etherpad since the previous board meeting. We had condensed the questions and concerns into four distinct areas:

  1. OpenStack and its evolving relationship with adjacent technologies.
  2. Unanswered requirements, and how they will be address by the project over time.
  3. Whether OpenStack is sufficiently able to evolve architecturally architecture to meet certain needs.
  4. Community health indicators the board and the wider community should be paying attention to.

It was felt that we would only be able to discuss these in a useful way with an in-person board meeting, and the hope is that we will be able to hold this meeting alongside the PTG with involvement from the Technical Committee.

In order to help frame the discussion at that in-person meeting, Allison proposed that board members consider a series of 12 strategic questions as homework for the next board meeting. These questions are based on the 12 "boundary questions" proposed by Werner Ulrich in his work on Critical Systems Heuristics (CSH). There was some discussion as to whether these questions could, in future, be posed to the wider community via a survey.

There was some brief discussion about how this relates to "OpenStack-wide Goals" mechanism recently introduced by the TC. Toby Ford gave the concrete example of "1000s of nodes under the management of a single control plane", and wondered whether that would qualify as an OpenStack-wide goal. Doug Hellmann happened to be on the call and was able to explain that the goals mechanism is used to achieve changes that address concerns across all projects and which can be completed in a single cycle.

The discussion ended with the board agreeing to complete the 12 questions prepared by Allison for an in-person meeting in Atlanta.

Gold Membership Expansion

The final topic of discussion was raised by Shane Wang. Now that the 24 Gold Member slots have been filled, an obvious question remains ... should the Foundation increase the number of Gold Member slots?

Shane made the case that more companies want to join as Gold Members, particularly in China and gave the example of an other major Chinese telecommunications operator that is eager to join.

Roland explained that the topic had been discussed at a recent - but poorly attended - meeting of the Gold Members. It was felt at that meeting that more options need to be considered than simply increasing the number of Gold Member slots - for example, increasing the number of Platinum Member slots so that perhaps some Gold Members could move to Platinum, or the introduction of a Silver Member tier.

However, it was also felt that we should carefully consider our goals even before jumping into considering specific options. Anni made the point that we're trying to achieve a balance between the risk of devaluing the membership status versus wanting to welcome more participation in the Foundation.

All felt that this was an important topic that warranted further discussion and consideration.

Looking Ahead to 2017

And so, the boards work for 2016 has come to an end. The schedule of meetings for 2017 has not yet been finalized, but the next two meetings are likely to be a two hour conference call on January 31 and an all day in-person meeting in Atlanta on February 24.

Sustainable Investment in Open Source

This is the prose version of a talk I gave today at OpenStack Day, France. The slides are available here.

Today, I want to speak about a somewhat subtle, meta-topic. I hope to share some insight on the question of how a company should think about its investment in any given open-source project. The reason I think the subject is important right now is that, as OpenStack follows its inevitable path through the “hype curve”, we are seeing some major players in the OpenStack ecosystem have recently re-shaped their investment in the project. I think there is plenty of opportunity for companies to take a much more realistic view on this subject, and my hope is that this will lead to a much more sustainable level of investment in the project.

My Story

My views on this question are so heavily influenced by an early personal experience, that I’m tempted to talk at length about my own story. But time is short. Very quickly, though, as I was finishing university, I realized I wanted to focus my career on open-source, and I was faced with the obvious question of who was going to pay me to work on open-source? What value would be open-source work bring to my employer? I spent a lot of time thinking about this, even after I found myself employed to work full time on open-source.

My Employer

An interesting thing happened. Because I had spent a good deal of time thinking about the value of my own open-source work, I was well-placed to help my employer think about how, where, and why to invest in open-source projects. It quickly became apparent to me then - and is still apparent to me now - that this fundamental question is fraught with difficulty, and most people struggle greatly to answer it.

Investment vs Business Needs

Over the years, I’ve boiled my answer to this simple-sounding question to something equally simple - your investment in a project should be directly related to what the business needs from the project. I think it’s important to frame it this way, because if the business doesn’t have a good have a good understanding in the value of an investment, the business is going to be quick to discontinue that investment when it is looking at how to make the best use of its resources.


What do I mean about an investment that isn’t directly related to the needs of the business? Let me dig into that a little bit with some anti-patterns.

Focus on Features

First, features. Or, as Thierry Carrez puts it, “tactical contributions”. Companies often look at the “what do we need from this project” question through the lens of feature analysis - what are my requirements? What is missing?

The good thing about contributing features is that it is directly related to business needs. The thing about your primary focus being on new feature development is it misses the bigger picture. A community of developers that is focused only on their own new features is not going to get anywhere. Who is thinking about the long-term future of the project? Who is looking at feedback from users? Who is merging the code for these new features?

All of these types of activities are the basic necessities of any software project. They are the basis through which new features get added. You must invest in ensuring that this is happening in this project whose future you care about.

The Donation

This anti-pattern is about our choice of language, and how it affects our thinking. People often talk about “donating” code to a project. Calling it a donation suggests you have a feeling that the return on your investment is quite intangible. How long will you continue with these “donations”?

For Recognition

Related, it’s often quite clear that a major motivation for companies investing in open-source is the recognition they receive in doing so. Certainly, in OpenStack, with Stackalytics we have spawned an impressively pointless competition between companies for ranking in contributor statistics. If you give your employees the goal of achieving a particular ranking in the contributor statistics, you may achieve this, but what does that really achieve?

The type of business value that it delivers is essentially short-term marketing value. We don’t want investment in open-source projects to be made out marketing budgets, since that’s possibly the least reliable source of funding!

"100% Upstream"

Not so long ago, when companies were falling over themselves to demonstrate their commitment to OpenStack, we saw an interesting phenomenon - the “100% dedicated upstream resource”. These were individuals and teams at various companies who were employed to contribute to the project but - as far as I can tell - were self-directed and deliberately kept isolated from any “downstream” work.

This is an incredibly alluring opportunity for those involved! The company is saying that the project is critically important to the business and whatever you or your team does to help the project be successful, that’s valuable to the company! Unfortunately, we can see how these things go in cycles and, at some point, the company will take a harder look at what this person or team is doing. When that happens, the likelihood is that the company has very little visibility into - or understanding of - the work being done and, worse, the person or team has no experience articulating how the value of the work is meaningful to the business!

There are some exceptions to this, even within Red Hat. But as a systematic way of investing in a project … it’s unlikely to be sustainable.

Non-Profit Staff

Finally, the culmination of a number of these anti-patterns - the idea that companies should "donate" to a non-profit organization like the OpenStack Foundation, have that organization use the donations to employ staff who are "100% dedicated upstream resources", and the value to companies ...? The recognition it receives for being such generous benefactors?

Having some technical staff employed by the non-profit is fine. Some of my favorite people work for the OpenStack Foundation! My preference would be for Foundation staff to be in facilitation roles. But certainly, you would do well to avoid this pattern for the majority of the contributors on a project.

One example of this is the Linux Foundation's Core Infrastructure Initiative. In the wake of the OpenSSL Heartbleed vulnerability, the Linux Foundation brought together funding from a number of companies to invest resources for key projects like OpenSSL. It's fascinating because here is a project like OpenSSL that many, many businesses depended on, but few invested in. What the Linux Foundation has done is positive, but I can't help feel we have failed as a community if this is the only way to sustain these projects. You'll notice that Red Hat hasn't joined this initiative, despite us being supportive of it - we have always invested in these projects directly, and think that is actually a healthier model for the future.

Think Strategically

Ok, so that's a bunch of anti-patterns ... what you generally shouldn't do. What should you do? Well, you need to think strategically. You are choosing to have your business depend on something you don't control, but you should not allow yourself to feel powerless about how successful that choice will be.

The Future

Think about the future, the long-term. Given the business choice you are making, for how long will your business success depend on the success of the project? Indefinitely? What are you doing to ensure that success?

One way to think about that would be a worst-case scenario. The unimaginable happens, and the rest of our community disappears. You are left almost completely alone maintaining the project. What you focus on? Obviously, you wouldn't choose to depend on a project where there is a possibility of that happening, but the thought exercise does help you think about your priorities.


If you are determined to ensure the success of the project, you'll have your own view of what that success looks like. Are you happy to hope the community will find a direction that fits your needs, without any input from community leaders that understand the needs of your business?

At Red Hat, we talk about wearing "two hats". Given a particular problem, a particular question of direction, you should have the ability to understand what's good for the project overall and what's good for Red Hat. And crucially, you should have a way to reconcile those two views. This is not a zero sum game. Almost always, you can find a solution that is good for both the project and Red Hat. Why would Red Hat want a solution that is harmful to the project?


In order to be successful with any technology, you need to have access to expertise that understands the technology. There is no better expertise than the authors or maintainers of the project. These are the people who understand not just how the technology works now, but how it evolved there, and how things are likely to change in the future. They understand the pitfalls, the know the cool new tricks.

You can have access to that expertise by having those experts join your team. They stop being experts pretty quickly if they stop having time to work on the project, so their upstream responsibilities should continue to be a significant proportion of their time. But you'd be amazed at how their presence on the team can help the whole team be successful.

Red Hat's Model

As somewhat of an aside, since this presentation is not a sales pitch, think about Red Hat's business model, and our proposition to our customers. Certainly part of the model is that, through our product subscriptions, the customer is investing in the projects involved and, by proxy, is safeguarding the future of the project, gaining a level of influence in the project, and has access to expertise relating to the project.

A Measurable Goal

Recently, on Red Hat's OpenStack team, and thanks to the influence of Alexis Monville, we've been using the "Objectives and Key Results" framework for using well-defined, measurable goals to guide our teams. We started brainstorming on these OKRs almost a year ago, and from those early discussions, I wondered “how do we frame an measurable goal around our investment in upstream?”. What indicator could we use to know whether we were on the right track, and to ensure we’d stay on the right track?

Our Vision

Our first thoughts on this was to look at data like our position in the contributor statistics, or the number of core contributors, PTLs, or TC members on our team. None of this sat well with us, though, because we have seen that these type of goals don’t drive the right behaviors. When we started drafting a vision statement for each goal, I wrote:

“Teams of engineers with the required motivation, an understanding of Red Hat's vision, and empowered with the necessary time, encouragement, and recognition, working upstream to drive and influence many diverse parts of OpenStack.”

And there it sat for a while, us all lacking ideas on how to measure this. Quite recently, Russell Bryant and Doug Hellmann hit on a promising solution. Survey the team with a small set of questions and use that sentiment of our measure of success with this goal.

The Questions

The questions that Russell and Doug developed are:

  1. Does your team have effective input into the features accepted and design decisions made upstream?
  2. Does your team have effective input into bug fixes and backports made upstream?
  3. Does your team have effective input into discussions related to processes, schedules, requirements, infrastructure management, and other decisions made by the upstream OpenStack community in general?
  4. What level of investment does your team make in upstream work?

The allowed answers are “not enough”, “just right”, “too much”, and “don’t know”. We also had a free-form comments section which is helping us gain insight into the results.

Notice one important aspect of this - we are asking individuals about the effectiveness of the investment their team is making upstream. That reflects the vision above.

The Results

We only recently started running this survey, and we will do one every release cycle. So far, we’ve had over 70 responses, so that’s a pretty good start.

Level of Invesment

The really interesting judgment call we need to make is what percentage of “just right” answers do we want to aim for? It would seem misguided to aim for 100% - do we really think that it’s important that every individual feels we’re striking the right balance? We’ve arbitrarily chosen 80% as our target, which means we feel pretty good about where we’re at, but there’s still opportunities for improvement.


One thing I’m loving about my job these days is the direct exposure I have to Red Hat customers who are choosing to invest in OpenStack. Deciding to build a significant cloud for production use is a huge decision, and no-one takes it lightly. It’s exciting, and companies doing this can look forward to a true transformation in how they think about IT resources. The truly daunting part is the sense of responsibility that comes with it.

These are long-term choices being made, and they’re being made because people believe in the future of this project. Red Hat takes the responsibility seriously by making choices that we hope will ensure the project has a long, sustainable future.

November 17th OpenStack Foundation Board Meeting

I had previously posted summaries of most board meetings, but had stopped doing this when I was appointed as Red Hat's representative on the board. Lately, I've sensed folks at Red Hat becoming more interested in the workings of the Foundation, so I figured it might be useful to start doing this again.

The OpenStack Foundation Board of Directors met for a two hour conference call last week. The usual disclaimer applies - this my informal recollection of the meeting. It’s not an official record.

Gold Member Applications

The first half of the meeting was given over to an Executive Session, after which the board voted to approve China Telecom, Inspur, and ZTE as Gold Members of the Foundation.

This completes the handling of the 7 Gold Member applications that were presented to the board at the October 24 meeting in Barcelona. 99Cloud, China Mobile, City Networks, and Deutsche Telecom were approved at that meeting.

For the first time, the Foundation now has reached the maximum of 24 Gold Members. We will only be able to consider applications for new Gold Members if an existing member departs, or if we go through a difficult process to change the limit in our bylaws.

User Committee Proposal

Next up, Edgar Magana updated the board on some proposed changes to the User Committee that was first discussed at the October meeting.

Currently the bylaws describe the User Committee is an "advisory committee" of three members appointed by the Board and TC, which prepares regular reports for the Board and TC. The idea with this proposal is to make the User Committee a parallel entity to the TC, with its members chosen through an election of Active User Contributors (AUC).

The bylaws changes outline how the User Committee has at least five members, that elections of Active User Contributors (AUCs) are held every six months, an affiliation limit for members of the UC, how AUC status is determined, and more.

The hope is that feedback will be collected as comments in the proposal document and that the Board will vote on the proposal during our December 6 meeting. A vote of the Board is sufficient to enact the changes.

One point of discussion was whether bylaws changes are necessary at all. The hope when the bylaws were originally drafted was that the User Committee would have plenty of lattitude to evolve via changes to the UC charter. Edgar made the point that the key change is for the UC to become a parallel entity to the TC rather than an advisory committee to the Board and TC.

"Futures" Discussion

Next, Toby Ford gave a presentation on a topic he had proposed along with Imad Sousou, Allison Randal, and Mark Baker. Toby introduced the topic by saying that as any project evolves and matures, it is important to reflect on competitive threats and the need to evolve the project.

Toby talked about a wide set of competitive threats to OpenStack from the container ecosystem (including Kubernetes and Mesos), to other storage implementations, to various projects in the Telco world (OpenVIM, E2, 3GPPP), and the obvious challenge of AWS, Azure, and Google with AWS revenue over $10B.

Toby moved on to talk about "the good and the bad of the Big Tent", describing the need for a balance between diversity and innovation versus consolidation and refactoring. Toby made the case that we're seeing a lot of expansion in the Big Tent, but not consolidation and refactoring. He expressed particular concern about how and whether core projects will be able to evolve, especially if the Big Tent does not allow for competitors to existing projects.

Toby then put on his "AT&T hat" and talked about the challenges for OpenStack from an AT&T perspective - the need to get to a control plane that scales to 10k servers, the problem of managing over 100 different production sites, the challenge of more and more happening "at the edge" with 5G, innovation happening in the networking space and how it relates to OpenStack, and the unsolved problem of keeping a production environment current with latest OpenStack releases.

To wrap up his presentation, Toby listed a few "possible recommendations" the Board could make to the technical community - (1) allow core projects to have competition within the Big Tent, (2) a mechanism to incubate new approaches, and (3) a mechanism to reationalize, clean up, or refactor.

What followed was a pretty lively discussion that covered much ground, over and beyond the concerns raised by Toby. While the success of OpenStack in bringing together such a diverse set of interests was acknowledged, there was a definite frustration that some form of necessary change is failing to emerge naturally, and whether it falls on the Board to try to at least try to clearly articulate the problem at a strategic level.

Jonathan tried to focus the conversation by giving his perspective that the Big Tent concerns had tied down until "recent comments in the media", and that is probably a distraction from the concerns people are expressing about core projects like Nova and Neutron. He was at pains to say that this isn't about project teams doing bad work - we continue to make huge progress in each release, and valuable work is being done. However, we're definitely seeing frustration from some quarters that it is difficult to influence the community with their ideas.

Jonathan warned that talking too much in the abstract creates the risk that the discussion will go around in circles. Despite this, the discussion never did go into any particular detail on where we've witnessed the problems we were discussing. From my own perspective, it was clear that much of frustration was as a result of how the Ciao and Gluon projects have been received, but we're failing to learn anything significant from those experiences by not talking about them in detail.

By the end of the discussion, we had agree to collaborate on a concrete description of specific problem areas, the questions they raise, and some possible solutions. The hope is that we would complete this before our December meeting, and we may then plan a longer meeting (possibly face-to-face, possibly with the TC) to dig into this.