Personal thoughts on our work together
Antonio Ojea
Hi all,
I wanted to write this because I feel that lately, there have been some misunderstandings and communication problems that are creating frustration. I think it is a good moment to do some introspection, look at the big picture, and make sure SIG Network is a good and productive place for all of us.
Kubernetes is more than 10 years old. People come and go, and we lose a lot of history and knowledge. For new people, it can be confusing. As someone who joined the project several years after it started, I know it would have been impossible for me to navigate this vast project without the help of people I now consider practically family. So, I think a quick reminder of how we work is a good idea. The official docs have more details if you are interested: community and governance.
Steering Committee: This group exists to manage the project's governance and act as a final point of escalation. It's important to know they are there to help when we are really stuck in a debate, not to give orders to SIGs. This can be a point of confusion for people who may map it to their internal company structures.
Special Interest Groups (SIGs): That's us! We are persistent, open groups focused on a specific area of the project. Like Steering, we are not a top-down command structure. We are guided by our charter and we collaborate with other SIGs because networking is an intrinsic part of a distributed system like Kubernetes.
Working Groups (WGs): These are temporary groups to fix problems that often expand across more than one SIG.
Subprojects & Repositories: Within each SIG, we have smaller, focused subprojects, often with their own repos in the kubernetes or kubernetes-sigs GitHub organization. This is where many new ideas happen! You can own a repository if you have a clear plan and scope and you promise to be responsible. This means you report back to the SIG, ask for help with problems, and make sure your project is healthy.
To manage all this work, we have processes like the API review process. I know sometimes these can feel like extra work or bureaucracy. But they are very important to protect the project and our users. They are also a main channel for us to communicate. When you add the api-review label, you are starting a public conversation that helps us find and solve problems together.
This system works because of our community, which is organized via the contributor ladder. It is easy to start contributing. As you do more, you get more responsibility.
This brings me to leaders—SIG leads, subproject leads, repository maintainers, it doesn't matter the title. If you are a leader, you must be an example for others. It is our job to make sure communication is good and that we discuss problems in the open, not let them become bigger.
And this is the hard part of our work: we have to balance keeping Kubernetes stable with adding new things. The standard for adding new features to the core is very high, and new KEPs like 3136-beta-apis-off-by-default and 5241-beta-featuregate-promotion-requirements show this. I know many of us feel the pressure to deliver features quickly to meet deadlines. It's a tough situation, and the careful, collaborative nature of Open Source can sometimes conflict with that. Part of our job is to bridge that gap, by advocating within our organizations for the value of sustainable contribution and helping to find ways to recognize this important work.
At the same time, while we are being careful, we must also avoid getting stuck. Discussions can stall when we look for perfection or focus too narrowly on a single use case instead of the project's broader needs. Finding the best path forward for Kubernetes as a whole sometimes requires us to make difficult trade-offs. This can mean revisiting our own designs or changing our approach, even when it feels disruptive, for the benefit of the entire project.
Our real goal is to find a balance between being safe, making progress, and serving our users. We should remember that Kubernetes does not need to do everything. It is often better to partner and collaborate with all the other great projects in Open Source.
So, let's try to do this together. Let's bring our problems to the meetings, mailing lists and public channels, use our processes for discussion, and try to assume good intentions from each other. SIG Network is very important for Kubernetes, and I know we can continue to do great things.
Thanks,
Antonio Ojea