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

The biggest misconception about open source contributions is that you need to write code. Scroll through GitHub, and it’s easy to assume that pull requests are the only currency that matters. But according to Kat Cosgrove, Kubernetes Release Team Subproject Lead and Head of Developer Advocacy at Minimus, that assumption is killing potential contributions from people who could make a massive impact.

Cosgrove hasn’t written code for Kubernetes. She’s written tons of documentation and done extensive project management work. And those contributions are just as critical to Kubernetes success as any feature implementation or bug fix.

“No open source project—ever—is going to succeed just on the back of really good code,” Cosgrove states emphatically. “That doesn’t matter if people can’t use your project because the documentation is poor or nonexistent.”

The Documentation Crisis Nobody Discusses

Great code with terrible documentation is unusable code. This isn’t a controversial statement, yet the open source community continues to undervalue documentation work compared to code contributions. The result is projects with powerful capabilities that nobody can access because the learning curve is impossibly steep.

Kubernetes has invested heavily in documentation, and Cosgrove credits that investment as a significant factor in the project’s success. But even with that commitment, the documentation team constantly needs more contributors.

Technical writing is a valuable skill for open source projects. If you can write clearly about complex technical topics, you’re needed. If you can read and understand a style guide, you can review documentation for compliance. Sit there reviewing documentation long enough, and projects will make you an approver with the ability to merge documentation changes.

The work matters because documentation is how most users first encounter a project. If they can’t understand how to get started, they’ll move to something else. All the brilliant code in the world doesn’t matter if users bounce off poor documentation.

The Localization Gap

The need for non-code contributions becomes even more apparent when looking at localization efforts. The Kubernetes documentation is localized into multiple languages, all done by real people. The project doesn’t use AI tooling for translation, and Cosgrove indicates they almost certainly never will.

The localization situation reveals a stark reality. Only one language team is fully staffed: Hindi. Every other localization team needs help.

“If you fluently speak a language other than English, that’s a valuable skill for an open source project,” Cosgrove explains. “If you speak a language that’s not English, please come join one of our localization teams.”

This is a concrete, high-impact way to contribute that requires zero coding ability. If you’re bilingual and can read technical documentation, you can make Kubernetes accessible to thousands of developers who would otherwise be excluded.

The gap in localization staffing also highlights a broader issue about whose voices get centered in open source. English dominance in technical documentation creates barriers for developers worldwide. Localization work directly addresses that inequality and makes the ecosystem more globally accessible.

Project Management: The Unsexy Essential

Another undervalued contribution type is project management. Cosgrove describes all open source maintainers as essentially engineers who developed project management skills. But people who already have those skills can contribute directly.

The Kubernetes release team provides a structured entry point for people with project management experience. Applications open about two weeks before the start of every release cycle, so at most you’ll wait three months for the next opportunity.

“If you have project management skills and you don’t know how to start on doing that for an open source project, come try to join the Kubernetes release team,” Cosgrove invites. Not all projects have something as formal as the release team, but all projects need coordination, planning, and organizational work.

The release process requires tracking enhancements, ensuring production readiness reviews happen, confirming user-facing changes have documentation, and making sure everything ships on time despite inevitable obstacles. None of that is coding, and all of it is essential.

Marketing Still Matters

Even marketing is a necessary open source contribution that gets overlooked. Projects need visibility to attract users and contributors. The CNCF provides marketing resources for projects donated to the foundation, but projects still need people who understand positioning, messaging, and audience development.

“Open source projects still need marketing,” Cosgrove points out. “It’s always a mistake to focus on only ever caring about the code when there’s so much more going on to ensure that your project actually succeeds.”

The Other Side: When Code Contributions Aren’t Welcome

Billy Thompson, Senior Global DevOps & Platform Engineering at Akamai, adds a perspective that contributors need to hear but rarely do. Sometimes code contributions genuinely aren’t welcome, and it’s not because maintainers are being difficult for no reason.

“Sometimes that really isn’t what people want,” Thompson explains. “Because you also have to consider the people maintaining this and their responsibility to maintain it. If a whole bunch of people are contributing some code and just sort of contributing it and then moving on with their lives, the maintainers still have to maintain that long term.”

Maintainers may have very specific reasons for not wanting certain features added. The maintenance burden they already carry might be crushing. Adding more code to maintain, even good code, can make an unsustainable situation worse.

This creates tension between contributors who want to give back and maintainers who are already overwhelmed. Understanding that dynamic helps contributors channel their efforts more productively. Sometimes the most helpful contribution isn’t a new feature. It’s documentation for existing features, or fixing bugs in code that already exists, or testing and validation work that reduces maintainer burden rather than increasing it.

The Toxic Maintainer Problem

But Thompson also raises an issue that nobody wants to discuss publicly. Some projects suffer because the maintainers themselves are difficult to work with.

“It’s also just as much kind of on the maintainers to be open to working with people and not berate people for their PRs and the issues that they’re opening,” Thompson states. “There’s the flip side of this too, that I feel like nobody’s saying.”

Toxic maintainer culture kills projects. When maintainers are hostile, dismissive, or cruel to contributors, people stop contributing. The project stagnates, and eventually dies or gets forked by people who can create a healthier culture.

Maintainers carry enormous responsibility and often work without adequate support or compensation. Burnout is real and understandable. But that context doesn’t excuse creating hostile environments that drive away the very people trying to help.

The responsibility for healthy open source culture goes both ways. Contributors need to respect maintainer boundaries, understand maintenance burden, and expand their definition of valuable contribution beyond code. Maintainers need to create welcoming environments, communicate clearly about what kinds of contributions are helpful, and treat contributors with basic respect even when declining contributions.

Redefining Value in Open Source

The open source community needs to fundamentally expand its definition of valuable contribution. Code matters, but it’s not the only thing that matters. Documentation enables usage. Localization enables access. Project management enables coordination. Marketing enables discovery.

For individuals wanting to contribute, this is liberating news. You don’t need to be a developer to make a meaningful impact. If you can write, translate, organize, or communicate, open source projects need your skills.

For projects, this is a call to actively recruit non-code contributors and treat their work with the same respect given to code contributions. Create clear pathways for documentation review, localization work, and project management. Recognize and celebrate those contributions publicly.

The sustainability of open source depends on expanding who can contribute and how. The code-only model leaves too much talent on the sidelines and creates an unsustainable burden on the small number of people doing all the unsexy essential work.

As Cosgrove puts it: good code alone will never be enough.