This post is going to be a long one. I figured if I'm going to write about the two months that led up to my GSoC selection, I should do it properly the whole thing, from the very beginning, not just the highlights. So grab a coffee, get comfortable, and let's go back to where this story actually starts.
A Classroom Demo I Never Forgot
The first time I heard the name CircuitVerse, I was sitting in a Digital Principles of Design class in my third semester. I'm currently in my sixth semester, so that's about a year and a half ago now. It wasn't a big moment. It wasn't even really part of the class.
Our faculty and I'm genuinely grateful to her for this had pulled up CircuitVerse on the projector one day just to show us something. It wasn't in the syllabus. It wasn't going to be on the exam. She just wanted us to see what it actually looked like when the circuits we were drawing on paper came to life on a screen. We were studying:
- Half adders and full adders
- JK flip flops
- Foundational digital logic that you spend your first years drawing on paper or building with actual wires on a breadboard
She simulated a few circuits in front of us, walked us through how the inputs and outputs worked, showed us how you could change values and watch the circuit respond in real time. It was maybe twenty minutes of a single class period. And then we moved on.
But I remember thinking even then, as a third semester student still getting used to the pace of engineering college that this was a really interesting platform. There was something satisfying about seeing the logic work visually, in real time, without needing physical components. I didn't do anything with that thought at the time. I just filed it away somewhere.
That's where it started. One classroom demo that I technically didn't need to pay close attention to.
Why This Year
Fast forward to the beginning of this year. I'm in my sixth semester, roughly halfway through my degree, and I had been thinking about GSoC for a while not in a serious, planned out way, but in the background. I knew what it was. I knew it was something I wanted to try. I just hadn't pulled the trigger.
This year felt different. I had a feeling and I think a lot of students who've gone through this will understand it that if I kept waiting for the perfect time, the perfect time was never going to arrive. There is always:
- An exam
- A project due
- Some reasonable-sounding reason to push it to next semester
And at some point, next semester becomes next year, and next year becomes too late.
I'm in sixth semester. If I didn't apply this year, I'd have my seventh and then my final eighth semester, and by then everything gets consumed by placements and final year projects. The window felt like right now, not later.
So when the 2026 GSoC organisations were announced and I saw CircuitVerse on the list, something clicked immediately. I already had that memory of it from third sem. I'd always had a genuine interest in circuits and digital logic it goes back further than that DPD class, actually, all the way to eleventh and twelfth grade in school, where I first encountered electronics properly. It was one of those subjects that made sense to me intuitively in a way that not everything does.
And I thought: I know what this platform is, I care about what it does, and I can try. So I did.
Starting From Zero
I want to be honest about where I was when I started contributing to CircuitVerse in February. I was not a well-prepared, experienced open source developer who had been waiting for the right organisation. I had contributed to a few other open source programmes before, so I wasn't completely new to pull requests, issues, and code review. But CircuitVerse specifically? I was starting from scratch.
And the first thing I ran into was the codebase itself.
CircuitVerse runs on Ruby on Rails. For those unfamiliar:
- Ruby on Rails is a web application framework built on the Ruby programming language
- It has its own conventions, its own file structure, its own way of thinking about problems
- It is absolutely not part of the curriculum at my college
I had never written a line of Ruby before February. I had never built anything in Rails. Both the language and the framework were entirely new to me.
The codebase is also large. This is not a small hobby project — CircuitVerse is a platform used by students and educators all over the world, and the code reflects years of development from many different contributors.
The first time I cloned the repository and opened it, I felt genuinely lost. Not discouraged — but lost.
So I did what you do when you're lost. I started from the very beginning:
- Watched Ruby on Rails tutorials and beginner walkthroughs on YouTube
- Read the official Rails documentation
- Read the CircuitVerse contribution guides and developer documentation
- Spent time building a mental map of how the whole thing fit together before I tried to change any of it
Did I fully understand it after a week? No. But I understood enough to start, and that's all you actually need.
The Rule I Set For Myself
From February onward, consistency became my only rule.
It might sound simple, but it is genuinely harder than it sounds. When you are trying to break into a large open source project as an outsider, the temptation is to wait until you feel ready...until you understand enough to make something meaningful. But that moment of feeling ready never comes on its own. There is no threshold you cross where the codebase suddenly makes sense. You only get there by actually working in it, making mistakes, getting feedback, and going again.
"The journey of a thousand miles begins with a single step" — and in open source, that first step is almost always smaller and more unglamorous than you expect.
So I started small:
- Documentation fixes — correcting things that were incomplete or inaccurate
- Updating tests — fixing outdated test cases that no longer reflected the current code
- Small bug fixes — low-risk contributions that didn't require deep knowledge of the whole system
Not glamorous work, but important work, the kind of work that keeps a codebase healthy and maintainable. More importantly, it got me reading the code every single day, building familiarity one small piece at a time.
I worked hard at it not in the sense of grinding through long sleepless nights, but in the quieter and more demanding sense of showing up without exception. Even on the days when I was tired. Even when the progress felt invisible. Even when I wasn't sure what I was doing was making any difference.
Some days I made several contributions. Some days I barely scraped through with one small fix. But the consistency mattered far more than the volume on any given day. Showing up every day, even for something modest, built a habit. And habits compound in ways that occasional bursts of effort simply do not.
Over the weeks, I started to feel the codebase becoming familiar. I began recognising file names, understanding what different directories were responsible for, knowing where to look when I encountered something I didn't understand. The codebase had not changed. I had just spent enough time in it that it stopped feeling foreign — and that shift, slow and quiet as it was, turned out to be everything.
The Saturday Meetings
CircuitVerse has weekly community meetings every Saturday, and I made it a rule to attend as many of them as I could. The only real exceptions were when I had an exam on Monday, and even then I'd try to go over what had been discussed afterwards.
I want to say clearly: these meetings were more valuable than I expected when I first started attending.
When you're a new contributor reading a codebase alone, you get a limited picture of the project. You see the code, but you don't necessarily understand:
- The priorities and ongoing discussions
- What the maintainers are excited about
- What's been tried and abandoned
- What's coming next
The meetings gave me that layer of context that you simply can't get from reading files alone. They also gave me a sense of how the community operated how decisions got made, how contributors communicated, how to bring up a question without sounding like you hadn't done your homework. These things aren't written in any documentation. They're things you absorb from being present over time.
Gradually, I started feeling less like an outsider submitting pull requests into the void and more like someone who actually belonged in the community, at least in a small way. That shift matters more than it might seem.
Growing Into Bigger Contributions
As February turned into March, I started feeling more confident. The codebase was familiar enough that I could look for more substantial issues:
- Actual bugs that needed fixing
- Missing features that were clearly needed
- Things that needed real work rather than just documentation updates
I started creating my own issues rather than only picking up ones that were already listed. I also reached out to the mentors for the specific project I was interested in. This felt more nerve wracking than it probably should have... there's an intimidation factor around directly contacting experienced maintainers when you're a new contributor.
But I sent the messages, asked the questions, and the mentors were approachable. They replied, pointed me toward relevant parts of the codebase, gave feedback on my pull requests. I want to acknowledge that, because I think the attitude of a project's maintainers has a huge influence on whether new contributors stick around or quietly disappear.
Feeling like your questions are welcome makes an enormous difference when you're just starting out.
Deciding It Was Time to Write
At some point in early March I made a call: I have enough now. It's time to start writing the proposal.
I want to be clear about what "enough" meant. It didn't mean:
- I had mastered the codebase
- I had become an indispensable contributor
- I felt completely ready
It did mean:
- I had enough familiarity with the project
- I had enough presence in the community
- I understood what needed to be built well enough to write something credible
Before I wrote anything of my own, I spent time reading. The project I was applying for had been proposed the previous year and hadn't been selected I don't know exactly why, but it meant there was history to learn from. I read:
- Proposals from people who had worked on CircuitVerse in previous GSoC cycles
- Older ideas pages and discussions
- Notes about what had been built and what was still outstanding
That research took days. But it was the most important preparation I did, because it meant that when I started writing, I wasn't guessing at what the organisation wanted. I had evidence.
Seven Drafts, Maybe Ten
I wrote somewhere between seven and ten drafts of my proposal. I lost count after a while.
I kept going back to it. The cycle looked something like this:
- Write a section
- Read it the next morning
- Decide it wasn't clear enough
- Rewrite it entirely
- Add diagrams → delete diagrams → add them back in a cleaner form
- Restructure the timeline
- Rewrite the problem statement
- Change the order of sections → change it back
The hardest section, without question, was the timeline.
In college, someone gives you a deadline and you work toward it. You're not usually asked to commit, in writing, to what you will accomplish in each specific week of the next three months. GSoC asks you to do exactly that — to look at twelve weeks and say with real specificity what will be done by the end of week one, two, three, all the way through.
In my case, there was an additional layer of complexity — I had to account for my college schedule, which I can't fully predict:
- Internal exam dates aren't announced at the beginning of the semester
- Assignment deadlines shift based on faculty schedules
- Lab work takes unpredictable amounts of time
I had to build buffer into my timeline without making it look like I was padding. I spent more hours on that timeline than on any other part of the proposal.
The second hardest section was the problem and solution where you show that you actually understand what you're proposing to build, not at a surface level, but in real technical depth.
Five Forty-Five AM
All of this was happening while I was attending college, sitting internal exams, completing assignments, and trying to maintain some kind of normal student life.
The time I found was in the mornings.
I started setting my alarm for 5:45 AM and trying to be up by six. That gave me an hour to an hour and a half before I had to think about anything else before college, before messages, before the day's demands started stacking up.
It doesn't sound like much. But when that's the only truly quiet time available in a given day, you make the most of it. And over six or seven weeks, those morning sessions added up to something real.
There were mornings when the alarm went off and getting out of bed took everything I had. Days when I sat at my desk with coffee going cold and the proposal open and nothing useful in my head. But I showed up anyway, did what I could, and went to college. And slowly the drafts got better.
Submitting
I was late submitting my proposal for mentor review, which meant I didn't get as much feedback as I'd wanted. I got some — one mentor gave me genuinely useful notes that I was able to implement... but I wish I'd started the review process earlier.
If there's one piece of advice I'd give to anyone applying next year: send your draft to the mentors at least two weeks before the deadline. You need enough time to actually act on the feedback, not just read it.
The final deadline was March 31st, 11:30 PM IST. I submitted at 11:20 PM.
Ten minutes to spare. I'm not recommending this approach.
I was proud of what I submitted though. It was specific, honest, reflected months of work, and was genuinely mine in a way that felt important. And then there was nothing left to do but wait.
What This Process Actually Is
I want to end this post with something I believe is genuinely truemnot just something people say to make those who weren't selected feel better.
The pre-GSoC period teaches you things that cannot be learned any other way:
| Skill | Where you learn it |
|---|---|
| Reading a real-world codebase | By actually working in one |
| Writing a credible technical proposal | By writing seven drafts and rewriting them |
| Consistent community contribution | By showing up every single day |
| Professional communication | By reaching out to maintainers and getting feedback |
GSoC is not a competition for the most brilliant students at the best universities. It is an opportunity for anyone who is genuinely interested in open source and willing to put in consistent, honest work.
I was a sixth semester student who had never written Ruby before February. I didn't have a polished portfolio or a list of impressive prior projects. I just kept showing up every day and tried to get a little better.
If you're reading this and considering whether to apply next year — start now. Not next month. Now. The earlier you start contributing, the more comfortable you'll be with the codebase by the time the proposal period opens. And even if you don't get selected the first time, the work you do in the process is real and valuable in itself.
In the next post: what happened after the submission the shortlist, rounds of interviews, and the night I found out I got in.