Quick Tips to Help You get Accepted on Google Summer of Code

I’ve great news that, AFAIK, there are two students from Indonesia that have been accepted on Google Summer of Code 2010. They are (drum roll please) Akeda and Dwi. I’ve been posted a message on gsoc student mailing list to alert other Indonesian students, but no one replying. So, I guess there’s only me and dwi get accepted this year.Since, I’ve accepeted I’ll give my own tips on how to get accepted as a student of Google Summer of Code.

The key is write a good proposal and communicate with your mentoring project oftenly. A good proposal is not your first try proposal. When you writing your proposal for the first time oftenly it’s just a draft proposal. You need to ask your mentoring project some feedbacks and iterate the process by rewrite and ask again until the mentoring project says okay. This year is a little bit different, some mentoring organisations posts some bugs tagged for applicants and each applicant should work, on bug(s) by submitting patch for that bug. I did this. Doing this means your chance to get attentions from mentoring organisation is higher. So, you need to touch the codebase of the project which you have interest on it. Because of this you shouldn’t have to submit a proposal as much as you think to get accepted. The increased quantity of your proposals may even decreased overall proposal qualities, since you have to split your focus.

Okay, you’ve got the picture? Alright, how about the content of good proposal? Some mentoring organisations were kind enough to give us templates of proposal to work on. The templates are general as it should have a brief description about the project you have interested in, implementation plans, timeline and short biography about yourself. You should focus (IMHO) on writing your implementation plans and timeline. A google summer of code project is around 3 or 4 months duration, so it can be said as a medium project for a single developer. The key is how good you describe the problem and its solution. When you touched the codebase of a project for submitting patch, you get the benefits on how you’ll describe the software on your proposal. Use the name of the classes, methods, libraries that related to your project and how you’ll using it to solve the problem. Mentoring organisations will pick up student that already familiar with their codebase. Don’t write too much, use screenshots if available. If your project is a complex one, divide your project into three or four subprojects then define the timeline of each subprojects. Well, that’s my own quick tips. I hope Indonesian students will aware about this event on the next year.