GSoC前 — CircuitVerseへの道を見つける

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 proje