Open Stack

Zane,

Thanks for this great note and for all you have done as part of the TC!

Jay

On 3/27/2020 4:38 PM, Zane Bitter wrote:
> 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.
>
>