Lately I’ve been spending some time on writing my SoC applications for this year’s edition. I’ve applied to 3 organizations so far, mainly because of the fear that just one application isn’t good enough to ensure a slot. A lot of students are frantic about how they must prepare their applications, and so I thought I’d give my 2 cents on the topic.
First off, relax. If there’s something I’ve learnt from last year, it’s the fact that if you’re really serious about the project you’re applying for, you have nothing to worry about. However, there are a small number of applications that are excellent in quality, but don’t make it because the organization doesn’t get as many slots. That place is not a good one to be in. So, it turns out that being excellent isn’t enough. You need to do better to make sure that you’re really on the top of the list.
Last year, I had applied to 6 organizations and 4 of those proposals were selected. In my opinion, all the 6 proposals had the same quality; they were all, after all, written by me and used the same “template”. So what was the reason for the 2 rejections? Gnome didn’t accept my proposal because my idea wasn’t very appealing to them – the proposal was great, but the project itself wasn’t something that was on their “priority list”. Portland State Univerisity didn’t accept my proposal because the idea was completey irrelevant to them – it even probably got marked as “spam”!
That means, the idea itself is as important as the application. To create a winning application, you first need a killer idea. I can safely assume that >80% of the applications selected last year were for ideas that were provided by the organization itself. Let’s face it, it’s difficult to come up with a killer idea that is *relevant* to the organization in question without being intimate with the organization beforehand. If you feel you’re not the creative type and you’re applying to an organization you haven’t been involved with before; play safe and go with one of the ideas posted on their ideas page. The mentors go through a lot of brainstorming to decide what ideas make it to that page. However, be warned that not all ideas may be really important to them: Gnome has divided their ideas page into three categories of decreasing priority.
Consequently, choosing a high-priority task also means that you’ll be facing stiff competition; and you’ll have to work extra hard to make your application stand out. But that’s what it takes to make a winning application. The organization is guranteed to pick their high-priority projects, unless there are *no* good applications for it (which is very unlikely), and that means the odds are higher here anyway.
Once you’ve chosen your idea, you need to sit down and write the application itself. Which, in my experience, just boils down to answering the 5 fundamental questions:
1) What? Be as detailed as you possibly can about what exactly you’re trying to do. Giving detailed explanations of what the problem at hand is all about, gives mentors the confidence that you know what you’re talking about. Some students have asked if they should start mentioning functions names or minute technical details; but in my opinion that’s a no-no. Detailed means a surface review of what problem you’ll be solving, or what feature you’ll be adding – not the exact technical details. In fact, in many proposals, figuring out those technical details may be a part of the project itself.
2) Why? If you’ve chosen a high-priority task, this answer should be easy. But it’s important to send a message to the organization justifying why this proposal is important to them, and how it would benefit them and the FOSS community in general. If you’re proposing one of your own ideas, this part is all the more important.
3) How? Here’s the part where you explain what your strategy for solving the problem is. Again, there’s no need to mention function prototypes or the nitty-gritty of implementation details; but you certainly must say enough to convince the mentors that you have the technical prowess required to complete the task at hand. As I’ve said before, in certain cases, working out these technical details is part of the proposal itself. In which case, include the various options that you intend to pursue. What happens if one of these options don’t work out quite right?
4) When? A timeline is an important part of any application. You don’t have to get it down to the date, but a rough outline in terms of weeks should be Ok too. Remember, mentors are looking for *quantitative* ways of measuring your progress. Give them milestones and spread out the project evenly across the given time. Also remember that this time around Google has given a whole month to get familiar with the project and working with infrastructure common to open source projects in general – So don’t say stuff like “Getting familiar with the codebase” or “Learn how to use CVS” in the coding time allotted. You need to do all that *before* you get down to business – on the 28th of May.
5) Why You? Summarize your application with a brief biography. Who you are and what makes you suitable for this project. You don’t need to repeat your whole resume here – certainly link to it – but be rather informal and focus on your *specific* skills or experience that are relevant to completing *this* project. The mentors can read your entire skillset in your resume anyway, use this space to convince them you’re the right one for this job instead. Give links to previous relevant work you’ve done. Show them you’re serious about this, and convince them that you will finish what you start.
A typical proposal is around 1000 words in length, 3 pages long maybe. Atleast mine are! Don’t be too brief nor too explanatory. The average amount of time a mentor will pay attention to your proposal is 2 minutes, so make sure your proposal can be read and understood in that time.
The applications I sent in last year are available here, and I’ll be posting this years soon. All the best, and most of all, Have Fun! FOSS is all about community and having fun, after all 
