Advice to prospective Google Summer of Code participants

(Note: because “prospective GSoC participant” is a mouthful, I refer to these folks as “students” throughout the rest of this post, even though you no longer have to be a student to participate in GSoC!)

You may have heard that the Open Transit Software Foundation (“OTSF”), the parent organization of OneBusAway, the best open source real-time transit software, was accepted into Google Summer of Code’s 2024 cohort of mentoring organizations! We’ve been delighted with the response that we’ve seen from prospective participants, too: a record 135 proposals!

At the time of writing this blog post, I have reviewed and ranked every proposal. It seems very unlikely that we’ll get as many slots as we want, but even two or three smart and talented GSoC participants will help us further our mission.

Having now completed my first year as a mentor and admin for a participating organization in this phase of GSoC, I wanted to offer some advice to students hoping to have their GSoC proposals accepted by our organization or any other participant. Hopefully my advice will help you stand out from the crowd!

Ask thoughtful questions

Before asking a question, spend a few minutes checking the project’s website, search Slack, review GitHub/GitLab issues, and maybe even do a quick Find in Files across the relevant codebase first, and tell the mentor up front what steps you’ve already taken before asking them for help. You don’t need to spend hours on this process, but you should be able to demonstrate that you put in a good faith effort to answer the question for yourself. For instance:

Hi Aaron - I’m trying to understand more about how Feature X should work so that I can better prepare my proposal. I read the open issues on GitHub that seem to relate to this, and learned about the previous attempts to build this feature. However, I’m still not clear on {ARCANE TECHNICAL ASPECT} of the feature. Can you help me understand how this should work? Also, with your permission, I’ll add your description to the relevant issue on GitHub so others know how this should work, too.

Remember: the potential mentor you’re conversing with is constantly asking themselves: “do I want to spend 12 weeks answering this person’s questions?” Make sure that the answer is always “yes!”

Consider the organization’s strategic priorities

Ask yourself: what are the strategic priorities of the project that I want to work on? What are the features I can add or bugs that I can fix that most align with those priorities? If you can’t come up with an answer, ask your prospective mentor to help answer this question for you. (Remember: demonstrate you’ve done the research before asking!) The GSoC mentor organization undoubtedly has more prospective participants than open slots, so make sure the work you propose doing is maximally valuable.

Focus on projects that are getting less attention

Look through the GSoC channel (or channels) on your mentor organization’s Slack: which projects are getting the most attention? Ignore those! Your odds of being picked for a project with one or two other applicants are much better than a project with ten or fifteen other applicants.

If you don’t know which projects might qualify, feel free to ask! As a mentor, I would have been delighted if a student had asked me:

Aaron, I want to maximize my chances of getting accepted into GSoC, and so I wanted to ask you which projects are most important to you, and which of those are getting the least attention by prospective GSoC students right now?

You can combine this with the last two points, too:

Aaron, I’ve reviewed the example projects for OTSF and looked at the relevant issue trackers for inspiration. I think projects X, Y, and Z are the most important projects that I can work on, given my skillset. Which project do you think is getting the least attention right now, and where would I be most likely to get accepted?

Demonstrate your abilities

This year, I reviewed several proposals that were very detailed and sounded quite impressive, but they were ranked lower than other less impressive project proposals because I couldn’t find any evidence that the author could fulfill the expectations they set forth in their proposal. For example, if you want to work on an Android project, demonstrate that you know something about Android: include links to GitHub projects in the target environment, and enough context in your proposal to suggest that you stand a good chance of being successful.

If you don’t have a project to point to, then consider volunteering on the project that you want to work on for GSoC. In fact, you should do this anyway, as a good pull request will go a long way towards demonstrating your skills to a potential mentor. Just remember that when you open a pull request, you are ‘auditioning’ for the role you want to have. Your prospective mentor will get a very clear picture of whether they want to work with you for 12 weeks based on what they see.

Ask for feedback on your proposal

Before submitting your proposal, be sure to reach out to your desired mentor to ask them to review the proposal. Take their feedback seriously, too. If your desired mentor tells you that they won’t support your proposal as written, then you should believe them and rework it. Furthermore, please take your mentor’s constructive criticism with good cheer. They’re spending a lot of time on this process, too, and want your proposal to be as strong as it possibly can be.