My Blog

How to write a good Google Summer of Code Proposals


Let me keep it short. As short and concrete as your proposal should be. I document my examples with this years proposals, but the fact you see title of your project here means nothing. These are just examples.

Project title

Nothing more here. Keep it short and precise. NTFS for FreeBSD is so much different than Proposal for FreeBSD. Positively different.

Short description

I always try to think that lesser is more. Please keep it short. Very short. Lets make it 2-sentence short. So short description can contain 1 sentence answer for each of the questions:

Most of the short descriptions of the projects were surprisingly good.

Provide real name and surname

If possible, provided something that can be entered with limited set of characters. Basically something that consists of a-zA-Z characters. The reason is that we all have limited knowledge of the world and to save ourselves lots of confusion, lets keep things simple. Please provide name you’ll be using over duration of the project If for some reason name from the Google form is different that the one which you use on a daily basis, please point it out in the proposal right away. This saves us some time too.

E-mail, phone, IRC, language

Nothing special goes here. Whichever e-mail is fine, as long as you check it on regular basic. Phone … probably won’t be used, so I wouldn’t be too much afraid.

IRC is very useful – please mention precisely what’s your typical nick when where are you typically hanging out. FreeBSD has a dedicated IRC channel:


You can meet actual mentors there. Once you join, you can feel free to ask questions about GSOC.


Provide relatively accurate availability: number of hours per week which you can spend on the project. Be honest. We all know 8 hours per day of actual coding is rare if you have school, assignments and real life. Yes, doing what you want (FreeBSD is what you want, right?) makes GSOC fun and you can spend more time on it, but don’t make this number higher artificially.

So here is important thing: I don’t know what’s the Google’s expectation for these numbers. If they expect “8 hours” …. well … you have to put 8 hours. Actually 8 might be right.

(I think the secret idea is to figure out which people can handle: 4[weeks]x4[days]x8[hours] schedule and steal them to Googleplex later)

Remember what those 160 hours mean: it means hours on refining the project, answering e-mails, coordination, delays, waiting for your mentor to review your work, figuring lots of obscure problems on your own, cursing BSD community (well, other communities are bad too, but these are only BSDs that are identified with Beastie).


This is important for me. Lets assume you’re applying for the FreeBSD project. Some stuff which I’d expect you to write in a bio is:

Possible mentor

This section is important to me, since it shows me you’ve researched the topic well. Mentioning person who I know has an expertise related with your proposal means you:

All of it is very good, since it shows you did some additional work to actually help your proposal get accepted. Yes, you can actively lobby to help your project. Basically: if I see you actively pushing people over e-mail/IRC to help you with finding a mentor, this is a good sign.

If no activity is done from your side, this is bad.

IRC channels: #freebsd-soc and #bsdcode on EFnet are the good place to hunt for mentors. You can ask on a mailing list too. We have a mailing list for this purpose too. However, I don’t know what its activity. So maybe ask on have a freebsd-hackers. This is probably pretty darn good way.

Project Description

Before you jump to the project description - I sort of miss “motivation” section in this whole Google/Melange world. I think having a motivation backed by good arguments is important. So please include answers to: Why did you pick this project? Why do you think it’s interesting? This will help us understand what’s driving you in the GSOC train.

Anyway: I’d expect you to provide in-depth explanation of the project next. A lot of projects are very different in between each other, and it’s hard to give a guideline, but just like they teach us all: introduction, content, summary. This is how I would like to see GSOC project descriptions stated. Some questions which you may find helpful: What’s the project all about? What does it solve? What current system/program doesn’t have, that your project will bring? Who will benefit from it?

Don’t include all answers to all questions. “Project description” must be technical, and not only having brave statements. So include technical details too:


This is pretty short, but important. “Deliverable” is what you deliver. This is more or less your schedule.

This isn’t all that rocket science. I often have problems with assessing time. So just take several assumptions: you have 160 hours. Let say 60 hours are spent on: interruptions, coordination, reading manuals, documentation, web pages, blog entries etc. which help you figure out what’s the stuff you’re working on all about. Basically: 60 hours of cost related with learning and catching up.

This gives you 100 hours for doing real work.

Typically you’d jump and start coding. Yes, I know, I know. However, it would be good to have a sketch. It would be good to have a schedule.

Can’t help you with that. Really. Joel Spolsky has something for you: Painless schedules

(By the way, he wrote tons of good stuff on his blog, which is summarized in his two books:

Really excellent resources of knowledge, I can highly recommend)

Anyway, lets get back to deliverables. Example:

Note dates. Note specifics. Basically it’s good to see whether you’re on track or not. It helps you, it helps your mentor.

Test Plan

If you work on FreeBSD, ask first. In FreeBSD base we have some directories that contain unit tests. Provide something that tests what you’ve done. Having type 17 commands is always worse than typing 2-3 commands. In the perfect case you’d provide 1 script that tests whatever you’ve made.

Of course that’s very generalized case: if you have worked on very specific kernel-level project, you’ll have to provide other means of testing framework.

However, you get the point. Provide your mentor a way to systematically test your work and actively give you feedback.

If I have to type:


to observe what you’ve done already, it’s much more likely I’ll do it and provide some feedback. The end, Hope that helps