A Guide to the Google Summer of Code
Over the last few days, I’ve received several messages and emails on the subject and after addressing some common queries online, I decided to compile everything into a single post.
A short note on the program
The Google Summer of Code (GSoC, for short) is a program whose primary goal is to boost interest in open-source. The program targets college and university students and gives them the opportunity to contribute to open-source organizations of their choice over the summer. The coding period is the main part of the program and is when you work with your mentors. It is divided into three sections by evaluations. This is where your mentor provides feedback and evaluates your work in that period.
The myth of the ideal candidate
Goals
The first thing I would like to talk about is that GSoC is not a competitive examination. It is an opportunity for you to play a role in open-source software development, implying that you would benefit a lot more from this program if you are actually keen on contributing.
That’s why it is often said that choosing a project that you actually use in your life is a pretty good idea. It would be much harder and oftentimes less rewarding to finish GSoC successfully if you are just doing it to appear “successful”. For me personally, did finishing the program open more opportunities for me? Probably. Would I have been less ‘successful’ if I hadn’t participated in the program? Maybe not.
Skills
A common question I get asked is: Am I good enough?. Though skills are an important part of your program, I would say that they are not deal breakers. If you know how to code in the language your project uses, or if you have a decent idea of a particular framework, you should not have any problems getting selected. Of course, it is imperative that you spend a little more time honing your skills than someone with “ideal” skills would.
Shortlisting organizations
This is a very important step of the process. It is necessary to be realistic but at the same time, a little optimistic. It would probably be a little too hard trying as a candidate for, say, the git project, if you have no idea how it works or have no knowledge of the C programming language. That’s not to say that it’s impossible, just that most people would be doing it alongside their regular course loads and it would certainly be more difficult to balance both.
Though one often gets the advice: “Just pick a organization and start contributing…”, it is often not that straightforward (well, it probably is if you’re really skilled and/or extremely lucky). I suggest going through previous years’ projects and organizations (present in the archives) and focusing on the ones who use the languages and frameworks of that you are interested in. Probably short list about 2–3 or even 4 organizations that interest you - they may seem like a cool project to work on and your skills align to a greater degree when compared to other organizations.
Make sure that your selected organizations have participated in the at least the past year. Though it is very rare for a regularly participating organization to not be selected for the next year’s program, it is still possible. Unfortunately, not much can be done about this, except to keep your options open: hence, the advice of shortlisting multiple organizations.
Contributing
Once you are done with the shortlisting step, you should ideally end up with a set of organizations that you are happy to work with. Now, I’d suggest introducing yourself on their communication channels (generally mailing lists or slack), talking about who you are, why you are interested, which particular area of the project you are interested, your skills, etc.. Make sure to go through any contribution and new comer guidelines prior to this. It does not look to good if you ask them where to start, and there is an entire section with the exact same title on their website.
Don’t be afraid to ask if you are unsure of how to start (but only if it is not clearly mentioned anywhere, though it usually is) - you’ll save everyone some time. And time is likely the most important factor in your selection. If there is no obvious place to start contributing (again, there usually is), just ask. They’ll like your enthusiasm. You could also suggest adding some contributing or new-comer guidelines to the maintainers. Maybe this could be your first issue.
Communication is an important aspect of your journey - you’ll spend hours in contact with your mentor(s). Being polite, enthusiastic and giving prompt replies to emails or messages gets you closer to being the ideal candidate.
Around February, start thinking about which organizations you are going to move forward with. And that’s it: just stay active, show your skills and enthusiasm and with a little luck, you should see yourself as a participant.
Announcing the Participating Organizations
Though the GSoC time line varies a little (have a look at the timeline on the official website), you should expect participating organizations to be announced in the second half of February. As mentioned earlier, almost every organization continues participating year after year. This is probably a good time to finalize which organization you’ll actually move forward with, so that you have enough time to dedicate your complete attention to it and more importantly, your potential mentors notice your enthusiasm.
The proposal
It was the most daunting part of my journey, and I’m sure some would agree. The scary part is probably the fact that you have to come up with it all by yourself and it is impossible to get help (not a 100% true). Till now, your journey was a little more mechanical - you went with the flow. Personally, I feel that the difference between a good proposal and a great one is the deeper understanding of a project and ones own abilities.
For the uninitiated, your proposal is basically your ticket to the program. If you ace this part, your chances of selection are greatly increased. Your proposal basically outlines what you, as a candidate, will do and when. This means that you should have a timeline in mind along with clear cut goals. Ideally, there should be some big goals, which should be divided into a per-week basis. Each coding period (there are three) can have its own goal.
This is of course, not the only way. There are several excellent posts out there that you could have a look at to fine tune your proposal. Just make sure that you follow your organization’s proposal guidelines (formatting, structure, etc), deadlines and most importantly, ask your future mentors for tips if they are willing (they most likely will).
The last stretch
There are a few weeks between submitting your proposal and the announcement of the selected candidates. Use this time to focus on the areas you’ll be working over the summer. Make sure you are comfortable with stuff like virtual environments, git, GitHub, docker, the command line - whatever your project uses. Continue to contribute, all the while increasing the significance of your contributions. When the day arrives, you thank yourself for your efforts.
In conclusion
Just remember that even if you are not chosen, it may not be only about you. As a mentor, you’d definitely want to go with the ‘best fit’, and that may not always be the ‘most skilled’. Many people don’t get into the program in their first attempt but are much stronger candidates in subsequent years. Be sure to ask for some feedback as to where you can improve the next year. Then again, there are bound to be some candidates who end up failing due to missed deadlines, so make sure you are organized and have everything on your calendar (I hope you use a calendar :)).
Though I have attempted to make this guide thorough but general enough to apply to everyone, it may not be as exhaustive as I had initially hoped. Please put any suggestions and queries in the comments. I hope this post helped you.
Good luck!