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-proce... 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-opportunit... (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.