Skip to content
Welzin
Talk to us
← All posts

WOSS

How to Contribute to CNCF: A Practical On-Ramp from First PR to Maintainer

Aman Mundra · 2026-07-04

TL;DR - The Cloud Native Computing Foundation (CNCF) crossed 300,000+ contributors in 2026, and there's a well-worn path from your first pull request to becoming a maintainer. This is that path: find the right project, land a "good first issue," plug into a TAG, use programs like LFX Mentorship, and climb the contributor ladder. No permission required - just the on-ramp, mapped.

Most engineers assume contributing to CNCF is reserved for a priesthood of Kubernetes core developers. It isn't. In 2026 the CNCF community passed 300,000 contributors - and the vast majority started exactly where you are: staring at a huge ecosystem, unsure where to put their first commit.

Here's the map I wish I'd had. It's the same map Welzin Open Source Software (WOSS) uses to anchor its own upstream work on kagent, a CNCF Sandbox project.

What is CNCF and how is it organized?

The Cloud Native Computing Foundation is the vendor-neutral home of the cloud-native ecosystem - Kubernetes, Prometheus, Envoy, containerd, and 150+ other projects - hosted under the Linux Foundation since 2015. Understanding its shape tells you where a contributor fits:

LayerWhat it isWhere you contribute
Projects150+ repos across three maturity tiersCode, docs, tests, triage
TAGsTechnical Advisory Groups by domainWhitepapers, reviews, cross-project work
ProgramsLFX Mentorship, GSoC, OutreachyMentored, scoped projects
EventsKubeCon + CloudNativeCon, KCDsIn-person community, talks

Every project also carries a maturity badge - Sandbox, Incubating, or Graduated - that shapes how welcoming it is to newcomers. That distinction warrants its own guide; the short version is that smaller, earlier projects are usually the fastest on-ramp.

Why contribute to CNCF at all?

Three honest reasons. Skill - there is no faster way to level up than shipping code reviewed by the people who built the tools you use daily. Reputation - a merged PR in a CNCF project is a public, permanent credential no bootcamp can match. Leverage - for a company or a community like ours, upstream contribution is how you earn real influence over the infrastructure you depend on.

And the ecosystem genuinely needs you. Across 150+ projects at every maturity level, maintainers are perpetually short on hands for triage, docs, tests, and fixes. Contribution isn't charity you're begging to give - it's a gap you're helping close.

Where do you actually start?

Not with Kubernetes core. That's the deep end. Start narrower:

  1. Pick a project you already use. You'll understand the problem space and care about the outcome. A Sandbox or Incubating project (like kagent) moves fast and welcomes newcomers more readily than a graduated behemoth.
  2. Read its CONTRIBUTING.md and Code of Conduct. Every project has its own flow - DCO sign-off, PR templates, test commands. Respect it.
  3. Find a "good first issue." Most projects label them. Filter the issue tracker for good first issue or help wanted.
bash
# Browse good-first-issues across a project on GitHub
# Filter: is:issue is:open label:"good first issue"
gh issue list --repo kagent-dev/kagent --label "good first issue" --state open

Claim one by commenting, and you're in.

How do you land a clean first PR?

The mechanics matter more than the size of the change. Most CNCF projects use a Developer Certificate of Origin (DCO) rather than a CLA, which means every commit must be signed off. A typical first-PR loop looks like this:

bash
# 1. Fork, clone, and add the upstream remote
git clone git@github.com:<you>/kagent.git && cd kagent
git remote add upstream https://github.com/kagent-dev/kagent.git

# 2. Branch, make your change, then commit WITH sign-off (DCO)
git checkout -b fix/typo-in-crd-docs
git commit -s -m "docs: fix typo in Agent CRD reference"

# 3. Run the project's tests/linters BEFORE pushing
make test && make lint

# 4. Push and open the PR against upstream main
git push origin fix/typo-in-crd-docs

Three things reviewers quietly reward: a PR that does one thing, a description that links the issue it closes (Closes #123), and green CI on the first push. Miss the DCO sign-off and a bot will block the merge - git commit --amend -s fixes it.

What are TAGs and why do they matter?

CNCF Technical Advisory Groups (TAGs) coordinate whole areas of focus - runtime, security, observability, network, and more. They're where the cross-project thinking happens: whitepapers, best practices, project reviews.

For a contributor, a TAG is a shortcut to belonging. Join a TAG's meetings and Slack and you stop being a stranger dropping PRs into a repo - you become a known face in the domain. Many maintainers and reviewers are active in TAGs, and it's often where mentorship and opportunities surface before they hit a job board. Pick the TAG that matches your interest and show up.

For WOSS specifically, the relevant surface is TAG Runtime and the cloud-native-AI conversation - the same intersection our anchor project kagent lives at, bridging CNCF and the Agentic AI Foundation (AAIF) via the Model Context Protocol. Aligning your TAG choice with the project you contribute to compounds: the people reviewing your PRs are the people in the meeting.

How do the mentorship programs work?

CNCF runs structured on-ramps so you're not learning alone:

  • LFX Mentorship - the Linux Foundation's paid, project-based mentorship (2026 Term 1 ran March–May). You work with a maintainer on a scoped project over several weeks.
  • Google Summer of Code (GSoC) and Outreachy - additional mentored pathways, the latter focused on people underrepresented in tech.

These aren't token programs. Since 2020, 25 LFX mentee alumni have become CNCF project maintainers, and 40–65% of mentees keep contributing in the year after. If you're serious, applying to a mentorship term is the single highest-leverage move on this list.

What is the contributor ladder - and the flywheel?

CNCF describes growth as a mentorship flywheel: a mentee becomes a contributor, a contributor becomes a maintainer, and a maintainer becomes a mentor who pulls in the next generation.

text
   mentee ──▶ contributor ──▶ maintainer ──▶ mentor
     ▲                                          │
     └──────────────  brings in  ◀──────────────┘

Concretely, most projects have a ladder: first-time contributor → regular contributor → reviewer (you're trusted to approve certain changes) → maintainer (you own areas and set direction). You climb it the boring, reliable way: consistent, quality PRs; good reviews of others' work; and showing up in the community until people know your name.

What's the realistic first-90-days plan?

  • Weeks 1–2: pick one project, build it from source, run its tests green, read CONTRIBUTING.md, join its Slack + the relevant TAG.
  • Weeks 3–6: land 1–2 small PRs - a doc fix, a test, a "good first issue." Small and merged beats ambitious and abandoned.
  • Weeks 7–12: take a slightly bigger issue, start reviewing others' PRs, and apply to the next LFX Mentorship term if the timing fits.

That's it. There's no secret. The people with "maintainer" next to their name simply did this, consistently, before you did. The best time to start was the last mentorship term. The second best time is today.

How does WOSS put this into practice?

This isn't theory for us. Welzin Open Source Software follows exactly this playbook, deliberately: pick a young, high-leverage Sandbox project at the intersection of our strengths - cloud-native infrastructure and agentic AI - and contribute upstream, in public, until the work speaks for itself. Our anchor is kagent, and our wider bet on cloud-native AI is documented in the CNAI pillar.

The strategy is boring on purpose: one project, real PRs, a relevant TAG, and the mentorship flywheel. If you're an engineer in India or anywhere else looking to build a credible open-source reputation, the on-ramp above is the whole game - and the KubeCon India / KCD circuit is where those contributions turn into a network.

Frequently asked

How do I start contributing to CNCF projects?

Pick a CNCF project you already use (a Sandbox or Incubating project is often more welcoming than a large graduated one), read its CONTRIBUTING.md, find an issue labeled "good first issue," and open a small, focused pull request. Join the project's Slack and the relevant CNCF Technical Advisory Group (TAG) to plug into the community.

What is LFX Mentorship and how do I join?

LFX Mentorship is the Linux Foundation's paid, project-based mentorship program that CNCF participates in, running in terms through the year. You apply as a candidate to a proposed project and work with a maintainer over several weeks. Since 2020, 25 LFX alumni have become CNCF maintainers.

How do you become a CNCF maintainer?

By climbing the contributor ladder: land consistent, quality pull requests, review others' work, become a trusted reviewer, and eventually a maintainer who owns areas of a project. Mentorship programs and active participation in a TAG accelerate the path.

Do CNCF projects use a CLA or DCO?

Most CNCF projects use the Developer Certificate of Origin (DCO), which means you sign off each commit with git commit -s. A DCO bot will block your PR if a commit is missing the sign-off; git commit --amend -s (or an interactive rebase for multiple commits) fixes it. Always check the project's CONTRIBUTING.md for its exact requirement.

Written by Aman Mundra - founder of Welzin and the Welzin Open Source Software (WOSS), which contributes upstream to CNCF projects including kagent. Follow the series for practical cloud-native open source guides.

← All postsTalk to a senior engineer →