The OpenStack Foundation Board of Directors met in-person for two
in Boston last week.
The first day was a strategic planning
and the second day was a regular board meeting.
Executive Director Update
After a roll call and approving the minutes of the previous meeting,
Jonathan gave a presentation outlining his perspective on where
He talked about perception challenges that the Foundation is working
to address, emphasizing the messages of "costs less, does more" and
"all apps need Open Infrastructure".
He described how the Foundation has been iterating on a "pitch deck"
and had completed twenty or so interviews with journalists where they
presented this deck in a concerted effort to "change the
narrative". This begins by talking about some recent industry trends,
including a slowdown in the rate of public cloud growth and the
coverage of Snap's significant spending on public cloud services
compared to their revenues.
It goes on to compare "Gen 1" and "Gen 2" private clouds, with the
challenges moving from technology and people to culture and
processes. The advantage of a multi-cloud strategy, with sophisticated
workload placement was discussed as well as some detailed information
backing up the claim that companies are achieving cost savings with
Jonathan described how this presentation had been very well received,
and had resulted in some very positive
Jonathan briefly touched on key improvements in Ocata and information
about the profile of our contributors. This resulted in some debate
about the value of "vanity metrics" and there was general agreement
that while there continues to be demand for this information, we we
should all be cautious in over-emphasizing it.
Finally, Jonathan reflected on feedback from the Project Team
Gathering in Atlanta. Attendance was strong and attendees reported
feeling less distractions and a greater ability to have important
discussions because of the smaller venue and attendee count. While it
was mostly seen as a great success, there are areas for improvement
including the approach to choosing hotels and committing to hotel room
bookings, how scheduling is organized, the size of some rooms,
etc. Jonathan mentioned the success of the Forum and the OpenStack
Summit in Boston will be key.
User Committee and Compensation Committee
The board spent a fairly short time discussing two matters from its
Firstly, a proposal from the User Committee Product Working Group for
facilitating the organization of the schedule for The Forum in Boston
was well received, but since the board encouraged all interested
parties to work with the Foundation staff who are coordinating the
planning, particularly Tom Fifield and Thierry Carrez.
Secondly, the board approved Jonathan's goals for 2017, which had been
prepared by the Compensation Committee and sent to board members
earlier for review. The board only sets Jonathan's goals, and empower
him to set the goals for the rest of the staff. Related to Jonathan's
goals, the board also had some discussion later around documenting the
goals of the board itself.
Significant time during the day was given over to considering some
corporate membership applications.
With HPE resigning its Platinum membership, we had invited
applications to take over its slot and received applications from
Ericsson and Huawei. Both companies had previously applied in
November, 2014 at the OpenStack Summit in Paris to replace Nebula as
Platinum member, but Intel had been successful that time.
Anni Lai presented for Huawei and Chris
Price presented for Ericsson. Both
described their employer's vision for OpenStack, and their wide range
of contributions to date. Both also talked about their position in the
market, their key customers, and how they are growing the OpenStack
ecosystem. The presentations were well received and, after an
executive session, the board voted to approve Huawei as a Platinum
member. The board expressed their gratitude for Ericsson's interest
and preparation, observing that having multiple companies interested
in Platinum membership opportunities is a sign of the strength of our
Representatives from H3C also presented
their application for Gold membership. H3C is a prominent IT vendor in
China's enterprise IT market, distributes an OpenStack based cloud
product, has several very large reference customers, and is
establishing itself as a technical contributor to the project. After
executive session, the board voted to approve H3C as a Gold member.
One piece of good news wasn't public during the meeting, but has since
been announced by
The Board also approved the promotion of Thierry Carrez to VP of
Engineering for the OpenStack Foundation. Thierry has been a leader
in the technical community since the beginning of OpenStack and has
also built a team within the Foundation focused on upstream
I think it's safe to say the board were warmly supportive of this
change, wished Thierry every success in this new role, and looked
forward to working more closely with Thierry than ever before.
And, with that, the board dispersed feeling pretty fried after an
intense couple of days of discussions!
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.