Applying to Google Summer of Code: Top Tips from a Multi-Year GSoC Mentor

A collection of “Dos and Don’ts” from over five years of the Google Summer of Code program. Part 1 in a series of GSoC topics: advice for Contributors on crafting proposals.

GSoC Mentor Summit

It’s April and it’s almost time to submit your proposals! Wondering what to polish before your final submission? You’re in the right place: I have been mentoring involved in Google Summer of Code (GSoC) since 2019 and Mentoring since 2022 via Orthogonal Research and Education Lab and DevoWorm, thanks to support from the International Neuroinformatics Coordination Facility. Throughout this experience, I have helped guide numerous students through successful projects and gained insight into what makes a contributor thrive within this program. The following advice is intended to enhance your chances of acceptance, as well as provide some context on how GSoC works and the nature of its selection process — and maybe broader context on getting started in innovation spaces, too.

Stay tuned for our next post in this series, which will have insights from Orthogonal Research’s Director and Senior DevoWorm Contributor, Dr. Bradly Alicea, and more advice from other mentors and contributors on making the most of GSoC.

Disclaimer: these thoughts are all my own thoughts, and not a reflection of my affiliations or partnerships.

“How it works” according to Google

Google Summer of Code: Proposal Submission Essentials

Before diving into my personal recommendations, it’s worth considering some widely recognized strategies and practices shared by other experienced mentors and the GSoC community; you probably have seen most of these, but in case you haven’t here are some solid starters, with their key points noted:

• Writing a Strong Proposal (Google’s Official Guide): Clearly outline your project’s scope and deliverables. Provide detailed timelines and milestones. Show prior engagement with the project by submitting initial contributions or fixing issues.
• Preparation Tips from the Community (Reddit): Get involved early, learn about your chosen organization thoroughly. Regularly engage with mentors and maintainers via mailing lists, chat channels, and forums. Start contributing small patches to familiarize yourself with the workflow and build credibility.
• Official Student Advice from Google (Google Developers): Consistently communicate with your mentors. Proactively seek feedback and implement suggestions promptly. Balance your GSoC commitments with other academic or personal obligations.
• Bonus: Making Your First Contribution (First Contributions GitHub): A solid overview from Muhammad Mahad about GSoC, open source, and tips on how to overcome initial barriers and submit your first pull request confidently.

Mentoring Advice

This post came about because I received a record number of questions this year from many wonderful potential contributors to our projects at Orthogonal Research and also DevoWorm (OpenWorm Foundation.) While the above advice is essential, I’d like to add several key insights I’ve gained from mentoring and observing successful GSoC contributors — and some broader context around open-source projects, how Google funds its program, and other potentially useful context at large for what this situation involves.

Q1: Can I submit multiple applications?

A: Yes, you can, but should you, really? This year, I believe the application states you may apply up to three different projects. Consider what it looks like from a mentor or project leader’s perspective; if you submit several generic quality applications (especially if they are to the same org, or clearly GPT/GenAI generated), what does that say about your seriousness for addressing the actual problem at hand?

So, first, consider that your proposal(s) and all interactions you have with your organization, you are putting yourself on display. (More on this in Suggestions below)

Q1: Can I submit multiple applications?

A: Probably not, although if you haven’t seriously thought about it before reading this post, it may be cutting it close to create something substantial. This year, 2025, the final deadline is April 8, which is less than a week away. There is a serious advantage to connecting early with your mentors — but if you haven’t, and you have both a legitimate interest and a devoted intention to follow through with it, I would encourage you to apply. In general, my personal sentiment is to legitimately apply to whatever is relevant to your interest or would develop you and see what comes from it all — who knows what will turn up right for you.

Q3: Do I need to have mastered the language/tools or technology ahead of time?

A: No. In general, this is more or less seen as an apprenticeship where you learn from us, or with us, as we explore an open-source project. Some projects will require you to do very predictable tasks on very established codebases or existing applications; some will require you to innovate or explore brand new ideas and solutions — you may want to consider this in relation into the next question (Q4), in fact. But the point of GSoC is widely to get a personal experience within a community around how to collaboratively push a project forward. If you have concerns about your technical ability, this is where you should ASAP discuss with your mentor or project lead; they can reassure, advise, or offer solutions that will fit what is tenable for you.

Link to Post

Q4: What kind of project or organization should I apply for?

A: Great question! Indeed, this is probably one of the most important things to investigate, and it is perhaps not stated enough that a hidden gem of the GSoC process is you actually taking the time to understand how varied and diverse open-source projects can be — and beyond that, how many different kinds of organizations there are. Some are research focused (INCF), some are refining existing apps or developing new ones (MIT App Inventor), some are about furthering a language (Julia), or expanding data science practices (PostgreSQL). The landscape of technology is remarkably vast, and even in the microcosm of GSoC, it’s worthwhile, and maybe even fun, to spend time simply exploring what is out there and how people are doing it.

Even if your current skillset or interest make a better fit for one project this year, perhaps over the next year, you will be inspired to work with another organization — as a contributor, intern, or perhaps more. So don’t skip the exploration period, and, as a bonus tip: even after the application period has passed, you may do well to continue to investigate organizations to plan your future collaborations.

How To Apply To Google Summer of Code

Q5: So … what should I do — which kind of project/org should I apply to, then?

Here’s what I would do, in an ideal, and in a time-constrained sense:

The ideal sense is easy: apply all the advice listed so far, thoroughly get to know many organizations ahead of time, and find a best match after numerous engagements or discussions with prospective orgs, and ideally their own mentors or past project participants.

In a more realistic or even time-triaged sense:

1. Identify a topic of interest or skillset you’d like to pursue. It can be challenging to navigate all the potential opportunities, which is why the scouting time period is invaluable (and why my bonus advice is what it is*.)

It may be unwieldy, but that search bar can turn up a number of surprising niche interests or things you may want to contribute to. Take a few Levy Flights to explore the space and get a sense of what is available.

2. Prioritize 2–3 organizations and reach out ASAP. Why? Even if it’s simply getting some name recognition, it will be better than cold-submitting an application from someone the mentors never heard of.

3. Choose. Depending on time and ability, it’s probably going to be one really good application when its all said and done. Ideally you will have feedback or more information coming in to help with this, but it may not come in time for you to make some real choices. Maybe you will complete additional proposals, but don’t worry if it’s just one. If you’ve made the commitment thus far to care this much, at least finish the deal and submit one reasonable proposal. Go for it!

4. Draft your proposal. Don’t wait for extensive responses from anyone, especially if time is short; Just Do It. Why? Because you will figure out along the way if you really are interested or not, and likely do preliminary problem solving. It’s also good advice to complete the draft and think about things with as much time between it and a revision (or, you know, iterative and incremental development) as you can manage.

5. Revise & Review. Put it all together with the feedback and any other advice you have. It doesn’t have to be perfect, but going over for overall coherency will be good. Does it generally make sense? I will discuss this more in the next section. If you’ve made it thus far right now, while you are reading, congrats! You’re almost there.

6. Actually Submit the Proposal. If you aren’t used to doing this, it can be daunting. But, I personally like the idea of simply having a go-to remark, or reminder, or theme song, or something, that pumps you up to actually send the email, submit the document, or complete the form. Submit it, and celebrate the effort and the moment. This kind of process can be cathartic, even if it takes a while for you to reflect on what was written and how you feel about the subject matter that you just, at least theoretically and emotionally, committed to spending several months on ahead.

What To Keep In Mind During The Process — and when Preparing your Proposal

So, you’ve started the process, and now it’s time to finish the proposal. Here are some more things to consider as you’re engaging with the org, the community, project members, and hopefully understanding more about yourself and your interest in doing this kind of work ahead.

You’re always promoting yourself…

Yes, as much as tech workers may wear shorts and flip flops and being a digital nomad is more popular than ever, there is still a version of yourself you will be “selling” to others. GSoC is accessible yet competitive, and you would do well to act accordingly. Some people come into this program with extensive competition and training and hackathons and other experiences — but some do not, at all; it is not a prerequisite.

Bad news: You probably aren’t Jensen Huang in terms of your Tech Fame. Good news: you could be one day, and GSoC could help you on the way. It’s wise to have some humility when addressing others or speaking about yourself — but that’s not to say you can’t be thoughtful or considerate in your ambitions or aspirations. Finding your voice is one of the unlisted parts of this program, and hopefully your mentors will work with you to communicate yourself and your achievements.

…but not everyone fusses about how much you are “selling” or performatively posturing yourself

The advice here is to be aware of how all of your interactions collectively build up the organization’s sense of who you are — whether an email reply. social media, how prepared you are for a meeting, or other factors. They all aggregate and compile into their sense of who this person is and what they can do for the org — and how you fit their goals, interests, or requirements.

I would steer most applicants away from thinking they have to act or appear a certain way and more towards sincerely investigating the orgs and the people you hope to work with. Connection and interfacing can establish rapport and slowly build trust. Ask questions, even if you don’t know how to ask them as articulately as you’d like to; sometimes it’s more important to show that you are thinking about things, rather than waiting or laboring to present your thoughts “perfectly.” Showing that you care and are willing to learn is valuable, and there are many well-polished applicants who sell an idea well but do not know how to connect their idea or technology to the organization itself, or the people who comprise it.

Understand and value the matchmaking process

Let’s do a brief thought experiment: put yourself in the position of someone leading a project, and hoping to find an apprentice to invest in. As a mentor…

1. I want someone who can “do the work”, yes, but I also want someone who seems reliable enough to get through the project. Essentially the biggest danger we’re looking to avoid is someone simply disappearing or not finishing the program itself. Then, everybody loses, and Google might see the sponsoring organization as unreliable themselves and give them less funding next time.
2. Summertime and The Long Journey: Keep in mind they are having to determine who to invest their time during the summer months, which for most folks, is when they get time away or time to do “what they actually want to do,” particularly in academia. So, it’s not just a project, or an idea, it’s spending the summer with a group of people focused on a collaborative challenge. Understanding that mentors and orgs will have this as a factor, even if it’s not explicitly stated anywhere, will be good to keep in mind. Who are you as a Contributor and mentee; will you be good company to slog through several summer months? ProTip: This is good practice for scouting and getting experience for other advisors and mentors later in life, too.
3. Who to invest in. Essentially, a reiteration of the previous point — the more someone looks like they will benefit from the mentoring program, the better the fit. Is the student eager and open to face challenges? Do they seem like someone who would benefit from the project? Might they even want to work on it after it’s done?

These are somewhat impossible questions for anyone to have an answer to ahead of time, but I mention them here as things to keep in mind when interacting with your project-mates. It may help you to understand what they are looking for when they try to get to know you, beyond your coding proficiency.

Unsolicited Career Advice

Speaking of such things, a bit more on that earlier Bonus Tip, about taking the time to develop your macro-context of tech orgs, styles and types of work in them, and their relative environments — it might be a nice bookend to revisit at the close of this section. Speaking of such things, a bit more on that earlier Bonus Tip, about taking the time to develop your macro-context of tech orgs, styles and types of work in them, and their relative environments — it might be a nice bookend to revisit at the close of this section. […]

📄 For the full post,

**continue reading on our article at 📄**

We’ll continue the discussion with Final Comments on the Submission Document and what to do if your proposal is not accepted by your GSoC organization.

Follow us for our ongoing discussion series, articles, and forthcoming podcast!

What’s Next?

Stay tuned for future posts where I’ll be sharing additional insights and bringing in perspectives from other mentors in our Lab, industry folks, and participants from upcoming events.

Together, we’ll offer a variety of views and experiences to help you thrive in your development contributions and innovation spaces and hopefully grow as a mentor and/or mentee, as well.

Happy coding, and best of luck!

Jesse Parent

Originally published at https://innovationstrategymentor.substack.com.