The OpenStack Foundation Board of Directors met in-person for two
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
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
and the User
State of the Union
Next, Mark Collier presented his view of the state of
with a particular emphasis on the four areas planned for discussion
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
talked about how this will play a key role in helping people
understand what OpenStack provides and how it can be used.
Mark talked briefly about the working groups under the User
and the transition from Design Summit to Project Team
Forum formats. These concepts
are all important in understanding how OpenStack thinks about our
requirements gathering, strategic long-term planning, and
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
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
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
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
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
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
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
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
Over lunch, everyone wrote their concrete, actionable ideas for
improvement on sticky notes and put them on flipcharts for each of the
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
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
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
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
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
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
The OpenStack Foundation Board of
met for a two hour conference call on
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
The 2017 Board
This was the first meeting of the board since the recent Individual
and Gold member director
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:
- Antitrust policy
- Code of Conduct
- Transparency policy
- 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
Finally, we reviewed the board meeting schedule for the year,
including 6 conference calls and 4 in-person meetings.
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
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 Interop Working Group also talked through their January 2017
and the board voted to approve the 2017.01
Finally, the board spent some time discussing the strategic planning
discussions that started at the November
and continued during the December
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.
The OpenStack Foundation Board of
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
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
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
User Committee Proposal
Next up, Edgar Magana presented some proposed by-laws changes around
the structure of the User
and related changes to the UC
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.
The board then turned its attention to a discussion started at the
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
- OpenStack and its evolving relationship with adjacent
- Unanswered requirements, and how they will be address by the
project over time.
- Whether OpenStack is sufficiently able to evolve architecturally
architecture to meet certain needs.
- 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
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
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
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.
This is the prose version of a talk I gave today at OpenStack Day,
France. The slides are available
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 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.
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
Focus on Features
First, features. Or, as Thierry Carrez puts it, “tactical
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.
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”?
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!
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”
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
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
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.
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.
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
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
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
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
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 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,
“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 that Russell and Doug developed are:
- Does your team have effective input into the features accepted and design decisions made upstream?
- Does your team have effective input into bug fixes and backports made upstream?
- 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?
- 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.
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
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
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.
I had previously posted summaries of most board
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
met for a two hour conference call last week. The usual disclaimer
applies - this my informal recollection of the meeting. It’s not an
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
of the Foundation.
This completes the handling of the 7 Gold Member applications that
were presented to the board at the October 24
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
User Committee Proposal
Next up, Edgar Magana updated the board on some proposed changes to
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
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
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
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
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
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
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
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
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