Back in 2021, I decided to try my luck at Google Summer of Code (GSoC). It was a great experience and it’s something I would recommend to anyone who’s interested in software development. But, as a beginner to open-source (as I was), it might get a bit overwhelming to figure out what might be the best thing to do at a given time. I intend to reduce that stress by providing a clear set of steps that you can follow in order to maximize your chances of getting selected. Feel free to skip over sections that you’re already familiar with.

GSoC Logo

Clearing Some Doubts

Oftentimes, people tend to believe that you must be an expert at programming to complete GSoC. This is, in no way, the case. As I see it, the real reason why the completion of GSoC receives so much recognition is that it acts as a stamp of approval saying, “this person can get stuff done”. So if you manage to find a project that interests you, or you are already passionate about any form of coding, then you can be sure that you can make it.

That being said, you do need to have some coding knowledge before you get started with applying (it wouldn’t be worth it if it was easy :-) ). If you’re starting from zero, then don’t worry! I’ve seen many who have completed GSoC without coming from a CS background. Take some time to build your knowledge in some coding language (something like Python can be easy to start with), and come back.

In case you already have some experience with coding, then great! Continue on to the remaining sections.

Steps for Getting Selected

1. Pick the Right Organization

Finding the right organization and project can be quite a time-consuming task, but it’s important to choose it in a way that maximizes your chances of selection and completion.

Filtering Organizations

You can filter the organizations using the following criteria:

Uses a language you’re comfortable with
Is / Includes a software you’ve already used
Is in a field you’re interested in

If you’re lucky, you’d be able to find something that satisfies all three of the above criteria. However, this may not always be the case.

If you already have some projects in mind, then this part would be somewhat faster. But if you don’t, there’s no easy way around it. To find the right organization, you may have to go over all of them on the GSoC organizations page. GSoC has divided the organizations into different categories, so you can get some assistance from that, but the categorization may not always be accurate. For example, they categorized Tensorflow under programming languages which, in my opinion, isn’t the best place for it.

GSoC Organization Categories

The good news is, you don’t have to dive in deep for every organization. Each organization card has an explanation of a few words that describes itself well enough to get an idea. If you find something that looks interesting, then dive a bit deeper.

Blender Foundation GSoC card

Start with about 5 - 10 organizations, and continue narrowing it down until you are left with 2 or 3 organizations. While narrowing down, if you happened to come across one you really like, then sticking with that is fine too.

What Next?

The next step is to get familiar with the chosen few. Try using the software itself. Keep an eye out for any improvements that you can make. If you’re lucky, you may even find a bug. If you do, report it and make a note of where you reported it. That’ll be helpful when it’s time to write the proposal. Also, take a look at the codebase. You’re likely not going to understand anything at a first glance (I didn’t), but this is just to get a feel for things, so no reason to worry.

2. Make a contribution

While this step is definitely optional, I’d say it’s the most influential. If you’ve made a contribution by the time you apply for a certain organization, then you would have drastically higher chances of passing the selection. Of course, the necessity for a contribution would depend on the project you’re going for, as well. Keep that in mind as we move forward.

Here’s how I’d do it:

Step 1: Setting Up and Communication

Look for any existing documentation for new contributors and read them.
Clone the source code and compile if needed. Try to get a local copy of the software up and running, from source.
Join the discussion groups. You can find the respective links for your chosen organization on the GSoC organizations page.

Communication channels

Step 2: Find an Issue

Find the issues page and find an unresolved issue.
You may find “easier” problems classified as “good first issues” but don’t limit yourself to these issues since they can be harder than they look.
Give priority to newer issues over older ones.
If there are newer “good first issues”, then they might be the best ones to go for.

Tensorflow “good first issues”

Above is a good example of why “good first issues” aren’t always easy. As you can see, it’s an issue from 2018. A better option in the above case would be to go for the “contributions welcome” label.

Step 3: Have a go at the issue(s)

It almost definitely WILL be extremely daunting when you get started. Especially, if it’s software that’s been around for a while. The sheer size of these codebases will be daunting. But fear not. That’s how we all start. Besides, I doubt even the founders of most of these software are fluent with the entire codebase.

Let’s break this step down into “sub-steps”:

If you haven’t already, download an IDE. I recommend VS Code due to its flexibility.
Open the downloaded source code on your IDE
Try to find a part of the source code that is responsible for the issue. Not exactly the easiest task, but the IDE will help you with it.
- If you’re working with software that has a user interface, then searching for the name of the UI component might be your best bet. For example, if there’s a problem with an improperly functioning button, your best bet may be to search by the label of the button. This likely won’t lead you straight to the source of the bug, but once you get there, you can try looking for what functions the button press triggers.
- If you’re working with software without such a visual component, maybe like an API or a library, then you can search by the name of the faulty function, and then work from there.
- Try to set up debugging, if possible. By debugging, I mean the ability to add a breakpoint in the codebase so that you can confirm that the code has reached a certain point. Setting this up differs from software to software, so I won’t go into details regarding how to do that.
Try to fix the issue. Once you’ve found the exact source of the issue, it’s usually not too hard to do so.
Another thing to keep in mind is, never hesitate to ask questions. In fact, the more questions you ask, the more your presence is felt, and thus, the more likely you are to get selected. Additionally, be courteous and thank those who helped you.

Step 4: Submit your solution for review

You may have come across some contributing guidelines back in Step 1 (sometimes they appear as “CONTRIBUTING.md” in GitHub repos). Sometimes these guidelines have instructions on how to submit a fix/solution for review. If they do, then follow those instructions to make your first contribution.

If you weren’t so lucky as to find such documentation, it’s always fine to ask for help. The other community developers would be happy to either point you to the right resources or guide you themselves.

The next step is to get your submission reviewed. Keep in mind that some of these organizations get dozens of patches for review every day. So, it can be a bit difficult to get someone to review your patch. Try to find the best person to review. It could be someone who helped you out during the solving of the problem, or it could be the person who wrote the code, initially. After adding the reviewer, if your submission goes unnoticed for 3 or 4 days, then feel free to poke them just a bit. Keep in mind that they may have more urgent work and thus, may not be able to review it at the moment. Be patient, and it’ll happen.

After all this effort, the patch may still not get accepted. However, keep in mind that that was not the goal of this. Rather, it was everything that took you to get to that point and you can give yourself a pat on the back once you get there.

3. Creating the Proposal

This, too, is quite an important step; not purely for the proposal itself, but also for your interactions during the period.

Check if your organization has a page dedicated to GSoC. If they do (they most likely will), then see if any of the suggested projects catch your eye.
If you decide to go with one of the suggested projects (which is safer), then create a draft proposal (we’ll discuss more about this in a bit) and find someone to help you improve the proposal. It would be good if you could find a potential mentor for that particular project. Sometimes this may be mentioned on the projects page itself.
The other option is to create your own project idea. However, before spending time on making the proposal, it may be a good idea to ask the developers if they think it’s suitable for the GSoC project. Also, ask whether it would fit into the required number of hours for the project. Once the idea is validated, you can create a draft proposal.
If you previously worked on making a contribution, you could pick (or suggest) a project in that area of the codebase. That’ll be helpful during selection since they’d know you’re already familiar with that part of the code.

Creating the Draft Proposal

The only reason I’m calling this a draft proposal is that it’s likely to undergo further changes. This means that you should try to create a well-defined proposal as the first iteration itself. That’ll be somewhat time-consuming but it reduces the work that has to be done by the developer who’s helping you improve the proposal.

If the organization has provided its own guidelines for creating the proposal, then follow them. Otherwise, my suggestion would be to look at the proposals of applicants from previous years of the same organization. In the case that you chose an organization that’s participating in GSoC for the first time, then you can use the proposal guidelines provided by Google themselves.

Let me provide some tips for two important sections that are almost sure to appear, regardless of the proposal format.

1. Tips for the Deliverables

When creating the estimated timeline, try to overestimate the time you’ll take to complete each deliverable. You can add a note saying that you’ve overestimated the time you’ll need, in order to leave room for error.
Break down each task into clear, easily accomplishable subtasks. Not only will this help to show the reviewers that you have a clear plan, but it’ll also give you a straightforward path to follow.
Try to create a very simple prototype, and provide a link to it on your proposal. I believe this is another thing that can greatly improve your chances of passing the selection. If you have the time, this is something definitely worth spending it on.

2. Tips for the Bio

This is where you should mention some of the stuff we talked about in the previous 2 steps. Provide links to things like your contributions, bug reports, etc. If the work you did is in the same area as the proposal, then do mention that specifically.
Feel free to reference any projects that you’ve done using the programming languages used by the organization.
If you would like to continue to contribute even after the GSoC period, then that’s a great point to mention.
If you’ve used the software in the past, then do mention that, as well.

4. After Submission & Before Selection

If you’ve done the steps before (or most of it), then you don’t really have to worry too much about this period. But, there’s still stuff you can do to improve your odds.

The main idea is to continue to interact with the community and be active. It doesn’t have to be any major contributions. Even simple bug reports and occasional attempts at bugs are quite valuable. Last year in Blender, one of the applicants continued to contribute to the community in different ways, and they decided to make him a paid contributor. I’d say that’s just as good, or even better than passing selection. So it’s definitely worth investing time on since it allows the selectors to feel confident about their choice.

Final Thoughts

Hopefully, these tips would be helpful for you to secure your position at GSoC. If you have any questions, feel free to reach out to me on LinkedIn or comment down below. Good luck to everyone!

☕ Buy me a coffee