This post is based on my talk at AWS Student Community Day Bolivia, "Get Paid to Learn in Public: How LFX Mentorship Took Me From Student to CNCF Contributor". The talk was short, so this is the longer written version. The slides are online too.
As a student, most of your learning happens where nobody can see it. You work through a tutorial, build something on your laptop, and the only person who ever looks at it is whoever grades it. Open source works the other way round. Your code, your questions, even your mistakes are out in the open, and the people reviewing your work are engineers who keep real systems running.
LFX Mentorship adds one more thing to that: you get paid for it.
What LFX Mentorship is
LFX Mentorship is the Linux Foundation's mentorship program. Open source projects propose a piece of work, assign one or more mentors, and pick a mentee to do it over a fixed term. The Cloud Native Computing Foundation (CNCF) uses it across its projects, and runs three terms a year: March to May, June to August, and September to November.
Mentees receive a stipend. It is paid in installments, based on mentor evaluations and satisfactory progress, and the amount depends on your country of residence. The stipend page has the current details.
You apply on the LFX Mentorship platform. You create a mentee profile, browse programs that are accepting applications, and apply. Each program lists its own prerequisites, such as a resume, a cover letter or a small task, and your application stays pending until you submit them. You can apply to at most three programs per term.
My path
I didn't start with LFX. I started with one bug.
In July 2025 I fixed a bug in PipeCD, a CNCF continuous delivery project. Its analysis stage wasn't filling in template variables for two of its three strategies, so raw text like {{ .App.Name }} showed up in logs and queries. The fix was small. A maintainer had filed the issue, asked me to sign off my commits, tested the change and approved it. It was cherry-picked into the v0.52.2 release, and the maintainers encouraged me to keep going.
I first heard about PipeCD through CyberAgent, the company that created it, while I was exploring the GitOps ecosystem around tools like Argo CD and Flux CD.
So I kept going. Over the next few months I laid the foundation for the Analysis stage plugin in PipeCD's new plugin architecture, cleaned up spelling and grammar across 25 docs files, and wrote the project's plugin contribution guide, blog contribution guide and an expanded contributing guide. None of that was glamorous. All of it taught me how the codebase and the review process worked.
When PipeCD proposed a project for LFX Mentorship Term 1, 2026 to build out its Kubernetes multi-cluster plugin (issue #6446), I applied and was selected.
The application included an interview. Before applying, I made sure I had the skills the project actually needed. I think that's important.
As a mentee, from March to May 2026, I built 6 of the plugin's 8 deployment stages, including canary, baseline and traffic routing. Across the multi-cluster plugin work I've had more than 30 PRs merged, and I added a per-target deploy status to the plugin SDK so operators can see which cluster failed instead of just "stage failed". I wrote about it on the PipeCD blog.
Since then I have become a maintainer of PipeCD. I've now reviewed more than 170 PRs from other contributors. And this term I'm on the other side: I'm an LFX Mentor for Term 3, guiding work on a PipeCD plugin for Headlamp, the Kubernetes UI.
How to pick a project
There are a lot of programs each term. A few things that helped me, and that I now look for as a mentor:
- Pick a project you have already touched. I had been contributing to PipeCD for months before the term started. I knew the codebase, the maintainers knew my name, and I knew how reviews worked.
- Pick a stack you can grow into, not one you already master. The term is there for learning, so a project that stretches you a little is a good sign, not a reason to skip it.
- Read the program description and the upstream issue properly. Each CNCF program links to a tracking issue on the project's repo. That issue tells you far more about the actual work than the one-paragraph summary on the platform.
- Look at how active the project is. Check how fast PRs get reviewed and whether questions get answered. A responsive project makes a much better term.
How to write a strong application
The application is not where you start. By the time you write a cover letter, the best thing you can point to is work that already exists.
Contribute before you apply. Start with something small: a docs fix, a typo, a failing test, an issue labeled for newcomers. My first PipeCD contribution was a focused bug fix, and some of my later ones were documentation. Small, merged PRs show a mentor that you can set up the project, follow its rules and finish things.
Read the issues. Before writing code, read the open issues and the discussion on the program's tracking issue. You'll learn what the maintainers care about and where the hard parts are, and your questions will be better.
Talk to mentors in the open. Ask questions on the issue or in the project's public channels, not in private messages. The CNCF mentoring README is explicit about this. Public questions help the next person too, and they show how you communicate, which matters: mentors are told to consider your ability to work well with others, not just technical skills.
Keep PRs small. A PR that does one thing gets reviewed. A PR that touches everything sits. During the term I shipped the plugin one stage at a time, often in separate PRs for rollout and clean, and that habit started before the mentorship.
Write a specific cover letter. CNCF programs ask for a cover letter (statement of purpose). Say what you've already done in the project, link the PRs, and explain how you'd approach the work in the tracking issue. Generic letters are easy to spot.
What the term is actually like
The term is real work on a real project. My job was to take a plugin that maintainers had started with a basic multi-cluster sync stage and add the progressive delivery stages the single-cluster plugin already had.
Most of my time went into reading existing code, opening a PR, getting review, fixing it and doing it again. Reviews often took several rounds, the same as my contributions before the term.
I really enjoyed working with my mentors. They pushed me to get better at communicating my ideas, not just at the work itself. It was also a great experience to work alongside engineers who run production systems at large companies.
The stipend arrives in installments tied to evaluations, so steady progress matters more than a big push at the end.
Writing is part of it too. I wrote the plugin docs and README to release standard, and I wrote a blog post about the work.
What happens after
The term ends. The project doesn't.
The most valuable thing I did was keep contributing after May. I kept working on the multi-cluster plugin, and I took on work outside it, like cutting the noise from PipeCD's Dependabot updates, fixing dependency bumps that broke tests, and closing security alerts. Maintainership came from that steady run of merged and reviewed PRs, before, during and after the term, not from the mentorship alone.
Maintainership changed what my work looks like. I review more than I write now, and I think about the people trying to make their first contribution, because I was one of them recently.
Start now
You don't need permission to start. Pick a CNCF project, read its contributing guide, find a small issue and open a PR. If the project takes part in LFX Mentorship, you'll already have a head start when applications open.
Programs for each term are announced on the LFX Mentorship platform and in the CNCF mentoring repo, so watch those for the next round.
If you want the spoken version, the talk page links to the stream, and the slides are there to follow along. For the technical side of my term, read Building the Kubernetes Multi-Cluster Plugin for PipeCD.