The Whole Truth About Google Summer of Code - Part 1

Part 2
Part 3
Part 4
I think the topic is not new and everyone knows that a student can earn $ 5000 over the summer. The Internet is full of stories about “how cool I dragged in the summer,” but few people talk about the inside of this event.

At first glance, everything is simple - apply for a receipt and receive a scholarship. But if everything was so simple, there were not so few Russian students. And there are really few of them. Somehow rummaging through statistics, I found that from my city I was generally the only student ever to participate in the GSoC (that year, now there are more of us). And this is very bad, because I know a lot of people who are smarter than me and for some reason they did not participate or did not pass the selection.

1. How does it all start?

Somewhere in the middle of winter, Google pleases the world with its decision to spend the summer of coding. Т.к. the event has been held for more than a year, the organization is ready. In February, the first movements on the topic “well, we need to come up with what we want us to do” begin on the newsletters. In early March, organizations should already submit applications, i.e. the mailing lists already have a draft list of ideas. In mid-March, Google publishes a list of organizations. From this moment you need to actively move.

Idea sheets are already appearing on community sites and you should start learning them as quickly as possible. There is very little time. Approximately, you have a week to choose the organizations and projects for which you will apply. Then you should start working on the proposal.

Presented (proposal) - application for participation. Includes your profile and a detailed description of the project that you are going to code. You can submit several such applications, but you will work only one at a time.

Register, then subscribe to the mailing list for student candidates.

2. Who can?

All students and graduate students in any year of study, even in the last.

3. How to choose an organization?

The list of organizations will indicate key programmer skills. Usually in this column programming languages. Keep in mind that if an organization writes C ++, then you should have a good knowledge of C ++ and you should have at least some development experience in this language. There is such a special category of students that perceives these requirements as what they will learn during the course of the project. Nobody will teach you anything, this is a job, not an internship with a nanny.

Often students run to popular organizations like gnome, kde, apache, gimp, google, etc. It is clear that the projects there are interesting, but there will be many such interested. Besides the big question - what prevented you from doing something for this community outside the summer of coding?
To weed out people, organizations very often introduce additional rules. For example, the rule of one or two patches, or one year of contributing (i.e., you have been participating in development for a year). So before you grab onto the project you like, carefully read the additional rules, maybe your application will not even be considered.

What else do you need to know?

Your organization may also have a bunch of other rules. For example, requirements for coding style or report forms. Usually such additional information is indicated on the site. Carefully study it, otherwise suddenly some of the points is contrary to your religion.

It would be nice to see the statistics of the organization’s participation over the past years - what projects were there, whether they were completed successfully, whether the code was included in the release.

Chose, subscribe to the newsletter. Subscribed - rummage through the archive and read the previous letters. Perhaps there will be information on your project.

4. Select a project.

The most difficult thing is to choose a project. Even if you really like the topic and you just tremble at the mere thought of coding this project - you must evaluate the pros and cons very soberly. For some reason, none of the students thinks that in the summer they may not pass the equator (Mid-term evaluations deadline) and fly out of the project.

All projects are divided into two types - research and routine. You must understand that if the organization itself is not involved in the development of anything, then there are reasons for that.

1. Too complicated - you need to read and study this issue.
2. Too boring - rewriting a module, coding on a dock or other routine and uninteresting work.
3. Too incomprehensible - the organization knows what should be the output, but does not know how to implement it exactly. none of the team has the appropriate knowledge.

If you read the Russian newsletter and the list of accepted projects, you get the feeling that our students are suffering from gigantomania. Almost all Russian-speaking programmers choose research projects directly related to their dissertations or diplomas. Just rewriting some piece of code is usually not comme il faut. My opinion is that it’s easiest to fly out of these projects, because at the initial stage of development, there is still no exact idea of ​​the complexity of implementation. It is one thing when you have already done something similar, another when you are just going. If you have a choice between the boring implementation of something simple and research - choose a routine. You have no experience and you still do not know how to plan, and with research you can dig for a period longer than the summer lasts.

Never and never.

Once in one year there was an organization that invited students to implement very complex research projects. The level of research is candidate, and not domestic. According to my estimates, a decent study (not even implementation) needs half a year. And the implementation of such a project may take a year. For whom such tasks were intended, for me a mystery. Perhaps this was a "preparation" for their students, who had already conducted research and started development. Perhaps someone was hoping to get someone else’s achievements cheaply. In general - unrealistic projects you should avoid in any case.

5. We wrote a letter.

After choosing a project you should write a posed. Officially, you should post your suggestions in early April. Not officially - by this date the organization already has a draft list of accepted students.

Proposals are written during communication with mentors, i.e. you write, communicate and add. During this period, mentors get to know you and decide whether it is possible to work with you or not. But you don’t even have to communicate - the first time you post the perfect one, I’ll post it and answer a couple of small questions in the comments (this is a joke, if that).

I posed it - your implementation plan, you can say TK (anyone who has finished senior courses knows what it is). When GSoC just started spinning, the organizers demanded that students write proof of the need for the project. It looked very funny - the organizers put forward ideas, and then you proved to them that they definitely want their implementation. Now there seems to be no such thing (only if you yourself do not propose an idea, but it is also possible) and students write point by point how they will still code. An organization may also include in its posed questions, for example, ask to write briefly about yourself, your development experience, links to your projects, etc.

General description.

First you write about what you should do, i.e. entrance and exit. And you should definitely understand what exactly you are implementing and what result you guarantee by the end of August. Describe the problem and its solutions. You can add links to articles or other resources that you will use when working.

Technical description.

General technical description. Those. "I am implementing such and such a function in such and such a module." In this part, you must show that you have a good understanding of the source code, you have been able to compile and run everything yourself. It would be nice to create a brunch and make a couple of commits.


You should divide your project into subtasks and write when and what you will code. A very important point was missing. If it seems to you that you will complete the entire project in 2 weeks, then you will have time to implement it in 3 months. If it seems to you that you are doing well, you will not be able to do it at all. Your optimism is your worst enemy. If you read this text, you think that you certainly pull it, and at night you code perfectly, and you can’t sleep for 48 hours - go drink some water and take a few deep breaths, maybe let it go. It’s better to plan a lesser amount of work and then please your mentor with additional code than skip deadline. Write your plan pessimistically - if you have a plug, you will not fly out, and if everything goes well - no one will blame you for additional work.

The most important point is your first deadline. Those. The first date to which you promise to provide a piece of working code. Usually the beginning of June. If you have a routine project, add yourself a week, if you have a research project, add two. There is nothing worse than skipping the first deadline. Let it be better that you have extra time and you will do more than you promised, than you will begin to fall behind from the very first days. In addition, at the initial stage of development, the project always moves more slowly, the closer to the end, when you are already in the subject.

The most productive development time is two weeks before midterm and three weeks after. Then you will get used to the code and will be well versed in the task. Try to plan your time so that the bulk of the work falls on this time.

Plan your vacation. You need rest, and there is nothing illegal - you have the right to vacation. Plan your vacation for midterm or after - so you can relax and not drop out of the project.

Do not split the project into too small subtasks - so you will not leave room for maneuver. It happens that some subtasks have to be postponed to a later date, some to an earlier one.

Leave yourself a week after each major test task. Testing is your airbag in case you fail to do something. In addition, it is often impossible to plan the entire scope of work in advance, and you will have extra time for force majeure.

Do not leave anything important for August. Mid-August pencils down. So the week before this date is the final test. If you are still asked to write documentation or make any final changes, this will take another week.

6. Quantity and quality.

Once upon a time, Google recommended students post a few posts. At that time, this recommendation was relevant because the bulk of students threw themselves at well-known communities, while very few applications were submitted to unknowns. But now the situation has changed - there are more students who want to participate, and people really appreciated their chances of submitting to gcc or gnome.

I think it’s better to choose 2 or 3 communities and start working with prozozalami. If work is better in some communities than in others, then you need to throw all your strength into this one. There will be time - you can make the second. More, I think, will be difficult, because You can’t compose a good one without working with source codes.

7. The evaluation period.

After you post your position, the mentors begin to evaluate it, even if the evaluation period has not yet begun. After posting, you should start a discussion about your project in the mailing list - make your postal publicly available and throw a link to the mailing list on it. In some organizations, mentors talk to students through the newsletter or IRC, rather than in comments. They have democracy there, i.e. everyone should give their mark, not just the mentor of your project. If there are many projects, then a lot of time is needed for discussion. That is why the proposals that are posted on the very last day have practically no chance of success.

When the evaluation period begins, mentors already know who they will take. Perhaps you will still be asked questions about technical implementation, but only in order to make sure that you deserve a positive review. So, if you see in kamenty a question not from your mentor - do not be surprised and do not file. If interested, then they will vote for you.


If the same student goes through two projects, then his fate is decided in the second week of the evaluation period. It seems that you should prioritize projects, but I don’t know how exactly this mechanism works now. Previously, everything was solved through chat. Those. mentors contacted the main and reserve students and everything was decided online.

There were also cases when a student who was in two organizations, as a result, did not get into any. So if you have 2 good intentions, it’s better to tell the developers right away that in case of collisions you want them.

Google bugs.

I don’t know why, but almost every year Google pleases students by sending out preliminary results. Not everyone gets on the newsletter, and why no one knows why this happens. Somehow (it seemed like more than once, in 2011 it was exactly like that) students were sent not only preliminary results, but also assessments of mentors - “garbage”, “complete garbage”, “it’s better not to watch.” I was lucky to get to the newsletter only once. 4 days before the announcement of the results, a letter without text with the subject of congratulations came to the mail. In 9 out of 10, these results can be trusted, but not in cases of conflict. So one mentor was very indignant at congratulating the student when he was still in conflict.

8. How do we choose?

There are many tips on the Internet: what to do to be chosen. In my experience and the experience of my friends, I can say that such rules do not exist. Each organization operates on the basis of its own experience, their beliefs, preferences, current situation with prozozalami, etc.

The first advice that you are given is to communicate directly with the mentor. My opinion is not very good and not democratic. By the way, the idea of ​​democracy runs through the entire GSoC in bold red lines. Not all mentors love private discussion. First, they have democracy and the decision about your admission must be approved by the rest. Secondly, other students may also be interested in this project and it is easier for a mentor to respond to the newsletter than privately. For the same reason, it is not very good to discuss a project in IRC. Thirdly, not all organizations have a mentor appointed immediately. It happens that you will find out exactly who you work with only after the announcement of the results.

Communication in the IRC. Yes they love IRC because it is the best way to get to know you better. But there are several drawbacks - the time difference, the language barrier and current employment. All the same, the newsletter is better, because Any community member can join the conversation at any time. But if the organization wants and the mentor insists, you will have to chat a lot. You can say this is a good sign - they are ready to spend a lot of time on you, which means they will most likely take it.

Dirty hacks.

No, of course, you can take some actions that will greatly increase your chances of success, but there is only one way - to go on increasing.

More patches. You are asked to make a couple of patches, so do 3 or 4. So you stand out among the other candidates.

Early bid. As a rule, applications (good applications) submitted earlier are more likely to succeed. But there is another aspect - other students. If a student browses a list of ideas and finds that several applications have already been submitted for this project, he can refuse it, even if it is well suited for this development. Your task is to submit your application as early as possible, make it public and drop it into the newsletter. So you “mark” the territory and start a discussion with the mentors. Then you can rewrite the proposition, add more details - in general, do everything to show the community that you can work with other students and that “the place is taken”.

Project code. Add a piece of the working code of your project to your prozal. And do it quickly, so that the rest of the students do not apply for your project and you are not compared with anyone. Yes, even if served. They will promise that all of May they will read the docks and deal with the sources, and you have already read everything and partially coded. So you bypass the patch rule and provide a sample code.

Increase difficulty. If you are able to write a piece of project code as a patch, then you can promise to do more than you want. A small extension of the idea will look very profitable against the background of other applications. Sometimes a community indicates several levels of complexity in advance in the description of an idea, i.e. you can make feature “a”, but also feature “b”, and if you also make “c”, it will be really cool. So they try to get a student who will do as much as possible for the money Google.

Substandard project. Sometimes in large organizations (well, in small ones too, but less often) there are projects that affect some section of Computer Science. If this is not artificial intelligence in the game and not a search, then there will be few people who want to hang out or no one will be at all posit. In short, a tidbit for a Russian student. It will not be a pity for a large organization to give you a slot - for the sake of diversity, well, and you will make your own scientific project.

Portfolio. Candidates who can provide links to the code of their own project in the repository look more profitable than the rest. Sometimes this requirement is mandatory, because Mentors want to see an example of your code. So, if you have your own small project, then it's time to comb it and put it in the repository.

9. Volunteering.

Sometimes an organization offers volunteering, i.e. all the same, only without a scholarship. If your project wasn’t accepted (there weren’t enough slots, or you post it too late, or what other reason) and you have the opportunity to become a volunteer, agree. Complete the project successfully - next year means you will definitely pass; they don’t pay attention to you - it’s also good, you didn’t get into an organization that does not know how to work with students, next year choose another one. Try to benefit from any situation - experience in a tight time frame can be much more valuable than money.