In a global and virtual community, high-bandwidth face-to-face time is
essential. This is why we made the OpenStack Design Summits an integral
part of our processes from day 0. Those were set at the beginning of each
of our development cycles to help set goals and organize the work for the
upcoming 6 months. At the same time and in the same location, a more
traditional conference was happening, ensuring a lot of interaction between
the upstream (producers) and downstream (consumers) parts of our community.
This setup, however, has a number of issues. For developers first: the
"conference" part of the common event got bigger and bigger and it is
difficult to focus on upstream work (and socially bond with your teammates)
with so much other commitments and distractions. The result is that our
design summits are a lot less productive than they used to be, and we
organize other events ("midcycles") to fill our focus and small-group
socialization needs. The timing of the event (a couple of weeks after the
previous cycle release) is also suboptimal: it is way too late to gather any
sort of requirements and priorities for the already-started new cycle, and
also too late to do any sort of work planning (the cycle work started almost
2 months ago).
But it's not just suboptimal for developers. For contributing companies,
flying all their developers to expensive cities and conference hotels so
that they can attend the Design Summit is pretty costly, and the goals of
the summit location (reaching out to users everywhere) do not necessarily
align with the goals of the Design Summit location (minimize and balance
travel costs for existing contributors). For the companies that build products
and distributions on top of the recent release, the timing of the common event
is not so great either: it is difficult to show off products based on the
recent release only two weeks after it's out. The summit date is also too
early to leverage all the users attending the summit to gather feedback on
the recent release -- not a lot of people would have tried upgrades by
summit time. Finally a common event is also suboptimal for the events
organization : finding venues that can accommodate both events is becoming
Time is ripe for a change. After Tokyo, we at the Foundation have been
considering options on how to evolve our events to solve those issues. This
proposal is the result of this work. There is no perfect solution here (and
this is still work in progress), but we are confident that this strawman
solution solves a lot more problems than it creates, and balances the needs
of the various constituents of our community.
The idea would be to split the events. The first event would be for upstream
technical contributors to OpenStack. It would be held in a simpler, scaled-back
setting that would let all OpenStack project teams meet in separate rooms,
but in a co-located event that would make it easy to have ad-hoc cross-project
discussions. It would happen closer to the centers of mass of contributors,
in less-expensive locations.
More importantly, it would be set to happen a couple of weeks before the
previous cycle release. There is a lot of overlap between cycles. Work on a
cycle starts at the previous cycle feature freeze, while there is still 5
weeks to go. Most people switch full-time to the next cycle by RC1.
Organizing the event just after that time lets us organize the work and
kickstart the new cycle at the best moment. It also allows us to use our time
together to quickly address last-minute release-critical issues if such
The second event would be the main downstream business conference, with
high-end keynotes, marketplace and breakout sessions. It would be organized
two or three months after the release, to give time for all downstream
users to deploy and build products on top of the release. It would be the best
time to gather feedback on the recent release, and also the best time to have
strategic discussions: start gathering requirements for the next cycle,
leveraging the very large cross-section of all our community that attends
To that effect, we'd still hold a number of strategic planning sessions at
the main event to gather feedback, determine requirements and define overall
cross-project themes, but the session format would not require all project
contributors to attend. A subset of contributors who would like to participate
in these sessions can collect and relay feedback to other team members for
implementation (similar to the Ops midcycle). Other contributors will also
want to get more involved in the conference, whether that's giving
presentations or hearing user stories.
The split should ideally reduce the needs to organize separate in-person
mid-cycle events. If some are still needed, the main conference venue and
time could easily be used to provide space for such midcycle events (given
that it would end up happening in the middle of the cycle).
In practice, the split means that we need to stagger the events and cycles.
We have a long time between Barcelona and the Q1 Summit in the US, so the
idea would be to use that long period to insert a smaller cycle (Ocata) with
a release early March, 2017 and have the first specific contributors event
at the start of the P cycle, mid-February, 2017. With the already-planned
events in 2016 and 2017 it is the earliest we can make the transition. We'd
have a last, scaled-down design summit in Barcelona to plan the shorter cycle.
With that setup, we hope that we can restore the productivity and focus of
the face-to-face contributors gathering, reduce the need to have midcycle
events for social bonding and team building, keep the cost of getting all
contributors together once per cycle under control, maintain the feedback
loops with all the constituents of the OpenStack community at the main event,
and better align the timing of each event with the reality of the release
NB: You will note that I did not name the separated event "Design Summit" --
that is because Design will now be split into feedback/requirements
gathering (the why at the main event) and execution planning and
kickstarting (the how at the contributors-oriented event), so that name
doesn't feel right anymore. We can bikeshed on the name for the new event
This was also posted to the openstack-dev ML:
please comment and follow-up there if you have thoughts to share.
We are 5 years into the OpenStack ride (and 3 years into the OpenStack
Foundation ride), and the challenges for our community are evolving.
In this article I want to talk about what I consider the most significant
threat for our open source community today: the loss of our common culture.
Over the past year we evolved the OpenStack project model to adopt an
inclusive approach. Project teams which
work on deliverables that help us achieve the OpenStack Mission, and which
follow our development and community practices should generally be accepted
under the "big tent". As we explained in
this presentation in Vancouver,
we moved from asking "is this OpenStack ?" to asking "are you OpenStack ?".
What does it mean to be OpenStack ? We wrote down a
set of principles,
based on the original four opens
that were defined at the very beginning of this journey. But
"being OpenStack" goes beyond that. It is to be aligned on a common goal,
be part of the same effort, be the same tribe. OpenStack relies on a number
of individuals working cross-project (on infrastructure, QA, documentation,
release processes, interoperability, user experience, API guidelines,
vulnerability management, election organization...). It is because we belong
to the same tribe that some people and organizations care enough about
"OpenStack" as a whole to dedicate time to those essential cross-project
This is why we standardize on logged IRC channels as a communication medium,
why we ask that every project change goes through Gerrit, and why we should
very conservatively add new programming languages to the mix. Some people
advocate letting OpenStack project teams pick whatever language they want,
or letting them meet on that new trendy videoconferencing app, or letting
them track bugs on separate JIRA instances. More freedom sounds good at first
glance, but doing so would further fragment our community into specific silos
that all behave differently. Doing so would make recruiting for those
essential cross-project efforts even harder than it is today, while at the
same time making the work of those cross-project efforts significantly more
complex. Doing so would make our community crumble under its own weight.
We started this journey with a pretty strong common culture. It was mostly
oral tradition. We assumed that as OpenStack grew, our culture would
naturally be assimilated by new members. And it did, for quite some time.
But today we are at a point where we dramatically expanded our community
(we doubled the number of project teams over the last year) and our common
culture did not naturally transmit to newcomers. Silos with local traditions
have formed. Teams don't all behave in the same way anymore. Most team
members only care about a single project team. We struggle to move from one
project to another. We struggle to provide common solutions that work for
everyone. We struggle to recruit for cross-project efforts more than we ever
did. OpenStack's future as a community is at risk. It's time to hold the
culture line, rather than time to further relax it.
It is also more than time that we document our common culture, so that it
can be explicitly communicated to everyone in the OpenStack ecosystem
(current and prospective members). We started a workgroup at the
Technical Committee, held a
virtual sprint to get a
base version written, and now here it is: the first version of the
OpenStack Project team guide.
Read it, refer to it, communicate it to your OpenStack community fellows,
propose changes to it. It is an essential tool for us to overcome this new
challenge. It's certainly not the only tool, and I hope we'll be able to
dedicate a cross-project session at the Mitaka Design Summit in Tokyo to
further discuss this topic.
At OSCON last week, Google announced the creation around Kubernetes of the
Cloud-Native Computing Foundation. The next day, Jim Zemlin dedicated his
keynote to the (recently-renamed) Open Container Initiative, confirming the
Linux Foundation's recent shift towards providing Foundations-as-a-Service.
Foundations ended up being the talk of the show, with some questioning the
need for Foundations for everything, and others discussing the rise of
Foundations as tactical weapons.
Back to the basics
The main goal of open source foundations is to provide a neutral, level and
open collaboration ground around one or several open source projects. That is
what we call the upstream support goal. Projects are initially created by
individuals or companies that own the original trademark and have power to
change the governance model. That creates a tilted playing field: not all
players are equal, and some of them can even change the rules in the middle
of the game. As projects become more popular, that initial parentage becomes
a blocker for other contributors or companies to participate. If your goal is
to maximize adoption, contribution and mindshare, transferring the ownership
of the project and its governance to a more neutral body is the natural next
step. It removes barriers to contribution and truly enables open innovation.
Now, those foundations need basic funding, and a common way to achieve that
is to accept corporate members. That leads to the secondary goal of open source
foundations: serve as a marketing and business development engine for companies
around a common goal. That is what we call the downstream support goal.
Foundations work to build and promote a sane ecosystem around the open source
project, by organizing local and global events or supporting initiatives to
make it more usable: interoperability, training, certification, trademark
Not all Foundations are the same
At this point it's important to see that a foundation is not a label, the
name doesn't come with any guarantee. All those foundations are actually very
different, and you need to read the fine print to understand their goals or
assess exactly how open they are.
On the upstream side, few of them actually let their open source project be
completely run by their individual contributors, with elected leadership
(one contributor = one vote, and anyone may contribute). That form of
governance is the only one that ensures that a project is really open to
individual contributors, and the only one that prevents forks due to
contributors and project owners not having aligned goals. If you restrict
leadership positions to appointed seats by corporate backers, you've created
a closed pay-to-play collaboration, not an open collaboration ground. On the
downstream side, not all of them accept individual members or give
representation to smaller companies, beyond their founding members.
Those details matter.
When we set up the OpenStack Foundation, we worked hard to make sure we
created a solid, independent, open and meritocratic upstream side. That,
in turn, enabled a pretty successful downstream side, set up to be inclusive
of the diversity in our ecosystem.
I see the "Foundation" approach to open source as the only viable solution
past a given size and momentum around a project. It's certainly preferable
to "open but actually owned by one specific party" (which sooner or later
leads to forking). Open source now being the default development model in
the industry, we'll certainly see even more foundations in the future, not
As this approach gets more prevalent, I expect a rise in more tactical
foundations that primarily exist as a trade association to push a specific
vision for the industry. At OSCON during those two presentations around
container-driven foundations, it was actually interesting to notice not the
common points, but the differences. The message was subtly different (pods
vs. containers), and the companies backing them were subtly different too.
I expect differential analysis of Foundations to become a thing.
My hope is that as the "Foundation" model of open source gets ubiquitous,
we make sure that we distinguish those which are primarily built to sustain
the needs or the strategy of a dozen of large corporations, and those which
are primarily built to enable open collaboration around an open source project.
The downstream goal should stay a secondary goal, and new foundations need
to make sure they first get the upstream side right.
In conclusion, we should certainly welcome more Foundations being created to
sustain more successful open source projects in the future. But we also need
to pause and read the fine print: assess how open they are, discover who ends
up owning their upstream open source project, and determine their primary
reason for existing.
Yesterday we reached the liberty-1 development milestone. You may have noticed
from the announcement
that the various components released were all using new, different version
numbers. What's going on here ?
Once upon a time
Since the beginning of OpenStack we've been using two versioning schemes.
One was for projects released once every 6 months and following a schedule
of development milestones and release candidates. Those would be using
a YEAR.N version number (like 2015.1 for Kilo).
Another was used by Swift, which was already mature when OpenStack started,
and which released intermediary versions as-needed throughout the cycle. It
would use a X.Y.Z version number which looked a lot more like semantic
At the end of the cycle, we would coordinate a final release that would
combine both. For example the "Kilo" release would be made of Nova 2015.1.0,
Swift 2.3.0, and everything else at 2015.1.0.
A few things happened over the last two cycles. First, we released more and
more libraries, and those would follow a strict X.Y.Z semantic versioning.
Those would also have an final release in the cycle, from which a stable
branch would be maintained for critical bugfixes and vulnerability fixes. So
the portion of commonly-versioned YEAR.N deliverables was fast decreasing.
Second, some projects got more mature and/or more able to release
fully-functional intermediary releases as-needed. As a community, we still
can't support more than one stable branch every 6 months, so those intermediary
releases won't get backports, but past a given maturity step, it's still a
great thing to push new features to bleeding-edge users as early and often as
we can. For those a YEAR.N synchronized versioning scheme would not work.
The versioning conundrum
At that stage we had three options to handle those projects switching from
one model to another. They could keep their 2015.2.0 version and start doing
semantic versioning from that -- but that would be highly confusing, when you
end up releasing 2017.9.4 sometimes in 2016. The second option was to reset
the version for projects as they switch. So Ironic would adopt, say, 3.0.0
while all other projects still use 2015.2.0.
The third option was to bite the bullet and drop the YEAR.N versioning at the
same time, for all the projects that were still using it. Switching
them all to some arbitrary number (say, 12.0.0 since that would be the 12th
OpenStack release) would create confusion as projects switching to
intermediary releases would slowly drift from the pack (most projects
publishing 13.0.0 while some would be at 12.5.2 and others at 13.1.0).
So to avoid that confusion, projects would pick purposefully distinct version
numbers based on their age.
After discussions at the Vancouver Design Summit and on the mailing-list,
we opted for the third option, with an initial number calculated from the
number of past integrated releases already published.
It's a clean cut which will reduce on-going disruption. All components end
up with a different, meaningful version number: there are no longer "normal"
and "outliers" projects. Additionally, it solves the weird impression we had
when we released 2014.2.2 stable versions sometimes in 2015.
As far as impact is concerned, distributions will need to make sure to insert
an epoch so that package versions sort correctly in their package management
systems. If your internal CI pipeline relies on sorting version numbers, it
will likely need an adjustment too. For everyone else, it should not have an
impact: when Liberty is out, you will upgrade to the liberty version of the
components, as you always did.
Liberty-1 and the future
The change in versions was pushed last week, and that is why for liberty-1 we
published 220.127.116.11b1 for Nova, 18.104.22.168b1 for Keystone, and 22.214.171.124b1 for
Designate, etc... Those are still on a milestone-based 6-month release cycle,
but their "Liberty" final version won't be all versioned "2015.2.0", but 12.0.0
for Nova, 8.0.0 for Keystone, etc.
To reduce the confusion, the release management team will provide tooling and
web pages to describe what each series means in terms of component version
numbers (and the other way around).
We hope this future-proof change will bring some more freedom for OpenStack
project teams to pick the release model that is the most interesting for them
and their user base. For a cycle named "liberty", that sounded like a pretty
good time to do it.
The election process to renew half of the OpenStack Technical Committee will
start tomorrow with candidates self-nominating to run for election. As the
chair of the existing Technical Committee (and running for reelection) I would
like to share some thoughts on what would make in my opinion good TC members
for the upcoming cycle.
A few words on the OpenStack Technical Committee role first. The role of the
TC is to lead the "OpenStack" software development in general. Each individual
project is lead by its project team and its PTL, but the TC leads "OpenStack"
development. That includes defining the limits of what is considered "an
OpenStack project": during the Kilo cycle we introduced new rules to handle
that question, mostly based on alignment with the OpenStack Mission and
determining if the new project team shares the common values OpenStack has been
built on, behaves like an OpenStack project and therefore should be considered
part of the OpenStack community. The role of the TC also includes providing
guidance and advice to OpenStack projects, as well as driving horizontal
efforts and solving cross-project issues.
The Technical Committee also serves as an ultimate appeals board to solve
conflicts in our open source community. Its members are elected by all the
OpenStack contributors and are trusted to make the right call should an issue
escalate to them.
With all this said, what makes a good Technical Committee member ? I'd say
the first attribute of a good candidate is how skilled they are and how
respected their opinion is on the above topics. Do you trust them to make the
right call as to what should be considered part of the OpenStack community ?
Do you trust them to place "OpenStack" interest above specific projects (or
specific companies) interest ? Do you trust their open source community
experience to make the right judgment call in case issues are escalated ?
The other attribute is, I think, equally important. It's how much time you can
specifically dedicate to the task of being a TC member. Being a good TC member
takes a lot of time. It's not an honorific position where you happen to sit
in a meeting one hour per week and decide the fate of OpenStack. It's about
diving into proposals, look into new projects, drive cross-project initiatives,
identify long-standing issues in our community and raise them. I spend about
40% of my work time working on TC stuff, and I wish I could spend more.
Let's be clear: I don't think that all TC members in the past had enough time
to dedicate to Technical Committee work. They were all community leaders,
skilled and trustworthy. But a lot of them had other fulltime responsibilities
too, like being the PTL of a large OpenStack project, or being a manager in
a major company or startup. In the end that meant the past TC members were
not as active on cross-project matters as they could have been.
In liberty I'd like the Technical Committee to identify and propose plans
to address long-standing issues in OpenStack in general. I'd like individual
members to dive into specific projects and provide an audit of their current
health. I'd like us to make things better, rather than limit ourselves to
codifying governance. I'd like us to
step out of the way,
and start being more useful. That takes a lot of time.
So as self-nomination period opens, I would like to encourage new people to
run for election. I'd like candidates to explain why they are fit for the job,
and why they think they will have a lot of time for it. And I'd like voters to
take that availability into account when they decide who to vote for.