![\"[Sharon](\"https://static.lwn.net/images/2026/fossy-yang-sm.png\" "\\"Sharon")
\nLWN.net needs you!
\nWithout subscribers, LWN would simply not exist. Please consider\nsigning up for a subscription and helping\nto keep LWN publishing.
By Jake Edge
\nSeptember 30, 2026
Sharon Yang is a Chromium developer who worked at Google on the browser\nand now works on it at Igalia. On the final day of FOSSY 2026, she gave a\npresentation on her experiences with both of those companies, comparing and\ncontrasting the ways each one operates and how that affects work on the\ncode base. She enjoyed working at Google and feels the same about Igalia,\nso the talk was not aimed at complaints—instead it was meant to give a feel\nfor two companies that are rather different.
\n
The talk was entitled "From Corporate to Co-op" highlighting one of the\nmain differences between the enormous company, Google, and the\nemployee-owned cooperative at Igalia. She is from Vancouver and went to\nthe University of British Columbia, where FOSSY was held. While she was a\nstudent, she did an internship at Google, working on the Chrome browser,\nwhich is the Google product based on Chromium.\nIn her slides,\nshe showed a photo of herself—complete with propeller hat—in front of a\nGoogle sign.
\nWhen she was a student, her life was measured in semesters, but some of the\npeople she worked with at Google had been working on Chrome for four years,\nwhich was amazing to her at the time. She ended up working at Google\nfull-time for six years, all of it on Chrome. Most of her work was on the\ncontent layer of the browser, which is part of the open-source Chromium\nbrowser. So she works in the same\nrepository (GitHub mirror), and with many of the same people, at Igalia as she did at\nGoogle. She briefly reflected on her time at Google: ""I had a good time\nworking on Chrome, the people were nice, I enjoyed it, it was cool, there\nwas lunch, it was good stuff"", she said to laughter.
\nEventually, she thought it might be time to move on, and perhaps out of the\nSeattle area where she was living, so she started looking around at the end\nof 2024. She had seen Igalia email addresses in the code base and met some\nof the people from the company at the BlinkOn conferences. Igalia is an\nopen-source consulting company that is hired to work on various things,\nincluding Chromium; it is the largest contributor to Chromium that is not a\nbrowser maker, in fact. She joined Igalia and moved back to Canada a\nlittle less than a year before the talk in August.
\nShe contrasted the two companies, starting with the number of employees:\nGoogle has around 180,000, while Igalia has around 180. In terms of\nrevenue, last year Google had more than $400 billion, ""Igalia, much\nsmaller, we'll just say under a billion dollars"", which was greeted\nwith laughter. Google is owned by institutional investors, while Igalia is\nowned by employees, which the audience applauded. Google has a wide range\nof compensation, from the CEO's $600 million salary package to her pay\n(somewhere in the range of\n$100,000-$300,000) when she worked there; at Igalia, all employees are paid\nthe same, top to bottom and across the globe.
\nWhile they are ""massively different entities"", both companies have teams\nworking on things in common; she works on Chromium, but there are also\nteams from each working on accessibility and on web standards.
\nChrome and Chromium are ""kind of the same, they're kind of not"".\nChrome is a Google product, with Google branding and colors, while Chromium\nis an open-source project that anyone can use to build a browser. Chromium\nis missing proprietary pieces like digital rights management (DRM), ""AI\nintegration"", and certain codecs; ""and it's blue"". There are\nvarious other browsers based on Chromium, including Microsoft Edge and\nBrave, as well.
\nMost of the Google Chrome team members do most or all of their work in the\nChromium repository. Obviously, the proprietary pieces are handled\nelsewhere, but she and other Google Chrome developers rarely have to\ninteract with that code. Near the end of her time at Google, she had to\nget help to do a simple task that required access to the ""totally different\nuniverse"" where the proprietary parts live.
\nShe then compared the experience of working for the two companies. The\nfirst week is pretty much the same at any new job, she said. The initial\nsteps are getting to know your coworkers, reading internal documentation,\nlearning how to communicate internally, and so on. Igalia has a whole set\nof open-source tools that it uses, which is nice.
\nThere are some differences, as well. For example, there is a system for\ndoing faster builds of Chromium, ""otherwise you'll just spend all your\ntime building Chromium"". That system is immediately available to\nGoogle employees, but external users have to request access to it. A\nbigger area of friction is access to bug reports, which are meant to be\nopen to everyone unless they are security bugs. Due to a bug-tracker\nmigration a few years ago, though, there are bugs that should be\nvisible to outsiders, but are only visible to Google employees. ""It is\nnot a malicious thing"", and it is easy enough to get the access\nfixed, but it is something extra she has to do once a week or so.
\nThere is other information that could be more readily available to the\npublic, but is not because it is stored in Google Docs without being\nshared. Ensuring that the public has access ""is a best-effort thing and\npeople forget"", which is unfortunate. In addition, all of the tools\nfor tasks like bug tracking are maintained by Google and, essentially, for\nGoogle, so outsiders have no way to provide feedback or request features and\nchanges. They are ""relatively minor points of friction"" but they\nare enough to feel that ""I am now separate from this"".
\nAfter a month in her new job, she started to see even more similarities\nwith her previous one. The team members are all still available via the same\ncommunication channels (e.g. Slack), and she is likewise available to them.\nSome of the work that Igalia does comes directly or indirectly from Google;\nshe is working a Chromium project that comes through the Linux Foundation,\nwhich Google is a member of. ""I'm working on the same repository, I'm\nusing the same tools, I'm getting money from Google, what's changed here?""
\nThe answer it seems is ""kind of everything and kind of nothing"".\nThe types of projects are different at Igalia, though. At Google, she\nworked on the projects that were important to the people in her management\nchain; those are often new features or ""a flashy metric that they want\nto improve"". They are often aimed at getting promotions for the\nengineers and those in the reporting chain.
\nThe projects handed to Igalia to work on come directly from the technical\nstaff, so they tend to be ""code-health or tech-debt kind of\nprojects"". For example, Igalia worked on componentizing the Chromium\ncode base and its current project is ""improving web-platform-test\ninteroperability between browsers"". It is important work that is good\nto do, but ""it is just so hard to imagine anyone at Google doing it for\ntheir day job""; it is ""not the kind of work that gets prioritized or\nrewarded"". Many of the people that she worked with on Chromium at\nGoogle would love to be able to do that work. ""These are people who care\nabout the code base, they want it to be good, but there's just no room in\ntheir day job to do that, which is too bad.""
\nShe was initially attracted to the Chrome team because all of the people on\nit seemed to be welcoming. That remained true throughout\nher tenure at Google and has continued into her work at Igalia. ""People\nwho work on Chromium have just generally been friendly and inclusive in all\ndomains, which is good, and is not to be taken for granted."" She has\nbeen able to maintain relationships with her former coworkers, review their\npatches, leave comments on work that they have in common, and so on.\n""It's a nicer experience than sending a code review to some stranger.""
\nShe put up a slide of an organization chart from a typical company, with\nher picture in a leaf node as the only filled-in box. In a chart like\nthat, the engineer is at the bottom of the hierarchy; they have a manager,\nwho has a more senior manager, and so on. An engineer is concerned with\ntechnical decisions, such as which language to use or how to test the code\nbeing written, while at the top, they are deciding things like company\ndirection and vision. The people in the middle are doing some technical\nwork, but it is often not entirely clear what it is that they do; ""who\nknows?"", she said to laughter. ""The people at the top are\npaid a lot more than the people at the bottom.""
\nAt Igalia, things are quite different. The ""org chart is intentionally\nflat"" and there are no managers. There are various teams, such as the\nChromium team that she is on, a Linux kernel team, and more. The flat\nhierarchy means that ""all of the employees do a lot of work that you\ntypically wouldn't do as a leaf-node employee at a big company"", which\nincludes making company decisions, such as which projects to take on,\nwhether to increase headcount, and how much vacation time there is.
\nIgalia is\na cooperative, so votes are taken on those kinds of questions. ""These\nare not decisions you have any influence at all over at a big company.""\nOne of the nice things about that arrangement is that the people who are\nmaking the decision are the ones who are affected by it, which is ""just\nnot the case at a standard company"". The most obvious\nexample for that is layoffs, Yang said.
\nThere is a cost to doing things that way, of course. The meetings for\nthose decisions are lengthy and run for two days—in a European time zone.\nWhen she was at Google, she was in the dominant time zone (US Pacific), and\nher teammates elsewhere had to have meetings at weird times, so this feels\na bit like karma for her, she said. But that is a ""minor price to\npay"" for a structure that is ""so fundamentally different and feels good"".
\nIt took her a while to fully recognize just how different Igalia's\nstructure is; the impacts of it did not sink in right away. The biggest\nimpact for her was promotions, which do not exist in a flat organization\nwhere everyone is paid the same amount. When she was a new graduate,\npromotion was her focus because it is expected of new hires; ""Meta\nliterally fires you if you don't reach a certain level in a certain time"".
\nTrying to ensure that she was working on the right projects and\n""demonstrating the right skills"" in order to be promoted was\nstressful and took a lot of effort. Much of it is out of the engineer's\nhands and is up to their manager. She was lucky and had a great manager at\nGoogle, but even if they are good, they have multiple people reporting to\nthem. ""For you, it's like your whole professional life, but for them\nit's one of the million things that they have to do.""
\nThe flat pay structure is also a welcome change—there are no pay\ndiscrepancies. As a woman and someone who was formerly working on a visa,\n""these are very real concerns you have, and now that's just all\ngone"". Everyone is on the same level playing field, which leads to\nmore trust and collaboration.\n""If that sounds fun, go join or start a coop"", she said to applause.\nThat was the end of her prepared talk, but\nshe had plenty of time for questions, which were numerous, perhaps\nunsurprisingly.
\nThe first was about where direction came from in a flat structure; how are\ndecisions made about what she should work on? That depends on the project,\nYang said, some are closely aligned with the engineers at the client\ncompany, while other projects are less hands-on. When working with the\nclient's engineers, the direction likely comes from the client side as in a\nmore typical organization. Sometimes projects are more open-ended, where\nthe client agrees to pay for work on a specific task for, say, a year to see\nwhere things end up; in that case, the Igalia team decides on what to tackle.
\nAnother attendee wondered what it was that Igalia's clients needed done\nwith Chromium. Once again, it varies, she said. Her project is cleaning\nup the testing, which is something that Google wants and it does not fit\nanywhere in its team. Other clients want customized browsers for internal\nuse, so parts of the Igalia Chromium team are also working on downstream projects.
\nThe hiring process was up next. One attendee wondered how Igalia decided\nthat it needed to hire for a position and how the person to hire was\nchosen. ""Which teams get headcount is decided at a company level"",\nshe said, so if the Chromium team wants to hire, it makes a pitch to the\nassembly, which is the voting body. If that is approved, the team will\ninterview candidates and choose who it thinks should be hired, which goes\nback to the assembly. Normally, that choice will be approved unless there\nis some red flag that someone elsewhere in the company is aware of. Yang\nreminded attendees that she was still fairly new at Igalia, but that there\nwere other employees sitting in on the talk who might chime in to help\nclarify things; in this case she just got a thumbs up from them, she said.
\nHaving 180 employees in a flat structure already sounds a bit unwieldy, an\nattendee noted, is there a size where Igalia will essentially be forced\ninto a hierarchical structure just because of its size? Yang said that she\nasked the same thing when she was interviewing, ""everyone agreed that\nthis is definitely an issue but there's not a clear solution yet"".\nHer partner suggested that honeybees might provide a reasonable model of\nhow a split could be done; when a hive gets too big, part of the hive\nleaves as a swarm to\nfound a new hive.
\nAn employee at another employee-owned coop suggested that there were\nsynergies between open source and cooperatives, which might help when the\ntime comes to split up. He wondered if there were plans for Igalia to\nrelease its internal tools and coop-operating documents as open source,\nwhich could facilitate a new, separate company if that was needed. Yang\nnoted that her coworker Danielle Mayabb had a session in the next\nslot about running the company using FOSS tools.
\nA researcher who studied companies with flat structures asked whether some\nof the organizational structure came back into the picture within the\ndifferent teams. The teams are responsible for decisions like whether to\ntake a project or not, Yang said, and there are product managers that\ncoordinate between teams. The product managers work closely with clients,\nbut they have no inherent extra power, like a manager at a typical job.
\nAlong the way, she had said that she was not yet part of the assembly, so\nan attendee asked how that worked, how long it took, whether a vote was\nneeded, and so on. Yang recommended the video\nof a talk\nby Valerie Young at the first FOSSY in 2023, which goes into more detail.\nYang said that somewhere around the one-year mark it\nwould be decided whether an employee would join the assembly, though she\ndid not specify exactly how that was done. ""If you've done an\nexceptionally bad job, you won't be permitted in.""
\nThat was a good segue to the next question, which was about what would prevent\nan employee in the coop from just ceasing to work. In a flat hierarchy,\nwho is monitoring what employees are doing? Can someone just stop working\nwithout detection? She joked that she would give it a try and come back\nnext year with a talk on that. More seriously, there are people who are\nproviding feedback on the performance of their coworkers; each person has a\nmentor in the company who fills some of the roles of a manager at other\ncompanies, including gathering assessments of the work that is being\ndone. ""People are monitoring your performance and it is a collection of\nall of the people that you work with.""
\nAn attendee noted that there is a saying in the coop movement: ""If you've\nseen one coop, you've seen one coop."" That is why it is so helpful for\ncoops to share their internal structure; as with open-source software,\nother coops can learn from the trial and error that went into forming the\ncoop. Yang noted that there used to be a coop track at FOSSY and that there\nwas talk of bringing it back for next year.
\n[I would like to thank the Linux Foundation, LWN's travel sponsor, for its\nassistance with my trip to Vancouver for FOSSY.]
\n