DEV Community

Cover image for My GSoC '25 Experience
Damika-Anupama
Damika-Anupama

Posted on

My GSoC '25 Experience

What's GSoC

Google Summer of Code (gsoc) is one of open source code programs in the world. Every year summer, Google conducts this program to link open source organisations with new open source contributors. You can find gsoc organisations from here. Google also selects mentors per each organisation, mentors guide and evaluate contributors through out the summer to contribute organisations. In the beginning of the program, organisations define what are the projects they need to get completed or improved during summer, from the contributors, and mentors are allocated per each project. If you check gsoc timeline, you can get an idea how this normally works.

Why I'm Writing This Article

I want to share my 2025 gsoc experience with you guys. Furthermore what are the advantages of applying gsoc, working with open source organisations. Please consider this is not a success story or guide.

Who this Article for

This is more useful for the people who can contribute for gsoc. Please check the eligibility criteria for the contributors:

  • 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;
  • be a student or a beginner to open source software development.

If you're an undergraduate or a beginner to open source software development with a strong interest in programming, you can participate gsoc this time to grow your knowledge and profile. Here are some articles you may read why gsoc is so important: [1] [2] [3] [4]

You can enter gsoc as a contributor. First, you need to select an organisation and one of their projects they've listed. Then you need to create a project proposal for the project and submit on gsoc organisation portal during "GSoC contributor application period begins" to "GSoC contributor application deadline" period, please check the timeline. Normally, this is half a month of time period.

Why I wanted to do GSoC

During my university program, I learnt about gsoc from our seniors and lecturers, and the advantages novel programmers like us can get from open source code contribution. I researched about gsoc and found out famous open source organisations like Postgres, GitLab, Debian, Python and many more organisations are participating each year gsoc program and we can work on those organisation codebases and improve our experience. Isn't it great?

Furthermore we can work and get mentored by high experienced open source programmers all over the world. Rather than coding experience, novel programmers like us can improve engineering disciplines and soft skills too.

My Application History

I applied gsoc and got rejected in 2 previous years. When I was reviewing what went wrong, I identified:

  • There's a huge competition among new contributors and the contributors who applied once to get selected to the program again
  • Due to high competition, some projects may have multiple applicants and project proposal needs to be more descriptive and follow the rules that organisation has published.
  • Some mentors/ organisations expect contributors to solve their code repository (GitHub) issues and put some PRs to the project codebase to show their performance to the organization.
  • It's better to introduce ourselves to the organisation and communicate with organisation administrators and mentors regarding projects
  • Participate online meetings conducted by gsoc during contributor application period

So I understood it's not that easy to get selected and need to be more competitive. We need to show to the organisation why they choose our project proposal over the other applicants to the same project we're applying.

How competitive GSoC actually is

Although normally acceptance rate for gsoc is normally considered as 20%, year by year it's getting reduced, due to high competition. Here's the statistics about gsoc 25 program:

Google Summer of Code 2025 Program Statistics

Based on the official Google Open Source Blog announcements, Google Summer of Code (GSoC) 2025 statistics:

  • Total Applicants (Submitting Proposals): 15,240 individuals from 130 countries submitted a total of 23,559 proposals.
  • Total Registrations: A record 98,698 people from 172 countries registered for the 2025 program.
  • Accepted Contributors: 1,280 contributors were accepted into the program for 2025.
  • Program Completion: While the coding period began on June 2, 2025, and concludes later in the year, the preliminary data indicates that 1,261 projects were completed by 185 mentoring organizations in 2025.

Key 2025 Statistics:

  • Acceptance Rate: The acceptance rate for applicants (1,280 accepted out of 15,240 applicants) was approximately 8.4%, making it one of the most competitive years in GSoC history.
  • Demographics: 92.32% of contributors are participating in their first GSoC.
  • Prior Experience: 66.3% of applicants had no prior open-source experience.

What organisations actually look for

Organisations and mentors really like when contributors get familiarised with their selected project(s) and related codebase. Most of the time project has well explained documentation(s) or wikis. It's better to go through most of documentations and understand the project as far as you can, because your project proposal reflects your understanding of the codebase. So gsoc is not only about your coding ability, it's a blend of understanding the codebase, communication, following instructions, and initiatives such as case studies, PRs and discussions.

My organization: Checker Framework

During gsoc 25 I got selected to the Checker Framework. It's a compile time tool that enhances Java development by preventing bugs through pluggable type-checking, addressing issues like null pointer dereferences and concurrency errors that Java's basic type system does not cover. It serves as a robust bug-finding and verification tool, ensuring specific error types are absent in programs. The framework is user-friendly, aligns with existing practices. I chose Checker Framework during 25 summer, because I'm familiar with java programming language and was curious to work with java annotations.

As like other open source organisations, there was a competition to apply this organisation too, they told me I got selected from dozens of applications! They have provided their list of projects for new contributors and guidelines for gsoc contributors, as many organisations do.

Contribution before acceptance

During application period, they asked me to do a case study: Use their annotation tools on one of my previous java projects or openly available smaller java project. This case study was the critical reason I got selected to the organisation. From the case-study they identify whether I understood their project. Here's the link of my case study, compare with main branch with other branches. Furthermore I had to go through checker framework documentation and their developer manual to understand the functionalities of their annotations.

Communication with mentors and community

Communication medium is different due to the organisation: slack, google groups, discord, GitHub discussions and issue threads and different chat platforms. Always mentors and organisation administrators have emails related to the organisations, but be careful some of them don't like applicants put them private emails, they ask to join organisation main communication channel, introduce yourself and discuss about projects.

Welcome to the team

Communication is one of the best skills you need to have during gsoc. Always you need to be concise and comprehensive about your work. Documenting your work is another format of communication. After getting selected to an organization, you definitely need to have meetings with your mentors. In my case, I had 2 meetings per week, in there I had to explain my work, blockers, suggestions, my problems and so on. Before meetings I had to email my mentors regarding meeting agenda and after the meeting I had to email them meeting summary and the to do list before next meeting in the same email thread.

You may face different challenges like time zones, clarity feedback cycles and so on. It's better and more professional if you clarify most of these challenges with your mentors in the communication medium, because most of the time they are super busy with their own schedules. This is why I mentioned communication is important. To enhance contact with your mentor during gsoc, you can refer these links:

Description

What changed after getting accepted

I got selected to a 350hrs hard project (projects are categorised due to their scope). My project's whole plan and milestones were not defined. Since I had 2 meetings per week with my mentors, considerable changes were made related to the plan, how we were going to implement my project. So in reality I had to work on implementation as well as the defining the milestones of the project with my mentors. Furthermore week by week the responsibility was increased, I had to update the documentation, follow their guidelines before making pull request on their main branch, time management and etc.

Every organisation has their own code quality standards. This is important for open source developers, although you change your organisation you need to follow your current organisation coding standards, otherwise it's hard them to keep the code quality consistent for the future developments. I also went multiple times in my organisation documentations to get aware about their own quality standards and this was really helpful during coding and meetings with my mentors.

My code was reviewed in multiple levels. First, the checker framework has integrated an Azure pipeline to automatically execute my implementation changes on 20 different open source codebases (most of the cases, legacy open jdk versions), and if any of the checks fail, I must go to the Azure pipeline dashboard to discover and resolve the issue. If all automated tests pass, the next two or three mentors will review my modifications, and I must work on their code reviews. If all of these processes are completed successfully, the changes will be merged into the main repository. Another significant consideration is that each pull request/branch should only serve one purpose. If a PR consists of modifications relating to the implementation of a new Java annotation as well as the updating of documentation for another related annotation, I had to submit two separate pull requests.

What I learned (technical + non-technical)

GSoC'25 was my first time working on a large open source codebase. Reading a large codebase, extracting the required code segment in the correct file and the correct directory is a skill every developer needs to have. Running/ debugging code, reading terminal outputs and logs, checking documentations and reworking on relevant specific case I improved this skill. After me, checker framework new open source contributors also need to continue my project. So I was careful to write a maintainable code during my work.
Reading large codebases

During GSOC, it's essential to interact with mentors—who are experienced professionals—by demonstrating patience and professionalism. Initially lacking in professionalism, I learned to pay attention to mentor advice over time. Effective communication is key; when raising issues, specificity is crucial. Rather than express general confusion about a module, you should first go through the documentation, experiment with the module, and document results and errors. If confusion still exists, a detailed email to the mentor outlining the steps taken can facilitate understanding and guidance.

What I would do differently

In retrospect, I often overestimated my ability to manage various aspects of my project while underestimating the time commitment needed for each. If I have another opportunity applying gsoc, I would allocate more time to implement a crucial component of my work.

Advice to future applicants

  • Be careful about your project scope, tech stack and time period
  • Manage the time you spend on the project so that it does not interfere with your academic work or other personal activities.
  • Always try to learn from every mistake you make
  • Don't always make your mentor angry :)
  • Document well and read documents
  • Take a brake during burnouts! Keep calm and code

GSoC is a great experience and a really good challenge every developer need to experience in their life. This time is your turn, so take it!

Top comments (0)