Guests: Kat Cosgrove | Billy Thompson
Companies: Minimus |Akamai
Show Name: KubeStruck
Topics: Kubernetes, Open Source

Most people don’t plan to become open source maintainers. They see something broken, know how to fix it, and can’t let it sit there. That impulse, repeated over and over, eventually pulls them into the core of major projects. For Kat Cosgrove, it happened at six in the morning before coffee, with 11 tweets that went viral and changed the trajectory of her career.

Cosgrove is now the Kubernetes Release Team Subproject Lead and Head of Developer Advocacy at Minimus. But when the Dockershim deprecation drama erupted, she was just a software engineer using K3s who was tired of watching people panic about something they didn’t understand.

The Dockershim Drama That Nobody Handled Well

A few years ago, the Kubernetes project made a decision that sent shockwaves through the entire tech community. They announced the deprecation of the Dockershim, a small piece of software that allowed users to continue using the entire Docker tech stack as their container runtime.

The technical reality was straightforward. The shim only provided access to the instance of containerd running inside Docker Engine. Kubernetes wanted to standardize interfaces for container runtimes, and the Dockershim was a maintenance nightmare that didn’t align with the project’s long-term vision. It made sense to deprecate it.

The communication of that decision, however, drastically underestimated what the average person understood about the relationship between Kubernetes and Docker. “We, well, I say we, I was not involved in the deprecation,” Cosgrove clarifies. “But the Kubernetes project drastically overestimated what the average person understood about the relationship between Kubernetes and Docker, and the difference between Docker and just a container image.”

The result was immediate panic. Cluster admins freaked out. Software developers who didn’t directly touch Kubernetes but developed containerized applications freaked out. Some people thought Google was killing Docker the company. Others thought Morantis was being targeted. Many believed Docker as a tool was going away entirely and that containerized applications were doomed.

The miscommunication was spreading fast, and nobody from the Kubernetes project had effectively addressed the confusion in terms that non-experts could understand.

Going Viral By Accident

Cosgrove was watching this unfold at six in the morning. She hadn’t had coffee yet. And she saw an entire community panicking about something that didn’t warrant panic.

“I saw people freaking out, and they were wrong. They were freaking out about something they didn’t need to freak out about. And I explained it in about 11 tweets,” she recalls.

Those 11 tweets went viral on tech Twitter, an experience Cosgrove describes as super uncomfortable. She went from around 4,000 followers to 12,000 in approximately 36 hours. The sudden visibility was disorienting, but it also got the attention of the Kubernetes SIG contributor experience team.

They pulled her in to write FAQs and provide historical context. Why had Kubernetes been allowing Docker Engine all this time anyway? What was actually changing, and what would remain the same? Cosgrove provided the explanations that the project desperately needed to calm the community down.

And then she just never left.

Sucked Into The Bog

“I just kind of didn’t leave,” Cosgrove explains. “It’s like getting sucked into a bog, right? Because suddenly I could see all of this other stuff. Oh, I know how to fix that, and you’re just letting it sit there. Give me that, I’ll fix it.”

That pattern repeated. One fix led to seeing another problem. Another problem led to joining the release team. Three years on the release team led to leading a release. And then they gave her the entire subproject.

“Now I’m truly trapped. Now I herd cats professionally for an open source project,” she says with a laugh. “It’s fun, though. There’s no end of problems for me to solve. So I really enjoy it.”

This accidental path into open source maintenance is more common than many people realize. Very few maintainers set out with the explicit goal of becoming project leaders. They start by fixing one thing that bothers them, and the momentum builds from there.

A Different Path, Same Impulse

Billy Thompson, Senior Global DevOps & Platform Engineering, Office of the CTO at Akamai, took a completely different route into open source, but the underlying motivation was remarkably similar.

His Windows laptop was unbearably slow. He couldn’t stand it anymore. So he told a techie friend to wipe it and install Linux, and he would figure it out from there.

That forced immersion into Linux led Thompson to Stack Overflow, where he became a regular asking questions. “That would be my big introduction to the really massive developer community,” he explains. Eventually he became someone who could help answer questions on Stack Overflow. He learned Python, then Java, and kept expanding from there.

But Thompson knows himself well enough to recognize his limitations. “I am not a maintainer of anything, and I probably never will be,” he states clearly. “I write a lot of code, certainly, and I love writing code, and I try to share it as much as I can, but my ADHD is just too off the rails for me to consistently stick with one thing long term.”

His ADHD affects even his consumption of content. He loves the Oxide and Friends podcast, finds the content consistently juicy, but still struggles to sit through entire episodes. The idea of committing to long-term maintenance of a single project feels impossible.

Code Everything Like It’s Open Source

Thompson’s inability to be a traditional maintainer led him to develop a different contribution philosophy, one that might actually produce better results across the board.

On his last product development team, they implemented a simple rule: anything the team wrote for internal use had to be evaluated through one lens. Can I open source this, and how will I open source this?

“Not only does that mean we need to write it just right from the get go, stop ourselves from coding things that just help us, but how can this help other people with the same problem,” Thompson explains. “And also doing it that way, it just ends up being better code when you’re thinking about the perspective of other people who are trying to read this and maybe use it and hopefully contribute to it later on.”

This philosophy transforms how code gets written from the very beginning. When you assume other people will need to read, understand, and potentially modify your code, you write it differently. You document more clearly. You structure it more logically. You avoid shortcuts that only make sense with internal context.

Thompson carries that approach into everything he codes now. Even if the code never gets open sourced, it’s better code because it was written with that possibility in mind.

Two Paths, One Truth

Cosgrove’s journey from annoyed engineer to release team lead, and Thompson’s approach of contributing everywhere without long-term commitment, represent two valid ways of participating in open source ecosystems. Both are driven by the same fundamental impulse: seeing problems and wanting to fix them.

Open source doesn’t require everyone to become a maintainer. It needs people like Cosgrove who get pulled into the bog and embrace the endless stream of problems to solve. It also needs people like Thompson who contribute thoughtfully across many projects without committing to any single one.

What matters is the underlying mindset. Don’t let broken things stay broken when you know how to fix them. Write code like other people matter. Contribute where you can, in whatever way works for your brain and your life circumstances.

That’s what keeps open source sustainable. Not grand plans or career ambitions, but the accumulated effect of people who see something wrong and can’t walk away from it.