Hey everyone, I'm Aritra! I work as an Operations Research Scientist at Lyric. If you're curious about my background, you may head over to my LinkedIn and GitHub; if you'd like to know more about my experience and projects or go through all my blogs, please head over to my portfolio where you'll find other blogs and ways to get in touch.
I’ve been involved in GSoC for a few years now, as a mentee with Mathesar (2023) and omegaUp (2024), and then mentoring with omegaUp in 2025. You will find all of my GSoC blogs here.
Got questions or want to say hi? Connect with me on LinkedIn! I also recently opened a Topmate account account—if you'd like to support my journey, you can find ways there (but only if you want to and can).

Why am I writing this blog? In this blog, I intend to share all the important information of GSoC which is publicly available but scattered all over the internet in different places. When I first applied for GSoC, I found it hard to understand the process flow and I wish there was a blog where I could find all the information in one place. Please note that this blog is not about tips and strategies to get selected in GSoC. There is no alternative to hard work and dedication. This blog is just to help you understand the process flow of GSoC and prepare accordingly. Apart from that, I will also share a few difficulties I faced and how I overcame them.

Why may you want to read this blog? This blog might give you a clearer understanding of the GSoC process flow and help you with a lot of questions that you might have in your mind regarding GSoC. Clearing them will help you focus on your contributions and project proposal.

What is GSoC (Google Summer of Code)?

Google Summer of Code is a global, online program focused on bringing new contributors into open source software development. GSoC Contributors work with an open source organization on a 12+ week programming project under the guidance of mentors. (From the official GSoC website).
A few important points regarding GSoC:

  • Massive Learning Curve: During the pre-GSoC and GSoC period, you will be able to learn to code like a professional! You'll level up your Git/GitHub skills, learn to collaborate remotely, manage a complex project, and communicate like a pro!
  • Stipend: The programme offers stipends to the selected contributors during the program duration. Learn more about stipends.
  • Eligibility: To participate in the Program, a GSoC Contributor must:
    • be eighteen (18) years of age or older upon registration for the Program;
    • for the duration of the Program, be eligible to work in the country in which they reside;
    • not be an Organization Administrator or Mentor in the Program; and
    • be a student or a beginner to open source software development.
    Please visit the GSoC page for more criteria. In short, you can take part in GSoC twice as a student and participate as a working professional/non-student only if you haven't participated before.

GSoC timeline:

The GSoC timeline is as follows:

  • January 19 - 18:00 UTC — Mentoring organizations can begin submitting applications to Google
  • February 3 - 18:00 UTC — Mentoring organization application deadline
  • February 3 - 18:00 UTC — Google program administrators review organization applications
  • February 19 - 18:00 UTC — List of accepted mentoring organizations published
  • February 19 - March 15 — Potential GSoC contributors discuss application ideas with mentoring organizations
  • March 16 - 18:00 UTC — GSoC contributor application period begins
  • March 31 - 18:00 UTC — GSoC contributor application deadline
  • April 21 - 18:00 UTC — GSoC contributor proposal rankings due from Org Admins
  • April 30 - 18:00 UTC — Accepted GSoC contributor projects announced
  • May 1 - 24 — Community Bonding Period (contributors get to know mentors, read documentation, get up to speed)
  • May 25 — Coding officially begins
  • July 6 - 18:00 UTC — Mentors and GSoC contributors can begin submitting midterm evaluations (for standard 12 week coding projects)
  • July 10 - 18:00 UTC — Midterm evaluation deadline (standard coding period)
  • July 6 - August 16 — Work Period (GSoC contributors work on their project with guidance from mentors)
  • August 17 - 24 - 18:00 UTC — Final week: contributors submit final work product and final mentor evaluation (standard coding period)
  • August 24 - 31 - 18:00 UTC — Mentors submit final contributor evaluations (standard coding period)
  • August 24 - November 2 — Contributors with extended timelines continue coding
  • November 2 - 18:00 UTC — Final date for all contributors to submit their final work product and final evaluation
  • November 9 - 18:00 UTC — Final date for mentors to submit evaluations for projects with extended deadlines
Let's take a pause and look at the important periods in the timeline.
  1. The mentoring organizations will be announced on February 19. But, considering that the organizations more or less stay the same from year to year, it's a good idea to look at last year's organizations to get an idea of who might participate this year.
  2. Once the organizations and the projects are announced, you should start going through the project ideas. Some of the organization typically have a competency test to shortlist candidates, be careful to read the instructions carefully as it depends on the organization. For omegaUp, I had to appear for a coding test before I could submit my proposal.
  3. Apart from that, you should also start going through the codebase. It's a good time to raise a few meaningful PRs as they will serve as a very good proof of work while writing your proposal. Don't hesitate to reach out to the mentors if you have any doubts regarding the implementation. In general, you should use public channels (like the organization's IRC/Discord/Slack channels) to ask your questions if not specified otherwise by the organization.
  4. You can submit your proposals on the official GSoC site from March 16 to March 31. Remember, you can submit up to three proposals, which can be for different organizations or the same one.
  5. After submitting your proposals, it's important to stay engaged with the community and be responsive to any feedback or questions from mentors. If you are actively contributing, you should continue doing that. Some of the organizations may also reach out to you for further discussions or interviews. I had to appear for an interview with omegaUp mentors before getting selected.
  6. Then, all you have to do is wait for the results! If you have made it this far, congratulations! If not, don't lose hope, you may continue contributing and reapply next year. This way, you will be in a much better position next time.

Writing a Proposal:

The proposal is the most important part of your application. A well written proposal can make a huge difference in your chances of being selected. A few things to keep in mind while writing your proposal are:
  • Do not use LLM to write your proposal. Write it in your own words. It should reflect your understanding of the project and your approach to solving the problems the project presents. You can definitely use LLM to fix grammar and spelling mistakes and improve the readability of your proposal. But, make sure to review the final output.
  • In general, the organizations provide a proposal template and impose certain guidelines. If available, try to follow them closely.
  • It's a good idea to include code blocks to illustrate your points. Besides, you can use flowcharts or diagrams to represent complex ideas visually. I prefer Lucidchart for creating diagrams.
  • Highlight your relevant skills and experience. Provide links to your previous work, contributions, or portfolio. If you have already contributed to the organization, make sure to mention that as well.
  • Please plan your timeline carefully. Break down the tasks and milestones clearly. This will also help you manage your time during the coding period (which is often underestimated).
Here's a good proposal example from previous year's omegaUp project "AI Teaching Assistant" (submitted by Nandini).
Here're few repositories with a lot of proposals from previous years:

A peek into the selection process:

Once you submit your proposal, the organization admins and mentors will have to review it and rank it based on some metric depending on their requirements. They might ask you for further clarifications or an interview. So, if the organization gets 100 proposals, they can choose to rank all of them or shortlist a few and rank only those. Ideally, if there are multiple proposals with the same project, the organization will rank only one for obvious reasons. Once the ranking is done, the organization will submit the rankings to Google. Now, it completely depends on the GSoC team to decide how many slots an organization gets. If they choose 4, then the first 4 proposals in the shortlist will be selected.

Additional Resources:

  • If you are a complete beginner to open source and git (or version control system, in general), you should definitely learn git (and GitHub) first. Git is an essential tool for open source development enabling you raising PRs and reviewing code.
    Here're a few resources to get you started: If you're looking for a hands-on Git session and want to support me, you may check out my 1:1 service on Topmate.
  • You may also want to take a look at previous years' organizations and their projects and get an idea about the tech stacks they used. You can head over to the following links to find the list of organizations from previous years:
  • While choosing an organization/project, it's completely fine if you don't know all the tech stacks used. You can always learn the rest and ask for help when needed. Sometimes, you might feel like the codebase is too complex to understand. You don't have to understand everything right away; focus on the parts relevant to your project/contributions. Once you get familiar with how things work, you'll soon get enough confidence and grip over the codebase to explore more.
  • In my experience — and while this can vary by organization — submitting a few meaningful PRs might be a huge help. Think of those PRs as your 'proof of work' showing that you understand the codebase well!
Wishing you all the best!
Found a bug/misinformation? I'm sorry, please feel free to ping me or open a pull request to fix it.