Over the last few days, I’ve received several messages and emails on the subject and after responding to some, 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. Potential candidates are required to write a proposal detailing the work they would be doing along with a timeline with specific deadlines for each sub-task. 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 periods of evaluation. This is where your mentor provides feedback and evaluates your work in that period.
The myth of the ideal candidate
The first thing I would like to say 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 the Summer of Code program successfully if you are just doing it to be more “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.
A common question I get asked is: Am I good enough?. Though skills are an important part of your program, I would say that having less than stellar skills is 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 difficultly getting selected. Of course, it is imperative that you spend a little more time honing your skills than someone with “ideal” skills.
This is an 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 version control 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.
One often gets the advice: “Just pick an organization and start contributing…”, It’s apparent from the vague nature of this response that starting out with GSoC isn’t that simple. 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.
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’re 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.
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.
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 :)).
- Am I skilled enough?
Ans. Yes. (addressed in this post)
2. Which year in my undergraduate is the best time to participate in the program?
Ans. That depends on commitments and responsibilities. With respect to that metric, the general order of years from best to worst is: 1 > 2 > 3 ~ 4. The obvious problem with this is that your experience and skills growth follow the opposite trend. The happy medium is probably the second year, but if you are skilled/interested enough you could potentially do it in the first summer. Make sure you have enough time during the summer. In my opinion, the only thing worse that not getting selected is failing the program because you have too many things on your plate.
3. I have done the Andrew Ng machine learning course on Coursera. What else should I do to improve my chances of getting selected for GSoC?
Ans. If you want to pursue a ML project for GSoC, please work on as many personal projects as possible. Almost everyone has done that course, so you’ll need to build experience.Your projects portfolio will show your potential mentors your style, skills and approach to problem solving.
4. Do I need to know Linux?
Ans. A vast majority of open source projects use Linux. Its hard to give a definite answer since the choice of operating system you will be using the one your project’s development happens in. I’d recommend learning to use Linux — at least the basics like the terminal, the directory structure, creating and using virtual environments and installing packages and tools.
5. Will I be able to get into the program if I start now?
Ans. Yes. But the earlier you start, the better (in my opinion).
6. How do I start contributing?
Ans. Most organizations have some issues reserved for beginners and new-comers. They are usually labeled “easy”, “beginner”, “low-hanging fruit”, or something like that.
Remember that your first contribution need be world-changing. It can be as simple as a typo in their documentation. As you get comfortable with the project, you’ll naturally be able to solve more complex issues and bugs. Use the fact that you are new and let the maintainers know if the “Getting Started” section needs any improvements.
Though I have attempted to make this guide thorough but generic enough to apply to everyone, it may not be as exhaustive as you may like. Please put any suggestions and queries in the comments and I’ll add them to the article.
As I get more questions, they will be added to this post.
Originally published at polaris000.github.io on January 3, 2020.
Top comments (0)