This is a competitive program, each year Google turns down many more applicants than it funds. While pre-proposal activities are key to improving your chances of success, a poorly-written proposal is an easy way to fail. There is much you can do to ensure that your project proposal catches the attention of organization reviewers in a positive way.
The Basics
First and foremost, make sure you meet Google’s formal requirements for participation in Summer of Code. This includes ensuring that you are eligible to work in the country where you reside for the duration of the program. Remember, if you are in a country on a student visa or another type of visa you could have restrictions on the number of hours you can participate in a program like GSoC or you may not be eligible to participate at all. Hopefully, you have already checked this by now, but be sure to double-check before you waste time and energy on a proposal.
Inventory your time. Figure out how many hours per week are already spoken for outside of your GSoC commitment, including time spent volunteering for other projects and activities, a part-time job or counting credit-hours of academic instruction. In any case, be completely clear about outside time commitments as part of your proposal. If you know you need to take a couple of weeks off because of finals or a wedding, etc. be upfront with the mentors, we have added some flexibility into the program so this should be fine, you just need to let your mentor know as soon as you know the details. Do not surprise an organization with your time commitments later on. It may be possible to extend the end date of your project if your org will allow it. But this should be discussed early on so everyone can be on the same page.
Make sure that you are able to be in regular close contact with organization mentors via the usual open source means (email, chat, etc) for the duration of the program. It is not necessary (or likely possible) that you be geographically near your mentor. However, if you are not sure you will have good Internet connectivity continuously over the summer, GSoC is not for you.
This program is the Google Summer of Code. If you are less than fluent in the programming languages that your target organization uses, you might want to skip the work of writing an application. If you do decide to proceed, be clear about your level of ability, so that the organization can make an informed decision.
Elements of a Quality Proposal
Most organizations have their own proposal guidelines or templates. You should be extraordinarily careful to conform to these. Most organizations have many, many proposals to review. Failure to follow simple instructions is highly likely to land you at the bottom of the heap.
There are certain elements of the proposal that should apply to every organization. Proper attention to these elements will greatly improve your chances of a successful proposal.
Name and Contact Information
Putting your full name on the proposal is not enough. Provide full contact information, including your preferred name, email address, websites, etc.
Title
Your title should be short, clear and interesting. The job of the title is to convince the reviewer to read your synopsis. Do not put your name in the title.
Synopsis
If the format allows, start your proposal with a short summary, designed to convince the reviewer to read the rest of the proposal.
Benefits to Community
Don’t forget to make your case for a benefit to the organization, not just to yourself. Why would Google and your organization be proud to sponsor this work? How would open source or society as a whole benefit? What cool things would be demonstrated?
Deliverables
Include a brief, clear work breakdown structure with milestones and deadlines. Make sure to label deliverables as optional or required. You may want your plan to start by producing some kind of white paper, or planning the project in traditional Software Engineering style. It’s OK to include thinking time (“investigation”) in your work schedule. Deliverables should include investigation, coding and documentation.
Related Work
You should understand and communicate other people’s work that may be related to your own. Do your research, and make sure you understand how the project you are proposing fits into the target organization. Be sure to explain how the proposed work is different from similar related work.
Biographical Information
Keep your personal info brief. Be sure to communicate personal experiences and skills that might be relevant to the project. Summarize your education, work, and open source experience. List your skills and give evidence of your qualifications. Convince your organization that you can do the work. Any published work, successful open source projects and the like should definitely be mentioned.
Follow the Rules
You will need to generate a PDF version of your proposal to upload.
Many organizations have a required application format or other guidlines including application length limits. In general, organizations will throw out your proposal if you fail to conform to any guidelines they specify.
You should take the time to polish your proposal. Make it look professional, and be sure to have detailed information about your plans.
Submit a Proposal early
Submit your proposal early during the application period so that the organization mentors can review it and ask you questions or request more detail on aspects of your proposal before the final deadline. You can edit the proposal as many times as you wish before the application deadline. You may even want to label the proposal as a draft so it is clear you are looking for feedback before submitting the final proposal.
Remember, thousands of potential GSoC contributors are submitting proposals so it can take organizations a few days or even a week+ to get back to you if they have questions. So the earlier you submit a well written draft proposal, the more time they have to give you feedback on it so you can make it stronger and understand more of what they are looking for.
Follow the instructions from the organizations on the content and format of your proposal.
Remember to submit your final draft before Google’s deadline, regardless of if you have received any feedback or not from the org. If you do not have a proposal submitted in the GSoC webapp by the deadline there will be nothing for the org to look at. There are absolutely no extensions to deadlines in GSoC proposal submissions for anyone, ever.
Outside the Project List
Some organizations allow GSoC contributors to propose work that is not on their official Ideas Page. This can be a great opportunity to get your proposal on the top of the stack. Reviewers tend to get excited about a GSoC contributor that goes beyond a direct response and enthusiastically proposes work that is novel and creative.
However, original proposals are also riskier; their flaws will be much more apparent. Here’s some of the ways that such proposals fail:
Projects without a mentor
Try to make sure that someone in the organization would be willing and competent to work with you.
Projects that better belong with other Summer of Code organizations
Open source organizations try hard to avoid stepping on each other’s turf. Try to find your best fit.
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 the organization can be confident that you can complete a project in the allotted time and the project isn’t left incomplete indefinitely.
Incoherent proposals
The organization needs to see a clearly contained piece of work. If the organization can’t understand or define the work, the proposal will be thrown out.
Projects that are “inappropriate” for legal or social reasons
If your proposal is near the boundary, make sure you clear it with your target organization in advance.
Boring projects
For the mentor and the organization, half the fun is helping a GSoC contributor do something novel and cool. Infrastructure per se isn’t necessarily boring, but it should be part of a luminous vision.
Stuff that’s already been done to death
Novel work should be novel. Surprise.
Even given this list, there’s plenty of room for cool work. Given the opportunity, you should seriously consider taking advantage and writing a proposal that differentiates you.
General Notes
While there is an official limit of three submitted proposals, it is okay to submit more than one high-quality proposal. If you have several strong possibilities for the same organization, consider submitting several proposals. Organizations will figure out which one they like best. But avoid sending many medium-quality proposals and concentrate on fewer high-quality proposals.
Most organizations are risk averse. It is better for everyone if your project is under-scoped and sure to complete; as opposed to a large-ish project which may not get done. Under-scoping is an annoyance. Incomplete is a disaster.
Integrate and leverage existing open source code in your project. Only propose to write something yourself if you cannot get it any other way.
The “Pencils Down” deadline for your project to be completed will come sooner than you think.