Navigating contributions and community health in Kubernetes

Bart: All right, so first things first: who are you, what's your role, and where do you work?

Note: While this transcript snippet doesn't contain any specific technical terms that require linking based on the provided links, I've reviewed it carefully. The only potential link might be to dosu.dev since Taylor mentions working at Dosu, but this is part of a direct question about his background.

Taylor: My name is Taylor Dolezal. I just started a new role as head of open source software at dosu.dev. We focus on helping people manage repositories and supporting open source maintainers. My focus is on issue triage, getting answers from code and documentation, and creating a better experience to improve the ecosystem and community.

Bart: And Taylor Dolezal from Dosu, what's your Kubernetes story? How did you first get into Kubernetes?

Taylor: So that was a wonderful story. I remember working with Ruby, programming Ruby on Rails apps and getting started with open source. I was scared because all of my work was put out into the open. What if I do something wrong? Those thoughts entered my head.

As I continued working with Ruby and Ruby on Rails, I moved into a role at the Cleveland Clinic. This was around the time Docker had come out. I got on board with Docker, transitioned from software engineering into infrastructure, and realized that most of the world is run with a while true loop. That kept me up a couple of nights, if I'm being honest.

When I went to a Meetup and found out about Kubernetes and how it made running WordPress easier, I started thinking this was cool tech. I started using it at work, moved to Los Angeles, and began working at Disney Studios. There was a mandate that we all wanted to use Kubernetes because it would make it easier to work across teams and have a common language.

As I became more knowledgeable and confident with Kubernetes, I wanted to work more closely with the community. I looked at the CNCF ambassador program, attended Kubernetes meetings, and worked with the community. In its early days, it was difficult to become a CNCF ambassador. I got rejected many times before finally being accepted. Only a few people were pulled in every few months—about two a month—and I remember being let down, thinking I'd never become a CNCF ambassador.

Then community members like George Castro, Natasha Woods, and Caitlin Bernard reached out and invited me to join the shadow release team. I started working in the communications role within the SIG release team. Since Kubernetes 1.14, I've been deeply involved with the community, learning how the pieces fit together.

I've never looked back. This journey brought me to the CNCF and into communities like SigDocs. It's a wonderful community and a great place to get started. No change is too small. The key is consistency: Step one, show up. Step two, stick around. Step three, community.

Bart: And you make it sound simple with those three steps, but you already mentioned some of the multiple moving parts. Talking about when you got involved, version 1.14, and all these different changes happening constantly in this ecosystem: How do you stay up to date with all the changes?

Taylor: For me, staying up to date is a mix of things. Some straightforward ways I stay current include Kubernetes KEPs (Kubernetes Enhancement Proposals). I keep an eye on proposed features, enhancements, and improvements within the Kubernetes space.

In a broader sense, I really like a tool called Readwise Reader. It aggregates my RSS feeds, Atom feeds, EPUBs, PDFs, and highlights across my Kindle. The tool has repetitive learning features and note cards. This helps me stay updated on tech news, open source developments, and related happenings.

Bart: I notice the transcript is very short and doesn't provide much context. Could you confirm if this is the complete transcript or if there's more text to analyze? Without more context, I can't confidently add hyperlinks.

Taylor: Wait, what? Did something happen today? Did I miss it?

Bart: So in terms of the people, we often talk about the tech, but this is a very recurring theme in the interviews that we're doing for this community asset about the importance of people. Who is someone in the Kubernetes community who helped you level up?

Taylor: I'd say there's a trio that really comes to mind for me. I loved getting to work with them while at the CNCF and might have some work upcoming with them soon. Those three people are Bob Killen, George Castro, and Jeffrey Sica, who goes by Jeefy.

I remember meeting them. George was there from the beginning with me in Kubernetes and is just a wonderful soul who has never lost enthusiasm. I need to figure out his secret because I'm fairly enthusiastic, but George has me beat. I don't know if it's something in the Michigan tap water, but George has been a huge inspiration for me in how to embrace, encourage, and help people level up.

I remember meeting Bob and Jeefy at a KubeCon. I was initially intimidated because I'd seen all the work they'd done in the Kubernetes community. We met in a hotel lobby—they were sitting on a couch, and I sat across from them. We started talking and became lifelong friends. They helped pull me in, suggested things that might need changing, and gave me advice on how to interact with the community.

The focus is on people, which is by far the secret power of the Kubernetes and open source community. Finding mentors and people to bounce ideas off is incredible. It's not just about the tech or writing the perfect issue or pull request. It's about having friends and people to grow with. It shouldn't be a solo experience—that's my firm conviction.

Bart: Because there are so many different people in the ecosystem, Kubernetes can mean different things to different people. For you, Taylor, what is Kubernetes for you?

Taylor: Kubernetes for me started as an orchestration framework. I initially focused on the tech because I thought it was really cool and helpful. Kubernetes, for me, is about creating lasting change and thinking about the life we want to live.

Kelsey Hightower, who is very prominent in the Kubernetes and container communities, said something powerful at a recent KubeCon in Salt Lake City. People keep asking him about the future or what's next, and his response is: "The future is what you're building today." I align completely with that sentiment.

What are we building today? Are we creating something lasting? Will it make better lives for all of us? Will it allow us to sleep past those 3am alarms and create self-healing modes for infrastructure and applications? To me, Kubernetes is a way for all of us to level up and think differently about how we work with our systems, tools, and applications.

Bart: From your vantage point today, given the years of experience you have working with Kubernetes, how has Kubernetes itself shifted in the last two to three years?

Taylor: Kubernetes has been interesting as it enters the age of artificial intelligence, AI, machine learning, and batch workflows. It's been fascinating to see how the Kubernetes community has rallied around supporting things like GPUs, scheduling, and thinking about how to handle inference.

As Kubernetes looks to the next 10 years, the focus seems to be on making things more automatic, creating saner defaults, and setting up a better developer experience. From KubeCon talks and community interactions, the recurring theme is how to make things better—bringing important configurations to the forefront and making everyday life easier.

I see Kubernetes increasingly focusing on workloads, workflows, storage, and how to run applications more effectively.

Bart: How does value actually flow from Kubernetes projects down to the practitioners?

Taylor: I would say that typically it will be mostly around the community—around the demos they create, around the blog posts, around sharing things for events like KubeCon, CloudNativeCon, and how to write a compelling Call for Papers (CFP) proposal. I'd say it really is about the artifacts and assets that come out of the community, the how-to, the show and tell, really embodying that culture. That's one of the things I think is most helpful.

Bart: When looking at a project, there are often vanity metrics around GitHub stars. I remember Brian Douglas once mentioned: Don't fall into that trap, although it's one sign of project health. Look at things like pull requests. Are people actually motivated to work on it? What signals tell you that a project is healthy versus hyped?

Taylor: When it comes to healthy versus hyped, I'd say a healthy project is one where you have a good mix of people working on it. I know projects go through different seasons. When something's getting kicked off or started, you might have just one company, one vendor, or a smaller subset of people working on something to get the idea out there, to educate, and to prove that something can be done.

As the project starts to grow, pulling in a more healthy mix of contributors and maintainers from different walks of life, different companies, and different focuses is a good sign of health. It shows that lots of people want to work on something, and it's not just within a specific company or vertical. If it's just a finance-related project or just a storage mindset, seeing many people bring in their life lessons and career experiences to apply to a specific project indicates good health.

I'd be remiss not to mention—as I've talked to Bob Killen about many times—how long it takes for an issue to reach completion or the time taken to review pull requests. If something's sitting or stale for a while, whether an issue or pull request, that can signal project health based on my experience.

Documentation is always important, especially for developers. Typically, people want to focus on code and features, delivering value. What I've noticed is that docs often come last, which is not ideal—similar to security, it shouldn't be bolted on at the end. A healthy project means having updated documentation.

I'm excited about the work I'm doing at Dosu with the team and community, figuring out better ways to keep people updated and ensure a great first-time experience. Those first experiences matter. If documentation isn't clear, or if commands result in errors, there's a low chance people will return to the project.

When it comes to hype, I've seen projects that focus on pull quotes or a single feature without considering the broader context. Thinking holistically—about integration with other projects and workflows—is crucial. Some hyped projects might lose sight of the bigger picture, focusing on one objectively good thing while missing the broader ecosystem.

A great website is nice, but without documentation, examples, or learning resources, the project falls short. Those are the key things I keep in mind when assessing project health.

Bart: In terms of getting the right balance between vendor energy and community stewardship, what are some do's and don'ts that you could share?

Taylor: HashiCorp did fantastic things for the open source community. They started around 2012, at a very interesting time when the CNCF was kicking off at the tail end of 2015 and 2016. HashiCorp had Nomad, CNCF had Kubernetes, and there was some back and forth within the ecosystem about the right tool for orchestration.

Terraform is a good example of something done really well in the open source space, but it might have gone too far in providing so much within the open source offering. By the time they started creating vendor-focused items like Terraform Enterprise or HashiCorp Cloud, it felt like things were a bit late. Other projects like Atlantis and additional infrastructure as code tools emerged to help within an open source ecosystem.

When creating a project, focus on what makes sense within the open source space. You don't want to give too much away for free. I love open source, but companies need to make money, and vendors need to operate and justify their spend. We want to get paid for our work, solve pain points, and genuinely help people.

Figure out what makes sense to open source versus what to keep as your company's secret sauce. This approach allows vendors to create education programs, certifications, training, security audits, and community engagement. By focusing on open source efforts and engaging with the community through Slack, Discord, or GitHub issues, you create a healthy mix that lets vendors excel at what they do best while allowing the open source community to think outside the box and propose solutions that help the broader ecosystem.

Bart: In terms of getting the balance right, for startups entering the Kubernetes ecosystem, we work with large-scale organizations like Google, Heroku, Akamai, and AWS, as well as smaller startups. They're trying to figure out how to stand out without being too noisy.

What advice do you have for startups entering the Kubernetes landscape to add value and not become a repetitive noise? How can they embrace the best parts of the community and have the community embrace their unique know-how and the problems they're trying to solve?

Taylor: With startups, it's easy to become noisy—always wanting to say, "Hey, we did a thing." For teams and startups thinking about engaging with the ecosystem and community, focus on the pain points or problems. What problem are you trying to solve? I've asked that question a lot in my career and have been asked the same, often realizing I wasn't thinking deeply enough or was too close to the problem.

By stepping back and considering what we're trying to solve—have we proved it out?—we can better relate to people working on storage concerns, application runtimes, configuration management, or other challenges. If our company or solution addresses these effectively, we have a much better chance of success.

By focusing on the problem, writing blog posts, hosting office hours, and interacting with the community, you'll connect more meaningfully. This approach creates lasting relationships and might even inspire someone to contribute a pull request or file an issue to help elevate the project.

Bart: We've talked about the startup side, but now thinking about individuals who want to get involved in the ecosystem. I recently had a conversation with Bob Killen, and we were sharing our experiences with people who often ask, "Teach me how to contribute" or "I want to start contributing right now" with a sense of urgency. If I've learned anything, slow and steady wins the race here.

For individuals trying to carve a path in the Kubernetes ecosystem, whether or not becoming a maintainer is their immediate goal, what advice would you give to those wanting to start their Kubernetes journey?

Taylor: There was a really fun effort that I got to kick off while working at the Cloud Native Computing Foundation (CNCF) called Zero2Merge. The goal of the program was to teach people how to make their first contributions, focusing on end-user companies and project adoption, not vendors or resellers.

We dove into understanding why people want to work in open source. What problem are they trying to solve? Are they seeking a new career role, learning something new, or trying to focus on a specific area? How can we help?

Within the Zero to Merge program, we found that small steps matter. This includes updating your profile picture, creating a README in GitHub that tells people about yourself, and having a sense of direction. You don't need a five to 10-year plan, but understanding your goals for the next few months is a great start.

For the Kubernetes community, there are two potential paths. First, a project-focused approach: if you're interested in Kubernetes and want to learn more, you might explore projects like Argo, Open Telemetry, or others. This allows you to explore different communities and focus areas like developer experience, security, or documentation.

The second path is to start with a specific area of interest—such as documentation or security—and then find communities and projects that align with your goals. Both approaches can help you find where you fit best and connect with people you enjoy working with.

Bart: There are a lot of different perceptions of the Kubernetes community and what Kubernetes is all about. Is there one misconception about the Kubernetes movement that you'd like to retire?

Taylor: I think I wrote down that Kubernetes is the final platform. Candidly, I would love that because, as I get on in my career and get a little older, I love keeping production boring. This means understanding the changes you're making and avoiding constant tech stack shifts, which can be tiring and challenging to learn objectively.

However, Kubernetes is not the final platform. I align with Kelsey Hightower's perspective that Kubernetes will show its maturity by slowly fading into the background and creating space for tools to build on top of it. We've started to see this with projects like Argo, OpenTelemetry, Backstage, WebAssembly, and others that are building on Kubernetes' standard APIs and development approaches.

Kubernetes is not necessarily the final platform, but the right step in the right direction—similar to how Linux isn't the final operating system. It has created a great base for us to build upon. As we progress through the next 10, 20, 30, or 50 years, we'll likely rethink how we write applications and the bindings between storage, memory, CPU, GPUs, and potentially new hardware.

It'll be interesting to see how these tools change and what becomes the next big thing in platform and application development. Kubernetes is the best platform to work on right now, but is it the final platform? I don't think so. Time will tell, and it'll be cool to see.

Bart: And last but not least, what's your North Star question for anyone that's choosing a path here in the Kubernetes world?

Taylor: I would say, think about the impact you'll have, whether it's you right now or your future self. That's my biggest case for writing documentation: even if people say no one will ever see this, you might in the future, and it's a way to help yourself out.

By thinking about the impact you have, you can start by asking: What do you want to do in the world? Are you saving yourself or others 30 seconds of time? That adds up in a huge way if you're saving people five minutes or more.

Kubernetes, when it started, was just an idea of how to make production easier to work with and demystify deployment processes. Look at how much impact it has had. I think that's many people's goal: to create something massive that changes the world. Though, even small changes can significantly inject themselves into somebody's day-to-day life.

How do we help people ship more confidently? How do we stay asleep past 3 a.m. so we don't get paged when production goes down? By focusing on making people's lives easier—starting with yourself and then thinking about others—you can create meaning.

I think automation is great, but you should be mindful of what is automated and how it's automated. Impact and meaning are my North Stars in many conversations throughout the ecosystem and community.

Bart: This is unscripted, but when are you going to write a book?

Taylor: I wrote a Terraform cookbook. I thought it was going to take one year to write, but it took three years—much longer than expected. Many authors I spoke to said a book would take two to three times longer than anticipated, and that became true. It was a fun book to write, but it's very difficult to write about a specific technology, framework, or project version because everything changes so quickly. I'd love to write a more greenfield book that focuses on open source or working on your career.