Google Summer of Code is a program sponsored by Google to introduce students to open source programming. Students work on the projects mentored by different open source organizations. It is an incredible opportunity to learn the various tools and practices used in real world softwares. I was GSOC 2017 student under OpenMRS in my sophomore year. In this post I will shed some lights on how to start preparing for GSOC.
2018 Program Timeline : https://developers.google.com/open-source/gsoc/timeline
Understanding the GSoC 2018 Timeline
Before I go on to the general guidelines of getting selected for a project, let’s look at the timeline of the GSoC 2018 program. I’ll be discussing the events that are relevant to students, and the detailed timeline can be found on the official site.
- February 12: List of accepted mentoring organizations published on the Google Summer of Code 2018 site.
- 12 March: Student application period opens.
- 27 March: Student application deadline.
The period of February 12th to 27th March is of utmost importance to students who wish to get through. This is the time when you decide which organizations to work on, connect with the mentors of the project and prepare your proposals to be reviewed by your mentors. By 27th March, you must have submitted your proposal on the official site, after which your proposal is locked. If, however, you find mistakes in your proposal, you may ask your mentoring organization to make it editable.
A student is allowed to submit at most five proposals to the program under various organizations. It is therefore possible that two or more proposals are selected. But a student can work on only one project during the summer as per the rules of the program. So the organizations try to resolve it first among themselves, or ask the student which project they would like to work on.
- 23 April: Accepted student proposals announced on the Google Summer of Code 2018 site.
- 14 May: Students begin coding for their Google Summer of Code projects;
The time between the announcement of selected students and the beginning of the coding period is called the ‘community bonding period’. Google recommends that you spend the time getting to know people on the mailing list or the IRC, read documentation and get up to speed with what is happening in the organization to begin your coding. However, you may also start the coding in the community bonding period if you and your mentor decide that’s the best thing to do. A welcome package is sent to you at this time.
- 15 June: Phase-1 evaluations deadline; Google begins issuing Phase-1 student payments provided passing student survey is on file.
Your work is evaluated by your mentor after four weeks since the coding starts. If you have been meeting the goals you set in your proposal, you should be able to pass this fairly easily.
- 13 July: Phase-2 evaluations deadline; Google begins issuing Phase-2 student payments provided passing student survey is on file.
Phase-2 evaluations are a lot more harder than the Phase-1. Under these evaluations, mentors expect to have a clear picture of whether or not the student will be able to finish the project or not.
- 14 August: Firm ‘pencils down’ date. Students can begin submitting final evaluations to Google. By this date you MUST be complete with all your work and proper documentation.
- 21 August: Mentors submit their final evaluation.
Your final work is judged by your mentoring organization to decide if you have passed the program. A certificate of completion and a Google Summer of Code t-shirt along with a few goodies would be mailed to you on successful completion of the project.
How can I get selected?
I have successfully completed the program last year and people often ask me for the secret recipe for getting accepted. There is obviously no such secret. However, there are definitely certain guidelines you can follow, but they are not applicable to every individual.
Pre-requisites
I believe the most important factor in getting into GSoC is having sound knowledge in one technology. Be it Java, Python, Ruby or JavaScript — make sure you are comfortable in the language and target organizations with projects based on your comfort zone.
Secondly, all open source organizations use version control software to manage changes in code from a globally distributed team. Be it git, svn or mercurial, you should know the basics of version control and be comfortable using it.
Another important pre-requisite in my opinion is the use of unit tests. Most organizations need you to write unit tests for the code that you submit and therefore, you need to know how to write them well.
Although prior contribution to open source projects is an advantage, it is not necessary as long as you can prove you can contribute to the codebase by submitting a patch.
Choosing the right OS
If you are a Windows user then you might feel odd one out in the group of developers. Most of the developers (including myself) prefer Linux over Windows for various obvious reasons. Although it is not a necessity (unless you are working on the Linux kernel itself :P) but it is highly recommended that you install and learn any of the Linux flavor. You might find it difficult at first but trust me, it will make your life a lot easier later into the program. Go to your org and ask people on IRC to help you with setting up the developing environment.
Start early
Although it’s already late to consider this, but if you plan to apply for GSoC 2018, start now. If you are reading this already late post, finish it! Stop everything you are doing and start! The earlier you start, the better your chances are for selection. But how exactly do you “start”?
You could check the organizations that have been selected (If the list of organisations is not out yet look at previous years organisations), go through their “ideas page” and see if you are interested in their projects. You could suggest your own ideas, but the ideas listed on their respective pages have already been debated and organizations are most probably going to go with those ideas — unless yours is really innovative! (and that’s very rare :P)
If an organization interests you, join their developers’ mailing list and hang out in the IRC chat room. Open source people are generally very friendly and if you have any issues, they’re there to help you out! However, remember that mentors also have full time jobs and open source is only voluntary work, so you should be considerate too!
Also, make sure you’re polite when you communicate in the mailing list or IRC. In addition to that, be patient (and avoid being like this).
Remember, mentors are volunteers and they are not obliged to help you. They have many other important things to do, so respect their time. Learn the IRC, mailing list etiquettes and how to ask smart questions. This presentation is also going to help you a lot.
Prove you can contribute to the codebase
Getting introduced on the mailing list or IRC may not be enough. To be selected for a competitive program such as the GSoC, you need to prove you’re among the best. The easiest way to get noticed is to contribute to the codebase.
Read the documentation and clone the code on your local machine. If you have issues running it locally, you can always revert back to the mailing list or IRC (you will surely get your issues resolved!)
Every organization also maintains an issue tracker (or some list with some other name like a bug tracker). Find an easy bug to start off, or ask for one on the mailing list. At this point, you must know one important thing — many others are working on the organization, so never start working on a bug unless you have been assigned the bug. If you do and someone was already working on it, the organization is obliged to accept the solution that was provided by the one who got it assigned first.
Once you solve a bug, submit a pull request (or a patch, if it’s on GitHub, GitLab or BitBucket). Then work on a second bug. Then a third and fourth and so on. Most organizations require you to submit a pull request as a pre-requisite to be accepted in the program.
Making the proposal
The proposal is a detailed document that you submit to the organization before getting selected for the program. It roughly contains information on what you plan to do over the summer, which requires good understanding of the project that you are working on.
The outline for proposals are usually supplied to you by the mentoring organizations. They usually don’t have a word limit — so it’s a good idea to make it as long as possible, explaining every small detail. In my opinion, include everything in as much detail as you can, include UI ideas (if your project involves one), include diagrams, graphs. Try to make it as detailed as possible, a good proposal would be around 10-15 pages.
Here are a few guidelines on writing a great proposal.
Here’s my own proposal
Code, eat, sleep, repeat!
Code the summers away! And don’t get disheartened if your proposal is rejected, you can always contribute to the organization and learn from the community.