We expect that this year, as in previous years, we will have more high-quality project proposals than Google will be able to fund in spite of their enormous generosity with Summer of Code. Here is our detailed list of suggestions about how to write a Summer of Code proposal that will stand the best chance of rising to the top of the heap…
Requirements
First let me summarize our minimum PSU requirements on Google Summer of Code Proposals.
- Applicants must, of course, meet Google’s requirements for participation in Summer of Code. (http://socghop.appspot.com/document/show/program/google/gsoc2009/faqs)
- Based on last year’s experience, we will not consider applications from those planning to be employed more than 6 hours per week outside of their Summer of Code commitment (including time spent volunteering for other projects and activities, and counting credit-hours of University instruction).
- Applicants must be able to be in regular close contact with their PSU mentors via the usual open source means (email, chat, etc) for the duration of the Summer. Thus it is not necessary for the student to be in the same city, state or country as his/her mentor.
- Applicants must be reasonably fluent programmers in their target programming language.
Proposal Outline
- Name and Contact Information
- Title. Make it attractive enough to convince us to read your synopsis.
- Synopsis. Short summary, attractive enough to make us want to read the rest of the proposal.
- Benefits to Community. Why would Google and PSU be proud to sponsor this work? How would open source or society as a whole benefit? What cool things would be demonstrated?
- Deliverables. Give a brief, clear work breakdown structure with milestones and deadlines. Make sure to label deliverables as optional or required. You may want plan to start by producing some kind of whitepaper, or planning the project in traditional Software Engineering style. It’s OK to include thinking time (“investigation”) in your work schedule. Work should include
- investigation
- programming
- documentation
- dissemination
- Description. A small list of project details (rough architecture, etc).
- Related Work. A short list of other people’s work. Could be as simple as a
URL with one sentence description. Be sure to explain how the proposed work is different from similar related work.
- Biographical Information. Brief personal info.
- Summarize your education, work, and open source experience.
- List your skills and give evidence of your qualifications. Convince us that you can do the work.
- Any published papers, successful open source projects, etc? Please tell us!
- Please list any non-Summer-of-Code plans you have for the Summer, especially employment and class-taking. Be specific about schedules and time commitments.
[Thanks to Mick Thomure for taking the initial notes for this outline.]
Proposal “Don’t”s
Here’s some of the things we’re unlikely to consider in a project proposal:
- Projects that we can find no one to mentor. Not likely, but has happened.
- Projects that better belong with other Summer of Code organizations. We try hard to avoid stepping on the turf of established open source projects.
- Projects that represent too large a scope. The time flies by quickly. If you have a large project, break it into small, coherent pieces and propose to get the first couple of them done. That way we know we’ll get at least one good piece out of you.
- Incoherent things. We need to see a clearly delimited, contained piece of work. If we can’t understand or define it, it’s out.
- Projects that are “inappropriate” for legal or social reasons.
- Boring projects. For the mentor and the org, half the fun is helping a student do something novel and cool. Note that we don’t find infrastructure per se boring; we just have to see that it’s part of a luminous vision.
- Stuff that’s already been done to death.
Even with that list, we think there’s plenty of room for cool work.
General Notes
Your proposal should be around 1500-4000 words. One-liners are hopeless. Much above 4000 words and we’ll never wade through it. Your proposal should be ASCII formatted, since you will copy it into a web textbox. If you want structured text or graphics, include URLs in your proposal, and make it clear why we would want to paste them into our browsers.
There is a very high official limit on the number of submitted proposals, so if you have several strong ideas, please submit several proposals. We’ll figure out which one we like best.
Do include URLs pointing to any information that would help convince us of your chances of success: preliminary project plans or progress, other projects you’ve been involved with that were successful, code samples, etc.
We are risk averse. It is better for everyone if your project is under-scoped and sure to complete; as opposed to a largeish project which may not get done. Under-scoping is an annoyance. Incomplete is a disaster.
Integrate and leverage existing open-source technologies in your project. One of the unique features of Google/PSU Summer of Code is that it is a great organization to help with projects involving integrating open software (and hardware!) from a variety of existing sources.
“Pencils down” deadline for your project to be complete is sometime in mid-August. This will come sooner than you think.
[Again, thanks to Mick Thomure for taking the initial notes for this section.]
Other Sources of Information
There are several other good guidelines on the web for helping to write a high-quality proposal. In no particular order…
