How to write a GSoC proposal

This article is based on the Google’s official guide, but also adds some personal experiences that I had.

Where to begin?

First and foremost, make sure you meet Google’s formal requirements for participation in the 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.

The second most important task is to decide which project you will be working on. After selecting which Org you would like to work with, you can read the ‘Ideas page’ of the organization to check which projects they are willing to have some work done this summers. Most of the Orgs update their Ideas page in late January so you can get a good head start.

How many proposals should I make?

Officially you can submit three proposals on the GSoC website to three different orgs. But I personally would recommend that you should stick with a single org and a single project. No doubt it’s a bit risky to do so, but keeping your hands in multiple baskets, you will be unable to focus on one project. Instead, give your 100% efforts on creating one proposal this way; it will stand out from the other student’s proposals who are making multiple. Also, google notifies the mentors on the number of proposals you have submitted, so this may as well reduce your chances of selection.

How to write a proposal?

The most important part is the content of the proposal. If you can express your idea and plans correctly through the proposal, your job is 90% done. These are some points that are well written in the documentation by Google.

  • 1. 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.
  • 2. Title: Your title should be short, clear, and interesting. The job of the title is to convince the reviewer to read your synopsis.
  • 3. Synopsis: If the format allows, start your proposal with a summary, designed to convince the reviewer to read the rest of the proposal.
  • 4. 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 an open-source or society as a whole benefit? What cool things would be demonstrated?
  • 5. 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 the traditional Software Engineering style. It's OK to include thinking time ("investigation") in your work schedule. Deliverables should include investigation, coding and documentation.
  • 6. Related Work: You should understand and communicate with 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.
  • 7. Biographical Information: Keep your 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 be mentioned.
  • 8. 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.