Each month, Intel VP and GM for Open Ecosystem Arun Gupta holds a live Twitter Spaces conversation with changemakers in the open source community. Follow him on Twitter to tune into the next conversation.
In this month’s conversation, Gupta talks cloud native with Christoph Blecker. Blecker, a Senior Principal Site Reliability Engineer at Red Hat*, and Governing Board Member at the Cloud Native Computing Foundation* (CNCF). He’s been involved with Kubernetes* and cloud native since 2016, and covered roles including technical lead of the contributor experience special Interest group and on the Kubernetes Steering Committee.
They discuss how to get started, how the CNCF works and why employers should consider open source community work on-the-clock time. This conversation has been edited and condensed for brevity and clarity.
Kubernetes: A Tour
Arun Gupta: You’re deeply involved in Kubernetes, can you take a step back and tell us how the project is organized?
Christoph Blecker: The Kubernetes project is quite large and organized into special interest groups (SIGS) that handle various aspects of the project. Some SIGS handle verticals within the Kubernetes code-based ecosystem, while others handle horizontal topics that cut across the entire project and ecosystem. The contributor experience SIG is responsible for tooling, documentation, and general experiences of contributors involved in the project. This includes policies, workflows, and automation of tedious processes. Additionally, the Steering Committee oversees the entire project and makes cross-project decisions around governance and organization. The steering committee is elected from the maintainers within the community and does not make technical decisions but delegates those out to the relevant SIGS.
Arun Gupta: Let's clarify what you just said. You mentioned some useful terms like SIGs, which can either be cross-cutting or vertical. You also talked about a steering committee that can triage where certain issues should be addressed. You also mentioned contributors and maintainers -- what’s the difference between the two roles?
Christoph Blecker: A contributor is anyone who actively participates and contributes to the project in various ways. While code contributions are the most common, there are people who open pull requests, fix bugs, and create new features. There are also other essential tasks to be done, such as documentation, infrastructure management, testing, and release processes. These tasks all require someone to work on them, and anyone who works on them is considered a contributor. We have lots of tooling and automation to help, but whether it's actually contributing code or standing up infrastructure so that people can meet and talk with each other and take notes and everything that supports collaboration, this umbrella of contribution extends beyond coding and encompasses all the tasks necessary to deliver a software project like Kubernetes.
Arun Gupta: It's important to recognize all the non-glorious work that happens alongside coding contributions. Zoom helps with discussions, but managing accounts, ensuring payments and credentials are valid, reviewing PRs and conference talks, and maintaining project sustainability are all necessary tasks. This non-glorious work is often referred to as...?
Christoph Blecker: Chop wood, carry water.
Arun Gupta: There you go: Chop wood and carry water. There's a Zen proverb which says before enlightenment, chop wood, carry water. After enlightenment, chop wood carry water – all the tasks are so essential for sustaining the project.
Now, you mentioned that you’re the Kubernetes Rep on the governing board. Can you tell us more about this governing board and your role?
Christoph Blecker: The CNCF has various bodies, including a governing Board that primarily oversees the foundation's activities. This group approves and vets the different projects and initiatives that the foundation works on, ensuring that they’re successful over a long period of time. The foundation's main role is to support projects under the cloud, including Kubernetes, providing the resources and support they need. The governing board, which includes various member companies and positions, works together to make sure that the foundation is working on the right initiatives and provides healthy oversight. As the founding project of the CNCF, Kubernetes has a historical seat on the governing board to ensure that the project's needs and those of its maintainers are heard and addressed at every level. Overall, the CNCF aims to make sure all projects receive the support they need to succeed.
Arun Gupta: If people want to raise something to the governing board level, how does that process work?
Christoph Blecker: There are different ways to bring concerns or feedback to the governing board, depending on the specific topic. As a member of the steering committee in the Kubernetes community, I have individual conversations with people to collect feedback on what's working and what’s not working. I can provide that feedback to the foundation so it can make more kind rapid pivots based on community input. If an issue is big enough to be brought to the full board, then I can bring that technical perspective to the various members on the board and speak to those concerns.
The governing board doesn’t dictate technical policy, but ensures that resources provided to projects, such as financial, marketing, and consulting, are allocated properly to support the projects as needed.
Arun Gupta: Maybe I'm biased because I've been involved with CNCF for a while, but the organization really extends the transparency element in open source by providing access to anyone to raise their issues, even up to the governing board level.
Can you tell us more about the lifecycle for CNCF projects?
Christoph Blecker: Depending on where a project is in its development cycle, it may require more or less assistance from the CNCF. Projects are categorized into different stages of maturity: There's a sandbox level, an incubating level, or a graduated level like Kubernetes. Resource requirements vary between projects, even within the same level of maturity. For example, a project like Kubernetes may not require as much marketing support as a newer, less established project that needs more help building its brand and educating people on its value. To make sure projects get the support they need, it's important for the contributor base to have a level of openness and the ability to ask for what they need, and for the foundation to be ready to respond in a timely manner.
Arun Gupta: While Kubernetes is one of the most well-known projects of the CNCF, there are actually around 160 projects across three different categories.
How technical are decisions made for Kubernetes? Is there an equivalent to the CNCF governing board for making these decisions?
Christoph Blecker: The decision-making processes in the Kubernetes aren’t handled by the top-level body – they're not the right people for making technical decisions. Instead, the steering committee provides guidance, oversight, and governance...In the CNCF, the technical decisions that are regularly made include which projects are fit for the CNCF and how to move projects between various levels of maturity. The Technical Oversight Committee (TOC) is responsible for handling these decisions. They work with the community to ensure that the cloud native ecosystem remains healthy and can adapt to support new areas. The TOC is an essential body that ensures that projects in the CNCF adhere to best practices in governance and technology to meet the needs of the community.
How to get started
Arun Gupta: What do you recommend for a newcomer, starting with cloud native in general?
Christoph Blecker: I love talking to students who are coming up in this space. My advice to them is to pick a specific focus area, whether it’s a school project, part of a day job, or something that interests them. The cloud native ecosystem is vast, and hard to get a grasp on all at once.
For instance, if a beginner wants to contribute to Kubernetes, I suggest they pick a SIG that aligns with their interests and attend the meetings. These meetings are public and recorded, so they can listen to past discussions no matter what time zone they’re in. This helps them understand if it's a subject area they want to pursue, who the key players are, and the problems they're facing. Once they have an idea of the key figures and the project's details, they can talk to these people or join the relevant Slack channels, those are great too.
Don’t be afraid to ask questions! People will either have answers or not, and if not, they’re friendly and will tell you where to look. It’s best to begin slow with smaller topics rather than attempting to get your head around everything all at once.
For example, if you want to join a specific project, like Kubernetes, there are over 30 different SIGs, on a range of topics. Each SIG needs consistent contributors and looks for people who show commitment rather than those who attend a couple of meetings or take on an issue in the repo and never come back. By choosing a smaller topic, asking questions, and displaying dedication by showing up consistently, even if it’s only for an hour a week, is more beneficial to the community than eight hours of contributions every two months.
Why non-code contributions matter
Arun Gupta: Fantastic -- you’re giving people the right to be a lurker. Just listen in. See what it’s like, what piques your interest? Talk to people on Slack, ask questions, and then show up consistently. You’ll be a maintainer one day, and I love that. To sum up: Consistency is the key. Just keep going and be persistent and resilient.
Christoph Blecker: In the industry, there tends to be a lot of emphasis on the code, software, and product. However, when it comes to open source specifically, I believe it's more about the people and relationships. Building credibility in this space isn't just about having the most optimized code, but rather about showing up, being consistent, and doing the necessary work to contribute to the success of the project. It's about working collaboratively and building respect and a good reputation within the community. Technical expertise is important, but consistency and reliability in interpersonal relationships are even more so. My background prior to getting involved in the project was not software development or software engineering, I come from an operations background. I spent a decade as a network engineer. Basically, I followed the advice I gave earlier: I showed up. I was friendly. I was consistent. I was reliable when folks needed something, I was able to show up and give a certain number of hours consistently. That's all it takes to grow in this community and find your place in the Kubernetes and cloud native ecosystem.
Arun Gupta: Beautiful advice. Open source is more about people, less about code.
How do you adapt to the new situation? How do you work in a multicultural Kubernetes? Is such a wide project and all CNCF projects for? That's like, you know, they have such a wide diversity inclusion element. How do you thrive in that environment?
Christoph Blecker: One thing that’s always been really important to me in the Kubernetes project and in the CNCF ecosystem is that we are welcoming and open to people from all different backgrounds. It doesn't matter where you live. Or who you are, if you have time and drive to contribute. The only requirements for contributing are a willingness to dedicate time and effort towards achieving a shared objective while collaborating with members from all corners of the globe. It’s crucial that anyone who wants to participate feels that they are part of a safe, inclusive environment where growth and development are encouraged, regardless of their skill level or the nature of their contributions.
A Day in The Life of a Kubernetes Maintainer
Christoph Blecker: It's all over the place to be quite honest. I have a day job and responsibilities at Red Hat, where I work on managing our OpenShift* offerings, which is a distribution of Kubernetes. Although my day job involves coordinating services and making similar decisions to those in the open source community, there isn't much crossover between the two. But luckily, my job allows me some on-the-clock time to work on open source projects and at the CNCF level.
For the Kubernetes project, I’m currently on my second term on the Steering Committee, which ends in October 2023. My tasks involve assembling and reviewing annual reports and attending several hours of meetings each week at various levels of the organization. I’m also part of the Code of Conduct Working Group at the CNCF level, where I spend about an hour or two each week reviewing feedback and proposals.
My day is never the same and involves various tasks and responsibilities throughout the week.
Why Employers Should Pay for Open Source Community Work
Arun Gupta: What’s in it for Red Hat to give you on-the-clock time to contribute to open source projects?
Christoph Blecker: I’m a very strong advocate of on-the-clock time. When I first became involved with Kubernetes, I was at a company that was adopting the platform during the early stages of development. As we came across bugs and issues, I began to spend my personal time contributing to the community by examining the code and providing fixes.
However, as I became more involved in the project, I realized that relying solely on personal time was not sustainable. While contributing on a personal level can be manageable for small-scale efforts, it quickly becomes challenging to maintain for more extensive projects. Moreover, the success of projects like Kubernetes is crucial for companies that rely on them, including vendors, end-users, cloud providers, and value-added services like storage.
At Red Hat, we sell and support a distribution of Kubernetes, making it even more critical for us to support the project's overall health and progress. This support extends not only to developers contributing code or documentation but also to those involved in governance and administration. Doing so supports the growth and health of the project and enables companies to build innovative solutions reliably. The project gets the time that it needs. And it gets that time consistently and maintainers don't burn out because they're juggling five different jobs. I'm a very strong advocate of any and every company involved in this ecosystem supporting time-on-the clock for this work.
How to Handle Burnout
Arun Gupta: You touched on a very important topic -- burnout. How do you avoid or minimize it?
Christoph Blecker: Well, first, I'm not an expert on this subject. At multiple points in my career and my tech journey have taken too much on my plate and burned out. It's a very easy trap to fall into. Tech as an industry requires folks to adapt really quickly because things move so fast.
You get asked this question very commonly in performance reviews or job interviews: “Where do you see yourself in five years?” For quite a while I was able to say, “I have no clue because the things that I'm working on right now literally didn't exist five years ago.” The stuff that we're working on right now in this ecosystem did not exist 10 years ago, did not exist at this particular level in a way that people can consume as readily as they can today. It's very difficult to see where things are going and you must adapt quickly to learn new things or new technologies, better ways of doing things.
It makes a very exciting space to work in, but it’s easy to burn out if you take on too much, if you're trying to do too much too quickly. Especially if you're trying while juggling a current job with its responsibilities – and you want to grow and learn in this cloud native ecosystem. How do I do both things at once?
My best recommendation: Know and understand your own limits. That can take a while to learn. What feels like a healthy, sustainable level will vary from person to person, but know yourself and listen to your own signals. If I start to feel an immense amount of stress over the large number of things I deal with, maybe it's time to look at shedding something. Maybe it's time to say no to things and let other people step up.
The other important thing is when you take on a role, a new job, or a new project is to understand your exit strategy from the beginning. Start thinking about that early so you can build up somebody behind you. That way if you need to step back, you can.
An example: I’ve been an active participant in this group for several years and have held the technical lead position for about half a decade. I don't have the same amount of time that I had before because there's been other places in the community like the governing board that I'm involved in...So now we have two new folks who have progressed through a mentoring cohort and now are taking on that role.
This allows my colleague, Nikita, and me to shift our attention to other aspects of the ecosystem. Transitioning from an active role to a more advisory or emeritus position is critical for the sustainability and longevity of our community. It’s important to consider early on and identify people who can assume responsibilities and continue the work that you started.
Arun Gupta: You also mentioned the Code of Conduct Working group. Tell us more about that.
Christoph Blecker: The Kubernetes project has maintained a code of conduct and committee since its early days. We wanted to ensure that when we have thousands and thousands of folks from all over the world with different backgrounds with different cultures that all those people can work together in a harmonious way and in a way that promotes those values of openness and inclusivity. It serves as a common set of guidelines and expectations for all members, regardless of their backgrounds or levels of participation. However, not all projects under the CNCF umbrella have had the resources or expertise to establish their own code of conduct committees. To address this issue, a working group was formed last year to develop policies for a permanent code of conduct committee at the CNCF level, capable of handling wider concerns and matters that go beyond individual projects. Over the past several months, the working group has sought community feedback to update the code and establish a solid foundation for the new committee.
Arun Gupta: It’s clear that the CNCF is working on making the projects at CNCF level, not just Kubernetes more diverse, more inclusive, more welcoming, more open.
Christoph Blecker: When you set up a Code of Conduct and a committee, the hope is that you never need to use it. But the reality is that we have contributors from around the world, coming from many different employers, cultures, backgrounds. With all these different people working together, there's going to be friction points, situations that come up... You need to agree to these ground rules and these these values so that we can work together in that open, inclusive way and by setting up both healthy and consistent expectations across the board in our code of conduct. You also need a way to resolve issues when they come up – and it has to be already set up and ready to go. It increases the trust that the community has -- this is an open, safe, inclusive space, and if somebody, whether accidentally or intentionally, makes that that space unsafe we have a way of dealing with that and trying to resolve that issue... We're not shy: if a disruptive person needs to be removed from the community because they’re not making it a safe, open, inclusive space that will happen and there needs to be a mechanism for that. But that shouldn't be the first option and we should have ways to try and resolve issues in a manner that makes everyone involved feel that this is a safe, open and inclusive space to work in.
What’s Next
Arun Gupta: Kubernetes is becoming the de facto compute platform. Is anything being done to encourage universities to get more involved?
Christoph Blecker: While the Kubernetes project isn't driving the evolution of computing education programs, it's already happening. Students around the world are implementing interesting projects and working on increasing their knowledge. I talk to many of them at events like KubeCon* and they tell me about some of the interesting projects they're working on in class or as personal projects. Kubernetes has made computing accessible and democratized, allowing anyone to have the same power as large corporations, regardless of their background or access to resources. Kubernetes has democratized that part of computing – you can run Kubernetes on a Raspberry Pi*, you can run it on your laptop. You get the same power that you would as a fully scaled up hundreds-to-thousands of nodes cluster in a data center or cloud computing provider. So, it doesn't matter that you’re a student. You don't need to pay a zillion dollars to get access to a supercomputer or rent time on a large computer on campus.
The industry moves quickly and people need to adapt, making Kubernetes a valuable tool for staying current with cloud-native technology. You can’t use a textbook from 10 years ago to teach it, it didn't exist yet.