Skip to main content

From Contributor to Maintainer: My LFX Mentorship Journey

· 5 min read
Jayesh Savaliya
Jayesh Savaliya
Kmesh Maintainer

Introduction​

Hi everyone! I'm Jayesh Savaliya, a B.Tech student at IIIT Pune passionate about backend technologies and open source. Over the last two years, I've been selected for the C4GT program twice (2024 & 2025) - yes, they let me back in - and recently completed LFX Mentorship 2025 (Term 1), where I somehow went from fixing typos to being responsible for reviewing other people's code at Kmesh.

In this blog, I'll share my journey and the strategies that actually worked (no generic "just be passionate" advice, I promise).

My Background​

When I applied to LFX, I wasn't starting from scratch. I had already battle-tested myself with:

  • Sunbird (EkStep Foundation) via C4GT, where I learned that education tech is harder than it looks
  • Mifos, a GSoC organization focused on financial services (because debugging payment systems at 2 AM builds character)
  • Various backend projects where I definitely didn't break production. Much.

Choosing Kmesh​

I shortlisted projects from the LFX portal based on three key criteria:

  1. Tech stack relevance - Technologies I wanted to master
  2. Learning potential - Projects that would challenge and grow my skills
  3. Active maintainers - Communities with responsive, helpful mentors

I chose Kmesh, a high-performance service mesh data plane built on eBPF and programmable kernel technologies. Kmesh's sidecarless architecture eliminates proxy overhead, resulting in better performance and lower resource consumption.

Honestly? It had "eBPF" in the description and I wanted to sound cool at tech meetups. But it turned out to be genuinely fascinating work with a great community.

How to Succeed in Open Source Programs​

Here's my three-step approach that worked for LFX:

1. Make Meaningful Contributions​

Start small and scale up gradually. Don't be the person who says "I'll rewrite the entire architecture!" on day one.

Instead:

  • Weeks 1-2: Fix typos, improve logs, update documentation
  • Weeks 3-4: Fix small bugs, add tests
  • Week 5+: Work on core features and refactoring

This progression shows mentors you're not just throwing random PRs at the wall hoping something sticks.

2. Write a Strong Proposal​

Your proposal should be:

  • Clear: Explain your approach in straightforward language
  • Structured: Include a realistic timeline with milestones
  • Convincing: Demonstrate why you're the right person for the project

Make sure your proposal reflects genuine engagement with the project, not just surface-level research.

3. Be Actively Involved​

Stay engaged in project channels (Slack, Discord, mailing lists). Communicate regularly with mentors, ask thoughtful questions, and contribute to discussions.

But also: don't be that person who asks questions Google could answer or pings everyone at 3 AM with "quick question." Balance is everything.

The Formula: Consistent contributions + Strong proposal + Active communication = Standing out

The Path to Maintainership​

Becoming a maintainer wasn't planned. It happened naturally through sustained engagement after the mentorship period ended.

Consistency​

I continued contributing regularly after my initial PRs were merged:

  • Fixing overlooked bugs
  • Adding requested features
  • Refactoring code for better maintainability

Learning Mindset​

I embraced every learning opportunity, even when I had no idea what I was doing. eBPF concepts? Started clueless, ended slightly less clueless. Performance optimization? Learned by making things slower first. CI/CD improvements? Broke the build a few times, but now I own it.

Patience & Feedback​

Code reviews can be humbling (read: brutal). I learned to take feedback seriously even when it stung, iterate quickly, and stay patient when things inevitably broke.

Taking Initiative​

I started acting like a maintainer before having the title:

  • Suggesting project improvements
  • Writing comprehensive tests (because flaky tests are the worst)
  • Automating repetitive tasks (laziness is a virtue in programming)
  • Reviewing other contributors' work

By the end of my mentorship, the trust I built with the team led to being granted maintainer access. Going from "hey, can I fix this typo?" to "you're now responsible for reviewing PRs" was equal parts surreal and terrifying.

Key Takeaways​

Here's what I learned that might help you:

Start small, stay consistent - Begin with simple contributions and build from there. Consistency matters more than individual genius.

Focus on learning - Getting selected is great, but learning enough to make real contributions is what counts.

Communicate effectively - Ask questions, share progress, and be helpful. Respectful, clear communication goes a long way.

Suggest improvements - If you see something that could be better, speak up. Good ideas are always welcome.

Embrace feedback - Your first PR won't be perfect. Nobody's is. Take feedback as learning opportunities, iterate, and move on. Arguing about semicolons is not a productive use of anyone's time.

You don't need to be a genius. You just need to show up, contribute meaningfully, and improve consistently.

Final Thoughts​

The LFX Mentorship taught me more than just technical skills. I learned how to work with distributed teams across timezones, think critically about production software (logs are your friends!), and grow into a leadership role in an open source community.

If you're considering applying to LFX or any open source program, take the leap. With consistent effort and genuine engagement, you can make a real impact. If I can go from nervous first-time contributor to maintainer, so can you.

Connect With Me​

Feel free to reach out if you want to discuss open source, eBPF, or systems programming:

Thanks for reading, and see you in the next PR!