Applying to GSoC

Revision as of 09:13, 17 March 2023 by Ghutchis (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

How to Apply

Submit your application by 4 April 2023. If you submit early, we can give feedback. The best proposals are written and submitted as drafts early, giving time for suggestions / comments before the deadline. We cannot promise any feedback in the last few days before the deadline. (This year, if you submit for draft after 30 March 2023, don't expect to receive comments.)

IMPORTANT - Pick a project that interests you the most. The application process is not "we'll pick good students and put them on projects," but rather "you pick a project that interests you and you draft a proposal that convinces us (and Google) to pick you."

Before you apply, review the following:

  • Can you join? Check out Google’s FAQ and see if you’re eligible for the GSoC. Also make careful note of the GSoC timeline in your calendar.
  • Are you joining for the right reasons? Read “Reasons why you shouldn’t hack on open source projects” carefully. If you’re not passionate about what we’re doing, the work will suffer.
  • Let’s avoid rookie mistakes. Read “DOs and DON’Ts of GSoC (for students)“.
  • What’s your idea? Decide which idea(s) you want to work on. Feel free to email the relevant mentors listed in the ideas list to get their attention.
  • Use the programs. Have you *used* the Open Chemistry programs? Chemistry experience is not required, but you do need understanding of how the packages work.
  • Orient yourself. Have you contributed to Avogadro, cclib, 3DMol.js, etc. before, made a pull request or a plugin? Some projects demand greater expertise than others. In any case, make sure that you have a firm understanding of key concepts before you apply to any project. Browse the source code, especially the parts relevant to your project idea(s), and be sure you’ll be capable of integrating your idea into the existing project.
  • Familiarise yourself with Git & GitHub You should be familiar with common Git workflows before GSoC starts. See GitHub Help for more.
  • Submit a pull request. Submitting a pull request to the project you are interested in goes a long way to convincing us that you are serious and have a grasp of the basics. It has also historically been a strong positive indicator, and will be considered as part of your proposal. Point out any pull requests made in your proposal.
  • Draft your application (see template below). Feel free to type up drafts for different ideas and ask us which one has the highest chance of succeeding: Create your draft on an external site like your blog or a GitHub gist and email the relevant mentors.
  • Setting the scope is your job! It is your responsibility to cut down or expand upon an idea so that it’s both challenging but also completely feasible within 4 months. We will however provide plenty of feedback on scope during the application phase.

Many students show interest, but we will likely only be able to pick a few proposals. We need to believe that you will be successful and accomplish your goal. Convince us!

Personal Details Brief


  • Name: Your Name Here
  • Email:
  • Country & timezone: e.g. “Germany, GMT+1″
  • School Name & Study: The name of your university and field of study.


  • Skype ID or other instant message services: SkypeID or (for IM and voice chats).
  • Personal Website: http://yourdomain.tld (if applicable)
  • GitHub profile: A link to your GitHub profile, so we can see example code.
  • Phone number (incl. country code): For emergencies only. If all other contact methods fail at a critical time, we can try your phone.

Application Template


Give us the “elevator pitch“. You have 30 seconds to tell us what you are going to make, why we will like this project, and to convince us that you are qualified to do it! (You might want to write this section last).

Project Ideas

Project Details

Specs & Scope:

  1. Provide a brief breakdown of the features that this project will add (see the example specs in the Ideas List). Feel free to include some stretch goals, as long as they are clearly identified as such.
  2. Go into some detail on the scope of each listed feature. Which features do you expect will require the most and least amount of work?

Anticipated challenges:

Identify challenges or risks to the success of the project, such as the project being incomplete by the end of the GSoC term. How do you intend to detect these risks early on? How do you plan to mitigate the challenges?


What have you done so far with this idea? Include any work or research on this project you have already started. Has something similar been tried before, and how was it different from your approach? Summarise what you’ve discussed with other developers so far and where you’ll be going from there.

Project Schedule

How long will the project take? When can you begin work? How many hours are you going to work on this a week? Include an estimated timeline of the project with mini-milestones. Consider an outline school/vacation/work/life commitments that conflict with your project schedule, and please explain how you plan to compensate for them. This should contain a reasonable level of detail, and take into account milestones for the first, second, and third evaluation periods.


What is your experience using and developing Avogadro, 3DMol.js, cclib, or similar applications? What about other open source programs? Have you worked in conditions like these before (remote team work, timezone difference, deadlines)? Are you comfortable communicating technical development in English? What is your familiarity with the programming language in question - Open Chemistry packages are developed using C++, Python, and JavaScript.

Tip: Don’t just rely on the GSoC mentors to review your application in-depth. Ask a technical colleague or friend to review it carefully and provide critical feedback.

More Advice

  • [1] Advice from the Offensive Web Testing Framework (OWTF) project

Example Proposals:


Applications are submitted through the Google Summer of Code site.

You should submit a draft proposal, which will allow mentors to ask questions or give suggestions on your proposal (e.g., if something is unclear). We cannot see or comment on 'final' proposals - so if you want feedback, you *must* submit a draft.

As a reminder, you can submit and re-submit a 'final' proposal as many times as you wish up until the deadline.

After Submitting Your Application

After you’ve applied, check on your application at the GSoC site once or twice a day. Answering your mentor’s questions in a timely fashion is very important. Mentors will leave notes on your application if they need more information or have additional questions about your proposal that they need answered before making a decision. If they leave a note and you don’t respond, it’s not their job to track you down. There will be many applications, so making sure you stay on top of your application will help you compete for the few spots we have to fill.

If you have not submitted an issue or pull request for your project of interest, you should certainly do so soon after your submission. This helps us evaluate whether you have familiarity with the codebase and the GitHub workflow.

After the submission deadline, we cannot offer any comments on the applications until Google's official announcements. This is as frustrating for us as it is for you, but it ensures there's enough time for mentors to discuss proposals. Ultimately, while we recommend students and proposals for funding, Google and GSoC makes the final decisions.

Google will announce the accepted students on their site.