I’d known about Google Summer of Code since my second year. It was never a distant dream, more like a target I kept circling back to. As someone actively applying for machine learning roles, GSoC stood out as a definitive signal that I could contribute to real, production-level open source code, something which I hadn't tried before. This is the honest story of how it went.
The Org Selection Strategy Nobody Talks About
Most people pick an organisation by its logo, or by how familiar the tech stack feels. I did something different. I researched orgs the way you’d research a company before applying for a job. The question I asked wasn’t “do I know this?” It was “does this problem actually matter, and does it fit where I’m headed?”
I used gsocorganizations.dev to filter deliberately. How many consecutive years had the org been accepted? How many projects did it take per cohort? An org that takes two projects a year is a very different bet than one that takes fifteen. I was being selective, not just hopeful.
I also went through past proposals. Real ones, accepted ones, not just the official summaries. The GSoC archive on GitHub was genuinely useful for seeing what a winning proposal actually looks like, versus what people assume it looks like.
One Month, One Proposal
I came in late. One month to go, and the usual advice is to apply to at least two organisations. I didn’t. I was picky enough about the org and the problem that I put everything into one proposal, for the Accord Project, on building an LLM-based template logic executor.
Given the time I had, spreading myself across two proposals would have meant two mediocre ones. I chose depth over coverage, and I’d make the same call again.
Being selective isn’t the same as playing it safe. It’s choosing where to go deep instead of spreading yourself thin.
Writing the Proposal
Here’s what reading past proposals taught me. The ones that get selected read like they were written by someone who had already spent time inside the codebase, not someone who had just discovered the project last week. Specificity is everything. Exact files, realistic timelines, an honest take on where the hard parts are.
- Lead with the problem, not your résumé.
- Show you’ve already read the codebase, and reference it directly.
- Make your timeline realistic. Mentors have seen padding before.
- Acknowledge the risks. It signals maturity, not weakness.
For a real-world example, you can read my full GSoC proposal here.
The Interview Call
Twenty days after submitting, I got an interview call with the maintainers of the Accord Project. It was closer to a technical discussion between two people who had already read the same code. The groundwork I’d laid in the proposal is what made that kind of conversation possible.
A few weeks later, I was selected.
My Personal Tip
If you’re thinking about diving into GSoC, start earlier than you think you need to. I’ve known peers who began tracking organizations during their freshman year, though my cohort also included several seasoned working professionals. The key takeaway is to be much pickier about your chosen organization, and double down on just one or two proposals. The process rewards people who take it seriously, which, if you’ve read this far, you probably already do.