March 23, 2017 |

A Convincing Proposal for GSOC

As pointed out in my previous post on a mentor’s perspective on Google Summer of Code, there are some points you should keep in mind when getting in contact with your open source organization of choice. The article you are reading is influced by my work as mentor and admin for Terasology, but I think that most of it also applies for other organizations.


Now that the Google Summer of Code application period has just started I want to have a closer look on the proposal itself. I am not going to talk about successful proposals since even a good (or nearly perfect) proposal is no guarantee for being accepted. Sometimes the number may just not be in favor, and there isn’t much you can do about it.

GSOC is a competitive program where in the end Google pays students to work on open source projects over the summer. 1,032 students participated last year in GSOC 2016 (three of them with MovingBlocks), and all of them convinced an organization with their proposal.

If you are reading this, you potentially want to apply for a spot in this year’s round, but you are not sure how to start with your proposal (or how to polish it to be perfect). Usually, we see the first drafts being submitted a few hours after the application period started. And, usually, these early drafts lack information, detail, or focus. Sometimes all of it. In the following, I am going to point out a few things that might help you to stick out of the crowd with your application.

Talk to the Community - Early!

You should have already shown your motivation by first pull requests, participating in community discussions, or by just being active in the org’s chat, mailing list, or equivalent. Talking to the community early on is not only a matter of getting to know the community, but also a matter of mentors and developers of getting to know you.

Just to get an idea of how busy orgs and mentors suddenly get when applications are about to start, look at this little statistics tweet. This might not sound like too much, but I’m pretty sure the numbers scale for bigger organizations. Thus, don’t get upset if it takes us a bit of time to give a proper reply on your forum post or mail.

By talking to the community, you can easily figure out what is expected of a good/complete proposal. Every project has different ideas on how the proposal should look like, how detailed it should be, etc. (more on that later). It is always a good idea to contact your potential mentor(s), other students, and the community in general. Try to bring something to the discussion with mentors - technical questions, concrete proposals, generic ideas you want to turn into a project. It’s up to you!

Talking to mentors and others students can also give you an impression on how crowded a specific topic might be. Remember that there is only one spot for a specific topic and that you are likely competing with many other students for it (sometimes tasks can be split, but you should not count on that). Convince us that you are the best candidate out of all students applying!

Focus on One Thing

Hopefully, some of the ideas on an org’s task list are interesting to you. Probably, you actually like a bunch of them. That’s good and means that the organization managed to catch your interest. However, a (single) proposal should be focused on one summer project.

Avoid to cramp something-of-everything in a single proposals. This will just yield some random document that’s no fun to read. If you think about it from the organization’s perspective, it looks like you could not decide what you want to work on (in the best case) or that you have no clue about the project and the scope of tasks (in the worst case). Focusing on a single project idea also helps you to flesh out details of the document: the timeline, what you want to deliver, etc.

Keep in mind that you can hand in multiple proposals to cover different project ideas. A mentor will review your second proposal the same as your first one which means that both should be focused and on point. Of course you can copy common content, e.g., information about yourself.

Some Remarks on Structure

The structure of a proposal is not set in stone, and you can clearly come up with your own format. Most organizations have guidelines on their websites, for instance the KDE proposal guidelines or the Mozilla Foundation Application Template. And, as I am not the only one who has an opinion, you can find various articles by mentors and/or former GSOC student; I enjoyed reading Teo Mrnjavac’s thoughts on the matter.

According to various guides and templates, reviewers of your application usually expect the following aspects to appear in the document:

  • section about you
  • brief motivation of your work
  • a timeline
  • deliverables (and stretch goals)

In addition, you can provide any additional information you want us to know. Previous contributions to the project, qualifications and certificates, special courses or lectures you’ve attended, etc.

Learn from Successful Proposals

Google Summer of Code is all about open source and communication. That’s why it is not uncommon to share your application with others. We are already seeing this in the current application period, and I think it helps the students to spot open questions in their texts. Although the following disclaimer should not be necessary, I am still going to say it once: Don’t “steal” ideas or copy applications, convince us with your own words of the project you want to work on.

If you are curious about what a convincing proposal from last year looks like, you can find the GSOC 2016 proposal by tdgunes in our forums. Ashray Malhotra has shared his very detailed proposal as well, it’s worth a read. And then there is also the FOS proposal collection, including the one by rzats who worked with MovingBlocks last year.

Take Your Time (to Improve)

The application period has just started, and you are not in hurry to complete the whole thing within the next 24 hours (in case you are reading this early enough, that is). Start with a draft version, add placeholder and hints for what is not there yet. Use the remaining time for discussions, and incorporate the feedback you get. A second year student suggested how to emphasize your skills better - work it in. A mentor pointed out that you should spent more on a specific sub task - adapt the timeline. There was a discussion that lead to a pleasing graphic illustrating the idea - add it to the proposal!

I as a mentor like to see how a student adapts the proposal based on feedback. However, I don’t like to find parts unchanged which I clearly advised to rethink them. We are not trying to prove you wrong, we are just trying to make sure your summer project will be a success. If we ask to clarify a sentence we want to assure that we are not talking at cross purposes. Estimations on your timeline are based on our experience with the code base. If you are faster than expected, there will always be stretch goals you can work on.


Last but not least I want to mention the GSOC Student Guide by FLOSS Manuals which has tons of tips and tricks. If you haven’t looked at it yet you should definitely head over and read through some chapters. May I suggest Writing a Proposal?