Summary: I record my experience so far as an Internet2 mentor for the Summer of Code program. The primary audience are students, especially those who plan to apply for similar grants in the future. Secondarily, I address grant-giving organizations and individuals and fellow mentors. I give my best advice on writing a good application to the students, so that the best of them can make it through the sieve.
Google's Summer of Code program in 2005 not only allowed Internet2 to fund students to work on our open-source projects, but, by virtue of attracting the best students, allowed us to find contributors of quality we would have difficulty finding otherwise---money or no money. We are immensely grateful to Google for this.
I wrote the original version of the Summer of Code ideas page on May 31. June 14 was the deadline for applications. June 24 was the deadline for notifications. Internally, Google set June 23 as the deadline for mentoring organizations to finish ranking their applicants. The ideas page contains our suggestions on proposal content, etc. This is much more informal advice to future applicants.
I believe it benefits everyone to make the process as transparent as possible. Having a transparent process will help the best students win the grants, thus giving Google the most bang for their buck and the mentoring organizations the most amount of output. Having an opaque process, on the other hand, will make students guess at the best strategy, and, thus, introduce some randomization into the process, which will help only one party: the group of students who would not have received the grants meritoriously. This year, the process was being developed as we went. I will attempt to record here what happened inside the selection process and give my best advice on how to prepare the application the next time, or generally for a similar grant. I am only giving my best advice; it would have worked on me; I don't know whether I am a typical reviewer of these applications, but I have no reason to believe I am not. I would encourage other mentors to record their thoughts: the increased amount of information will help the best students win. As mentors, we're interested in getting the best students, so self-interest dictates the need for making one's decision process transparent.
If you want to win in a competitive stipend program like the Summer of Code, you'll be competing against an unknown number of people of unknown quality from all over the world. I know you're good, but they're good, too. You need to try to write the best application that the mentor will see. This is an easy guide to follow; it depends on your imagination, so let the imagination run free. Are you an undergraduate? You'll be competing against graduate students. Are you a grad? There will be ABDs in the pile. ABD from a top school with a list of relevant peer-reviewed publications and many years of experience? A few people of this level of qualification were rejected by us this time around due to lack of commitment to writing a good proposal. There will be smart and eager undergraduates who will put days or weeks of full-time effort into the proposal. You get the drift. You need to aim to write the best application. You might miss; your application might turn out to be second-best or even fifth. The point is, if you aim this high, and are serious about it, and are any good, you'll get the grant.
As I read the applications, I am concerned most about one thing: can the applicant really do what he promises to do? There are many ways to convince me, of course, but here are some typical ones: resume, related prior work, started work on the project towards which the applicant is submitting his proposal. Of these, resume is by far the least efficient. Don't try to emulate cookie-cutter (i.e., ``professional-looking'') resumes. The value of such resumes in job hunting is dubious, but for grants, they simply don't help. Usually, resumes are read by human resources specialists, i.e., people whose job is to read resumes. HR specialists will typically not understand what you do (unless you're applying for an HR position, that is), and will not judge the merit. They judge ``fit.'' To fit the position well, you need to submit a resume that has a set of keywords as closely resembling the job ad as possible. I am not an HR specialist, so I don't even read your list of skills. Keyword comparison is a poor predictor of performance, or Google would have automated the whole selection process. Prior related work (and any prior work that I can see) is much better than resume. Having performed similar work in the past is a good predictor of ability to perform such work in the future. Even better is work on the suggested project: if you can show that you're already doing the work that needs to be done, and doing it successfully, you have solved the problem of convincing me you can do it. You might still burn out, have a personal emergency, or get hit by a bus, but I have high confidence that you're capable of doing the work. Another excellent way to convince me in your ability to do the work is to present a detailed plan for doing it, with a good schedule. Such a plan is a great complement to any other ways. All applications we accepted had good plans, and not having a good plan was grounds for rejection even for people with very impressive resumes.
As you read this advice, I'm sure you're thinking ``That's a lot of work for an application.'' Exactly. That's the point. You prove your ability to do work with work. The more work you put into an application, the better are your chances of success. As the number of submitted applications increases, your chances of being accepted for at least one project actually decrease. Put all the work into one (or, at most, two) applications. Be prepared to spend at least two full days preparing your application. If you want to make sure you succeed, spend a week. Study the literature. Read the code. Prepare a plan. Ask questions. (No, I won't be annoyed. Not even a little bit. OK, I might be annoyed if you're too lazy to look something up, but never if you want to ask about the best approach or the meaning of something.) Write code. Can you write a prototype that implements some part of the system that I am asking for? If not, you probably won't be able to do the project. If you can, and do so, you stand out from the crowd immediately. If you can, and don't, you've just harmed your chances. The more work, the better. This isn't wasted work, either. If you put a week into preparing your application (and if you're any good), it won't be rejected. So, you simply did the work ahead of time.
We received 126 applications. We selected 12 of these for approval. Google gave us 10 slots, so the top 10 choices were funded. It was very easy to reject perhaps a third of applications that were very poor, indeed. Where do people get the notion that cutting and pasting my own text from the project description so that I can review it is worth $4500? Who are the people who think that one-line or one-paragraph applications will get them the stipend? Some of these very brief applications were written by people with impressive resumes. It was obvious they could do better. Yet they doomed themselves to failure. I'm guessing that many of them didn't want to do work before being paid for it. I'm guessing some of them applied for too many projects and thus could not write good applications. I don't know what exactly were the reasons, but it isn't possible, for the vast majority of people (OK, I'll make an exception for celebrity hackers), to convince a mentor you'll be able to do the job with an application that was written in five minutes. These applications consume a bit of mentors' time to reject them, but they aren't a threat to serious applications. There is no way a slot would be taken by a one-liner.
It was almost as easy as the first round of rejection to select the few top choices. These were the people who did what I advise above to do; they submitted outstanding applications. You want to be in this part of the pile, where we're not talking about whether to take you, but about the exact deliverables or other minor tweaks to your project.
The difficult part was in the pruning of the large number of very good and excellent applications to fit the number of slots we would get. Many excellent applications were rejected in the process. We could not take everyone, and Google allocated a finite amount of money for the program (they did double the amount from $1M to $2M when they saw how many applications there were). This is not a good place to be: on one hand, you've invested quite a bit into your application and have well-grounded hopes that it succeeds; on the other hand, the success is far from being guaranteed. Did we make any choices that we would have reversed, given more complete information about the students' abilities? I'm sure. So, as an applicant, you need to give us this more complete information. In a high-profile program such as anything run by Google, the entire scale is shifted towards excellence. Excellence is the norm, once you quickly filter out the really bad applications. Excellence, thus, isn't enough. Aim higher.