Comparing Chromium Development at Google and Igalia

The talk was entitled "From Corporate to Co-op" highlighting one of the main differences between the enormous company, Google, and the employee-owned cooperative at Igalia. She is from Vancouver and went to the University of British Columbia, where FOSSY was held. While she was a student, she did an internship at Google, working on the Chrome browser, which is the Google product based on Chromium. In her slides, she showed a photo of herself—complete with propeller hat—in front of a Google sign.

When she was a student, her life was measured in semesters, but some of the people she worked with at Google had been working on Chrome for four years, which was amazing to her at the time. She ended up working at Google full-time for six years, all of it on Chrome. Most of her work was on the content layer of the browser, which is part of the open-source Chromium browser. So she works in the same repository (GitHub mirror), and with many of the same people, at Igalia as she did at Google. She briefly reflected on her time at Google: ""I had a good time working on Chrome, the people were nice, I enjoyed it, it was cool, there was lunch, it was good stuff"", she said to laughter.

Eventually, she thought it might be time to move on, and perhaps out of the Seattle area where she was living, so she started looking around at the end of 2024. She had seen Igalia email addresses in the code base and met some of the people from the company at the BlinkOn conferences. Igalia is an open-source consulting company that is hired to work on various things, including Chromium; it is the largest contributor to Chromium that is not a browser maker, in fact. She joined Igalia and moved back to Canada a little less than a year before the talk in August.

Contrasts

She contrasted the two companies, starting with the number of employees: Google has around 180,000, while Igalia has around 180. In terms of revenue, last year Google had more than $400 billion, ""Igalia, much smaller, we'll just say under a billion dollars"", which was greeted with laughter. Google is owned by institutional investors, while Igalia is owned by employees, which the audience applauded. Google has a wide range of compensation, from the CEO's $600 million salary package to her pay (somewhere in the range of $100,000-$300,000) when she worked there; at Igalia, all employees are paid the same, top to bottom and across the globe.

While they are ""massively different entities"", both companies have teams working on things in common; she works on Chromium, but there are also teams from each working on accessibility and on web standards.

Chrome and Chromium are ""kind of the same, they're kind of not"". Chrome is a Google product, with Google branding and colors, while Chromium is an open-source project that anyone can use to build a browser. Chromium is missing proprietary pieces like digital rights management (DRM), ""AI integration"", and certain codecs; ""and it's blue"". There are various other browsers based on Chromium, including Microsoft Edge and Brave, as well.

Most of the Google Chrome team members do most or all of their work in the Chromium repository. Obviously, the proprietary pieces are handled elsewhere, but she and other Google Chrome developers rarely have to interact with that code. Near the end of her time at Google, she had to get help to do a simple task that required access to the ""totally different universe"" where the proprietary parts live.

She then compared the experience of working for the two companies. The first week is pretty much the same at any new job, she said. The initial steps are getting to know your coworkers, reading internal documentation, learning how to communicate internally, and so on. Igalia has a whole set of open-source tools that it uses, which is nice.

There are some differences, as well. For example, there is a system for doing faster builds of Chromium, ""otherwise you'll just spend all your time building Chromium"". That system is immediately available to Google employees, but external users have to request access to it. A bigger area of friction is access to bug reports, which are meant to be open to everyone unless they are security bugs. Due to a bug-tracker migration a few years ago, though, there are bugs that should be visible to outsiders, but are only visible to Google employees. ""It is not a malicious thing"", and it is easy enough to get the access fixed, but it is something extra she has to do once a week or so.

There is other information that could be more readily available to the public, but is not because it is stored in Google Docs without being shared. Ensuring that the public has access ""is a best-effort thing and people forget"", which is unfortunate. In addition, all of the tools for tasks like bug tracking are maintained by Google and, essentially, for Google, so outsiders have no way to provide feedback or request features and changes. They are ""relatively minor points of friction"" but they are enough to feel that ""I am now separate from this"".

After a month in her new job, she started to see even more similarities with her previous one. The team members are all still available via the same communication channels (e.g. Slack), and she is likewise available to them. Some of the work that Igalia does comes directly or indirectly from Google; she is working a Chromium project that comes through the Linux Foundation, which Google is a member of. ""I'm working on the same repository, I'm using the same tools, I'm getting money from Google, what's changed here?""

Projects

The answer it seems is ""kind of everything and kind of nothing"". The types of projects are different at Igalia, though. At Google, she worked on the projects that were important to the people in her management chain; those are often new features or ""a flashy metric that they want to improve"". They are often aimed at getting promotions for the engineers and those in the reporting chain.

The projects handed to Igalia to work on come directly from the technical staff, so they tend to be ""code-health or tech-debt kind of projects"". For example, Igalia worked on componentizing the Chromium code base and its current project is ""improving web-platform-test interoperability between browsers"". It is important work that is good to do, but ""it is just so hard to imagine anyone at Google doing it for their day job""; it is ""not the kind of work that gets prioritized or rewarded"". Many of the people that she worked with on Chromium at Google would love to be able to do that work. ""These are people who care about the code base, they want it to be good, but there's just no room in their day job to do that, which is too bad.""

She was initially attracted to the Chrome team because all of the people on it seemed to be welcoming. That remained true throughout her tenure at Google and has continued into her work at Igalia. ""People who work on Chromium have just generally been friendly and inclusive in all domains, which is good, and is not to be taken for granted."" She has been able to maintain relationships with her former coworkers, review their patches, leave comments on work that they have in common, and so on. ""It's a nicer experience than sending a code review to some stranger.""

Hierarchy

She put up a slide of an organization chart from a typical company, with her picture in a leaf node as the only filled-in box. In a chart like that, the engineer is at the bottom of the hierarchy; they have a manager, who has a more senior manager, and so on. An engineer is concerned with technical decisions, such as which language to use or how to test the code being written, while at the top, they are deciding things like company direction and vision. The people in the middle are doing some technical work, but it is often not entirely clear what it is that they do; ""who knows?"", she said to laughter. ""The people at the top are paid a lot more than the people at the bottom.""

At Igalia, things are quite different. The ""org chart is intentionally flat"" and there are no managers. There are various teams, such as the Chromium team that she is on, a Linux kernel team, and more. The flat hierarchy means that ""all of the employees do a lot of work that you typically wouldn't do as a leaf-node employee at a big company"", which includes making company decisions, such as which projects to take on, whether to increase headcount, and how much vacation time there is.

Igalia is a cooperative, so votes are taken on those kinds of questions. ""These are not decisions you have any influence at all over at a big company."" One of the nice things about that arrangement is that the people who are making the decision are the ones who are affected by it, which is ""just not the case at a standard company"". The most obvious example for that is layoffs, Yang said.

There is a cost to doing things that way, of course. The meetings for those decisions are lengthy and run for two days—in a European time zone. When she was at Google, she was in the dominant time zone (US Pacific), and her teammates elsewhere had to have meetings at weird times, so this feels a bit like karma for her, she said. But that is a ""minor price to pay"" for a structure that is ""so fundamentally different and feels good"".

It took her a while to fully recognize just how different Igalia's structure is; the impacts of it did not sink in right away. The biggest impact for her was promotions, which do not exist in a flat organization where everyone is paid the same amount. When she was a new graduate, promotion was her focus because it is expected of new hires; ""Meta literally fires you if you don't reach a certain level in a certain time"".

Trying to ensure that she was working on the right projects and ""demonstrating the right skills"" in order to be promoted was stressful and took a lot of effort. Much of it is out of the engineer's hands and is up to their manager. She was lucky and had a great manager at Google, but even if they are good, they have multiple people reporting to them. ""For you, it's like your whole professional life, but for them it's one of the million things that they have to do.""

The flat pay structure is also a welcome change—there are no pay discrepancies. As a woman and someone who was formerly working on a visa, ""these are very real concerns you have, and now that's just all gone"". Everyone is on the same level playing field, which leads to more trust and collaboration. ""If that sounds fun, go join or start a coop"", she said to applause. That was the end of her prepared talk, but she had plenty of time for questions, which were numerous, perhaps unsurprisingly.

Q&A

The first was about where direction came from in a flat structure; how are decisions made about what she should work on? That depends on the project, Yang said, some are closely aligned with the engineers at the client company, while other projects are less hands-on. When working with the client's engineers, the direction likely comes from the client side as in a more typical organization. Sometimes projects are more open-ended, where the client agrees to pay for work on a specific task for, say, a year to see where things end up; in that case, the Igalia team decides on what to tackle.

Another attendee wondered what it was that Igalia's clients needed done with Chromium. Once again, it varies, she said. Her project is cleaning up the testing, which is something that Google wants and it does not fit anywhere in its team. Other clients want customized browsers for internal use, so parts of the Igalia Chromium team are also working on downstream projects.

The hiring process was up next. One attendee wondered how Igalia decided that it needed to hire for a position and how the person to hire was chosen. ""Which teams get headcount is decided at a company level"", she said, so if the Chromium team wants to hire, it makes a pitch to the assembly, which is the voting body. If that is approved, the team will interview candidates and choose who it thinks should be hired, which goes back to the assembly. Normally, that choice will be approved unless there is some red flag that someone elsewhere in the company is aware of. Yang reminded attendees that she was still fairly new at Igalia, but that there were other employees sitting in on the talk who might chime in to help clarify things; in this case she just got a thumbs up from them, she said.

Having 180 employees in a flat structure already sounds a bit unwieldy, an attendee noted, is there a size where Igalia will essentially be forced into a hierarchical structure just because of its size? Yang said that she asked the same thing when she was interviewing, ""everyone agreed that this is definitely an issue but there's not a clear solution yet"". Her partner suggested that honeybees might provide a reasonable model of how a split could be done; when a hive gets too big, part of the hive leaves as a swarm to found a new hive.

An employee at another employee-owned coop suggested that there were synergies between open source and cooperatives, which might help when the time comes to split up. He wondered if there were plans for Igalia to release its internal tools and coop-operating documents as open source, which could facilitate a new, separate company if that was needed. Yang noted that her coworker Danielle Mayabb had a session in the next slot about running the company using FOSS tools.

A researcher who studied companies with flat structures asked whether some of the organizational structure came back into the picture within the different teams. The teams are responsible for decisions like whether to take a project or not, Yang said, and there are product managers that coordinate between teams. The product managers work closely with clients, but they have no inherent extra power, like a manager at a typical job.

Along the way, she had said that she was not yet part of the assembly, so an attendee asked how that worked, how long it took, whether a vote was needed, and so on. Yang recommended the video of a talk by Valerie Young at the first FOSSY in 2023, which goes into more detail. Yang said that somewhere around the one-year mark it would be decided whether an employee would join the assembly, though she did not specify exactly how that was done. ""If you've done an exceptionally bad job, you won't be permitted in.""

That was a good segue to the next question, which was about what would prevent an employee in the coop from just ceasing to work. In a flat hierarchy, who is monitoring what employees are doing? Can someone just stop working without detection? She joked that she would give it a try and come back next year with a talk on that. More seriously, there are people who are providing feedback on the performance of their coworkers; each person has a mentor in the company who fills some of the roles of a manager at other companies, including gathering assessments of the work that is being done. ""People are monitoring your performance and it is a collection of all of the people that you work with.""

An attendee noted that there is a saying in the coop movement: ""If you've seen one coop, you've seen one coop."" That is why it is so helpful for coops to share their internal structure; as with open-source software, other coops can learn from the trial and error that went into forming the coop. Yang noted that there used to be a coop track at FOSSY and that there was talk of bringing it back for next year.

[I would like to thank the Linux Foundation, LWN's travel sponsor, for its assistance with my trip to Vancouver for FOSSY.]

---