In a few weeks students can begin submitting their applications for Google Summer of Code 2016.
KDE has been accepted as 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. 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 lack key information.
I’ve seen my share of good and bad proposals. 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 have been a Google Summer of Code and Google Code-In mentor (and organization administrator) and I’ve been working as a 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 world (about 1300 last year, 36 of those with KDE) who get to spend their summer hacking on open source software while learning from the very best software craftspeople, and get paid for it too. In order to achieve 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 plain text because the web application that handles proposal only has 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. 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 of all people 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). This is not a hard rule. You can structure your proposal otherwise, but I think this is a good guideline if you need some inspiration:
- Introduction. Your software project should solve a clearly defined problem. Before offering the solution (your Google Summer of Code project), you should first define the problem. What is the current state of things? What issue do 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.
- 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 the Google Summer of Code season is what counts. It is better to promise less and deliver more than to promise a lot and then fall short. At this point you are making a commitment, and should your proposal be accepted, your mentor will evaluate your progress through these deliverables (and other factors).
- Implementation. This section can be longer and more detailed. You should describe your plans 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.
- Timeline. This section is easily overlooked, yet it’s arguably more important than the previous section. With the timeline section you show that you understand the problem, that you have thought hard about a solution, and that you have also broken the solution down into manageable bits. If your timeline is reasonable and its deadlines achievable, you show that you have an actual path in mind that would take you from idea to delivery. With this section you set expectations, so do not make promises you cannot keep. A humble, realistic and detailed timeline is much better than a timeline that promises to move mountains. Google has selected the very best open source organizations in the world to take part in Google Summer of Code, and the mentors in these organizations are often the top professionals in their respective fields. Mentors can easily spot unrealistic timelines. Be upfront about other commitments during the season’s coding period, including but not limited to: exams, classes, travel and vacation days, internships, jobs, volunteer work, etc.
- 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. If you’ve already done some open source work, don’t forget to include links.
Proofread your proposal. We get that English may not be your first language, and nobody will reject an otherwise good proposal just for a few spelling mistakes, but please check your punctuation and use a spellchecker. A proposal with too many spelling and punctuation mistakes can be hard to read and looks sloppy. With your proposal you want to present yourself as the opposite of sloppy.
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. As far as KDE is concerned, you should submit your proposal to the developers 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.
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 my advice is to not overdo it: quality is better than quantity.