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

Kubernetes orchestrates the world’s most critical workloads, but who orchestrates Kubernetes? Behind the second-largest open source project on the planet is a community grappling with burnout, sustainability challenges, and the pressing question of corporate responsibility. In a candid conversation, Kat Cosgrove, Kubernetes Release Team Subproject Lead and Head of Developer Advocacy at Minimus, and Billy Thompson, Senior Global DevOps & Platform Engineering, Office of the CTO at Akamai, pull back the curtain on what it really takes to keep this massive ecosystem alive.

From 15 Friends to 300 Strangers: The Growing Pains of Maturity

Kubernetes has evolved from a promising container orchestration tool into the backbone of cloud native computing. As the second-largest open source project in the world after Linux, it underpins a significant portion of global digital infrastructure. But with that success comes complexity. The CNCF landscape has become overwhelming, stretching like Atlanta itself—compact at the center but sprawling seemingly forever in every direction.

Cosgrove describes the cultural challenges that come with this growth. Kubernetes is 11 years old now, and many original maintainers are still around, creating an interesting dynamic. The project has had to confront a difficult reality: it’s no longer just a group of friends building something cool together. When you go from 15 close collaborators to 300 strangers relying on your work, everything changes. Documentation that never seemed necessary suddenly becomes critical. Processes that were understood through years of working together now need to be explicitly written down for newcomers who don’t have a decade of social context.

Thompson offers an external perspective, noting that despite these growing pains, Kubernetes has been a marvel of maturity for years. The project set the standard for open source governance and community-first development. From his vantage point at Akamai, he’s watched Kubernetes conferences bring together everyone from hobbyist developers on an activist mission to large enterprise teams, all genuinely excited about open source and its community aspect.

The Perfect Storm: Why Kubernetes Succeeded

What made Kubernetes explode in popularity wasn’t just one factor—it was perfect timing meeting perfect execution. Docker had just made containers accessible and shareable, causing an explosion in containerized application development. But the industry lacked a good way to manage these containers at scale. Kubernetes landed at exactly the right moment, backed by Google engineering talent and supported almost immediately by the newly formed CNCF and the resources of the Linux Foundation.

But there’s another often-overlooked factor: cultural timing. This was the moment when the industry finally accepted that open source could be profitable. The expensive Red Hat acquisition helped convince skeptics that open source wasn’t just for “internet hippies” but a legitimate business model. Companies saw an opportunity to build profitable services around this technology, driving rapid adoption and ecosystem growth.

The Hidden Crisis: When Money Isn’t Enough

Here’s the uncomfortable truth that Cosgrove doesn’t sugarcoat: most Kubernetes maintainers are burned out. Despite the project’s success, despite corporate sponsorships, despite all the momentum, the people actually doing the work are crispy. And Kubernetes isn’t alone. The External Secrets Operator crisis exemplified a problem spreading across the open source ecosystem. ESO maintainers, despite receiving financial sponsorship from companies, threatened to stop releasing the project entirely. Why? Because they didn’t have enough people, enough maintainers, enough approvers. Money doesn’t write code. Money doesn’t review pull requests. Money doesn’t manage releases.

Cosgrove is blunt about what companies owe the projects they depend on: both financial resources and actual engineering hours. If your product makes you money—maybe even made you rich—and it relies on an open source project, you have an obligation to contribute back. Not just sponsor it with cash, but dedicate engineers to working on it. Even a few hours a week from an engineering team makes a massive difference. Otherwise, that critical infrastructure you depend on might simply disappear. Open source maintainers can turn it off whenever they want, with no legal obligation to issue a deprecation notice.

Thompson adds perspective from the enterprise side, pointing out that the bottleneck is often ridiculous company policies rather than lack of willingness. Employee contracts that claim ownership of any code written on company computers inhibit contribution. Companies that have figured out marketing and could easily help with documentation or community building simply don’t think about it as their responsibility.

Contributing Beyond Code: The Overlooked Opportunities

One persistent myth is that contributing to open source means writing code. Cosgrove hasn’t written code for Kubernetes—she’s written documentation and done project management. And that’s exactly what the project needs. Technical writers, project managers, people fluent in languages other than English, anyone who can review documentation for style guide compliance—these skills are all valuable and desperately needed.

The Kubernetes documentation is localized into multiple languages, all done by real people, not AI tooling. Most localization teams need help. The release team is always looking for people with project management skills. No open source project succeeds on good code alone. Without documentation, without marketing, without community building, even the best technical solution will fail.

Thompson emphasizes the flip side: maintainers also need to be open to working with people rather than berating contributors for imperfect pull requests. The responsibility for healthy open source culture runs both directions.

The OSPO Decline and What It Signals

For a while, the industry seemed to be moving in the right direction. Companies were spinning up Open Source Program Offices, instilling open source culture internally, and making significant upstream contributions. But in the last couple of years, many OSPOs have been decimated by layoffs. Cosgrove can’t tell if this represents companies deciding that contributing back isn’t profitable, or if it’s just another symptom of widespread belt-tightening despite record profits.

If this trend continues, we’ll see more crises like ESO. We’ll see more critical projects, maintained by just a few people, suddenly disappear. Even Kubernetes, with all its resources and institutional support, isn’t immune. The project struggles to find maintainers. Senior leadership has been around for a long time, and replacing them is hard.

AI Hype: Web3 All Over Again?

Asked about AI workloads on Kubernetes, Cosgrove’s skepticism is palpable. Kubernetes isn’t doing anything special to enable AI workloads—it’s just the default way to orchestrate containers in a distributed manner, so of course some AI workloads run on it. But she sees the current AI boom as remarkably similar to the Web3 and blockchain hype cycle. There’s a small handful of actually innovative AI tools, and an ocean of mostly useless shiny wrappers around them. Companies are hard-pivoting to AI overnight to please investors, and we’ll likely look back on this moment with embarrassment.

Thompson takes a more measured view, comparing it to the Kubernetes hype bubble itself. Some people understood the specific problems Kubernetes solved and benefited greatly. Others just jumped on the bandwagon, running self-managed clusters to host static landing pages that could have been an S3 bucket. AI is following the same pattern—it will solve specific problems for people who understand what they’re using it for, while others will burn money chasing hype.

The Burnout Reality and What Keeps People Going

When pressed about burnout, Cosgrove doesn’t hide it. She’s burned out. Most open source maintainers working on projects this long are burned out. They’re all crispy. The trick is not letting people see it, because when you’re an open source maintainer and developer advocate, you don’t get to have a bad day in public.

Her coping mechanisms are revealing: lying to both coworkers and friends at long conferences to steal alone time at nice restaurants with a book. Not working at all in December. Spending time in the mountains without cell signal or electronics. These aren’t just nice-to-haves—they’re survival strategies.

Thompson burns out and reignites frequently, trying to work his right brain more with analog music production and creative work to balance the constant left-brain coding. He admits to coding through an entire night before the interview without realizing it, too locked into what he was building to notice time passing.

Why It Still Matters

Despite the burnout, despite the challenges, despite companies not pulling their weight—both Cosgrove and Thompson are still here. The cloud native community has created something rare: a genuinely welcoming space where developers feel at home. Strong codes of conduct with teeth, enforced diversity requirements for conference panels, and a culture that prioritizes community over transactions all contribute to people wanting to participate.

Kubernetes isn’t going anywhere. It’s foundational to the CNCF and will remain so. Whether it becomes as broadly fundamental as Linux, or gets abstracted away like every other technological leap since the ENIAC, it will continue underpinning the cloud native ecosystem. But its sustainability depends on companies understanding their responsibility to contribute more than money, individuals realizing they can contribute more than code, and the community continuing to prioritize people over technology.

The question isn’t whether Kubernetes will survive—it’s whether the people maintaining it will thrive while doing so.