How I Got Into GSoC, and an Offer That Came Before It

I completed Google Summer of Code (GSoC) 2026 with Meshery. The run was May 25 to August 24, both evaluations passed, and the project is here. And before any of that, in March, Meshery offered me a software engineering internship on its own hiring track, nothing to do with the GSoC process. The timing did not work out because of prior commitments, but the offer made something clear: six months of real contribution to one project opens doors on its own, well before a program's results are out.

It took me three years to get here, and most of that time was spent doing it wrong.

The three-year version

First year. One evening I was having tea with three friends, and one of them mentioned, almost in passing, that it was the last day to submit GSoC proposals. I went back to my hostel room and spent the entire night reading about the program: how it worked, what people did to get in, how early they had started. By morning I had a clear picture of a great opportunity I had completely missed. I told myself I would do it properly next year.

Second year. I was working as an intern, so I could not contribute regularly. I also still did not really know how to choose an organization. I poked at two or three orgs, spread thin, never went deep in any of them. I was not selected, and looking back it is obvious why. I had not given any single community enough of myself to be worth a slot.

Third year. I started in December, months before proposal season. I picked one organization, Meshery, and contributed to it consistently for six months. GSoC lets you submit up to three proposals to three different orgs. I submitted one. That was not a gamble; it was the confidence that comes from six months inside a single codebase and its community. I knew the maintainers, I knew the project, and I knew what I could realistically ship over the summer.

The rest of this post is the process I wish I had followed from first year.

Pick the org before you pick the project

Most people start by hunting for an interesting project idea. Start with the organization instead. A good org fit carries you through the parts of the summer that idea-excitement does not.

Go to gsocorganizations.dev. For every org you are considering, check:

• Participation history. How many years has the org been in GSoC? Orgs that show up every year are a safer bet than a first-timer, because they know how to run the program and mentors have done it before. If you are aiming for GSoC 2027, look at 2024, 2025, and 2026. Consistent participation is the signal.
• Number of slots historically. Some orgs get 3 contributors a year, some get 15. More slots means better odds, all else equal.
• Tech stack. The site lists the languages and technologies each org uses. Be honest about which of those you can actually be productive in within a few weeks. Do not pick an org built on something you would be learning from zero while also trying to land contributions.

Cross-reference with the org's real activity: is the GitHub repo active this month, are issues being triaged, is there a public chat with people actually talking in it. A healthy, busy org is where you want to be.

I picked Meshery because it checked all of these: repeat GSoC participant, a Go and React stack I could work in, and an unusually active community.

Read the contribution guidelines first, and actually read them

Every serious org has a CONTRIBUTING.md or a contributor handbook. Read it before your first PR, not after it gets rejected. It tells you:

• How to set up the project locally
• Commit message and sign-off conventions (many CNCF projects require DCO sign-off)
• PR title format, branch naming, how issues get assigned
• Whether they want you to comment on an issue before starting

Following these exactly on your first contribution tells maintainers you pay attention. That reputation compounds.

Start with good-first-issues, then climb

Your first few PRs are not about impact. They are about learning the review loop: how this org does CI, how nitpicky reviewers are, how long turnaround takes, how to respond to change requests.

• Take good-first-issue labelled tickets to start. Small doc fixes, small bugs, small UI touch-ups.
• Only pick an issue you genuinely understand, or spend the time to understand it fully before claiming it. Claiming an issue and going silent for a week because you were in over your head is worse than not claiming it. If you do not get the issue, ask clarifying questions on the thread first.
• Once you have three or four merged PRs and know your way around the codebase, move to harder issues that touch real subsystems. That is what makes your proposal credible.

That is roughly the arc my Meshery work followed. I started in December 2025 with small visual regressions across the web properties, then moved to mobile-responsiveness fixes that touched real layout debt, then to building new interactive sections and features like multiplayer cursors on the Kanvas site. By March I had merged PRs across three of the organization's repositories.

There is no syllabus, so just be present

There is no prep material to grind. What actually matters is being a visible, consistent presence in the community:

• Join the Slack or Discord and turn on notifications for the channels that matter.
• Show up to the weekly community meetings. Meshery runs them; a lot of orgs do. Even just listening teaches you what maintainers care about right now.
• Introduce yourself, then keep showing up. Familiarity is half the battle.

By proposal season, the maintainers should already know your name.

Discuss real doubts in the open

When you are stuck, ask in the public channel or on the issue thread, not just in DMs. Two reasons:

1. You get answers from whoever is around, not just one person.
2. Maintainers see you engaging with the actual substance of the project, not just farming easy PRs.

Ask genuine, specific questions. "I traced this bug to X, but Y also seems involved, is this the right layer to fix it?" beats "how do I start?". Thoughtful questions are a form of contribution.

Write the proposal from your contributions

By the time proposals opened I had been contributing since December, with merged PRs across three of Meshery's repositories, and I had moved from first-issue-sized fixes to real features. So the proposal mostly wrote itself: a section on what I had already shipped, then a phase-by-phase plan for what I would build over the summer, each phase tied to issues that already existed. I shared drafts with my mentor early and folded in the feedback.

The proposal that works is not a pitch. It is a continuation of work already in progress.

What the summer actually looked like

My project was "Scaling the Meshery Ecosystem: Frontend Modernisation and Backend Reliability," mentored by Lee Calcote. The work spanned three repositories: refactoring legacy UI components, building new interactive sections, clearing recurring mobile-responsiveness bugs, and fixing routing and build issues on the backend side.

The code was a great experience and I learned a lot, but the part that stuck with me was everything around the code:

• Helping newcomers get their first PR merged. Answering "where do I even start" questions, pointing people at issues that matched their level, looking over their branches before a maintainer did.
• Reviewing other contributors' PRs. Reading someone else's diff and leaving useful comments taught me more about the codebase than writing my own ever did.
• Hosting community meetings. Running the agenda, keeping notes, following up on action items afterwards.
• Taking feedback without getting defensive. Early on, a dozen review comments on a PR would sting. The contributors who improve fastest treat each comment as free mentoring, apply it, and move on. That shift mattered more than any single technical skill.

By the end it did not feel like a program with a start and end date. It felt like being part of the team.

If you are not selected, it is not over

Every org gets a limited number of slots. Strong contributors get turned down every year purely because the org had 5 seats and 12 good candidates. That is not a verdict on you.

And selection is not the only outcome. Consistent, high-quality contributions get noticed on their own. Maintainers offer internships, freelance work, or just keep pulling you into bigger things, entirely outside the GSoC pipeline. That is what happened to me: the software engineering internship Meshery offered in March came through its own hiring track, off the back of the contribution work, not the program. Prior commitments meant the timing did not work out, but the offer existed at all because of the open source relationship. That relationship was the real asset. GSoC was one thing it produced.

The short version

1. Start early. December is not too early. Go deep in one org instead of spreading across many.
2. Pick that org using gsocorganizations.dev, and weigh history, slot count, and a tech stack you can actually use.
3. Read the contribution guidelines and follow them precisely.
4. Start with good-first-issues, then move to complex ones once you know the codebase.
5. Only take issues you understand; understand them first if you do not.
6. Be present in Slack, Discord, and weekly meetings from well before proposal season.
7. Ask real questions in the open and discuss your proposal with mentors.
8. Do not be disheartened by a rejection. The contributions have value on their own.