A Comprehensive Guide to GSoC

Hey! I’m Maanas and I’ve been a Google Summer of Code (GSoC) contributor and mentor. I’d love to share some insights and how you can improve your chances of getting into the program.

Please note this article is intended for absolute beginners and experts alike. Feel free to skip to the Applying section if you are familiar with what exactly is GSoC and how it works.

What is the Google Summer of Code?

Google Summer of Code(GSoC) is an initiative by Google to bridge the gap between new contributors and open-source organizations to further the growth of the open-source community. It is an online, international program designed to encourage new contributors.

There are three major stakeholders in the program:

Contributors — This refers to the people new to open-source who write code.

Mentors — These people are part of the open-source community and help guide the contributors.

Organisation Administrators or Org Admins — They are at the pinnacle of the open-source organisation and are responsible for ensuring things run smoothly under their organisation.

How it works

Approximately around January, open-source organisations register to be a part of the program. Around February, the accepted organisations participating in GSoC are announced. These organisations offer multiple projects that the contributors can work on. In addition to this, members of their community play the role of mentors that help guide the contributors.

Next, contributors submit proposals for the projects they wish to work on — with a maximum of 3. The deadline is generally around April. These proposals are carefully analysed by the community members and mentors of the respective project and ranked accordingly.

Lastly, Google matches contributors to various projects keeping in mind the rankings provided by the open-source organisations with the constraint that a contributor can only work on a single project. These accepted contributors are generally announced around May. With this, the program moves into the community bonding period followed by the coding period.

Being accepted into the program is not the end of it. The contributors have to work on the deliverables stated in their proposal and their progress is tracked by the means of evaluations. There are 2 evaluations in the complete GSoC term, a mid-eval and a final-eval. It relies on a pass-or-fail criterion — failing means you are immediately out of the program.

For the eligibility criterion of the program, check this out.

Benefits

Talking about the benefits of the program, I know, the stipend is a good enough reason to participate. But to be honest, putting yourself out there in troubled waters — out of your comfort zone — to fall and get back up is the thing that stuck with me the most. It really builds up confidence and also increases faith in oneself.

Talking about the materialistic advantages, yes, there is a handsome stipend for the contributors based on the kind of project they work on — medium-sized(~175 hours) and large-sized(~350 hours) projects. This stipend is adjusted as per the country’s purchasing power parity. Last but not the least, GSoC also shines brilliantly on your resume :)

Applying

Moving on to the last and probably the most important section — how to approach applying for GSoC?

The first and most crucial task is to choose a project and an open-source organisation. For this, I highly recommend first writing down the skills that you currently possess and the ones that you wish to acquire. This will help you narrow down your search.

Now, if the open-source organisations for that year’s GSoC have already been released — head over to the list of projects and filter them out based on the set of skills you just wrote down. Try to start with this as early as possible. I’ll admit I was pretty late to the party and began doing this when the proposal submission had already begun. But it all worked out in the end :)

If the organisations have not yet been released — head over to the GSoC archive and filter them out based on the skills you wrote down. The projects and organisations that have been part of GSoC for the past couple of years are most likely to be a part of the program this year too. This will require you to look up projects for the past few years.

Once you have a hefty list of projects, move on to narrow it down to 3–4 projects. This is really important as you cannot work effectively on more than those many projects. For narrowing down I recommend the approach I personally used — try to pick out the most “out of the way” projects in each iteration. Like in the first iteration read all the project descriptions and their GitHub readmes, make a gist and then drop the ones that just don’t feel right to you. It can be because you don’t like working on the front-end, because you don’t resonate with the problem that the projects aim to solve or any small detail for that matter. DO NOT reject a project based on the sole reason that it requires you to learn new stuff. Stick to this and you’ll thank me later. This will eliminate 2–3 projects from a pool of 20 let’s say. Perform such iterations and don't forget to go over the descriptions again and again — trust me it’ll help — till the time you are left with 3–4 projects at hand.

So by this time, we have the projects that we want to work on — which is amazing! Most of the folks don’t invest their time in the above things and are either left with too much to do or are aimlessly putting in efforts where they are not required. Next, there are 2 main things you need to focus on. First, making your presence felt in the communities and second, contributing to the projects you decided on. These two things go hand in hand. There is no exact way of doing this but I’ll highlight what worked out best for me.

Firstly, to make your presence felt in the open-source community I would suggest going through the community’s website — most communities have one — and finding their open developer chatroom like slack, gitter or such. Just drop a hi with an introduction expressing your interest in the community and the project. Trust me it’s as simple as that. Many people don’t even go through with it.

Moving on to the second thing, contributing to the projects you have shortlisted. My best advice here would be to head over to the GitHub(or whichever platform the respective community uses) repository of the project, go over the readme, try running it on your local machine and then move to the issues section. The thing is to look for good first issues that align with your interests and skillset— mostly they are tagged with what you need.

Now comes the overlap. To understand issues completely, you can leverage the developer chatroom to clarify your doubts from the maintainers of the repository — having run it on your machine also shows that you are not only interested in the project but are also willing to work for it. Having productive discussions with the maintainers and other members of the community can help broaden your vision and also introduce you to new points of view.

Having gathered enough information about the project and the issues move on to the next thing — working on the issue. Try setting up the environment on your system, and also seek out help from the maintainers if need be. Finally, work on the issue and open your pull request. Now just a heads up, if you are unaware of Git and GitHub, please learn about the same — these are an integral part of any open-source project.

Finally, when the time comes, you will have to write a proposal for the project you are applying for. Now, this is another tricky, yet fun part of the whole process. Writing a quality proposal is no walk in the park and requires a lot of time and effort. To provide you with a direction, I’d highlight the important components that I feel would help. That said, many organisations have guidelines and templates for their proposals so be sure to check them out and stick to them.

Checklist for sections of a quality proposal:

• A clear and precise title
• Name and communication information
• About me
• Project Overview
• Deliverables
• Implementation strategy

There are some major setbacks that people face while writing a proposal. I guess highlighting them for you might help, so here they are. Firstly, take sufficient time to write a project proposal. You cannot have a perfect proposal in the first iteration — go over the things again and again, work with the maintainers to clarify doubts and whatever else comes to mind. Next, submit multiple proposals — a potential contributor can submit up to three proposals for any of the projects. Submitting multiple proposals will surely increase your chances of getting into the program. Lastly, submit your proposals for early review by the maintainers on the GSoC portal. This will help you receive early feedback, incorporating which might prove helpful.

Just one last piece of advice, I’d suggest you carefully evaluate your commitments for the coming summer so you can do justice to the project as well as yourself if you are selected :)

So that’s all from my side. Hope you found this helpful! Good Luck!

P.S. Feel free to ask any questions in the comments below or reach out. Any feedback is welcomed :)

Feel free to connect with me on LinkedIn