[+] Proceed to the article
Sharon Yang is a Chromium developer who worked at Google on the browser
and now works on it at Igalia. On the final day of FOSSY 2026, she gave a
presentation on her experiences with both of those companies, comparing and
contrasting the ways the each operates and how that affects work on the
code base. She enjoyed working at Google and feels the same about Igalia,
so the talk was not aimed at complaints—instead it was meant to give a feel
for two companies that are rather different.
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 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.]
Did you like this article?? Subscribe now at the special discounted rate to get a lot more like it.