Applying to Google Summer of Code: Top Tips from a Multi-Year GSoC Mentor
Dos and Don'ts from over five years within the GSoC program. Part 1 in a series of Google Summer of Code topics: this time, advice for Contributors on crafting proposals.
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 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.
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.
Questions To Consider (FAQs and How to Choose)
Q1: Can I submit multiple applications?
A: Yes, you can, but should you, really? (Some organizations may clearly limit your proposals to a specific number, but many do not). 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)
Q2: Is it too late to start my proposal?
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.
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 Secret to Everybody* 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 GSoC
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:
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:
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. 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.
Ask relevant questions that may help you determine what project to focus on or if fit makes sense. You can even be direct and say “are you having a lot of interest in project X?” or “Here is my CV/portfolio, do you think I have enough potential fit with where your team wants go during the summer?” Value the matchmaking process itself (more on this below).
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!
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.
If you finish your draft - or even an outline of the draft - and have not heard from a mentor or project member for feedback, follow up and include your drafted material. It will help them understand where you are and be a good nudge for them as well. The more thought and completion, the better feedback you’re likely to receive.
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.
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.
…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 its an email reply (and yes, 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 its 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…
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 looses, and Google might see the sponsoring organization as unreliable themselves, and give them less funding next time.
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.
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.
Much of this advice is to intentionally develop your understanding of the problem/research/development space over time, so your broader context pays dividends on the quality of your choices and evaluations. This is an extremely valuable long-term endeavor and strategy, which both influences the efficiency of some of your attention/focus “what to work on next” class of questions, and can help you navigate the ever-emerging space of AI and tech, at large. It’s quite challenging to actually learn how to ask questions to develop this context (a forthcoming series on this), but the kinds of questions you would ask are related to both what mentors/orgs are looking for, and your increasing ability to determine your fit and your compatibility on your own. The more wisdom you can accumulate about those choices, the more your career will benefit, and the more efficient your choices will be.
About That Proposal: Final Comments on the Submission Document
This perhaps could be its own post to go into great detail with how to generate specifics, but the reality is many of those specifics will be determined by your org and the project itself. So, a few, very broad, parting remarks on the submission document are worth noting here.
It will not be a perfect plan. We know it’s virtually impossible to accurately predict exactly what will happen each week of the program for a problem you haven’t fully begun to explore yet. So, instead of trying to arbitrarily justify a perfect plan, build in some contingency. This is an implicit communication of your experience, expertise, or know-how, or at least your relative sobriety about what’s going on and what could go on.
Instead of specifics, think of general stages of development, and identify some of they key factors that will either bottleneck, inhibit or be a catalyst for transitioning through the stages of development.
Outcomes: Tenable vs Reach. Ambition is not a bad thing, but identifying a lower-tier, more-accessible goal is wise, and will be useful in your career ahead. Understand what a minimum viable product (MVP) is relative to GSoC, which is something you’d determine through discussing with the project mentor.
In reality, talk of a MVP may be too much for these summer months of mentorship, but the point here is more to differentiate short vs long term goals; low/medium/hard ; earthshot/moonshot/galaxyshot/LoonShot, and the like.
Communicate clearly a more tenable, short term goal, and mention some less developed but nice-to-have goals that might require more development — or at least your initial solutions and troubleshooting to work out relatively seamlessly.
Identify how to record and measure project progress - even if its you doing it by yourself. It’s unlikely you’ll have a ton of project management experience prior to GSoC, and I know I have my PM & Research Coordinator hats on right now saying this, but it does matter. It will definitely make your proposal seem more legit the more you have something of substance on this topic.
🤫 …and the reality is, many people in tech development spaces don’t actually like project management, documentation, or doing the “messy” work of tracking how projects develop. No judgement or commentary about it, just saying that you may happen into a space where your org or mentor is not actually that concerned about this, but especially for early career researchers, learning the language and structure of this kind of tasking (and how it affects the actual development of said project) is valuable.
You don’t need to invest in an elaborate Gantt Chart, but familiarity with GitHub issue tracking may be an easy, open-source ready means of recording what happened. Actual documentation for recording major decisions, and how the coding thought process evolved, is another worthwhile approach.
Please don’t just use GPT. Honestly, I wonder how this will change in the future, and I may simply have a personal preference here. Note the emphasis is actually on the “just use”, as in only using it; I’m going to sidestep the discussion about whether or not using GenAI is a problem or not, in education or techdev. But what I will say is, if you simply throw things at GPT and then copy and paste it into a doc, save as PDF, and send to us, we can tell. Outside of some hallmark formatting tendencies, communicating to us in your real voice about how you see something matters, and may even substantially matter; you don’t want us to wonder if the writing is legitimate and makes sense, but, is that actually attached to the person that we’re going to work with for months ahead? Let yourself come through somewhere. Perhaps make some kind of custom image or chart; something more than a list of standardly spaced unnumbered lists, and generic summaries.
Final Thoughts & What To Do If You Don’t Get In
To round out this piece, I’ll zoom out with the following:
Focus on Learning, Not Just Delivery: As above, use GSoC as an opportunity to deeply understand software development practices and open-source community workflows. Ask questions, explore documentation, and don't hesitate to explore related technologies or tools that could enrich your project - and understand how the project fits within larger aims of the org, or the problem space at large.
Document Your Journey: Regularly document your progress through weekly blogs or posts. This is required in some instances, but the degrees and amount of involvement will be determined by your org and mentors. Overall, though, transparency helps mentors guide you better and creates a valuable reference for future applicants (and for the actual sustainability of the open source project).
What if You're Not Accepted?
There comes a time where we are all rejected, but do not despair.
One thing that you should know is the amount of funding, and therefore contributors funded, by Google each year is inconsistent, and when and how Mentors are made known of how many mentees they take on is not necessarily clear during the application process itself. This means that we don’t always know how many folks we can take on, when you are applying. It also means that sometimes there are outstanding candidates we have to turn away (or offer other ways of contributing), rather than the fully funded GSoC option.
This actually happened to me when I first applied; I was not one of the “funded” contributors to the project, but the organization I worked with still let me contribute, which lead to a lot of experience and a publication, and eventually doing more with the group down the road. So, don’t take “not getting funding” as the end of the line. It is a good chance to reassess your other summer plans, and whether or not working on the project either on your own or in some un-funded senses, is worthwhile for you. If you are deeply interested in the project, and really want to work with the group or a specific mentor, let them know.
That said,
Stay Engaged with the Community: Many successful GSoC contributors initially faced rejection. Continue contributing to your chosen project or organization and build your profile for the next cycle.
Seek Constructive Feedback: Politely reach out to mentors or community members to learn how you can improve your proposal or contributions. Use this feedback constructively to strengthen future applications.
Explore Other Opportunities: There are other open-source mentorship programs like Outreachy or MLH Fellowships that also offer valuable experiences and community involvement. Or, there are excellent and accessible opportunities such as Neuromatch & ClimateMatch, which offers a summer school on a variety of topics.
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, fellow open-sourcers and 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!
 | A guest post by
|