TL;DR: Working on building open governance that is both inclusive and able to make hard decisions.
Three weeks ago, Kubernetes leaders met for a very busy day to reflect and plan how the community was being growing. I was humbled to be part of the Kubernetes Leadership Summit due to my work as the Cluster Ops SIG co-chair. Please join us every other Thursday at 1 PT to share stories about running or planning to run Kubernetes.
This event had to thread a delicate balance for an open project: we needed to limit attendance to focus discussions while ensuring that the community was represented. Our notes (captured in Google Docs) are being transcribed to markdown here.
Here are some key topics that shaped the day from my perspective:
- A consensus that core needed to focus on paying down debt and getting smaller. The core project is seen as a bottleneck to growth. The comes from number of people trying to interact in the repo and from having too much technical debt, As a group, we agreed that paying this debt was very important; however, we did not define or authorize specific action to address it. I felt that just acknowledging this focus by a show of hands was a positive action.
- Moving forward on formation of a Steering Committee. The bootstrapping committee reviewed their Steering Committee proposal. The concepts here are to design a governing body that intentionally delegates their authority. I think it’s an interesting approach that will help to empower more people in the project. This design is different than a corporate board that’s focused on supervision. Here’s the draft document we reviewed as input into the next phase proposal.
- Continue using SIGs to divide work. A consequence of the governance design is that we are (ab)using special interest groups (SIG) to organize the coding and feature work for Kubernetes. They also carry the load for releases, product management and operations. The push from the meeting was to have all SIGs with specific deliverables. I think that works well for some SIGs, but more user/operator focused groups (like Cluster Ops) will feel that it’s harder to find the right engagement models.
Overall, the event was very positive with lively group discussions. This group is focused on building Kubernetes, so there was very little vendor, marketing, user or operator focus. As the project grows, I believe these other focus areas will be important to manage. Likely, those concerns cannot be addressed until the Steering Committee is formed.
RackN is committed to helping make Kubernetes operable and improve the operator experience. I’m interested in hearing about your remote or local impressions of this event. What items should have gotten more discussion? What is the project missing?
