Yeunjoo Choi from Igalia on Chromium - The Consensus
Help us understand your transactional database usage. Take our survey! On software infrastructure.SubscribeSign InLog OutDatabasesProgramming LanguagesInterviewsJobsFundingEventsWeeklyYeunjoo Choi from Igalia on ChromiumMay 20, 2026 by Phil Eatoninterviewsweb browsersc++open sourceYou are getting early access to this article as a subscriber. Your support makes articles like this possible. Thank you.This article is part of a series interviewing developers (not founders, not executives) working on software infrastructure to understand their work, how they got here, the projects they’re proud of, the incidents they’ve learned from, and what they’re curious about.Yeunjoo (LinkedIn, Website), has worked on web browsers (WebKit and Chromium) for the past 15 years, first at LG Electronics and today at the open-source software development consultancy Igalia.What have you been working on recently at Igalia?#I'm a member of the Chromium team and have recently been working on enterprise browsers. Many enterprise browser vendors adopt Chromium because of its compatibility with web standards, strong cross-platform support, active upstream maintenance, ecosystem, tooling, and so on. Browsers also have become the main control point of enterprise services, so there have been more opportunities for Igalia to collaborate with enterprise vendors.Working with several enterprise vendors, I have implemented enterprise features related to policy control and data protection, rather than working on areas like layout, JavaScript engine, or media features. Chromium already has the built-in enterprise policy for generic browser controls, but some customers want more specialized behaviors for their browser which require adding new code paths and hooks, not just adding new policy entry in a JSON file. On top of that, I also need to consider their separate policy engine with its own syntax, protocol, and evaluation logic.Another area I have worked on for enterprise browsers is branding. Branding is usually the first task when starting a new project from scratch. It involves not only changing icons and strings, but also customizing layout of settings or the new tab page, splash screens, and so on. In one project, I worked directly with an UX designer to get assets and discuss about layout. That was one of the interesting experiences for me because it helped me better understand the perspective of UX designers.When you say “enterprise browsers”...#I mean versions of Chromium used in products developed by enterprise solution vendors. Those browsers are often sold as enterprise solutions to their customers, but in many cases the companies also require their employees to use them internally. Their employees are often the first users of those enterprise browsers.How do you keep all these enterprise forks up-to-date? Isn’t that a lot of work?#Rebasing is always a challenge because Chromium is a large and fast-moving repository, with non-trivial commits in every release. As far as I know, well-known browser vendors that use Chromium have their own rebase strategies to keep their forks up-to-date.Igalia also has been asked by customers for help and advice in this area. There are several important factors when defining a rebase strategy: Rebase or Merge? When to update? Size and shape of downstream deltas? Automation? Team capacity for QA? and so on. My coworker José Dapena Paz has published an interesting series of blog posts about downstream maintenance, which I'd recommend reading.Personally, when developing on Chromium forks, I try to structure downstream changes in ways that reduce merge conflicts during rebasing. For example, I prefer implementing new downstream features in isolated layers (such as //igalia) and reusing upstream components like //components, //content and //ui to keep my own delta smaller. One important point is respecting the hierarchy and boundaries of the existing layers. Most upstream refactors keep clear dependency rules between layers, so downstream change that follows those structures results in fewer merge conflicts and fewer regression during rebasing.What’s a project like at Igalia?#As Igalia is an open-source consulting firm, most of our projects are customer-driven. Some projects involve implementing product-specific features or maintaining downstream Chromium forks, while others focus on upstream contribution. On the upstream side, we sometimes help upstream features developed for customers or we also help accelerate CSS standardization efforts.We work not only on customer projects, but also on internal investment projects. Igalia invests part of resources into open-source projects that we believe are meaningful or strategically important. Since we have worked closely with various customers for a long time, Igalia has a good understanding of what is needed in open-source projects and ecosystems.Some of those investment projects come from recurring needs we've seen. For example, my coworker Miyoung Shin is working on migrating extension-related code from //chrome to //extensions , enabling Chromium to support extensions on embedders through componentization.When Igalia reviews project proposals, we first check if we have available resources and people are interested in the project. That also means I have opportunities to work on projects that match my interests. I usually say "I'd like to work on that project!" because I enjoy working across different areas of the Chromium rather than focusing on a specific domain.Project size and duration vary depending on the goals of the project. For example, if the goal is to build a downstream browser based on Chromium and implement new features, the project may be large at the early stage and become smaller as the goals are achieved. On the other hand, some maintenance projects are small but long-term, spanning multiple years.What’s something recently you’ve been learning about or finally understand. Maybe something you feel silly you didn’t know about or understand earlier?#One thing I've finally realized is that open-source projects are easier to approach than I had imagined.Before joining Igalia, I hadn't contributed to open-source projects, even though I had worked with several browser engines for almost 10 years. I might have been a bit lazy, and honestly, I was overwhelmed by the idea of contributing to such large open-source projects. I was afraid of breaking something in projects that were widely used by so many people. I also doubted whether my downstream work would be interesting or useful for upstream, because I thought it was too product-specific.Another challenge was stepping outside my comfort zone. Korea has been a relatively homogeneous society, and in the past I rarely communicated with people from different cultural backgrounds. I wasn't sure whether I could communicate well in English while discussing and reviewing code changes.But I didn't need to worry so much! Open-source communities are welcoming to new contributors from diverse backgrounds and willing to help beginners. My first upstream contribution to Chromium was a small refactoring commit, and I was surprised because it was much easier than I expected. After learning the Chromium ecosystem by contributing small commits, even larger commits no longer felt intimidating.What got you into programming? Did you go to university for computer science?#I majored in Electronics, but I was more interested in digital signal processing and embedded systems than traditional hardware fields like semiconductor or circuit design.C programming was also one of the core subjects in the curriculum, so I was already somewhat familiar with programming. I became more attracted to software development because I could see visible results much more quickly than in hardware projects.I started my career at a large industrial company and joined a browser team doing pure software development. Although I was interested in programming, I didn't have much formal computer science background, so I had to learn many things while working on real-world software projects. After work, I spent time studying computer science from well-known books recommended by coworkers, such as "The C++ Programming Language", "Design Patterns" and "Refactoring".In the end, I realized that I genuinely enjoyed solving problems with software.How did you get into browser development?#I was assigned to a browser team right after starting my career. At that time, I had no idea what browser development was - which makes sense, because I barely knew computer science either! The first task I worked on was enabling hardware acceleration for WebGL on a SmartTV browser. The only part I could contribute to was a very small optimization that reduced unnecessary copies between the CPU and GPU using EGL APIs. Back then, I wasn't thinking about diving into browser development since I was too busy digesting a bunch of new knowledge.I worked on WebKit, and later moved to Chromium after my previous company adopted it. As my scope gradually expanded across different parts of the browser, it hit me that I had learned much of what I know about software engineering from working on mature open-source browser engines. Browser engines are a melting pot of diverse technologies, and I learned a lot by reading clean, well-structured code written by talented engineers in the open-source community.That's probably why I still enjoy browser development today. There is always something new to learn and browser development has been the best place for me to grow as a software engineer.One of the first big open-source contributions you made to Chromium was helping Google do a bunch of refactoring. Can you tell us about that project? And why does Google need help outside of Google?#One big refactoring project was the Multiple Page Architecture (MPArch) project led by Google, which introduced significant architectural changes to fully support features like back/forward cache, prerendering, portals, and fenced frames.It modified the core navigation architecture and affected many parts of Chromium, so the changes couldn't be rolled out all at once. Google introduced new navigation paths for MPArch, and I helped replace the old ones incrementally. The work involved verifying that nothing was broken across different platforms, and it sometimes required a long discussion with code owners.I think that this kind of large-scale refactoring requires many contributors working together, especially because it touches core parts of Chromium. Igalia was already a major contributor to the Chromium open-source community, and having many experienced contributors working together helped accelerate the refactoring project.What was the worst bug you caused? What happened? How’d you find and fix it?#I worked on implementing video features for digital signage devices at my previous company. One use case was continuously playing video advertisements without shutting down the device, so stability was very important.One memorable bug was reported as an intermittent black screen during video playback, but it was very difficult to reproduce. As far as I remember, I spent quite a long time trying to narrow it down.By chance, I once tested a video with a completely white background and noticed that the white area was rendered as black. That gave me a clue that the issue was related to alpha handling during video composition, which exposed the layer underneath. I don't remember the exact fix now, but I remember it ended up being a one-line fix once I figured it out.C or C++? (Or some other favorite language entirely?)#Definitely C++! I can't really explain it well, but writing modern C++ feels very natural to me now since I've spent my whole career writing C++ code.Personally, I think every language has its own strengths, and it's really satisfying when I can use a language in the way it was designed to be used, such as using C++ templates to write reusable code and reduce boilerplate.It must take forever to compile browser code, being such large C++ projects. What’s your development process like?#Good question. I'll never forget that it took 9 hours to do a clean build of Chromium for Android on my old laptop.It now takes less than 3 hours to do a clean build after buying a brand-new powerful laptop, and I also use ccache to speed up local builds. Ccache works especially well when I don't need to frequently update the base code, such as when working on downstream projects. If I were working on a downstream project with large daily updates touching many files, I would probably set up an environment that fetches and builds nightly.When contributing upstream, I rely on Google's remote build execution service since I have “try job access” (i.e., permission to run pre-merge test builds on Google's shared infrastructure) as a Chromium committer. It's quite fast, usually taking around 10-15 minutes for a clean Android build on my laptop, although I've sometimes thought about trying other RBE backends to reduce dependency on Google.What’s testing like (in Chromium)?#I would say testing is essential in Chromium, as it is a browser engine that supports many features and targets a wide range of platforms.Chromium includes tens of thousands (or even more!) of unit tests, integration tests, layout tests, platform-specific tests, and so on. It is very difficult for developers to run all tests locally. So upstream has a Commit Queue (CQ) that runs tests for each change, and lands the commit if everything passes. When working on downstream projects, it is good to enable Chromium tests in the CI environment as early as possible. At least, projects should enable the testing suites related to the components they modify.Given the huge number of tests, Chromium development feels very test driven for me. Contributors are expected to write tests with good coverage of their changes, and reviewers will usually ask for tests during code review if they are missing.I think this strong testing culture is one of the reasons Chromium can continue evolving while supporting such a huge codebase and so many platforms.Did you like working with WebKit or Chromium more? (And why?)#I'm not sure if I can compare working with WebKit and Chromium, because I worked on WebKit during my junior years. But working on WebKit helped me understand the concept of multi-process architecture in modern browsers, and that made it much easier for me to understand Chromium after that.I still enjoy working on Chromium, but I'm also open to contributing to WebKit if I have the chance. :)What are you excited to work on or learn about next (in software)?#I want to learn how to utilize AI Clients in my work environment. These days, I'm using Claude Code, and it definitely boosts my productivity. But I really only started using Claude Code recently, so I think there is still a lot of room for improvement, such as learning how to use its skills effectively.I also have some ideas for using AI tools to build my own productivity tools or VIM plugins. I'm already excited just thinking about it.How has AI made things better or worse for you and the Chromium community?#That's a tricky question. Personally, AI has made things better for me as a Chromium developer, since it reduces the time to investigate such a large-scale codebase. It is especially useful when trying to understand unfamiliar components or trace complicated code paths.Regarding the Chromium community, although I haven't been very active upstream for a while, I think now is a transition period as the community adapts to new technology. Committer requirements have been updated to include guidelines for AI-generated code, and upstream Chromium now provides //agents for files related to AI coding agents.Tools are tools, and I'm optimistic about this trend in the Chromium community. But we should stay careful not to be dragged around by AI agents.Vim or Emacs or something else entirely?#I can exit Vim. :) I sometimes nose around other editors like NeoVim or VSCode, but I always come back to Vim because of its flexibility and simplicity.Thank you for your time Yeunjoo!#My pleasure. It was a good chance for me to look back on my career. Thank you for having me!About the authorPhil is the founder of The Consensus. Before this, he contributed to Postgres products at EnterpriseDB, cofounded and led marketing at TigerBeetle, and was an engineering manager at Oracle. He runs the Software Internals Discord, the Software Internals Email Book Club, and co-runs NYC Systems. @eatonphilEnjoyed this article? Subscribe for unlimited access and to help us keep producing excellent articles.Noticed a mistake? Have a question or comment? Write to the editor.MoreDeveloper SpotlightYeunjoo has worked on web browsers (WebKit and Chromium) for the last 15 years, today she's at the open-source consultancy Igalia.Read the interviewJob OpeningsAutomatticSenior Systems EngineerRemoteseniorphpNormal ComputingSoftware Engineer, BackendNew Yorkdeveloper-toolsTrue AnomalyQuality Engineer, HardwareLong BeachassemblyqaSee allFunding and AcquisitionsSeries C · $355MModalAnnounced May 21, 2026🇺🇸 New York HQRead more.Series A · $20MPreludeAnnounced May 20, 2026🇫🇷 Paris HQRead more.Series C · $250MExaAnnounced May 20, 2026🇺🇸 San Francisco HQRead more.See allThe Consensus WeeklyWant to learn about new articles on The Consensus, new funding announcements, and new job postings?Join The Consensus Weekly for free.EventsSoftware You Can LoveVancouverOctober 3, 2026systemsFeaturedSouth Bay SystemsQueues & RDBMS ExtensibilitySunnyvaleMay 26, 2026foundationdbmysqlHimank Chaudhary and Steve Schirripa speaking.NYC++C++: THE DOCUMENTARYNew YorkMay 28, 2026c++PGDay BostonPGDay Boston 2026BostonJune 9, 2026databasespostgresSee allOn software infrastructure.FeaturedDatabasesProgramming LanguagesInterviewsJobsFundingEventsWeeklyCompanyAboutSponsorContributeBlogContactCopyright. All rights reserved © 2026 Consensus Labs, LLC 418 Broadway #7427 Albany, NY, 12207, USATerms and ConditionsPrivacy PolicyCookies Policy
JavaScript is required to read The Consensus.

Yeunjoo Choi, who has spent fifteen years working on web browsers including WebKit and Chromium, currently works at the open-source software development consultancy Igalia. Her experience spans understanding the development lifecycle, architectural challenges, and the nature of open-source contributions within large-scale software projects. In her recent work at Igalia, she has focused on implementing enterprise features for Chromium, concentrating on policy control and data protection rather than core rendering components like layout or the JavaScript engine. This work involved integrating specialized behaviors for enterprise vendors, which necessitated adding new code paths and hooks beyond the existing generic browser controls. She also engaged in branding efforts, collaborating with UX designers to manage assets and layout, which provided her with a deeper understanding of the user experience perspective.

Working with enterprise versions of Chromium involves managing the intricacies of maintaining these forks, which presents challenges related to rebasing, given Chromium's fast-moving repository and frequent upstream commits. Choi emphasizes the importance of defining robust rebase strategies, considering factors such as the update method, the size of downstream deltas, and team capacity for quality assurance. She advocates for structuring downstream changes by implementing new features in isolated layers and reusing upstream components to minimize merge conflicts and regressions during the rebase process, respecting the existing architectural hierarchy.

At Igalia, the firm engages in customer-driven projects, which range from implementing product-specific features and maintaining downstream Chromium forks to contributing to upstream efforts, such as accelerating CSS standardization. The firm also invests resources into internal open-source projects, demonstrating their deep understanding of ecosystem needs. These projects often involve migrating code, such as moving extension-related code, and accelerating foundational efforts. Choi demonstrated a preference for broad contributions across the Chromium ecosystem rather than focusing strictly on a narrow domain, often aligning with projects based on emerging needs identified through client interactions.

Her journey into programming stemmed from an interest in digital signal processing and embedded systems in her Electronics major, alongside familiarity with C programming. She transitioned to software development after realizing the visible results in software were more immediate than in hardware design. To build a strong foundation, she studied computer science concepts from foundational texts and focused on practical software engineering principles. Her experience developing browser engines provided exposure to well-structured, clean code within the open-source community, which has remained a driving force for her work.

One significant contribution involved helping Google with the Multiple Page Architecture (MPArch) refactoring project, which involved modifying core navigation architecture and ensuring consistency across platforms. This large-scale effort required collaboration among numerous contributors to successfully implement the necessary architectural changes. When troubleshooting, she encountered complex issues such as intermittent bugs, where identifying the root cause required careful analysis of lower-level details, leading to an understanding of alpha handling during video composition.

Regarding development processes, Choi noted the complexity of building large C++ projects, emphasizing the necessity of efficient build systems. She utilizes tools like ccache for local build speed and relies on Google's remote build execution service for upstream contributions. Testing is central to Chromium development, involving tens of thousands of tests across various categories. To manage this volume, upstream employs a Commit Queue system, and contributors are expected to write comprehensive tests for their changes, reinforcing a strong test-driven culture necessary for evolving such a vast codebase.

Moving forward, Choi is keen to explore the integration of artificial intelligence tools, such as AI clients, to enhance her productivity. While she sees AI as beneficial for navigating the vastness of the Chromium codebase, she stresses the need for caution regarding AI-generated code in the community, remaining focused on the principles of software engineering. She values the flexibility of editors like Vim for complex coding tasks alongside other modern tools.