This is a competitive program, each year Google turns down many more students 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.
First and foremost, make sure you meet Google’s formal requirements for participation in Summer of Code. 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, and counting credit-hours of University instruction. GSoC should be treated as a full-time job. If you have more than a few hours a week of extra commitments, you probably should skip GSoC; it is unlikely that you will be successful. In any case, be completely clear about outside time commitments as part of your proposal. Do not surprise an organization with your time commitments later on.
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 Summer. It is not necessary 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.
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 email addresses, websites, IRC nick, postal address and telephone number. Also provide full contact information for a friend or relative that the organization can contact to find you in case of emergency.
Title
Your title should be short, clear and interesting. The job of the title is to convince the reviewer to read your synopsis.
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 your 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
Most organizations accept only plain text applications. Most organizations have a required application format. Many organizations have application length limits. In general, organizations will throw out your proposal if you fail to conform to these guidelines. If you feel you must have graphical or interactive content associated with your application, put just this content (not a copy of your proposal) on the web and provide an easy-to-type URL. Do not expect reviewers to follow this link.
Submit your draft 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.
Remember, thousands of students 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 and use the GSoC program site instructions on successfully submitting and sharing a draft to the organization. You must create the draft and write an abstract before sharing the draft with the organization.
You can edit the draft as many times as you wish before the application deadline.
Before the application period closes you must submit a Final PDF Proposal - this must be done for your proposal to be considered for the GSoC program. If you only submit a draft and fail to submit the Final PDF Proposal the organizations will not be able to see your proposal and therefore will not be able to accept you - it is an automatic reject from the system.
Follow the instructions on the GSoC site and the process is quite straighforward.
Some organizations allow students 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 student 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 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 customer.
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 they will get at least one good piece of work out of you.
Incoherent proposals
The organization needs to see a clearly delimited, 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 student 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.
While there is an official limit of five 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 complete is usually sometime in mid-August. This will come sooner than you think.
There has been error in communication with Booktype server. Not sure right now where is the problem.
You should refresh this page.