Not Just Code: My GSoC Retrospective

On May 1, 2026, I got an email I'd been waiting for. I had been accepted into Google Summer of Code.

For the next three months, I would be working with the R Project for Statistical Computing on ClassBound, an open-source project for visualizing classification decision boundaries. At that point, I knew the technical work would be interesting, but I had no idea how much of the experience I'd remember for reasons that had nothing to do with code.

This isn't a technical write-up of everything I built during GSoC. I've documented that separately on my technical blog, and there's a detailed record of my work in my GSoC 2026 repository. This is more about the journey itself.

A second-semester course that somehow led to GSoC#

My introduction to R happened during my second semester of college. Like many students, I encountered it because it was part of a course. At the time, I found it interesting how a language with fairly simple syntax could be used for powerful statistical operations and visualizations. It felt different from the languages I'd mostly used while building projects.

I didn't know then that a college course in R would eventually lead me to Google Summer of Code. But that's one of the things I like about learning and building: you often don't know where something will lead when you first encounter it. A course, a random project, or a tool you decide to explore can unexpectedly become useful years later.

Eventually, that earlier exposure to R led me to the R Project for Statistical Computing and, more specifically, to ClassBound. The project focuses on visualizing classification decision boundaries, helping users explore how different machine learning classifiers divide and interpret data. My role during GSoC was to help take the project further and build a more complete, extensible package around that idea.

The final project is here: ClassBound on GitHub

Thursdays, Discord, and the people behind the project#

One of the best parts of GSoC was working with my mentors. Natalia da Silva and Ignacio Alvarez-Castro were based in Uruguay, while I was working from India. It's funny how quickly something unfamiliar becomes routine. At the beginning, weekly meetings with mentors on the other side of the world felt like something new, but soon enough, our Thursday meetings and Discord messages were just a normal part of my schedule.

During those meetings, we'd discuss what I'd worked on, problems I was running into, ideas for the project, and what needed to happen next. But conversations weren't always limited to ClassBound. The FIFA World Cup happened to coincide with our GSoC period, which gave us plenty of chances to talk about something other than R, classification boundaries, or software architecture. Those moments were important; they turned a remote working arrangement into an actual relationship.

That was one of the quieter things GSoC taught me. The internet has made global collaboration feel almost ordinary. Open source can sound abstract when you describe it—you imagine repositories, pull requests, issues, code reviews. But behind all of that are people. Every now and then I'd stop and actually think about it: I was in India, working on the same project as people in Uruguay, meeting online every week, and geography mattered far less than whether we could communicate and move the project forward together.

Three months with one project#

One thing that felt different about GSoC, compared to a lot of what I'd done before, was the amount of time I could spend on a single project. Hackathons are intense and short: you build quickly, decide quickly, and try to get something working before time runs out. GSoC was different. I had time to understand the project more deeply, revisit decisions, get feedback, rethink approaches, and watch it evolve over months.

The proposal gave us a direction, but the actual work brought new questions along the way. Some things turned out differently than they looked at the start, and that was part of the experience. I enjoyed that. There's something satisfying about working on a problem long enough to move past the first obvious solution, and to start asking whether it can be cleaner, more flexible, or more useful to the people who'll actually use it. That kind of iteration is where I feel like I learn the most.

If you're interested in the technical side, features, architecture, development process, outcome, I've written about it in detail here: My technical GSoC report

The GSoC Alumni Camp in Delhi#

In the middle of the program, I got to attend the GSoC Alumni Camp 2026 in Delhi, held during the final week of July. That was very different from the rest of GSoC. Most of my journey had happened remotely, working from my own setup, attending meetings online, spending months focused on ClassBound. The Alumni Camp put me in a room with people who'd taken very different paths, some working remotely, some building their own startups, some still figuring out what they wanted to do next.

As a final-year student, there's a strange pressure to feel like you should have everything figured out; jobs, higher education, startups, research, and a dozen other paths all seem to demand a decision. Meeting people at very different stages of their journeys, some settled on a direction, some changing course, some still working it out, was a useful reminder that there isn't one correct timeline for starting something meaningful.

Oh, and there was also a scavenger hunt at the event. I ended up being one of the winners. I'll take that.

What I'll remember most#

When I look back at GSoC, I'll obviously remember the project: working on ClassBound, learning more about R, contributing to something that existed before I joined and will hopefully keep growing after. But I think I'll remember the people just as much. The Thursday meetings with my mentors. The conversations that wandered off-topic. Working across India and Uruguay. The FIFA discussions that somehow became part of a software project. Going to Delhi and meeting people building completely different things, and seeing how many directions a technical career can take.

GSoC gave me three months to focus on something meaningful, but it also gave me a better sense of what collaboration in open source actually feels like. It made the whole ecosystem feel a lot more human.

A few things I'd tell someone applying to GSoC#

I don't think there's a magic formula for getting selected, every organization, project, mentor, and applicant pool is different. But a few things are worth keeping in mind.

• Choose something you can genuinely stay interested in. GSoC lasts months, and you'll spend a lot of that time on the same project, the same codebase, and problems that don't always have quick answers. Skills can be learned along the way; curiosity is what keeps you engaged once the initial excitement wears off. Try to find a project where you actually want to understand the problem, not just one that looks good on a résumé.
• Understand the project before trying to impress anyone. It's tempting to focus heavily on the proposal, and it does matter, but it gets much stronger once it comes from actually understanding the project. Read the code, explore the existing work, try things yourself, ask questions when you have real ones. The goal isn't just to convince mentors you're capable; it's to figure out whether you actually want to spend the next few months on that problem.
• Communicate like you're already part of the project. Open source is collaborative by nature. Technical ability matters, but so does discussing ideas, taking feedback, explaining your thinking, and changing direction when you need to. That's not separate from the technical work, it is the work. Some of the most useful moments during GSoC came from conversations where an idea got worked out before it became code.
• Don't expect the original plan to survive contact with the work. Your proposal gives you direction, but the real work starts once you're dealing with the actual project: you understand more, you run into constraints you didn't expect, someone gives feedback that changes your thinking, an approach that looked fine starts causing problems somewhere else. That's normal. Changing your approach because you understand the problem better isn't drifting from the plan, it usually means you're finally understanding the problem properly.
• If you don't get selected, the effort isn't wasted. If you spent weeks exploring an open-source project, talking with its community, and building things before applying, that effort still counts. You've learned something, maybe made contributions, maybe found an area you're genuinely interested in, maybe built relationships that outlast the application. Selection matters, and I know how good that acceptance email feels, but it shouldn't be the only outcome you value from the process.

Thank you#

I'm incredibly thankful to my mentors for making this experience what it was, and for all the discussions, guidance, and feedback throughout the project. I'm also thankful to the R Project for Statistical Computing for the opportunity to work on ClassBound, and to everyone I met through GSoC and the Alumni Camp.

Three months went by much faster than I expected. From opening that acceptance email on May 1 to attending the Alumni Camp in Delhi in late July, this ended up being one of the most memorable experiences of my college life.

• The project, if you'd like to check it out: ClassBound, github.com/natydasilva/classbound
• My complete work and journey through the program: GSoC 2026 ClassBound, github.com/Vai-Man/gsoc-2026-classbound
• And if technical details are your thing: Technical Report, classbound-gsoc.vercel.app/blog/

Thanks for reading.