The third way I found into Google Summer of Code
The usual advice for getting into GSoC is "have a strong profile" or "contribute for months first." I had neither, here's the third route that worked for me.
Most advice about getting into Google Summer of Code boils down to two routes. Either you already have a strong, visible public profile, a track record of contributions, a name recognized in the community you’re applying to, or you spend months quietly contributing to your target organization before applications even open, building trust the slow way. Both are good advice. Neither was available to me.
I didn’t have a standout public profile. And I didn’t have months of history with any specific org, the one repository I had contributed to meaningfully had already missed out on GSoC once, and I had no reason to believe its second attempt would go differently. If I waited for either of the standard routes to apply to me, I wasn’t getting in.
Finding a different way in
What I did have was time and a willingness to go looking. I came across a research lab’s machine learning repository, a computational neuroscience group at TU Munich, through a social media feed, almost by accident. I didn’t know the maintainers, hadn’t used the tool before, and had no standing with the lab at all.
So I spent several weeks actually studying the codebase: reading how it was structured, understanding what the maintainers cared about, and looking for a contribution that was substantive enough to matter, not a typo fix that would get merged and forgotten. I found something domain-adjacent, not the exact GSoC project scope, since that hadn’t been announced yet, but unmistakably related work that demonstrated I understood the problem space and could ship working code against a real codebase.
Leading with evidence, not a resume
When GSoC applications opened, I emailed the mentors directly, people working across machine learning and computational neuroscience, and the email did not open with a generic introduction or a resume attachment. It opened with the work. Here’s what I built, here’s why it’s relevant to what your lab does, here’s the repository if you want to look.
That ordering mattered. A cold email asking “can I work with you” invites a mentor to evaluate you in the abstract, credentials, GPA, a generic cover letter. An email that leads with a concrete, relevant, already-shipped contribution invites something different: a mentor looking at actual evidence that you can do the kind of work their project needs.
The mentors replied. Not just an acknowledgment, they engaged with the proposal, pushed back on parts of it, and helped me sharpen it into something that fit both what I wanted to build and what the lab actually needed.
What happened
I was accepted into Google Summer of Code 2024, working with HNN-Core under INCF, building batch simulation workflows for a tool neuroscientists use to connect cortical models with EEG and MEG signals.
I want to be careful not to overstate what this proves. GSoC 2024 accepted 1,220 contributors across 195 organizations, it’s a competitive but not impossibly narrow program, and plenty of people get in through the two standard routes I mentioned at the start. This isn’t a claim that my approach is better than those, or that it would work identically for someone else’s specific situation.
The actual lesson
If you don’t have a strong public profile and you don’t have months of history with your target org, you still have a third option: build evidence adjacent to the problem before you ask anyone to trust you. You don’t need permission to study a codebase, understand what a team cares about, and ship something relevant. That evidence does the work a resume can’t, it answers the question a mentor actually has, which isn’t “is this person qualified in general” but “can this person do the specific kind of work my project needs.”
The two standard routes into GSoC are standard because they work. But if neither fits your situation, the move isn’t to wait until one does, it’s to find a way to demonstrate the same thing those routes demonstrate: that you can be trusted with real work, on real code, for a problem you’ve taken the time to actually understand.