From contributor to maintainer: A guide to building an open source career

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

In this case, there are no specific technical terms that require hyperlinks based on the provided LINKS table. The transcript is a straightforward introductory question asking about the speaker's background.

Phil: My name is Phil Estes. I'm a principal engineer at Amazon Web Services, and I currently work on the open source strategy team, leading our open source strategy around container technology and cloud native.

Bart: How did you first come into contact with cloud native and Kubernetes?

Phil: Docker engine and Docker tooling were my initial introduction to this space. I got interested in the project and started contributing to the Docker open source project. I became very involved and became a maintainer. Docker became the initial container runtime used by Kubernetes. Out of that came Containerd, which was donated to the CNCF, and I was part of launching that container runtime project that became the basis for many Kubernetes installations over the years.

Bart: And to walk folks through the story of Containerd, what was it like at that point when it wasn't entirely certain how things were going to develop? The community was growing, but perhaps there wasn't 100% certainty about the direction in terms of adoption and other considerations.

Phil: [Definitely very interesting days if you go all the way back to 2014, 2015. In the couple years after that, Kubernetes was around in those early days of Docker, but it was really around 2016, 2017 when things like the CNCF were created, and Kubernetes was donated as the first initial project.

There were actually a fairly strong set of conflicts and friction around these communities, the Docker engine, and different ideas about how container orchestration should be architected. Docker came out with their own ideas. Containerd emerged from this desire to have a common core that wasn't beholden to Docker the company or the Docker project that had its own orchestration technology built into it.

Containerd is really a success story of people who were in this moment of friction and conflict, coming up with a solution that solved everyone's problems. Docker could still have this base to build their product, and Kubernetes could have a core runtime engine without other orchestration concepts. I was really happy that out of that tense moment, Containerd came and became very successful by being a simple and small core runtime that could be used by anybody, including Kubernetes.]

Bart: Fast forwarding to nowadays, this ecosystem moves very quickly. What works best for you to stay up to date on all the changes that are happening?

Phil: Events are a huge part of staying connected, such as KubeCon, Open Source Summit, and Kubernetes community days. Between talks and the more important "hall track", you really find out where people are heading and what new things they're trying.

It's been interesting to see the waves of new ideas over the years. Networking and CNI were huge, with many startups emerging in that space. Security became a significant focus, again attracting numerous startups. Now we're experiencing the AI wave and related technologies.

There are two perspectives: it's impossible to keep up, and yet staying connected to the community is crucial. I'm not big on aggregators and news services, but personal connections and CNCF Slack are where the real chatter happens that keeps me up to date.

Bart: And in terms of people in the ecosystem, could you give us an example of one or two people that helped you level up?

Phil: A name immediately comes to mind who sadly is not really very visible anymore: Michael Crosby, an early Docker engine maintainer and early employee of Docker. He was super quiet, but his code is in everything we're using today in the cloud native stack. I had the opportunity in those early days to sit with him in person and get his guidance on how to be a good contributor and what to work on next. I definitely credit him with launching my open source career.

There were others at the time. Jessie Frazelle was also at Docker, but she was at the other end of the spectrum. She was extremely well-known on Twitter, with around 90K followers. She and Kelsey Hightower were coming of age at that point, super popular at conferences with packed talks. Jessie and Kelsey were part of the early Docker community and gave me a lot of guidance. They were awesome people to follow.

Bart: We're talking to a lot of different people, and when we asked the question about "What is Kubernetes", we get different answers. There's no right or wrong answer. Phil, in your case, what is Kubernetes for you?

Phil: I started in the container runtime space. Kubernetes is a set of APIs and constructs that takes the concept of containers and container runtimes and allows you to orchestrate across, in the early days, a smaller number, but now tens of thousands of nodes. This enables effectively distributing workloads across cloud data centers and private data centers.

Kubernetes brought an additional layer of capability to containers that let people do amazing things with orchestration. Every cloud provider in the world now has a Kubernetes offering, and it became the de facto standard for how we orchestrate across a set of nodes.

Bart: Going back to your mention of early contributions to Containerd, what were those initial steps like where you decided this was a good place for you? How did you transition from contributor to maintainer? Was there a moment when you really decided you wanted to get more involved? What was it about the experience that attracted you?

Phil: My first experience was with Docker and Containerd. My early experiences were initially directed by my employer, who suggested I get involved in this open source project as containers were taking off. I had a background in Linux packaging and distro technology, so I jumped in. It was the first time I'd been deeply involved in open source in 10 years. Previously, I had been packaging Linux distros and working with community outputs.

What really excited me about the Docker community was the experience of creating a code change, having it reviewed, and accepted into the project. As simple as it sounds, there was a dopamine effect—"Wow, that was fun. I'm going to do this again." Over time, as I contributed small bug fixes and changes, I became more knowledgeable about the codebase. It became clear that I loved working in this project and could help maintain it.

It wasn't a single moment, but a gradual process of pouring my time and effort into something I wanted to help make successful.

Bart: For folks interested in becoming contributors, as opposed to maintainers, what are the different roles and levels of participation? Is there a question of status or being taken seriously when moving from one role to another? Not everyone might be suited for every role. For people curious about getting involved, what should they keep in mind if they want to be a contributor or make the jump to becoming a maintainer?

Phil: I have always told people who want to get involved in communities: go find where that community hangs out and meet who's involved. In our virtual world, that could be Slack, some older open source projects' email groups, or platforms where you can see community interactions. Some of that lives on GitHub, with maintainers responding to contributors or having discussions.

I find that early contributors succeed faster when they get involved in the community rather than just submitting their first contribution without any prior interaction. It's hard to understand their purpose when no one knows them.

Communities need all kinds of help, and it's not always about code contributions. My best story is about Sebastian, who showed up in the Docker community and said, "I don't know Go yet. I'm probably not going to contribute code, but I'd love to help organize your issues." He became an encyclopedia of every open issue, helping link similar issues and providing context. Now he's a Docker employee who manages and is a containerd reviewer.

People often say documentation is hard to keep up to date in fast-moving projects. If you're a good writer who can think about how someone might read a getting started guide, you can help by identifying excessive jargon or assumptions about a new user's existing knowledge.

There are multiple ways to jump in: find out who's in the community, make a friend, and see what help they need.

Bart: Over your career, you've mentored lots of different people and helped shape newcomers. For folks who have recently become maintainers, are there things they should keep in mind to create a culture where people feel open to ask questions, reach out, and get resources? Are there any recommendations you would share or common mistakes to avoid?

Phil: I think we've talked about this a lot in the containerd community. When something's virtual, it takes extra effort to make a community feel welcoming. There's no doormat, no room you walk into. How do we make people feel we're willing to accept their expertise with documentation?

When I see on GitHub that it's a first-time contributor—like when someone opens their first issue or pull request—we can sometimes be short in our responses because we're busy. I tend to be overly wordy to ensure they know: "Thanks so much for opening an issue" or "I'd like to help you."

For example, if they didn't sign their commit, I'll point them to a guide and encourage them to reach out. Being overly empathetic is key: we're glad they're here and trying to help, even if they didn't follow the guide perfectly.

Important for communities to realize everyone's human. Taking that extra step to make people feel welcome and wanted is crucial. We may have fallen short sometimes due to being busy, but the recommendation is to always acknowledge and appreciate when someone tries to contribute.

Bart: And you work deeply on the technical side, but you've also been involved speaking publicly and being vocal about the projects you're working on. How do you find the balance between deep engineering contributions and visible non-code work? I mentioned the essential nature of having good documentation, but also blog posts, speaking, community organization, and more. For folks out there who might struggle with technical contributions or public communication, what advice would you give to those wanting to excel in both deep technical work and creating content?

Phil: First, recognizing it's a hard balance to do both well. I did a bunch of initial deep technical work in Docker, implementing user namespaces, which at the time was something people had wanted, but no one had done all the work. I did the work, and it was difficult. Getting it over the finish line took forever.

Then I wanted to tell everyone about user namespaces and why you should use them. I started submitting talks to conferences and getting some accepted. Sometimes it's an ebb and flow. When there's a bunch of work to do, I probably won't have time to submit every talk or write every blog post.

The cool thing is that doing great work gives you awesome content to talk about. I'll think, "Here's some new stuff I want to do, and it would be cool to talk about how it applies to this—maybe I can submit it to the next KubeCon." It takes extra effort to consider CFPs and their deadlines.

To me, the awesome thing about having deep technical work under your belt is that your talk can be more relatable to developers and engineers. I'm not just pitching something my company is doing; these are things I actually did. I want to share what I learned, how I hit a roadblock, and overcame it with a solution. Those talks tend to be more exciting than generally talking about a random topic.

Technical work and sharing can go hand in hand, but there's no magic bullet. It takes extra effort to think about how this work will turn into talks, blog posts, and other content.

Bart: Throughout the course of your experience and contributing to open source, what's one lesson about building a reputation that you didn't expect? Something that only became clear after years of being involved.

Phil: I never expected to be stepping back to my earlier work. I worked 15 to 20 years before open source, and no one outside of my company or teams knew anything about me or what I did. What was crazy is that now, over 10 to 12 years into an open source career, I've had opportunities to talk at conferences and share information about Containerd, project history, Docker, and Kubernetes.

When I joined AWS four and a half years ago—and maybe this is a humble brag—some younger Amazonians would send me messages on Slack saying, "I can't believe you're here. I've watched every one of your talks and learned so much about containers from you." That was really rewarding. It didn't come after one or two talks or just a year or two, but from a decade of generating content and speaking at conferences.

In my previous work, no one ever approached me to say they loved what I do or had watched my talks. I'm no Kelsey Hightower or Joe Beda, but I've had an impact and helped people learn things. It took a lot of hard work—boring tasks, working on difficult problems, and consistently crunching away on maintainer tasks.

To me, it was a cool feeling that all of that added up to a reputation of helping people learn about containers and cloud native technologies. I never set out with the goal of having people walk up and say they learned something from me, but it's a pretty amazing outcome. Because our community is open and we can share information freely through writing, publishing, and videos, having this kind of experience is truly unique.

Bart: A big lesson for newcomers in the ecosystem is that they might be expecting a turnaround of two months or something that will skyrocket them to a keynote stage. As with most things in life, these things take time. As someone who's been in the ecosystem for five years, you start to see the impact of things you did in the beginning bear fruit, with some things likely taking even longer.

I definitely echo what was shared: a lot of the work that isn't necessarily the most glamorous helps you build lasting relationships with people. Also, it's important to recognize that you don't need to be Kelsey Hightower or Joe Beda. That's their job, and it's great. Everyone has their own way to contribute and their own story to share.