How a Chrome developer ended up comparing Google with Igalia
On the final day of FOSSY 2026, at the University of British Columbia in Vancouver, Sharon Yang took the stage with a talk that could’ve gone sideways fast. A comparison between Google and Igalia sounds, on paper, like the setup for a polite workplace grievance. Hers wasn’t that. It felt more like a newsroom story with source code attached.
Yang’s path made the comparison land. She began as a Google intern, then stayed on for roughly six years as a full-time Chrome engineer, while studying in Vancouver. That’s a long enough stretch to learn how a giant company works from the inside, especially one where browser work touches both public open-source code and a lot of machinery you never see from the outside.
By the time she left, she had a very practical view of what it means to work on Chromium inside a corporation that is, to put it mildly, not short on scale. Her move to Igalia came near the end of 2024, after she started looking for a new job and decided to return to Canada from the Seattle area. The relocation matters here because the talk wasn’t some abstract thought experiment cooked up from a distance. It came from someone who had lived both versions of the same browser world: one with Google’s size and structure, the other inside an employee-owned cooperative with a very different rhythm.
The useful comparison wasn’t “which company is better?” It was “what changes when the people, the pay, and the decision-making model change around the same codebase?”
That was the real hook. Yang said she liked both jobs, which probably spared the audience from the usual corporate melodrama. The point of the talk was sharper than that. Her slide deck kept returning to the contrast between a giant corporate employer and a worker-owned cooperative, because that contrast is where the interesting part lives. What actually changes?, if both companies spend their days inside the same Chromium repository. The answer is not just one line in a mission statement or a different logo on a laptop.
It’s the sort of question that fits neatly into tech news, but it also brushes against ai policy and digital culture, because browser governance now sits near the center of both. Browsers shape what people can access, what defaults get baked in and which features get priority when companies decide what to ship.
In that sense, Yang’s talk was less about office culture than about power with a developer’s accent. She opened with an unusually calm premise for such a charged comparison: these were both jobs she had liked. That made the room listen a little harder. If this had been a gripe session, the conclusions would’ve been easy to dismiss. Instead, the talk promised something better and slightly more uncomfortable: a look at two workplaces that build on the same browser foundation, yet operate by different rules.
Same browser code, wildly different companies
The comparison gets less fuzzy once you put the two employers next to each other. Google operates at a scale measured in the hundreds of thousands of employees (or something like that) and hundreds of billions of dollars in yearly revenue. Igalia’s much smaller, closer to a few hundred people, with revenue that sits far below that giant bracket. That difference sounds boring until you remember what it means in practice: one company can spread risk across a sprawling organization, while the other has to be a lot more deliberate about every hire, every project, and every new commitment.
Ownership shapes the mood in the building, too. Google is controlled by outside investors and public markets. Igalia is employee-owned. That single distinction helps explain why the two companies feel so different from the inside. Pay follows suit. At Google, executive compensation can climb into the hundreds of millions and ordinary engineers can still be in the low-to-mid six figures. Igalia uses one salary level across the company. The browser engineer, the operations person, and the person handling business matters all sit in the same pay structure. That flattens a lot of the status theater before it has a chance to get loud.
Chrome and Chromium are the next fork in the road, and this is where a lot of people get tripped up. Chrome is Google’s branded browser product. Chromium is the open-source base that other browsers can build on, and the public repository is where much of the shared browser work actually lives. If you want the map of that codebase, the Chromium source tree overview lays out how the project is organized. Most Chrome engineers spend a lot of their day inside that repository, even though some Google-only pieces sit elsewhere.
A few things sit outside Chromium on purpose. DRM support, some media codecs, and certain AI-related integrations aren’t part of the open source base. They live in Google-controlled layers around Chrome instead. That means Chromium’s real browser infrastructure, not a toy or a stripped-down demo, but it’s still not the full browser product people download from Google. It’s the common trunk, with some branches left off.
Other browsers rely on that same trunk. Microsoft Edge and Brave are both built on Chromium, which is why a change in the shared codebase can show up in more than one browser at once. Igalia works in that same browser world, and its public browser work covers Chromium-related engineering and web-platform issues across browsers. The company’s browser team lays that out clearly on its browser technology page.
Shared source code does not create shared power. The company that owns the product, the staff, and the surrounding infrastructure still gets the louder voice.
That’s the part that turns this from a tech org comparison into a story about power and politics. The code may be open, but the use isn’t evenly distributed. Google’s size means it can assign people to Chromium development, keep proprietary pieces in separate layers and shape the product around a much broader corporate machine. Igalia can contribute serious engineering work. But it does so from a narrower base, with fewer people and far less financial muscle behind it. In other words, Chromium may be shared software, yet the companies around it don’t share the same influence.
The hidden doors: tools, bugs, and access
Even when two companies work in the same Chromium tree, the day-to-day experience can split fast once you leave the source code and hit the plumbing around it. That was the point Sharon Yang kept circling back to in her talk: the repository may be shared, but the machinery around it is still owned, tuned and guarded by Google. For engineers inside Google Chrome, that setup can feel ordinary. For people at Igalia, or any other outside Chromium contributor, the same setup can turn a routine task into a small scavenger hunt.
One example is the build system. Google’s internal Chromium builds are tuned for speed and convenience, and people inside the company can reach them without much ceremony. Outside the walls, it’s a different story. If you want access, you ask for it. The public get the code instructions spell out how to pull Chromium down and start working, but Yang’s point was that “public” and “equally accessible” are not the same thing. A lot of the sharp edges show up only after you’ve already done the obvious part and fetched the code.
Bug tracking has a similar split personality. In theory, Chromium bugs are visible to a broad crowd of developers, which fits the whole open source posture neatly enough. An older tracker migration left some issues readable only to Google employees, in practice. That kind of mismatch usually gets patched once somebody notices, but it keeps happening. A contributor files a bug, then discovers the thread or attachment they need’s behind the wrong permission wall. Someone from Google flips the switch, the issue becomes visible, and everybody moves on until the next one appears. Nobody’s likely to lose sleep over any single case, yet the pattern keeps chewing up time.
Open source does not erase gatekeepers. It just makes the gate a little more embarrassing to trip over.
That same friction showed up in documentation. Some information that ought to have been public wound up stranded in private Google Docs because the sharing settings were never finished or never revisited. It’s the sort of thing that sounds trivial until you’ve spent an hour asking why a design note or workflow explanation is missing from the place everyone expects to find it. When the doc lives inside a company account and nobody flips it to open access, the outside reader’s left guessing whether the file never existed or simply never got shared.
The bigger issue’s that the tools themselves sit under Google’s control. Bug filing, fix requests, workflow changes and the surrounding administrative gears are maintained by the company that also employs most of the people closest to Chromium. That means outsiders can report problems, point out rough edges and sometimes propose changes. But they have a narrower lane for changing the process itself. If a form’s awkward, a tracker field is confusing, or a workflow needs another step, an external contributor can complain about it. Getting the system revised is another matter.
That’s where open source governance stops sounding tidy and starts sounding human. The code may be in public view, and plenty of the work may happen in the open, but the people who run the tools still set the pace. A Google employee can usually wander through these systems without noticing the seams. An outside engineer sees them immediately. The difference isn’t dramatic in the Hollywood sense. It’s a thousand tiny inconveniences: a request for access here, a hidden bug there, a document that never got shared, a workflow nobody outside Google can easily tweak.
Taken one by one, those are minor irritants. Put them together, and they create a very specific feeling of separation. The project may be shared, but the route through it isn’t. That gap is what makes Yang’s comparison so telling, and it also explains why the next part of her talk moved away from access and into the kind of work Igalia ends up doing once it’s actually inside the project.
Why Igalia’s work looks less flashy and more foundational
At Google, the work Sharon Yang described tended to arrive from above. Managers set the direction, then projects got mapped to feature launches, product goals, or whatever could be folded back into a performance review. That doesn’t mean every engineer was chasing shiny new browser tricks all day, but it does mean the incentive structure pushed a lot of energy toward things that could be measured, presented, and credited.
Igalia works differently. Its browser development work usually comes from technical staff or from clients who want a specific problem solved. The result’s less about visible bells and whistles and more about code health, technical debt and systems repair. That sounds less glamorous because, frankly, it is. It’s also the sort of work that keeps a shared codebase from turning into a pile of mutually incompatible parts.
Some of the examples Yang pointed to were pretty plain-spoken, which is probably the point. Chromium componentization means splitting up a giant browser codebase so pieces can be maintained and reasoned about more cleanly. Web-platform test interoperability means getting browsers to agree on how those tests behave so developers aren’t stuck debugging the same issue in three different places. None of that’ll sell a browser in a splashy product demo. All of it saves people time later.
Browser projects run on the unglamorous stuff first. If the plumbing breaks, the shiny feature everyone remembers tends to fall apart with it.
That kind of work can be easier to appreciate from the outside than it’s to justify inside a large company. Yang suggested that plenty of Google Chromium engineers would happily spend more time on maintenance and cleanup if the work were rewarded, or at least protected from the usual churn of feature pressure. The appetite, in other words, may already be there. The calendar just keeps getting in the way.
The Chromium community itself came off as unusually calm for a project with this many moving parts. Yang described it as friendly and inclusive, with former coworkers still reviewing one another’s patches and leaving comments even after they had moved to different employers. That sort of continuity is easier to maintain when the code is public and the norms are well documented. Chromium’s own contributing guide lays out the basics of how outside contributors are expected to work, and that matters more than it sounds like it should. In a large browser project, process is half the social contract.
An open-source project also tends to survive on habits people build around each other. A Chromium open-source transcript makes the same basic point from another angle: the code may be public, but the day-to-day rhythm depends on whether people are willing to read patches carefully, answer questions without acting like gatekeepers, and keep the discussion focused on the code instead of on status. That kind of culture does not magically appear. It gets reinforced over time, one review at a time.
The career piece matters too. At Google, promotion pressure can hang over even routine work like a bad fluorescent light. Yang contrasted that with Igalia’s model, where everyone is paid the same and advancement isn’t the main organizing principle. That changes the temperature of the room. You’re still doing hard work, but you’re not trying to turn every task into evidence for a level-up packet. For people who spend their days in browser development, that can be a relief, especially when the job is mostly about fixing something that should’ve been fixed years ago.
That doesn’t make the work less demanding. If anything, it can make it harder in a quiet way, because there’s less obvious reward attached to a boring but necessary fix. Yet those fixes are often what keep Chromium usable across the wider web, and they’re exactly the sort of work an employee-owned cooperative can choose to value without having to dress it up. The backlog does too and the browser starts looking a lot less like a product race and a lot more like a long-running maintenance job with a very public audience, when the incentives change.
Who really steers Chromium?
By the time the talk got to governance, the comparison between Google and Igalia had stopped being a curiosity and started looking like the whole story. Igalia keeps its structure intentionally flat. There are no managers in the usual corporate sense, and teams are organized around projects like Chromium and Linux rather than around layers of supervision. That sounds tidy on a slide. In practice, it changes who gets to weigh in on the boring stuff that turns out to matter a lot.
Open-source software can share code without sharing power.
At Igalia, employees vote on questions most big-company engineers never get near: how many people to hire, how vacation policy should work, and whether the company should take on new work at all. The stakes feel different, because the people voting are also the people living with the result. A layoff isn’t just a line item decided somewhere above your head. Compensation isn’t a mystery box handed down by HR and management layers. Trust has to be built in plain sight, or it starts to wobble.
That setup has tradeoffs, of course. Speed is not one of the perks. Major votes can take a long time, with meetings stretching over two days because the company has to make room for European time zones. If you’ve ever watched a group try to settle a policy question by committee, you can probably hear the clock ticking already. Still, the slowness seems to buy something Google can’t quite replicate: a sense that the rules weren’t written by a distant office and then dropped on everyone else.
Yang also pointed out that equal pay and the lack of promotions remove a whole category of anxiety. That matters more than it may sound at first. For women in particular, and for workers on visas, the usual corporate ladder can come with extra pressure, extra guessing and extra risk. People who are already more exposed to bias can feel that burden more sharply, if advancement depends on pleasing managers and surviving opaque review cycles. Igalia’s model doesn’t erase inequality in the wider world, but it does strip away some of the machinery that tends to magnify it inside a company.
In the Q&A, she said project direction can come from client engineers when a job is tied to a customer’s needs, or from Igalia’s own team when the work is more open-ended. That flexibility sounds straightforward until you ask how it scales. Yang raised that question herself. Makes sense. A flat company can work cleanly when it’s a few dozen people or even a couple hundred. Push it much past that, and the meetings, votes and informal consensus may start to creak.
That’s where the Chromium story lands. The code’s open, and plenty of people can build on it. But access, priorities, and day-to-day authority still run through companies, budgets and voting rights. Google and Igalia both ship work into the same repository, yet they make decisions through very different systems. The browser may be shared. And the power around it? That’s still political.
