This blog covers my journey of getting selected for Google Summer of Code 2020.

Table of Contents

• What is GSoC
• Introduction
• Selecting an Organization
• Selecting a Project
• Contributing
• Writing the Proposal
• Waiting for Results
• Wrapping up

What is GSoC?

Introduction

The first time I heard about GSoC was back in my first year through a friend who told me about one of her friends who got selected into GSoC in their second year, and what an impressive feat it was. I remember laughing and telling her I would too next year, and it was a joke at the moment, a supposed way of saying I could do impressive things too, but it later became the biggest motivation to get selected.

At the time I was a part of my college dance society, and we spent most of the days practicing the routine for hours on end. While I loved both dancing and computer science, more often than not, I was beyond physically exhausted to do any amount of studying after getting home. My college grades, which depended a lot on attendance, took a great hit and it seemed like I had nothing to show for what I did in an entire year. Come second year, I ended up dropping out of the society to cover up all the missed opportunities from my first year. I started looking through courses and projects to get a better understanding of what I enjoy doing, and that’s how I started with web development. I had forgotten all about GSoC by this time until I attended a workshop with my friends where some speakers spoke about how they got selected last year. The speaker mentioned that it’s still not too late to apply for this year’s program. Once home, I did some research about the workings of the program and read some articles about how to get selected.

The general process to follow for applying to GSoC is:

• Selecting an Organization
• Selecting a project
• Contributing to the organization and the project
• Writing a good proposal
• Waiting for the results

Selecting an Organization

I started looking at organizations around mid-January. I found one which had a great community and considering how greatly other articles of GSoC emphasize selecting an organization that you can work with; I thought I had the biggest obstacle down. I started contributing, taking part in discussions, and looking through the issues. But when I tried to figure out a layout for my project proposal, I realized that although the mentors were great, and the community was great, the project didn’t really motivate me to try and bring out my best. And this was a huge lesson. You shouldn’t run after an organization. Your main focus should be the project that you will work on. While it’s okay to go for the big names for your resume, it wouldn’t matter if you end up not growing as a developer once you come out of the program.

When the final list for selected organizations came out at the end of February, I decided to have a look at all the project ideas, in case I could find something motivating, and fortunately, I found one that I really liked in OpenRefine. This project was more front end related and looked like something that will teach me a lot about user experience and DOM manipulation. Here is a link to the project.

One thing that could get a little intimidating when selecting an organization, especially if it’s your first time exploring open source, is the amount of different technologies a particular project uses. It is hard to find a project where you have experience with all the technical tools, so in hindsight, it’s okay for you to select an organization where you have only 40% of the tech stack down (and you might not even end up working with the part of software that uses a language you have zero familiarity with). Plus, the coding period begins much later, so you could use that time to learn all the unfamiliar technicalities of your project.

Selecting a Project

Often, people suggest selecting an organization before a project, but ideally that is most likely to not work in your favor. The organization and the project go hand in hand; selecting an organization and then finding a project might result in you ending up with something that you are only doing for the sake of it.

It’s very important, especially to get selected, to go for a project that excites you and motivates you to push your boundaries and learn additional things. A project that you love automatically means a proposal that will be great, it’s easier to write about something you are excited to learn and implement than something you are doing just for the sake of it.

And GSoC is not just the stipend and the name, it’s a significant way to learn how to look for efficient solutions and implement these solutions with the help of the mentors and the community.

Contributing

The next step is to contribute to the organization and the project you have selected. Go through the docs and set up the project in your local machine, start exploring and finding bugs. You can also look at the good first issues and start solving some of them. This step, although unnecessary, is still important as it shows the mentors that you understand the code base and could finish the project if selected.

The first Pull Request is the scariest one, and if you manage to get through that, the rest of it comes easily. I still remember my first PR, which was not only the first in OpenRefine but also the very first one. It seems intimidating to submit one and wait for a review that is most likely to contain some alterations. But the maintainers always know when it’s your first time and cut you some slack. While everyone thinks first impressions matter, no one is here to judge and people gladly help the newcomers. My first PR was a blunder, I made an embarrassing mistake and was ready to throw hands and never come back, but somehow I pulled through. And the happiness I got when that pull request was merged is incomprehensible. It feels like a certain kind of validation of your efforts.

This phase is also when most of your interactions with the mentors and the community take place. It’s the right time to evaluate how active a project and community are and ensure that you will receive help should you run into any problems. It will also help to understand the workflow of the code and get a better idea of how you will implement the project.

Writing the Proposal

The contribution phase becomes one that really affects the quality of your proposal. It is expected for a proposal to contain a detailed explanation of your implementation and timeline. And since it’s the basics, it is fair to assume that most students follow this path. What gives you an edge in such a situation is the contributions you have made to the project till then. This helps solidify the trust in your abilities to finish the project. I am not saying you should make tens of pull requests, but making even a few can strengthen your proposal to a great degree.

Often organizations have their own guidelines to write a proposal and it is important to stick to the given format if you want to get selected. Because of a large number of applications, it becomes easier to filter out applicants that do not adhere to the given format.

Your proposal should be short and give details on your plan of execution and timeline. It is important to stay honest and mention your abilities along with the things you have yet to learn. It’s a better practice to submit a draft proposal as soon as possible, as it can get hectic and take a while before you receive a review. I submitted my draft two days after the submission phase started and am glad to have done it early as I ended up having to change almost the entire logic of implementation in the proposal after the first review.

If your project is a front-end project, be it for web or android, it’s good to add some UI mocks to your proposal to help the mentors get a better idea of what you are planning. You should also discuss the project before starting to write the proposal to gain a better understanding of the goals and expectations.

You can write up to a maximum of three proposals, which means you can apply for three projects. Although it’s good to have a backup, make sure that the proposals you write are of high quality. Your chances of getting selected do not increase by the number of your proposals, but by the quality of your proposals.

Writing a proposal is hard. Students with well-written proposals are the ones to get selected as opposed to those who contribute a lot but do not have a proposal that stands out. It is good to start well before the submission phase, as it will give you more time to find and cover up the loopholes. You can look at my proposal here.

Waiting for Results

Once you submit the final proposal, all you do is wait. The results come out after a long time so it’s better to spend it learning more about the code and the ins and outs of the project. Stay active so that the mentors know that you are still around.

When the results came out, it was kind of hard to believe that I made it. GSoC is the first significant accomplishment during the time I have been in college. And I can tell you from experience that if you keep trying your best, no matter the competition, it’s not that hard to make it.

If you don’t make it, remember that it is not the end of the world. There are still a lot of other things to try out. Some things are not in your control, and it is okay to go at your own pace. A lot of students don’t make it on their first try, so you have a handy experience to give you an edge over the other students next year. Plus, you learn a lot in the process of applying.

Wrapping up

To conclude, I would say that GSoC is not something that only “geniuses” can get into. It’s all about determination and your will to learn and push your limits. Even if you don’t get selected, you come out of it gaining more knowledge of how a real software is developed. It helps discipline you and teaches you how to interact in discussions in a large community. It’s an exciting process and taking part in it, no matter the result, is definitely an experience that will shape you into a better programmer.