Open Stack

Zane,
I was lucky enough to join the OpenStack community when you're doing all of
the things listed above. You've done an amazing job. Thank you.

On Sat, Mar 28, 2020 at 6:42 AM Zane Bitter <zbitter at redhat.com> 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.
>
>
>

-- 
*Trinh Nguyen*
*www.edlab.xyz <https://www.edlab.xyz>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200330/9d09a400/attachment-0001.html>