Google Summer of Code
GSoC is a prestigious programme and many students dream of getting selected and calling themselves a GSoCer but only a few know what needs to be done and they end up making mistakes. If you don’t know what GSoC is, I would recommend first reading up about it and then come back to this blog.
Many people think that to get selected in GSoC and successfully complete it you need to be an excellent programmer with complete knowledge of the technologies but I beg to differ, sure that can help but all you need is patience and perseverance. I know it’s easier said than done but trust me it pays off. I would be jotting down some of the mistakes that I made and how I learnt from it.
My Failure
I heard about GSoC from a senior in my sophomore year and started preparing for it. I didn’t know any development languages back then and was only versed with C (thanks to competitive coding). I ended up shortlisting an organisation whose primary codebase was in C and didn’t focus on what the project is about and guess what, I couldn’t even contribute a single line of code because of my lack of interest in the project and its functionality. This brings us to our first mistake that many people make.
Mistake: Picking an organisation based on the current knowledge of languages/frameworks.
Pre-application phase
I think this is the most important phase and sets up the base. I started my GSoC preparation in the month of February and learning from the mistake I made, I thought of contributing in The Honeynet project because of my interest in cybersecurity, but that should not be the only factor on which you should select an organisation.
Picking an organisation
Google releases a list of selected organisations in the final week of February, and if you have already started your preparation before the release, you need to look for the list of organisations selected last year. As I mentioned before, shortlist some of the orgs based on your interest and what they do but do not limit yourself by the technologies.
Figure out their main medium of communication(which might be email, IRC, slack, etc.), join these channels and introduce yourself. Getting familiar with the org is as important as researching about the company before taking a job, otherwise you end up cursing the whole experience of GSoC and might leave midway.
Mistake: Not interacting with the community before shortlisting one org.
Along with this, take a look at the projects which interests you under these organisations and play with the projects as a normal user. This might also help you in shortlisting the project/org you wanna spend your summer in.
I know everyone wants to jump and start coding but these small-small things matter and hard work is like a vector, the direction is as important as its magnitude.
Contributing to the project
This part is where many people get intimidated by the codebase and give up and I don’t blame them, anyone would get intimidated by thousands of lines of code, but do you need to go through all of them? No.
I know my next statement might shock some but even the maintainers of open-source projects are not completely in sync with the whole codebase and would even need their own time to figure out things.
So how should you jump into the codebase, the answer is you shouldn’t. If you have already mapped and used the project as a user you might have a brief understanding of what might be happening under the hood. Go to their github repository, fork it and clone it. Look for the steps for development setup and follow them. Play around with the project and take your own time to be comfortable with it.
When you feel you are ready to contribute, look for beginner issues on their repository which might be labelled as beginner-friendly or good-first-issue. If you still can’t find beginner issues you can ask the community for help, remember that don’t shy away from asking questions(until you can find the answers with a google search) and always ask on public forums rather than DMing the mentor.
Mistake: Picking up hard issues.
Make sure to follow the guidelines mentioned in CONTRIBUTING.md and after pushing your code to your own forked repo create a Pull Request(PR) and wait for the mentors/contributors to review your code. Once the PR is merged, voila, you are a contributor to the project. Follow the same procedure and pick your next issue, once you start gaining confidence and get familiar with a section of the codebase you can tackle more difficult issues. The number of accepted PRs plays less role than you think in the selection, it’s the quality of the code that matters. My friend had 3 accepted PRs whereas I had 10 PRs in the same project and we both got selected.
Drafting application
Most of the organisations have their goals for the year pre-planned and thus the project ideas might be already mentioned on their website(or on similiar platforms) along with the template for the application. It’s a good idea to work on the already mentioned ideas as that represents the priority goals of the org/project and a higher chance of acceptance as compared to your own project idea.
Note! If you have a good idea, then don’t shy away from pitching it to the mentors.
You should start working on your application at least two weeks before the application period starts. This allows you to get feedback from mentors on your application and get the best version out in the end.
Once you pick the idea you are interested in, research about the idea by extrapolating on already mentioned information and make your own notes. You can compile these notes and send a mail to one of the mentors asking for the guidance and help. I am attaching a screenshot of my initial mail which did not include any of the notes and I realised my mistake later on.
Mistake: Not communicating with mentors on ideas and draft application.
You should have your application reviewed by your peers and look out for any grammatical/spelling mistakes. I am attaching my proposal here. Be to-the-point in your application and do not be ambiguous. When the Student application period begins on March 25th you should be ready with your proposal in a Google Doc (or whatever format the org prefers) and upload the link to the GSoC portal. Please make sure that you don’t email/message your proposal to the mentors(until they ask you to), cause any application not uploaded to the GSoC portal is not valid.
Once you upload the link, you can ping your mentors informing them regarding the same and use the next two weeks to get feedback and improve your application
Post application phase
Keep in touch with the community even if you have submitted your application cause that shows that you are really interested in the project and then wait patiently for the results.
If you are selected, kudos to you but don’t forget that getting selected is just the start, you need to keep up your hard work for the next 3 months and pass all the phased evaluation to call yourself a GSoCer.
If your application didn’t go through, don’t be disheartened. Ask the mentors for feedback and scope of improvement so that you can apply next year. Look back on the journey and see what all you have achieved in the past two months and take pride in calling yourself an open-source contributor, giving back to the community.
Tip! Open source is all about enjoying and having fun. Don’t forget to get some.