Yeunjoo Choi from Igalia on Chromium - The Consensus<br>Yeunjoo Choi from Igalia on Chromium<br>May 20, 2026 by Phil Eaton<br>interviewsweb browsersc++open source<br>You 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?#<br>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”...#<br>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?#<br>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?#<br>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...