How I Got Into GSoC — My Experience

The plane ride where I decided to write this

I’m writing this from a flight from Chandigarh to Hyderabad, roughly 10,000 meters above the sea, with no internet and no distractions. It feels like the perfect place to think clearly and put everything into words.

This is going to be a complete walkthrough of my journey: how it started, how I moved from “Hello World” to contributing to real projects, and how I eventually found myself in GSoC.

Where it all began

I’ve always been fascinated by technology. Even in school, I was drawn to coding and computers. I participated in a lot of Olympiads and competitions related to programming, and I always liked the feeling of solving problems with code.

But for a long time, I was also a bit scattered. I would learn many things, but I would not always stay consistent. I was interested in a lot of directions at once, and I was still figuring out what mattered most.

June to August: the beginning

It all started after my second attempt at BITSAT in June 2024. I decided that I wanted to take coding seriously. I was motivated to make a real change and not waste the opportunity.

So I did what most beginners do: I started with DSA and the basics. I spent a lot of time learning C++ and making notes, but I was still not very clear on the bigger picture. At that point, I did not even fully understand what GSoC was or what open source really meant.

The important lesson from this phase was simple: start as early as possible. More importantly, start.

September: the first real spark

My real development journey began in September 2024, when I got involved with Smart India Hackathon. We formed a team of first-year students and tried to build something meaningful. We qualified the internal round, but we got disqualified in the next one. Still, that experience mattered a lot.

It was one of those moments that pushed me forward. I realized that I wanted to learn development properly instead of just casually experimenting.

That was the point when I started exploring web development more seriously. I learned HTML and CSS, built a small Figma prototype, and began to understand that design and development were deeply connected.

October: the shift toward real skills

After that, I decided to get serious. I started learning OOPs concepts and then moved into JavaScript. I built a scientific calculator with some features I was proud of, and that gave me a sense of progress.

Around the same time, I got involved with UI design because some seniors were looking for a first-year student who knew Figma. I said yes, even though I did not know much at the time. That turned out to be a good decision.

I learned how to look for design inspiration from places like Bento Grid and Dribbble. That helped me understand not just coding, but also how good products are shaped.

The biggest lesson from this phase was simple: an imperfect skill can still become useful if you start building with it.

November: exploring AI and Python

In November, a professor asked if students who knew Python could help write a research paper. I did not know Python well, but I said yes and learned it quickly. That was another turning point because it pushed me into a new domain.

I got very interested in AI and started building small projects with Python. I experimented with computer vision, speech-related work, and other beginner-friendly AI ideas. I was having fun, but I was also starting to see that the most practical way to grow was to work on real projects rather than just consume content.

At that point, I also started paying attention to the kinds of tech stacks used by projects where beginners could contribute. That led me toward the web stack and eventually toward open source communities.

December: learning React and GitHub properly

By December, I finally started learning React seriously. I also jumped into TypeScript and started understanding how modern frontend development worked.

That was also when I started learning Git and GitHub properly, not just superficially. I began to understand pull requests, issues, and how real collaboration works in open source.

I started contributing to MusicBlocks, a JavaScript-based project under Sugar Labs. The issues were interesting, the work felt tangible, and I finally felt like I was moving from learning to doing.

January: first contributions and first PRs

In January, I started contributing more actively. I opened multiple pull requests and had several merged. I also realized that the first PR is often the hardest one, not because the work is impossible, but because you are unfamiliar with the process and the expectations.

My first PR taught me a lot. I did not understand everything perfectly, but I learned through the experience. That mattered more than feeling prepared at the start.

The lesson here was simple: do not be hesitant. If you think a PR will help the maintainer and the project, make it.

February: talking to contributors and building momentum

February was the month when I started to understand the social side of open source. I began attending community meetings, talking to contributors, and asking about issues that were still open.

That was a huge shift for me. I realized that open source is not just about writing code. It is also about communication, initiative, and understanding how communities work.

I started talking to other contributors and maintainers more openly. I learned that every organization has its own style, rules, and ways of handling contributions. In Sugar Labs, the approach felt especially welcoming because issues were open for anyone who wanted to work on them.

That was when I realized that networking and communication matter a lot. You never know who will help you understand the next opportunity or the next issue.

March: focused building and proposal work

By March, I became much more serious. I was building, contributing, and trying to make my work more polished. I was also learning Next.js alongside everything else.

This was one of the most exciting phases because I could feel my learning curve increasing rapidly. The combination of deadlines, projects, and active contribution made me understand concepts faster and build with more confidence.

As proposal season approached, I realized I should also put my work into a proper proposal and start presenting it seriously. That was when I started working on the GSoC proposal side by side with my contributions.

April: the milestone

By April, I had reached a point where my contributions were being noticed. I had contributed a significant amount of code, became a member of Sugar Labs, and had a growing presence in the community.

My proposal got accepted, and I got into GSoC.

That was a huge moment because it felt like the result of everything I had been doing over the previous months: learning, building, contributing, talking to people, and staying consistent.

The biggest lessons

If I had to summarize the experience, I would say this:

• start early, even if you are not fully prepared
• say yes to opportunities that push you outside your comfort zone
• build small projects in the stack you are trying to learn
• talk to maintainers and other contributors
• keep contributing even after you feel “good enough”

The most important lesson is that momentum matters more than confidence. You do not need to feel ready before you begin. You just need to start and keep going.

The ending note

GSoC was not the end of the story for me. It was a beginning. It was a milestone that made me realize how much I enjoy building, learning in public, and contributing to communities that value collaboration over competition.

I still look at that period as one of the most transformative phases of my life. It taught me that open source is not just a path to internships or programs. It is also a place where you can grow, meet people, and become a better builder.

And in the end, that is what made the journey special.