Opening the Chrome codebase for the first time was disorienting.
Millions of lines of code within hundreds of directories. I didn’t even know where to start looking. And somewhere inside all of it were the files I needed to change to implement a single feature.
That idea eventually turned into 23 contributions across Google's Gemini CLI and Chromium.
The First Feature. permalink
Back in early September, I finished developing my idea: the Open Button.
This first feature wasn’t meant to lead anywhere beyond itself. It was honestly just something I wanted to try. However, working on such a large-scale codebase drastically changed how I saw this project. Through my initial changes and subsequent ones, I realized I could directly improve how users interact with and navigate Chrome.
One change led to another. Then another.
Eventually, it stopped feeling like “trying to contribute” and instead started feeling like there was always something else I could improve.
Nothing is Where You Expect It. permalink
Writing the code itself wasn't challenging, it was understanding where the code even lived that took the most effort.
Many large codebases are typically complex and hard-to-follow, usually containing thousands of scripts. Especially files mentioning other files you haven’t read yet. Even fixing or implementing a small feature often meant tracking instances across multiple directories to understand what would happen when a change was fully made.
When contributing to Chromium or Gemini CLI, a large part of the learning process was simply navigation.
It took much longer than expected to find the right files and then to interpret how the behavior and implementation of a script or UI could be mapped to the current technology stack (the combination of programming technologies used to create components). I often thought I had found the right place to make modifications, but later learned I was still some distance away from what actually required changing.
I eventually needed to do a test run with my modifications. At the start, both GN (Generate Ninja) and Ninja were brand new to me (it wasn't until later that I realized GN created build configuration files that Ninja subsequently uses to execute them). Frequently, build processes failed because the structure of my changes did not match the code standards or expectations. From this point on, instead of trying to learn the entire codebase at once, I found that as I kept contributing, the process became increasingly familiar.
Because the majority of my contributions were to Chromium, contributing to Gemini CLI on GitHub instead of Chromium’s Gerrit felt very different (much faster development and a much lighter review process).
Looking Back. permalink
Software development remains a frustratingly iterative process.
Features rarely emerge fully formed. Many times, I witnessed firsthand how my original implementation evolved due to testing issues, reviewer feedback, or edge cases I had never even thought to consider. In fact, some of the most important improvements within my changes came from mistakes or misunderstandings during development.
It remains clear to me that the most rewarding aspect of this contribution experience wasn't (just) the number of accepted contributions, but the experience I gained from figuring things out along the way.