Open Source, GSoC, and LFX

I get a lot of repeated questions around GSoC, LFX, proposals, organization selection, and how I approached open source. This page is the link I can share instead of typing the same answer every time.

Short version: start early, contribute consistently, ask good questions in public community channels, and write a proposal grounded in real project understanding.

Quick links

YouTube playlist

Watch playlist

My videos around GSoC, open source, and related advice that I often share with students.

GSoC 2024 final report

Read report

A concise summary of the work I shipped during Google Summer of Code with Submitty.

My GSoC proposal

Open proposal

The proposal I submitted for Submitty. Helpful if you want to understand structure, scope, and timeline.

Google Summer of Code

Visit GSoC

The official GSoC site. Read the timeline, contributor guidance, rules, and program flow properly before applying anywhere.

GSoC Organizations

Browse orgs

A very useful directory for looking at current and past organizations, tech stacks, and repeated participation patterns.

Accepted proposal archive

View archive

A strong repo for reading real accepted proposals and understanding how others structure technical plans, milestones, and scope.

CNCF mentoring repo

Explore CNCF mentoring

If you are looking more around CNCF orgs, this repo is gold. It helps you track mentoring programs, project ideas, timelines, and other useful details.

What I usually recommend

  • - Read the GSoC website properly, including contributor and mentor-facing guidance.
  • - Shortlist organizations from the last 1-2 years in a spreadsheet and rank them.
  • - Study old idea pages and understand which ideas keep recurring in that org.
  • - Join the community early and observe how maintainers review, communicate, and onboard contributors.
  • - Start with small issues or bug fixes to build trust before attempting large changes.
  • - Write a proposal that matches real project needs, not a generic template.

If you are considering LFX

If you are interested around the Golang or cloud-native space, LFX could be super helpful. It is one of the best ways to get closer to CNCF-style projects, mentors, and real ecosystem work.

  • - Be active in the community, contribute PRs, help newcomers, and attend regular community meetings.
  • - Keep your discussions with maintainers focused on the work, your open PRs, and real project doubts.
  • - Be patient. Maintainers usually have their own jobs and other responsibilities outside open source.
  • - In some projects the cover letter is basically your proposal, while in others contribution history carries more weight.
  • - Enjoy the journey. This applies not just to LFX, but to most open source programs.

How to contribute better

Whether you are targeting easy, medium, or advanced issues, the process is usually gradual: understand the project, start small, study past work, and then increase complexity over time.

  • - Contributing does not always mean coding. You can also help by triaging issues, improving docs, testing flows, or reviewing context.
  • - Start by reading the documentation in more depth so you understand the project before touching code.
  • - Solve small issues first: good first issues, docs fixes, chores, or narrow bug fixes.
  • - Read other contributors' pull requests and study how maintainers review and accept changes.
  • - Look at older pull requests and commit history for files related to the issue you want to solve.
  • - Search the repository using issue titles or important text from the issue description to find related code, issues, commits, and discussions.
  • - Your contributions usually grow in complexity over time. Learning how to fix bugs in an unfamiliar codebase is a very valuable skill.

A lot of this matches advice shared by experienced contributors in the open source community as well.

Using AI for OSS contributions

You can absolutely use AI while contributing to open source, but only if you are still doing the actual thinking. AI helps most when you already understand the code, the bug, and the expected change.

  • - Yes, you can use AI while contributing to open source, but first clear your fundamentals.
  • - Read the docs, understand the problem, and know enough context before asking any LLM to help with code.
  • - If you cannot explain the bug well, you usually cannot give enough context to the model either.
  • - Ask doubts in the community channel when you are stuck instead of blindly trusting generated code.
  • - Use AI as an assistant for exploration, summarization, debugging ideas, or draft code, not as a replacement for understanding.
  • - If you submit low-context AI-generated code, it usually becomes a slop PR and wastes both your time and the maintainer's time.

Repeated questions

I want to do GSoC. What should I do first?

Pick 1-2 organizations, read all their docs, join their public community channels, and start contributing to small issues. The biggest mistake is spending all your time on proposal theory without touching the codebase.

When should I start?

As early as possible. Starting early gives you time to understand the codebase, get reviewed, and become visible in the community. Late starts are still possible, but they are much harder.

How do I choose an organization?

Match it to your current strengths first, not just hype. I usually look at tech stack fit, community responsiveness, issue quality, past idea pages, and whether new contributors can realistically land small PRs.

Do I need prior contributions?

For most serious orgs, yes, at least some meaningful activity helps a lot. A few good PRs, useful discussions, and visible consistency are often more valuable than sending many shallow changes.

How important is the proposal?

Very important for GSoC, and often equally important for LFX unless that project heavily prioritizes PR history. A strong proposal should explain the problem, your technical approach, scope, milestones, risks, and timeline.

How do I find good issues?

Start with labeled newcomer-friendly issues if the org has them. If not, read recent bugs, failing tests, small UI issues, or docs/setup pain points. Small fixes are a practical way to learn the codebase and gain reviewer trust.

Can I get selected from a tier 2/3 college?

Yes. Selections are driven much more by contribution quality, communication, proposal clarity, and consistency than by college name.

How is LFX different from GSoC?

LFX varies more from project to project. In some projects the cover letter is basically a proposal, while in others mentors care much more about PRs, meetings, and direct community involvement.

How should I approach Submitty specifically?

Read the docs first, set up the project carefully, and prefer small changes. Review cycles for external contributors can take time, so patience and smaller PRs usually work better than big speculative changes.

Important note

  • - These answers are based on my experience, but selection patterns vary a lot from org to org and mentor to mentor.
  • - Some communities care heavily about proposal quality, while others prioritize merged PRs and regular participation much more.
  • - If a project does not match your strengths, it is okay to switch early instead of forcing it for months.

If you are messaging me about GSoC or LFX, please go through this page first. It covers most of what I usually share one-to-one.