Kelsey Hightower // @kubernetes/kubernetes

Here’s what’s in store for this episode:

• 00:00 - Introduction: The hosts discuss GitHub May-ntainer Month and introduce Kelsey Hightower!

• 1:07 - The interview: Kelsey talks the hosts through how he got into tech, how maintainers can avoid burnout, the importance of identifying new leaders, what the future holds for Kubernetes and much much more!

• 32:55 - Maintainer shout-out! Aaron Francis, Cassidy Williams, Frances Coronel, Anthony Sottile, Peter Strömberg, and Brandon Ringe call in to share their appreciation for fellow maintainers in their lives.

Special thanks to our guest, Kelsey Hightower, and to all of the maintainers who shared their appreciation.

Check-out The ReadME Project, for more episodes as well as featured articles, developer stories, helpful guides, and much more! Send your feedback, questions, and ideas to [email protected].

---

Martin Woodward: This is The ReadME Podcast, the show dedicated to the topics, trends, stories and culture in and around the developer community on GitHub. I'm Martin Woodward from the GitHub Developer Relations Team.

Neha Batra: And I’m Neha Batra from GitHub’s Core Productivity Team. And this is a very special episode we’re bringing you to celebrate Maintainers’ Month in the month of May—or, dare I say, “May”-tainers’ month. Anyway, I’m going to get straight to it with great insights from someone we all look up to in the space.

Martin: Indeed, our guest is probably most well known for his work on Kubernetes, the incredibly popular, open sourced container orchestration platform and ecosystem, really, I guess. And in his spare time, he does a lot of work encouraging people to get into open source and kind of building their careers in computing. He's also one of the kindest and nicest people you're ever going to meet in tech.

Neha: If you haven't guessed by now, we're joined by legendary software engineer and developer advocate Kelsey Hightower. Hey, Kelsey.

Kelsey Hightower: Hey, how you doing?

Neha: I'm doing pretty good. I'm really excited to have you here. And we're going to get to some nitty gritty maintainer stuff in a bit. But I just wanted to start by hearing a bit more about how you approach growth and development. Like, what's your philosophy in the space and is it about being self-taught and just trying stuff out?

Kelsey: Yeah, for me, I think it's the whole person that I try to bring to this development process. You know, for me, my job before tech was like fast food. And so for me, getting into technology was like a means of survival. So self-taught was the preferred option, mainly because it was the most accessible option. You could go to a bookstore in 1999 and buy a book on any topic, and it felt like you were getting that college degree that other people had access to. You know, we say self-taught, but I think of it as you're being taught by authors you've never met. And so it became this thing where it felt like you could do anything. It was just one book read away.

Martin: Yeah. I mean, we were quite lucky in some ways growing up in kind of the late 1980s and early noughties, because you could go to the bookstore and learn a bit. I sometimes I'm just amazed by, you know, folks coming out of bootcamps and folks coming into tech now because of just the breadth of technology that they have to know. And yet, if I only had to know a little bit at a time. 

So how do you approach, you know, developing your skills now? Because it never stops, does it? What are your signs when something is worthwhile investigating or how do you prioritize your time and energy?

Kelsey: There's a point where I realized that the fundamentals are more important than people give credit for. You know, these days, a lot of open source projects have popularity, right, their logos, they have fancy names. They're usually attached to hype cycles. And so people get distracted by the new thing. And when I was coming up, I was learning Unix through free BSD, right? So maybe Linux was out, there was other things that were available, but I happened to stumble upon free BSD and I went super deep. I learned everything about free BSD, how it worked as an operating system, how to updated, how to upgrade it. And I remember doing my very first technical interview and all the questions were about Linux. And there's a moment in that interview process where I didn't have the answers because they wanted Linux specifics and I was like, “Listen, I do know Unix, but not Linux specifically.” And one of the interviewers on the three-person panel was like, “What Unix distro are you referring to?” And I was like, free BSD. And just so happened I hit the lottery because he had a free BSD tattoo on his leg.

Neha: Oh my God.

Kelsey: And he pivoted the whole interview to just talking about free BSD. And I was able to take all of the fundamentals and do pattern matching and give very detailed answers. And what I learned when I started the job, all of those FreeBSD skills, they transferred over to the Linux environment. And so my whole career, I was very focused on whatever technology is in front of me, whatever the programing language is, whatever the networking switch is, I'm going to learn everything about that thing knowing that 80% will transfer. So when I see new projects come out today, I look at all the buzz words, I look at all the fancy stuff, and then I go back to the fundamentals and say, “How many of the fundamentals is this thing implementing and what is it bringing new to the table?” What I learn at that point is there's only 10% delta that I need to coverage before I truly understand. Just ask questions for the rest.

Neha: So I feel like something that you talked about that really resonates with me. You know, I'm also self-taught and I feel like when it comes to going deep on a topic, being able to hit all of those fundamental principles underneath that with going deep on just one thing, I feel like that applies both when it comes to learning and also when it comes to teaching. And I was curious, when you consider the way that you approach learning and teaching in your work, are these distinct like separate efforts for you? Like, are you drawing on different skill sets? And if so, in what ways?

Kelsey: I would definitely say there are a couple for me. If I learn something from someone, I try to repeat it back. You know, you have those conversations. If I understand correctly, what you're saying is you can be off by a little bit and people will correct you like that's close, but not quite right. And that feedback loop accelerates everything. So it does require being a little bit vulnerable. A lot of times when you're learning in public, you're putting yourself out there. And so you've got to be very careful not to come off as an authoritative figure. Right. You don't want to be like, “This is the answer.” And so what I like to do is take a little bit of fact and a little bit of opinion and put them together and let that be the thing that I approach the space with. Like, “hey, here's what I've learned, here's what I think about that, if that's true.” And then people will then help shape my mental model to ensure I really understand that thing. 

And then the thing that I love to do is I try to build something with the knowledge that I have, especially if I'm learning something in a tech space, right? I might build a little prototype, I might build something at the hello world level, and then I'd like to share it. So I'll just put all of my notes like on GitHub, right? Like the whole concept of the read me, I just learn about service mesh. Here's a little prototype that I built to crystallize what I've learned, and it's going to throw it here on GitHub so others can like check my notes or maybe you can learn from it, too.

Martin: Yeah, that's. It's something I always struggle with, actually, because I'm never consider myself an expert in anything. You know what I mean? I think it is like one technology, which is super niche that nobody uses it now, I was probably the expert in that because literally nobody else cared. But everything else. I'm kind of just learning all the time. And I struggle sometimes with knowing when to experiment and work on things and how I differentiate that from when I'm doing the work that's kind of keeping the trains running on my open source project when I'm cranking stuff out. How do you manage this need for kind of innovation and experimentation in open source with kind of the stability and reliability side that you need in some of the open source projects? Like how do you approach that balance and how do you kind of divide your time?

Kelsey: Yeah. I mean, I think at some point I realized that you don't need to be the top person. You just need to be in like, the top 10,000. If you're in the top 10,000, that means you can get a job pretty much anywhere in the world, just being in the top 10,000 in anything. And so that just takes a bunch of pressure off. And then it's like, who are you competing with? Right? You can try to compete with other experts who have taken a very narrow approach to their career, and they're really hyper focused on one domain. And then I chose to be just better than my previous self. Right? So that means if I'm writing Go, I want to know how the Go programming language works. Why are there only 32 or 30-some-odd keywords, what are those keywords do? How does that impact the runtime or Go’s approach to memory management? And I might just take a moment just to read the memory management documentation and say what benefits does that give me as a developer? And then you can go read historical thing about memory management from other programming languages. 

So I think there's like a moment where if you have only one week—five days of work—you take one of those days and you just put a big block in your calendar called learning. There's a lot of value in just pushing back from the keyboard and saying, “Let me make sure I understand these fundamentals.” 

I’ll give you an example. I open sourced a project called Conf-d. It starts like most open source projects, you're trying to solve a problem for yourself. And so you build the tool that only does that one thing and you decide to open source it. Meaning I'm sharing this with others, but only useful to people if you have the same problem I have. I'm not trying to be all the things to all the people. And then one day someone said, “Hey, Conf-d is really cool. It's a really nice tool for taking key values and turning them into application configuration. But we really need encryption.” And I'm sitting here like, Oh my goodness, I am not comfortable adding encryption to this tool because I don't understand the tradeoffs. So now I'm going to have two weeks of really just researching the right ways of encrypting secrets. Should I do it natively in my tool? Or should I rely on the key value store to do it and decrypt it at runtime? And so you just go through this thing where you just learn everything about the various approaches. You go try other open source projects. As a maintainer, it turns out you don't have to solve all the problems from scratch. You can go see what other maintainers have chosen to do in their projects and then that can kind of inform you and you can just ask questions. So when you do your first implementation, you're kind of learning in public. You know, you put it out as a beta, you ask people to try it and boy, does the developer community love to give you feedback. “That isn't the right way to do it!” “No one uses those encryption ciphers anymore.” What are you doing? And it’s like, Hey, I hear you… give me a better idea, and I'm surely able to update my first prototype at this. And so that's always been my approach. But for me, I know what I'm doing. I'm investing in the future Kelsey. The time that I take to learn about these things, I know it's going to have a major payoff down the road. So I take the time to do it.

Martin: That's a great way to treat future Kelsey with the respect and grace that they deserve. Sometimes I think we treat our future selves without that kind of respect. You know, we sign ourselves up for all sorts of things. And rather than invest in ourselves sometimes, you know, so that future you is going to be a better person than where you are now. Now it is maintainer month and you know, you've got a lot of experience dealing with different open source communities. And as you say, people can be quite free with their opinions sometimes. So how do you deal with some of that? You know, like the disagreements, like conflicts, maybe? All of your projects, whenever I've been involved with you, it's always a very positive environment you create around you. How do you actually go about doing that? I'm guessing it's very deliberate.

 

Kelsey: I mean, I think if you've ever tried to maintain your own open source project, hopefully you grow a sense of empathy. You know, when Conf-d was open source, I was very excited about it. I remember going to FOSDEM, a very popular open source conference in Europe, and I went into one of these talks about configuration management. And I watched someone presenting a talk on Conf-d. I've never met this person. My mind was blown. This person is like, there's this amazing tool that changed the way we think about config management. And I'm just sitting in the back with my arms crossed like, “Oh my God, like, he's talking about this thing that I created.” And so I'm no longer just a consumer of open source. I'm also a contributor. Even better, I'm a maintainer and I remember being on this emotional high for a very long time that I was able to impact something that was seen around the world, literally. 

And so I remember, though, you have to pace yourself because you know that's a high. But think about that Saturday morning where you wake up and you see your email box flooded with feature requests for things you don't use, you don't plan to use. And you're sitting there working for free in your free time. And people are very demanding, right? People like, “This needs to be fixed ASAP.” For free. And you look at their email address and they work for some large organization that can totally afford to pay for this software or implement this change and submit a pull request. And so you don't want to let the community down, so you end up getting close to burnout. You end up working way too hard and you don't have the right pace. 

And so you slow down and you find the courage to actually slow down and you communicate to people. I can no longer add every feature that everyone wants, so we're going to add some scope to the project. We will never add this functionality, like, never, and people get a little upset with that that you're making a decision. But what I learned is you had to make a decision. So if you take all of those experiences and maybe one other experience that really helped me understand, I have this phrase called “different companies, same team.” A lot of us in the open source community, we work for different organizations. Sometimes they compete at the very high levels of the tech stack, but at the bottom of that stack are the people who are just interested in getting those ideas out there and implemented. And we kind of work together even if our companies don't. And I remember I said no to a very important Conf-d feature. 

The people at Hashi Corp, they have wonderful tools, including Console and Vault, and there was a request to add vault support to Conf-d: Encrypt all the secrets there, and Conf-d would pull them and you would have nice application configs. And I said no. And so the HashiCorp team made a competing tool called console template that would do all the things that I said no to. And then they released it and they became the number one post on Hacker News. And the community was like, Wow, I can't believe you all did that to Kelsey. How mean to take his idea, you big company that makes money, and build something that competes directly with him instead of contributing. 

The thing is, they didn't have all the insight. They didn't know that there was a back channel conversation where I decided that no was the right answer for Conf-d and yes was the right answer for console template. And I celebrated Mitchell Hashimoto in the HashiCorp team for taking the idea of Conf-d and allowing it to live on in this way that satisfies their community. Takes pressure off of me and it gives the community what they want. And that's the power of open source that we can actually collaborate even when we're competing. 

And so as a maintainer, I have empathy for all of those scenarios, and when I see a new project that I contribute to, I have that maintainer in my mind. This person has the right to say no. That could be very close to burnout and I'm asking them for a favor and they've already given me so much that the tool is usable in the first place. And so empathy allows me to really, really treat people with respect and show up the right way. You learn that code base, you write those unit tests, and don't forget the docs. And I think that's the right way to participate in any open source community.

Neha: I think this is really helpful to talk about. You were talking about like waking up on a Saturday and seeing all of these open issues and like, my heart started beating a little faster because I was like, You can't do all of those. You can't do all of those. And, you know, the answer is you have to say no, right? That's what it boils down to. So, we've had a number of maintainers on The ReadME Project share their experiences for like managing contributor relations, both at early stages and in smaller projects, and in later stages with larger projects. What advice do you have for these maintainers who are looking to balance their time managing contributions? Because saying no I think is a big tenant to that, but I'm curious if you can help them a little bit more. Like what advice do you have for them for managing their time?

Kelsey: Yeah, if you're a maintainer, we always think about the technical roadmap. What's in the next release? Where should this project be two years from now? But we don't think about the sub-roadmap that hidden roadmap. Who is going to be maintaining this two years from now, and it may not be you. And I think one of the things we should think about early is what is the succession plan? 

When you find someone in the community that's contributing, showing that they care about this project maybe as much as you do, that's the person that you want to figure out how to get commit access to, right? They've earned their stripes. If something happens to you, it could be burnout. Maybe you change companies. You don't use the tool anymore. You want to empower someone else to be able to step into that role. And so I think as a maintainer, you should always be thinking about who's going to be the next set of maintainers. What's the criteria? And maybe establish that early. And so you can start giving people that want to step up that opportunity to take pressure off of you, be collaborators. 

I think a lot of times when you're a maintainer of a very popular project, it feels like you're in God mode. You don't want to give that up. Everyone has nice things to say about you, and your stats look really good. You know, people like to post that GitHub graph, but sometimes you've got to know that you got to spread it out. And I think that's what good leadership is, is finding the next set of leaders. So that would be my advice. Think about the long game. You're running a marathon and sometimes you're going to make sure that you turn that marathon into a relay race and have someone that you can hand it off to to run the leg when the time comes.

Martin: Yeah, I think some of the biggest mistakes I've made in my life are when I've let my ego rise up and get in the way, not just in terms of like nano stuff, but also in terms of like working with the open source projects. Because you like that praise, you like making people happy, we’re people pleasers. You know, we like to solve people's problems, but I've had projects in the past where I've just had to step back because I'm not working on that anymore. I can't do any more on it. And interestingly, it's when I've stepped back, that's the time when I've left that space that then people have come in. You know, it's very easy to think, Oh, I can't step back because nobody's there. It's all on me, blah, blah, blah. But actually, when I have stepped back, yeah, the community suffered for a little bit, but then people have stepped forward to fill that void. You know, if the void is strong enough, it brings people in. 

Neha: You know, I've been thinking a lot about why it's so hard to step back in these kind of times. And it's I think one of the things about it is that when you're giving this free labor, essentially, right, there's got to be something that makes it worth it. And when people say thank you and when people appreciate you, all of a sudden it makes it worth it. And it feels like if you are ceding that piece where no one's like saying thank you for the free labor, it's so hard to realize that, like, the work will still be worth it. And it will be because you have less work to do and then you have someone to partner with and it will eventually become worth it in a different way. You're kind of like transitioning to a different way to get that value, and it's very hard to predict that that's going to happen, right? Like you're taking a leap of faith for it.

Kelsey: Also, as a developer, it is our one clean canvas to build whatever we want, right? There's no OKRs, there's no company pressure.

Neha: Finally.

Kelsey: Right? We get to decide. So an artist that gets to paint freely, it's such a powerful outlet for people who do this, whether it's full time or part time, you get to run at your own pace, you get to call the shots. You get to actually bring something to life that you believe should exist. And so that's the form we have to do it. And some of the maintainers that I really appreciate, those that have also gone through this. Ben Johnson: I came across him when I was working at Core OS, he implemented the RATH Library, which we use for building distributed systems. And man, he was like the only implementation in town, especially for something that was implemented in Go and everyone used it. I mean, big commercial database projects were relying on this thing. And you had this one person who was charged with maintaining such an important piece of the infrastructure stack. And I know he got burned out. If he never admitted it, it was very clear. 

And on his new project, he does something really wise: At the top of his README, he lets you know very clearly: “We are not looking to add a bunch of new features. Actually, we don't want a lot of pull requests. Bug features are the only thing we're really evaluating right now. What you see is what you get. And here's what my promise is to you: What this thing does is limited scope. I will try my very best to make it true. In terms of new features, don't want ‘em. Right? And if that's something you can't get down with, if you look into the upper right corner, there's this magical fork button. You can click it and this code can be yours to maintain and to add all the features you want.” And I think that is the right way to kind of do it, especially if you're a solo developer, you know what your limits are. It's a really great contract to give to people and I think they can respect that.

Martin: Yeah, definitely. One of the people I learned that from was a guy called Brad Wilson and he looks after the X unit projects in the Darknet space. And it's very opinionated in how the framework is. And he was very clear early on, like this is, you know, this is the opinions we've got. And it kind of links into what you were saying a bit before, Kelsey, about like you know, making art in your own time and having that creativity. Some of the best art comes with constraints as well. And so very clearly setting out what those constraints were to the community early on, like laying out the core philosophy, help people understand, you know, where the community is going. Not saying everybody, every 5 minutes, people would somebody would come up and say, “Can you do X, Y, Z?” And you'd have to say no, because this is the way we know this is our philosophy here. And so and you'd have to remind people and so on. But often you again, you'd find the community would remind people and you didn't have to do that.

Kelsey: So there was one phrase that changed my whole outlook on what it means to be a maintainer, right? The phrase is, you know, “some people have ideas and some ideas have people,” and as a maintainer it's like you have the ideas, right? You are the steward of the project. And what I realized was creating prototypes was the best way to get the ideas out there and encourage people to take these ideas and mature them. So, look, I'm not writing any unit tests. I will write the docs because I want people to understand the idea fully. I want them to be able to explore the idea with something that's tangible that they can touch and some people actually get value from, but then encourage people that this is just the start. If you take this and make it better, you deserve all the credit in the world for doing so. And I got really comfortable by just blazing the trail with like these prototypes as the perfect starting point for someone to flesh out and mature. So it can be production ready, and it turns out you can actually build a lot more projects that way and actually see them flourish. So then you become the maintainer of ideas, not just open source repositories.

Martin: Yeah. Yeah. Hey, listen, we can’t have a conversation with you without touching on Kubernetes. You know, I know you've been focusing on the human side a lot, but you've been involved kind of since inception of it, really. How have you seen it evolve? How have you seen the community change and kind of, you know, what do you think the future is around Kubernetes?

Kelsey: I mean, the future of Kubernetes is, if we're being honest, that it has to go away. And if it goes away, that's a sign of progress. If we're still talking about Kubernetes 20 years from now, that would be a sad moment in tech because we didn't come up with any better ideas. And so I think a lot of times and I actually met someone at KubeCon last week that had a Kubernetes tattoo on his forearm. There's a really cool tattoo, but I thought about it, and this project maybe isn't going to be around forever, but maybe the memories will be around forever. And so maybe that's the reason behind the tattoo. 

We're at year number ten. And I don't think people realize how early that is. For most of the social projects, Linux is over 30 years old. So Kubernetes is at year ten. And think about Kubernetes. A lot of people looked at it as like this brand new thing. But when I saw Kubernetes, the thing that attracted to me early on. It was a project that implemented the previous ten years of patterns. And so if you were around ten years before Kubernetes came out, you realize that this is what a lot of people were experimenting with in their own environments. And we finally took all of those patterns, put them together, and gave them a name. We called it Kubernetes. 

And so I think maybe it's really the year 20 ideas or a decade, all the implementations ten years old. So maybe we have another decade. So where we are with the community, there are a lot of people who are waiting on the sidelines, right? Hey, this thing may not pan out. It's just hype. We'll wait it out and we'll just go back to our VMs. Well, that didn't happen. And so those people that are coming off the sidelines now, they're attending their first Kube Con, they're going to their Native Vendors conference where there's VM World or Oracle World. And this technology is now front and center even at those conferences. So those people are coming in for the first time. And it's amazing when you meet those people because they'll say, Hey, I've been binge watching all of your videos, I've been reading your GitHub repository, “Kubernetes the hard way,” to help me understand everything at the fundamental level as I work my way up to the high level concepts and they really appreciate it. 

But there's another group of people who have been complaining about Kubernetes for the last five years. “It’s too complex,” “It's missing this,” “It's missing that narrative, this, this, and that.” “We've been using it for a while. We think it should evolve.” And so when they say, what would the future be? There's that saying it's easy to predict the future when you're working on it. And so what I look at is all of those projects that are like trying to build new things above the Kubernetes is a set of abstractions. And one of those are going to work out one day. And then that will be the new thing that shows up. But I think Kubernetes is really great because of its extensibility. That's one thing we don't really talk about enough. I think we talk about containers and orchestration, but the magic of Kubernetes was it had enough extension points for security, storage modules, cloud provider integrations. So there's no need to hit the fork button. Any innovation you wanted to do, Kubernetes made a really great call early on. The customer resource definition, we call them CRDs, and what CRDs allow you to do is to create first-class extensions that live in Kubernetes. They feel native, and it allows you to test new ideas without understanding everything about the core code base. If you've been a maintainer, the hardest thing is to add new functionality without getting the core project off track. You never want to get too distracted by adding something and making it too bloated, and it's going to be hard to maintain going forward. 

So I think Kubernetes’ API model, its plug-in model, was like a gift to all future maintainers. Because now that group of people don't need to try to figure out how to add every bell and whistle to Kubernetes. The API allows you to do it yourself, and the best ones will actually grow their own sub communities that satellite in the orbit of Kubernetes.

Martin: Yeah, it's, you know, just the challenges and the complexity there as well is interesting. You know, we talked about the CNCF and you look at the some of the charts of all the CNCF projects and you realize kind of some of the complexity in this space. But a big thing I've seen you doing, a big thing we all try and do really here is like trying to find ways to help folks find their path into technology, you know, bring them into the community. How do you go about, like, making some of this inherently complicated, fast-changing stuff? Like how do we make that more broadly accessible so that people can get involved?

Kelsey: So this discussion came up about six or seven years ago, and the number one thing was Kubernetes is too complex and some people had ideas that we should just have this big shell script, and we did. It was called kube-up.sh. And if you ran it, it would do everything for you. One command does everything, and for 5 to 15 minutes you're watching all this tech scroll by and you're like, “It's doing something. It's doing something. I'm sure it's going to be finished at some point…” and then 15 minutes later is like, I think it's done, but I'm not sure what happened. Yeah. And so even though you had the one command to bring up a cluster, you still didn't feel good about it. You knew that if something broke, there's no way you could understand it. It's like, you know, the pilot falling asleep at the wheel and it's like anyone can fly a plane. You're like, no, I just buy the tickets and take a seat. 

And so I decided that we didn't need more software. We needed some docs. And so I decided to write Kubernetes the hard way, and I wanted to show people every nuanced step it took to build a cluster from scratch. Download all the binaries, no shortcuts. I wanted people to copy and paste every command, tediously, multiple times, because I wanted them to know how it all fit together. And so that way, when they were done putting together the jigsaw puzzle, they would have the big picture. And so if they did go and run a script or use a managed service, they would feel way more comfortable knowing how the individual components move. Now, that sounds like that doesn't help with the complexity. But it turns out when people understand how something works, when you see a magician do a magic trick and they show you how they did it, it's not magic anymore. It's just a trick. 

And so I think what was needed was to keep people informed about how it all fits together so they can actually make these choices and troubleshoot and debug. And I think that has been one of the most important things, is just educating people what these features do, why they exist, and then making sure we're very patient. Going from alpha to generally available to everybody. So I think that's kind of the most important thing we can do to make sure that, yes, the project is complex because it's trying to solve a complex problem. But that doesn't mean we shouldn't take the time to educate people so they understand how it works.

Neha: We just keep on coming back to this recurring theme, which is that there's humans on the other side and they're real people. And like software is a bridge between people, right? That value for me is like to meet people where they're at, right? And to bring them along with it in the journey. And if they come along in the journey right, then you have that shared experience and you can do something real with that, right? The fact that you decided to approach this through documentation, right. Those are those tiny pieces of a project that it’s easy to forget but makes all the difference in the end. And there's a lot of those I mean, you touched on it earlier, right? Like those community managers in the background who may or may not be writing the actual code, but they are helping things come together. There's thousands of those tiny tasks that make a project successful. I'm really glad that you brought this up. You're talking about how to create more inclusive and diverse people into the project, right? I'm curious if you wanted to say a little bit more about that, like how can we create a more inclusive and diverse future in tech and particularly in open sources? And do you have any examples that you've seen of successful initiatives in promoting inclusivity within tech in the tech industry?

Kelsey: There's probably a lot of successful initiatives, but, we’ve got to remember a lot of people in other groups get to also make a choice. There's lots of conferences to go to. There's lots of projects to work on. And we're really asking them to spend their time and parts of their life with us. And if that's not welcoming, no one in their right mind is going to choose to go to a place where they have to fight to be there, just doesn't make sense. 

And so when I showed up to the Kubernetes community, yes, there was probably zero people that looked like me, 100%. And I didn't really participate in any explicit programs to get them in either. Maybe in other areas, but not in that particular area. But one thing I didn't know that I was doing because I was going to stop, I was like, I am tired of speaking at conferences. I am done. No more keynotes, no more live demos. They take a lot of work and they're taking me away from the day job. And so something has to give. And I was like, It will be the speaking stuff. 

So I find myself in London. And I'm the emcee of the conference. I'm a chair of the conference. And I'm also giving the keynotes, showing people what the art of the possible is. And I would do these keynotes, and what people don't know is behind the scenes as I'm tinkering with the technology, a lot of this stuff is kind of boring to me, but there's something that I'll experiment with that makes me feel a certain way. Like I get excited, like you all have written code before. Sometimes you get something to work and you just do that little dance like, Oh, I did that. And I try to take that feeling of I did that and put it into the keynote. And so when people are watching, I want them to feel like they can do it, too. I want them to have the exact same feeling. And so I was like, That's it. That's my last one. And I get off the stage, and if you've spoken at a conference before, and you do a good job, you're on a very emotional high. But I was ready to let it go. And there were people that were talking to me afterwards, and we walked to the vendor hall where all the sponsors are. And you start to do the, you know, you do the session, the hallway track, and this is where you just stand in the hallway and you just have these side conversations. 

And you can imagine a circle of eight people just standing there chatting about what they just saw, different talks, what they're excited about being here. And one thing I wanted to do in those circles is that when a new person comes up, you part the sea and you give them a slot, right? And then they just stand and they fill in the gaps. And there was a person that looked like me that showed up. And I'm looking at him and I'm like, “Yo, ask me any technical questions you want. This is going to be this. This is my bread and butter. I'm ready. I don't need any prep.” And he asked me a question that I wasn't ready for. He said, “How do you do it? How do you be the only black person in the room all the time?” 

You can imagine the other conference goers in that circle are like, “Whoa, that is not in the README.” And they are looking patiently at two black people having this conversation, and they want to know what the answer is. And I don't think I had a great answer. Because, in that scenario, I've kind of gotten used to it over a 20-year career. You know it's unfortunate and you haven't solved it. But the thing he told me was. And now we're everyone's getting allergies at the same time as probably the seasons, Right. So everyone's eyes are reacting to the allergies. That's what it was. And you said, “Hey, look, I never thought I needed a mentor until I saw you on YouTube. I was watching a video and a guy that looks like me came out and explained to me this new, complicated, open source project they were thinking about using at work and you look like me. And I realize how important that was. So when I knew Kube Con was coming to London, I decided to go and I never knew I needed a mentor until I saw you.” 

And then we were not paying attention in the circle because he said another thing, “I brought my son with me so he could see that not only can we attend the conference, we can lead it. I wanted him to see you in action. You are not just a person scheduled, and all the talks are important, but you're not buried in the schedule. You were highlighted in the program. And look at the number of people that follow you around and ask you all the questions and we can lead.” And I looked down and there's this son. He had both his hands on his shoulder so he can see me in real life. And I was able to shake his son's hand. 

And at that point, I realize sometimes just showing up and being invisible, you give permission to all the people who thought they were not welcome. They realize that they can buy a ticket—because people that look like them are going to be there. And so what I noticed now, these days, and maybe I had a small part to play in that, I go to these conferences and people who look like me, they're there and we don't have to coordinate anymore. We don't have to have a sub Slack channel where we decide what conferences we're going to so we can be safe. We know we're supposed to be there, that we add a lot of value to be there. And so what I learned is that, if you're an underrepresented community, as hard as it is to put in that CFP, as hard as it is to go there and be the only person at the table, it's kind of a necessary evil and it's not fair and it's not right. But it goes a long way. And I decided that I'm going to keep speaking. I'm going to do all the conferences I can possibly do. I'm going to tell the stories. And if I inspire someone who does have a better way to get more people into tech, then I will take that.

Neha: I'm speechless. Well, I also have to recover because you got me in tears. I thank you so much for sharing that. I think that it hit a lot of strings for me as well, personally. I just need a second. I think that there is something really special about that tenacity and the way that you kind of keep your motivation going over such a long period of time. And I'm kind of curious about that reflection when you look back. So how do you view working in open source today versus like ten years ago? And is there any, you know, unique challenges that you wanted to share with us or any different motivations, especially now that you were saying in that conference? But like, you can talk to people who are just starting out and you can share that back.

Kelsey: I mean, you know, one common problem in the early days of tech, at least for me, I was so afraid to apply for a job because when you look at the job requirements, they need 50 years of experience for like 100 different things. And you're like, I thought this was like a junior system administrator. How can you have 50 years of all experience of things? And so. I felt like that was the biggest gate in the world. I could never overcome that to even get started. So I actually opened a small computer shop and there's a long story there, but it felt easier to just do my own thing than meet the qualifications for your first job. 

And when you think about what it takes to build a gate, you can't build a gate unless you have like a strategic positioning, right? The land needs to be narrow enough where the gate can cover both ends to keep people out, and you guard the gate. But open source just feels like an open range. There is no gate you can build long enough for open source because anyone can start a project, anyone can contribute to a project. And so I felt like open source was so inviting. 

So for me, when I started to stumble into open source, no one was checking credentials. No one was like, Fill out this application first. You're like, Yo, thanks for the contributions, no matter how big or small, code or documentation. And I was like, Wow, this is freaking amazing. You can go to any meetup you want. You can talk about any of the tech topics you want. And it turns out a lot of people in that community, people who self-select to be there, most of them are super helpful. Like can't wait to explain to you, like, Oh my God, someone who's interested in Python like I am. I try to have these conversations with my wife and she doesn't care at all. But now I have my tribe. I go to this area and all of these people that want to learn and join me. 

It's one of those things that I think people don't realize until you get in that humans, actually, with competing goals, can come together and work on something to benefit each other. A lot of people don't think that's possible. A lot of people are, “you've got to pick a side.” But an open source, I think, has been one of the most inviting endeavors I've ever been a part of. And so I think the biggest challenge is just educating more people that that's possible. And maybe the way we treat each other in the open source community can rub off in other aspects of society that there are things we can do jointly together with our collection of skills that just benefits everybody. And it's okay.

Martin: I just want to let you know, thank you. It's been an absolute honor for us to have you on the show. You're an inspiration for all of us, so, you know. Thank you. Thanks for your time. But just, you know, thanks for keeping being you. I know it's easy to sort of listen to your own press sometimes and, like, start listening to the ego and things. But I've known you for a while and you've continued to be you. So thank you very much for that. Kelsey Hightower, a software engineer and developer advocate. Thank you for coming on the podcast.

Neha: Thank you so much.

Kelsey: Awesome. Thanks for having me. Yep.

Martin: Thanks so much again to Kelsey Hightower for that amazing conversation. He’s always just so thoughtful and kind. 

And before we go, I loved that Kelsey mentioned the support that can be found in the open source community, especially among maintainers. To celebrate that camaraderie we asked a few other maintainers if they wanted to give a shoutout to someone THEY’d like to thank. You should hopefully recognise a few familiar voices for those who have been around The ReadME Project for a while. To everyone who maintains an open source project, thanks from everyone here!

Aaron Francis: My name is Aaron Francis. I am the maintainer of Sidecar for Laravel. But more importantly, I want to thank Caleb Porzio for being the best open source maintainer that I know. He is such an inspiration to me. Caleb maintains Alpine J.S. and Laravel Livewire. I don't know how he does it all and he does it all with such a good attitude. Thank you, Caleb, for being the best.

Frances Coronel: I'm Frances Coronel and I'm the maintainer of Latina dev, an open source directory of Latina software engineers. I want to give a big shout out to Gabriella Corales, a fellow front-end developer. Gabby was the first person to volunteer and help me develop the MVP version of the web app. She’s also onboarded four other contributors so far to support us with design, documentation, and back-end development. So I really appreciate all that you're doing, Gabriella, and thanks so much.

Anthony Sottile: Hi, my name is Anthony Sottile and I maintain Pre-Commit, Flake8, PyTest, and more. I’d like to give a shout-out to Julian Berman, who maintains Python JSON Schema and also works on shaping the specifications for JSON Schema for all the other programming languages. Julian inspires an opinionated yet practical approach to open source with a healthy dose of dry humor as well.

Cassidy Williams: Hi, my name is Cassidy Williams and I’m the CTO at Contenda, a GitHub Star, and I love open source. I want to acknowledge Moriel Schottlender who is a systems architect at Wikipedia, a localization and accessibility evangelist, and an advocate for building all things out in the open. So many developers, including myself, can and should learn a lot from her.

Peter Strömberg: Peter Strömberg here. I created Calva, a Clojure extension for VS Code, which takes its main inspiration from CIDR for Emacs. The CIDR maintainer Poser Bastov is my main inspiration for managing Calva. Thanks [NAME]. I love the way you speak to your users and how you steward your open source projects. 

Brandon Ringe: I'm Brandon Ringe and I’m a co-maintainer of Calva. I want to give a shout out to Peter Strömberg, the author of Calva, for being such a great collaborator and for welcoming me into the project as a maintainer, which has been such a rewarding journey since day one.

Martin: That’s it for this episode of The ReadME Podcast. Thanks as always for listening. We’ll be back next month with our regularly scheduled episode. If you’re a fan of the show, you can find more episodes wherever you get your podcasts. Make sure to subscribe, rate, and review. Or drop us a note at [email protected]. You can also learn more about all that we do at GitHub by heading to github.com/readme.

CREDITS: GitHub’s The ReadME Podcast is hosted by Neha Batra and Martin Woodward. Audio Production and editing by Reasonable Volume. Original theme music composed by Zander Singh. Executive producers for The ReadME Project and The ReadME Podcast are Robb Mapp, Melissa Biser, and Virginia Bryant. Our staff includes Stephanie Moorhead, Kevin Sundstrom, and Grace Beatty. Please visit GitHub.com/readme for more community-driven articles and stories. Join us again next month and let's build from here. 

Martin: Dude.

Neha: Oh, my God. I'm wrecked for the whole day.

Martin: I know. Not a dry eye in the house, for sure, that was amazing.