Open Stack

As promised last year, I will not be running for a third term as a 
member of the Technical Committee. I'm stepping down to spend more time 
with my family (no, really! ;)

I thought this would be a good opportunity to talk to those folks who 
are thinking of running for a seat, or who aren't but should be. The 
most common question I hear from potential candidates is "what should I 
actually do on the TC?" I can't tell you what *you* should do, but I can 
tell you what I did and how that worked out. Maybe that will give you 
the flavour. And perhaps (he hinted) some of the other outgoing TC 
members can do the same to provide more of a cross-section.

* I drafted and edited the review guide, "How to Review Changes the 
OpenStack Way", to try to ensure that the best parts of our review 
culture are evenly distributed across the project: 
https://docs.openstack.org/project-team-guide/review-the-openstack-way.html 
(This started as part of an initiative from Julia Kreger to reduce 
nitpicking in reviews.)

In theory anybody could have done this, but in practice I think this is 
one of those things that only somebody elected to the TC could have 
driven. I received a lot of feedback afterwards (which is unusual for 
anything the TC does): several people, and one whole team, mentioned 
that they had tweaked their reviewing style after this discussion. And 
hearing their feedback prompted me to tweak my own reviewing style as well.

* I drafted and edited the Vision for OpenStack Clouds: 
https://governance.openstack.org/tc/reference/technical-vision.html. 
This was a ton of work as it involved consulting with so many people: 
first, folks in the community who on the surface appeared to have quite 
different visions for what OpenStack should be, who later turned out to 
not be so far apart as we all thought. After a lengthy round of reviews, 
I approached every project team individually to explain the specific 
relevance to them, and seek their feedback. Finally, I presented it to 
the OSF Board and held an in-person feedback session at the Forum, after 
all of which it was approved by the TC.

I have some mixed feelings about the success of this. I still believe it 
was desperately needed... in about 2013. Now the Kubernetes community is 
succeeding at engaging with actual end users (not just operators), which 
OpenStack has always failed to do. With contributions to OpenStack 
dropping, it's not clear that we can, or necessarily should, sustain 
such a broad vision. It is my hope that if and when the community needs 
to discuss adjusting our scope, we will do so by amending this document 
- going through it section by section and deciding which parts to double 
down on and which to allow to fall by the wayside - and not by a series 
of ad-hoc actions that leave everybody confused as to what the project 
is supposed to be once again. On a personal level, the vision has been 
extremely valuable for me because it required me to spend a lot of time 
thinking deeply about the various components of OpenStack and how they 
fit into a greater purpose. A large portion of the value comes from 
participating in the process, not necessarily the final document. I hope 
that all of the folks who helped along the way got as much out of it as 
I did.

* I developed the process by which we keep OpenStack up to date with new 
releases of Python: 
https://governance.openstack.org/tc/resolutions/20181024-python-update-process.html

I also shepherded it through the first couple of release cycles, to try 
to entrench it as a standard part of each release. (BTW this task needs 
somebody to take it over.) This mostly involved pointing people back to 
the resolution and inviting them to formally update it every time 
someone tried to bikeshed the details, which happened more than I ever 
believed possible. (To date there have been no changes proposed to the 
resolution.)

* I engaged with the OSF Board to pass on feedback from members in the 
developer community on the process for adding new Open Infrastructure 
projects (e.g. Zuul, StarlingX, Airship, Kata). Sometimes the work of 
the TC is completely invisible! I also tried to convey information the 
other way, publicising information that was otherwise only available by 
attending board meetings. (Most TC members usually attend board 
meetings, including the in-person joint leadership meetings held before 
Summits.)

* In response to feedback from the board, I replaced the "Help Most 
Wanted" list with the "Upstream Investment Opportunities" list, and 
kick-started the rewriting of the existing entries in a format that is 
more targeted at decision-makers: 
https://governance.openstack.org/tc/reference/upstream-investment-opportunities/index.html 
(Huge thanks to Tom Barron, who did even more work to complete the job 
of converting all of the existing entries - proof that you don't need to 
be a TC member to start contributing to governance activities.)

It remains to be seen whether this will have any effect, but this 
content is now being shared in the community newsletter, and the board 
is making moves to use it to actively solicit contributions to the 
community. Previously they felt unable to make use of the Help Most 
Wanted list because it was written with the wrong audience in mind.

* I tweaked the guidelines for the release naming system to better align 
with our actual practice, because they had diverged somewhat. Believe it 
or not, this one issue took up more of the TC's time than any other 
thing that happened in 2019, and I'm very glad that we ended up not 
needing these tweaks because we eventually replaced the process 
wholesale, with one that makes it explicit that the TC is ultimately 
accountable for the release name not causing any international incidents 
or other snafus.

* I researched and documented a design, developed during extensive 
discussions with many members of the technical community, for a new kind 
of simplified cloud built partially using OpenStack components but 
designed to be Kubernetes-native first: Project Teapot 
https://governance.openstack.org/ideas/ideas/teapot/index.html

I do think this is worth building, but if nothing else I really hope 
this helps bring into focus the parts of OpenStack that remain essential 
in a Kubernetes-centric world. In writing this I was very much guided by 
the Vision for OpenStack Clouds as well as the ways in which Kubernetes 
expects to interact with an underlying cloud. I think we need more of 
these kinds of exercises, and while they don't have to be sponsored by 
TC members, I think it helps.


If there's a pattern here it's this: take something that's implicitly 
agreed upon by the community (whether we realise it or not), write it 
down, seek feedback, and make it explicit so that anyone can refer to 
it, rather than leaving it as closely held tribal knowledge.

Of course it goes without saying that I was involved in many more 
discussions and reviews that were led by others. I'll leave it to them 
to talk about those. And it should also go without saying that all of 
the work listed above was greatly improved by the input of the many 
talented folks in our community who contributed.


In my humble opinion OpenStack is the best open source community of its 
size ever created. That's because we believe not just in one 'open' 
(source), but four 
(https://governance.openstack.org/tc/reference/opens.html); because 
we're committed to using open tools to build open software; and because, 
while it's certainly not the case that we can't improve, we have managed 
to do this while avoiding a widespread culture of bullying. To do all of 
this on the scale of OpenStack was, as far as I know, completely without 
precedent. (Perhaps the ASF comes closest, but its projects operate 
independently, unlike OpenStack subprojects.) All of us should be proud 
of this achievement. But it didn't happen by accident: it is the product 
of concerted effort by leaders in our community over the course of a 
decade. It's been a tremendous privilege to work alongside some of those 
folks, both before, during and (hopefully) after my time on the TC. I 
have learned so much from them. Now it is time for others to step up and 
continue to build that legacy, as the project evolves and adapts over 
time. The diversification of the OSF also gives us the opportunity to 
spread our ethos to other projects under the same umbrella, and from 
there to the open source community as a whole.

However, we must remember that having a great community is not enough. 
To remain relevant, we also need to produce software that meets users' 
needs, which change over time. By an accident of fate I have approached 
OpenStack from a different direction than most - I came to OpenStack via 
the Heat project, which means I've always looked at it from an 
outside-in standpoint: users are building cloud applications, how can 
OpenStack provide them with what they need from a cloud through an open 
API? Many others, by necessity, have approached it from the inside-out: 
we have all this hardware, how can we expose its capabilities to users? 
I think it is fair to say that many of these folks and I have found each 
other's views to be mutually incomprehensible over the years. In writing 
up the Teapot design, I have learned a lot more about the other 
perspective. I believe we will need a more people to also grow their 
understanding in the opposite direction to avoid the trap of most 
capital-E "Enterprise" software - designed to check the boxes of those 
who decide what products to buy, but widely hated by all those forced to 
actually use it. Future TCs will have to grapple with this because 
nobody else in the community is really empowered to do so. The 
openstack/ideas repo that JP created is a great place for anybody to 
start documenting ways that we can improve.

For my part, this is not goodbye. However, I have already been splitting 
my time between OpenStack and metal3.io and I expect that the drift in 
the other direction will only accelerate now that I no longer have any 
formal responsibilities here. Please feel free to contact me or ask 
questions if you think I can help.

Stay safe out there, and by "out there" I mean physically isolated in 
your own homes for the next little while.

cheers,
Zane.