LFX is not just "another open-source internship." It is closer to joining a real project team with a mentor watching how you think, communicate, and follow through.
I was selected as an LFX 2025 mentee with CNCF Jaeger. Compared with beginner open-source programs, LFX often feels more project-driven and expectation-heavy. That is a good thing if you prepare properly.
This guide is the practical version: how to find the right project, apply well, and avoid the mistakes that quietly hurt candidates.
What LFX Mentorship Is
The Linux Foundation Mentorship program connects mentees with mentors from open-source projects. Mentees work remotely on real project tasks, receive structured guidance, and may receive a stipend depending on the program.
LFX projects can involve:
- Kubernetes ecosystem work
- CNCF projects like Jaeger, Prometheus, or related tooling
- Linux kernel work
- Hyperledger and blockchain infrastructure
- Zephyr, RISC-V, Open Mainframe, and other foundation projects
- Documentation, testing, CI, observability, SDKs, APIs, and developer tooling
The exact structure depends on the project. Always read the specific project listing, not just generic LFX advice.
Current Official Details To Know
The official Linux Foundation docs are the source of truth:
Important current points:
- Most mentorships start at around 12 weeks, but project duration can vary.
- Some projects are paid, some may be unpaid, and the listing should say so.
- Stipends are location-adjusted using purchasing power parity.
- The current stipend docs use a $6,000 base, with a minimum of $3,000 and maximum of $6,600 depending on country.
- Stipends are tied to satisfactory evaluations and are generally paid in installments.
- Applicants must meet the specific program requirements and complete any prerequisites.
- Mentees are not Linux Foundation employees.
Do not rely on old blog posts for stipend numbers or dates. They go stale fast.
Who Should Apply
LFX is good for you if:
- You can commit consistent weekly time.
- You are comfortable reading a large codebase.
- You can communicate asynchronously.
- You are willing to complete prerequisite tasks.
- You want to stay with an open-source community beyond the program.
You do not need to be perfect. You do need to be dependable.
If a project asks for Go, Kubernetes, tracing, kernel development, or distributed systems knowledge, take that seriously. You can learn during the program, but you should not pretend you already know things you have never touched.
How To Find the Right Project
Start from the LFX Mentorship platform and the project community pages.
For each project, check:
- Required skills
- Expected deliverables
- Time commitment
- Whether prerequisites are listed
- Mentor names and contact channels
- Repository activity
- Existing issues and recent PRs
- Past mentorship projects from the same community
Pick projects where your current skills overlap with the work. A stretch is good. A fantasy is not.
The Application Is More Than a Form
The application usually includes your profile, resume or links, and a cover letter or statement of purpose. Some mentors also assign prerequisite tasks, interviews, or technical checks.
Strong applications show:
- Why this project specifically matters to you
- What you already understand about the codebase
- Which skills you bring
- What you still need to learn
- How much time you can commit
- Evidence of prior work: PRs, issues, projects, blogs, demos
- A clear plan for the mentorship period
Weak applications sound like:
I am passionate about open source and want to learn from your organization.That may be true, but it is not enough. Every applicant says that.
A Better Statement of Purpose Structure
Use something like this:
# Statement of Purpose
## Why this project
Explain the project, the problem, and why it matters.
## What I understand so far
Mention docs, issues, architecture notes, or code paths you studied.
## Relevant background
Connect your skills to the project requirements.
## Contribution plan
Describe how you would approach the work during the mentorship.
## Availability
Be honest about weekly hours, timezone, exams, job, or internship conflicts.
## Evidence
Link PRs, issues, demos, writing, or related projects.Keep it direct. Mentors are not looking for poetry. They are looking for signal.
How To Stand Out Before Applying
You can stand out without spamming maintainers.
Do:
- Run the project locally.
- Read recent design docs or issues.
- Try a small bug fix or docs improvement.
- Complete prerequisite tasks early.
- Ask specific questions with context.
- Attend community calls if available.
- Share a short write-up of what you learned.
Do not:
- DM every mentor with the same message.
- Ask for a guaranteed selection path.
- Claim issues and disappear.
- Open huge PRs right before the deadline.
- Treat the project as only a stipend source.
Maintainers notice how you behave before selection.
Working With Mentors After Selection
Once accepted, your job is to make progress visible.
In the first week:
- Confirm goals, deliverables, and success criteria.
- Agree on update frequency.
- Set up the development environment.
- Convert the project into smaller tasks.
- Identify risky parts early.
Every week:
- Share what shipped.
- Share what is blocked.
- Share what you plan next.
- Open small PRs.
- Ask for review before a task becomes too large.
Mentors do not expect you to know everything. They do expect you to communicate before things drift.
Common Mistakes
- Applying without completing prerequisites.
- Writing a generic statement of purpose.
- Picking a project only because it is famous.
- Underestimating setup and onboarding time.
- Not reading the issue history.
- Waiting too long to ask for help.
- Submitting work with no tests or docs.
- Treating the final evaluation as the only deadline.
The program is short. Momentum matters.
My Advice From the Jaeger Path
Choose a project where you care about the problem domain. With Jaeger, observability and distributed tracing were interesting enough that I wanted to understand the system, not just finish tasks.
That curiosity helps when the work becomes uncomfortable. And it will.
You will hit unfamiliar code. You will wait for reviews. You will misunderstand something. You will rewrite a patch. That is normal.
What matters is whether you keep the loop healthy: learn, ask, implement, test, communicate, repeat.
Final Checklist
Before you apply:
- Profile is complete.
- GitHub and resume links are updated.
- You understand the project listing.
- You have read the relevant repo docs.
- Prerequisites are complete or in progress.
- Statement of purpose is specific.
- Availability is honest.
- You have at least one piece of evidence: PR, issue, write-up, demo, or related project.
LFX is competitive, but it is not mysterious. The candidates who do well are usually the ones who make the mentor's decision easier.
Show that you understand the work. Show that you can communicate. Show that you can finish.