How to write a kick-ass proposal for Google Summer of Code

Mar 1, 2012   //   by Teo   //   Amarok, GSoC, KDE  //  11 Comments

In a few weeks students can begin submitting their applications for Google Summer of Code 2012.

KDE is applying to be a mentoring organization again this year, and I’ve already been contacted by several students looking to do a Google Summer of Code project with KDE (and specifically Amarok in my case). Prospective Summer of Code students usually have lots of enthusiasm, and they often write great proposals with little or no help, but sometimes these proposals might not be structured so well or lack key information.

I’ve been a Google Summer of Code student with KDE three times (four if you count Summer of KDE) so I’ve been in the very situation prospective Summer of Code students find themselves right now. I’ve also been on the other side of the fence: I haven’t been a Google Summer of Code mentor yet, but I have mentored Google Code-In students and I’m a professional software engineering instructor (since 2008), so I like to think I can relate with both students and mentors in this case.

This post is for students who wish to take part in Google Summer of Code.

Google Summer of Code is a kind of like a scholarship program, and a very competitive one: if you get picked, you’re one of just a thousand students in the whole world (1075 last year, 51 of those with KDE) who get to spend their summer hacking on Free Software while learning from the very best hackers, and get paid for it too! In order to do that, you need to submit an application to Google. An application is essentially a bunch of information you enter in a form, the most important part of it is your proposal.

A Google Summer of Code proposal is a document, it can be rich text but it’s best to consider it a plain text document because the web application that handles proposals has only basic formatting features.

The KDE community maintains a wiki page specifically targeted at Summer of Code students with very useful information on how to get started. Read it. Really, read it, please. Yes, all of it :-P Done? Great! Assuming you’ve gone through points 1-3 of the Recommended steps list, it’s time to prepare your proposal.

Writing a good proposal is not easy, especially if you’re a student making first contact with an organization, in this case your proposal is your best advertisement. You have to convince the organization (or at least some key people inside it) why YOU are the right person for the job! What follows applies to KDE, but it should work for other organizations as well.

I used to structure my proposals the following way (worked well 3 times). It’s not a rule! You can structure your proposal otherwise, but I think this is a good guideline if you need some inspiration:

  1. Introduction. Every software project should solve a problem. Before offering the solution (your Google Summer of Code project), you should first define the problem. What’s the current state of things? What’s the issue you wish to solve and why? Then you should conclude with a sentence or two about your solution. This is somewhat like an elevator pitch.
  2. Project goals. This section should again be short and to the point, and it might be a good idea to format it like a list. You should propose a clear list of deliverables, explaining exactly what you promise to do and what you do not plan to do. “Future developments” can be mentioned, but your promise for the three months of Google Summer of Code term is what counts.
  3. Implementation. This section can be longer and more detailed. You should describe what you plan to do as a solution for the problem you defined earlier. You don’t need to provide a lot of technical details, but you do need to show that you understand the technology and illustrate key technical elements of your proposed solution in reasonable detail.
  4. Timeline. This section is easily overlooked, yet it’s arguably more important than the previous section. With the timeline you show that you understand the problem, have a solution, and that you have also broken it down into manageable bits and are have an actual plan on how to approach it. With this section you set expectations, so don’t make promises you can’t keep. A modest, realistic and detailed timeline is much better than a timeline that promises to move mountains. Mentors can spot unrealistic timelines.
  5. About me. If you’re done with the other sections this will be a piece of cake. Just put down your contact information and write a few sentences about you and why you think you’re the best for this job. It’s ok to brag a little ;-)

Overall, submit your proposal early, keep it short but include all the necessary information. Get it reviewed by the right people in the organization, well before submitting it to the Google Summer of Code web application. In KDE’s case you should submit your proposal to the contributors’ mailing list of the relevant subproject as published on the ideas page. I can’t stress this enough: get feedback. Organizations want good proposals and good students, and are usually eager to help you improve your proposal. Just write a brief and informal email, attach your proposal and ask for feedback. No need to write “Dear Sir” and such, we’re cool ;-)

I hope this advice proves useful. We have also gathered some accepted proposals from past years, you might find them useful as inspiration.

You can submit more than one proposal to the same organization or different organizations to increase your chances, but don’t overdo it: quality is better than quantity.

Good luck!

11 Comments

  • I cannot stress enough the strength of the mentors. You will get access to people for *months* for whom other people pay €300 – 400 *a day* for to get training from. Many core KDE people actually teach training courses and this is the official price for them.

    • Well, I believe they do corporate training and nobody hires them for private 1-to-1 training? So you still have to divide that value by the number of students.

      And yeah, I do agree it’s really cool to be able to talk to and get consulted by the professional Qt coaches absolutely for free when working on KDE, e.g. via IRC. I always thank Chtulhu (:P) for the fact that I can ping dfaure any time I need him and he will provide valuable advice and fix kdelibs with me and for me (ok, for my project, to be correct.)

      Still.. I have this kind of personal ethical problem, related to open source and getting paid for it. If I am sponsored, and am an intern, and ask a dev that knows more than I do to help me, and that dev does some fix for me or does a major part of it, and is *not* paid at all – I’m like abusing him here? Not fair right? Well this is why I really like to consult professional Qt/KDE devs on complex issues – I always know we’re both rewarded for doing it, nothing unfair here. What do you think? Sorry for hijacking it a bit but the topic is so close, couldn’t resist asking.

      • Personally I wouldn’t feel abused as far as GSoC is concerned. In the long run, it’s for the good of a project I deeply care about. Sure I’d like to get paid to hack and to mentor, but that’s not what’s being offered by Google in this instance, it’s moot. Google offers some money for the project and some more for the student. In exchange, the student will write some code and the project has a shot at getting a new contributor. The only thing I have to do is set aside a few minutes a day to give a helping hand, minutes I’d spend hacking for free anyway – sounds like pretty much win-win to me. This way the student does some hacking (which some other contributor would have to do for free otherwise), more code is written and my workload-for-free isn’t any heavier. Also, as a rule I would help a student with suggestions and the occasional debugging, but not by writing major parts of *his* work i.e. work he promised to do – that’s the deal and I find it quite fair.

      • You should definitely *not* feel as if you’re abusing him or her. If they do it as part of their job, they are being paid to do it and if not, well even professionals are allowed to have a hobby, no? I am both a professional developer and have taught teaching courses before, and I love to teach what I know. Helping new people getting up to speed in my favourite project is a joy, at least if the “student” is picking up what I say. :)

  • Well I was actually talking about general open source development, not only gsoc, because people are sometimes sponsored to hack on open source projects :) But yeah, I see your point there – the ratio between the amount of work for you, volunteering, and for the paid guy.

  • Students should also read this imo: http://blog.martin-graesslin.com/blog/2012/01/the-importance-of-mentoring/

    Cheers, looking forward to a good GSOC again :)

  • s/write/wrote in the last meme

  • An excellent guide. Thanks Teo.
    I’ve my eyes set on a couple of KDE projects of this year’s GSoC. Hoping to make it. :)

  • [...] Teo's blog Diary of a KDE developer HomeAbout MeProjectsTeaching RSS ← How to write a kick-ass proposal for Google Summer of Code [...]

  • [...] great number of students that every year join KDE in submitting a proposal? Then look no further: we have a huge set of ideas, and we are more than happy to welcome yours (we know a lot of people with great ideas out there, [...]

  • [...] forget to check our student guidelines. Also, last year I published an article with some tips on how to structure your proposal, you might find it [...]

Leave a comment

Blog Categories

1

Google+ Activity

  • Tomahawk 0.8 is out for Windows, Mac and Linux, featuring a major redesign and heaps of new features!
    ... and a beta for Android too. -- 1 month ago
  • Productivity in a box! -- 5 months ago
  • THIS! °_° -- 6 months ago

Enter your email address to subscribe to this blog and receive notifications of new posts by email.