Published: October 28, 2025
I am Harsh Singh, a final-year B.Tech student in Chemical Engineering at IIT (ISM) Dhanbad and in 2025 I was a participant in Google Summer of Code (GSOC). This post shares my journey to be accepted into GSoC, and some of the things I learned while being involved.
Before GSoC: Discovering extension development
Back in my first year, like many others, I was keen on joining CyberLabs, our college's official tech club. To prepare, I went to a senior who showed me a Chrome extension he had built to get into the club. It was completely different from the standard web development I knew. It seemed like such a cool way to inject scripts and modify websites on your own browser.
I played around with a lot of extension APIs, even witnessing the transition from Manifest V2 to V3. I managed to build a small project using them, got into CyberLabs, and then got busy with college life, leaving extension development behind for a while.
Recently, while thinking about applying for Google Summer of Code (GSoC), I stumbled upon a project on Chrome Extensions APIs. The nostalgia hit me hard–"Wouldn't it be cool to make an API this time that sometime in the future a sophomore would use to enter CyberLabs? That would be the best flex." Since I already understand most extension terminology from my past work, the project feels like a perfect fit for me.
Preparing to apply
On a whim, I decided to contact Oliver, a Developer Relations Engineer on the Chrome Extensions team. I asked him what it would take to be a successful applicant for Chromium's GSoC program. He replied within a couple of days! His email was very encouraging; he said they just wanted to see that I could explore the codebase and write some C++.
I started by setting up Chromium on my machine. It was a real struggle; it took me four full days and countless attempts to finally set up the massive codebase and get a successful build. I found a simple issue online—something about sidePanel.open() without a user gesture—and submitted a patch to fix it. (Looking back, it was a tiny change 🙂). I emailed Oliver about my progress. He told me that it isn't something they plan to support, but he also said the work I had done was enough to show that I was serious. He then suggested I work on the getPosition method for the side panel. I figured it out, mailed him again, and he was really happy, saying my approach was in line with what their team had been discussing. This gave me the confidence to move forward with the project, knowing that I can understand the code and make changes.
My GSoC proposal
Next up was the GSoC proposal. The initial project description, "SidePanel APIs & DNR APIs," was very broad, so I wasn't sure what specific tasks to list or how to create a timeline in my proposal. I emailed Oliver about this, and he replied that he had updated the project description. To my delight, he had added several APIs, including the sidePanel.getPosition API I was already working on.
The key components of my proposal were an understanding of the project, design ideas, pre-proposal work, and a schedule of deliverables. I accurately scoped the size of my tasks, as it demonstrated a thorough understanding of the work involved. I drafted my proposal and had it reviewed twice.
One thing I regret, which is a big tip for future applicants, is not including a proper design specification for the features I planned to build. For instance, when proposing an API to close the side panel, I should have outlined the parameters, justified my choices, explained how I would handle edge cases, and described how the API could be standardized for all browsers. This would have shown a much deeper level of understanding.
In the context of the Chromium extensions project, a key body is the WECG (WebExtensions Community Group, pronounced "wee-C-G"), where new API designs are formally discussed. During the GSoC period, contributors may need to pitch their API proposals to this group. Therefore, having a design idea ready in your GSoC proposal is a huge advantage, as it shows mentors you are prepared for this crucial step and do well during the GSoC period.
In early May, I got the email—I was accepted! 🙂
My contributions during GSoC
The GSoC period was fantastic. My mentor, Solomon, was incredibly nice, and we had productive weekly meetings that kept me on track. I also got to know a fellow contributor, Amit P, who was a great help whenever I got frustrated. Attending the WECG meetings was an eye-opener; I saw how things worked at that level and understood why experience matters so much. I discussed my API proposals there and got the green light from another browser vendor.
I opened several CLs (changelists) in the beginning. My progress slowed down later because of the back-and-forth of code reviews, but I was happy to keep at it. My main merged contributions were to the Side Panel API:
sidePanel.getLayout()APIsidePanel.close()APIsidePanel.onOpened()andsidePanel.onClosed()events (These were based on a lifecycle proposal from Microsoft)
My other CLs for the Commands API are still a work in progress (depending on how active I stay after GSoC 🙂). You can see a detailed breakdown in my final report, which is available under the "view code" link on my GSoC project page.
A special thanks to Oliver Dunk, Solomon Kinard, Kelvin Jiang, Devlin Cronin, Tom Lukaszewicz, and Andrea Orru, who reviewed almost all my CLs. It feels amazing to see my code become part of Chrome. My mentors described me as having a strong sense of "ownership," which was a huge compliment for me.
Wrapping up
If you ask me what GSoC gave me, it was more than just technical knowledge. It gave me a seat at the table—where important discussions happened, discussions that will impact several extension developers out there. It was my first work that ever landed in a real-world application. I met patient mentors who guided me and taught me so much, making the entire experience incredibly enriching.
I hope my story can be a helpful reference for others who want to contribute to Chromium or be part of Google Summer of Code.
Tips for people applying to GSoC
- Choose an idea that you genuinely like. Interest should be your top priority. Your skills can always be improved, but passion is what will keep you going when things get tough. I've been on both sides, and trust me: when you're working on something you aren't interested in, you'll blame others when things go wrong. However, if you love the work, you'll see it as a challenge to overcome.
- Don't be afraid of competition. I've seen so many people get demotivated after seeing who else is applying in the community channels. Every good project will have competition. Focus on your strengths. If you've worked with any library before, find a project that uses it. You'll have an edge because you can bring your unique experience to the table.
- Acknowledge luck and focus on communication. Let's be real, GSoC involves a bit of luck. Some popular projects get over 300 proposals for 1-2 slots. I doubt mentors can read every single one in detail. This is why early communication is key. Get involved with the project beforehand, and make sure your proposal is solid and gets to the point.
- If you don't get selected, it's not the end. You now have valuable open-source contributions on your resume. Use that to apply for other summer opportunities. You've already done the hard work!
Last but not least:
"Everyone has been made for some particular work, and the desire for that work has been put in every heart." — Rumi
Thank you for reading.