src/docs/transcripts/wuwt-e06-open-source.md

# What’s Up With Open Source

This is a transcript of [What's Up With
That](https://www.youtube.com/playlist?list=PL9ioqAuyl6ULIdZQys3fwRxi3G3ns39Hq)
Episode 6, a 2023 video discussion between [Sharon (yangsharon@chromium.org)
and Elly
(ellyjones@chromium.org)](https://www.youtube.com/watch?v=zOr64ee7FV4).

The transcript was automatically generated by speech-to-text software. It may
contain minor errors.

---

What does it mean for Chrome to be open source? What exactly is Chromium? Can
anyone contribute to the browser? Answering all that is today's special guest,
Elly. She worked all over Chrome and ChromeOS, and is passionate about
accessibility, the open web, and free and open-source software.

Notes:
- https://docs.google.com/document/d/1a6sdrspJgAHDdQMMNGV0t7zo8QWgqq0hgsyV55tc_dk/edit

Links:
- [What's Up With BUILD.gn](https://www.youtube.com/watch?v=NcvJG3MqquQ)
- [What's Up With //content](https://www.youtube.com/watch?v=SD3cjzZl25I)
- [What are Blink Intents?](https://www.youtube.com/watch?v=9cvzZ5J_DTg)

---

00:00 SHARON: Hello, and welcome to "What's Up With That?" the series that
demystifies all things Chrome. I'm your host, Sharon. And today, we're talking
about open source. What does it mean to be open source? I've heard of Chrome,
but what's Chromium? What are all the ways you can get involved? Answering
those questions and more is today's special guest, Elly. Elly currently works
on the Chrome content team, which is focused on making the web more fun and
interesting to use. Previously, she's worked all over Chrome and Chrome OS.
She's passionate about accessibility, the open web, and free and open-source
software. Welcome, Elly.

00:34 ELLY: Thank you, Sharon.

00:34 SHARON: All right. First question I think is pretty obvious. What is open
source? What does that mean?

00:40 ELLY: Yeah, so open source is a pretty old idea. And it basically just
means, in the purist sense, that the source code for a program is open to be
read by others.

00:51 SHARON: OK. And Chrome, the source code is available to be read by
anyone. What else is it? Open source - I've heard of open-source community. It
seems like there's a lot to it. So why don't you just tell us more about open
source, generally?

01:03 ELLY: Yeah, for sure. There's quite a bit of nuance here. And there's
been differing historical interpretations of some of these terms, so I'll -
there's two big camps that are important to talk about. One is open source,
which means what I said - the source is available to be viewed. There's also
the idea of free software, which is software that actually has license terms
that allow for people to modify it, to make their own derivative versions of
it, and that kind of thing. And so historically, there was a pretty big
difference between those things. These days, the two concepts are often talked
about pretty interchangeably because a lot of open-source projects are free
software, and all free software projects basically are open source. But the
distinction used to be very important and is still pretty important, I guess.
Chromium is both open source and free software. So we ship under a license that
allows for - not only for everyone to read and look at our code, but also for
other folks to make their own versions of Chromium. So, yeah, Chromium, both
open source and free software.

01:56 SHARON: OK, very cool. And you mentioned Chromium in there. But I think
for most people, when they think of the browser, they call it Chrome. So what
is the difference between Chrome and Chromium? Are they the same thing? I think
people, myself included, sometimes use those interchangeably, especially when
you work on it. So what is the difference there?

02:16 ELLY: Yeah, fantastic question. So Chromium is an open-source and free
software web browser that is made by the Chromium Foundation, which is like an
actual .org that exists somewhere on the internet. Chrome is a Google-branded
web browser that is basically made by taking Chromium, which is an open-source
and free software web browser, adding some kind of Google magic to it, like
integrations with some Google services, some kind of media codecs that maybe
aren't themselves free software, that kind of thing, bundling that up into a
more polished product which we call Google Chrome, and then shipping that as a
web browser. So Chromium is an open-source project. Google Chrome is a Google
product that is built on top of Chromium.

03:03 SHARON: OK. So Google Chrome is a Chromium-based browser, which is a term
I think that people who work in any browser stuff - it's a term that they've
all [INAUDIBLE] before.

03:08 ELLY: Yeah, exactly. And in fact, you alluded to the fact that we
sometimes use those terms interchangeably. And especially at Google, we
sometimes get a little confused about what we're talking about sometimes
because we're - the Google Chrome team are the biggest contributors to
Chromium, the open-source project. And so we tend to sometimes talk about the
two things as though they're the same. But there's a really important
difference for folks who are working on other Chromium-derived browsers. So if
you're working on a Chromium derivative that a Linux distribution ships, for
example, your browser is based on Chromium, and it's really not Chrome. It's
Chromium, right? It is the open-source browser that Chrome is based on. But
it's not the same thing at all.

03:52 SHARON: Yeah, if you want to learn a bit more about basing things on
Chromium, the content episode is a good one to check out. We talk a bit about
that and embedding Chrome in Chromium and what that means. So -

04:03 ELLY: Yeah, absolutely.

04:03 SHARON: check it out if you [INAUDIBLE]...

04:03 ELLY: And there's also, in the Chromium source tree, there's actually a
thing called Content Shell, which is a minimal demonstration browser. It's like
the rendering engine from Chromium wrapped in the least amount of browser
possible to make it work. And we use it for testing, but it's also a really
good starting point if you're trying to learn how to build a Chromium
derivative browser.

04:22 SHARON: OK, very neat. So I think a next very natural question to come
out of this is, why is Chrome or Chromium - Chromium rather - going to try to
be good about using those correctly here - but why is Chromium open source?

04:40 ELLY: Yeah, so this is the decision that we made right when we were
starting the project actually. And it's based on this really fundamental idea
that the web benefits when users have better browsers. So if we, like the
Chromium project, come up with some super clever way of doing something, or we
come up with some really ingenious optimization to our JavaScript Engine or
something like that, it's better for the web, better for everyone, and
ultimately even better for Google as a business if those improvements are
actually adopted by other people and taken by other people and used by them. So
it is better for us if other people make use of anything clever that we do. And
separately from that, there's this idea that's really prevalent in open-source
communities of, if people can read the code, they're more likely to find bugs
in it. And that's something that Chromium constantly benefits from, is folks
who are outside the project, just kind of looking through our code base,
reading and understanding it, spotting maybe security flaws that are in there.
That kind of research is so much easier to do when the source code is just
there, and you're not trying to reverse-engineer something you can't see the
source to. So we get a lot of benefit from being open-source like that. And
those are the reasons we had originally, and those still all hold totally true
today, I think.

05:51 SHARON: That makes sense. Yeah, it seems, at first, a bit odd for a big
company like Google to make something like this open source. But there are
other massive open-source things at Google - Android, I think, being the other
canonical example, which we don't know too much about, but we won't be getting
too into that. But there are other big open-source projects around.

06:08 ELLY: Yeah, absolutely. And there's also, like - there's Go. That's an
open-source programming environment, like a language and a compiler and a bunch
of tools around it that is open source built by Google. There are plenty of
other open-source and free software projects built by large corporations, often
for really the same reasons. We benefit because the entire web benefits from
better technology.

06:32 SHARON: Yeah, I think some of the Build stuff we do is open source. Check
out the previous episode for that. And that's, yeah, exactly - not strictly
only used by -

06:37 ELLY: Yeah, and by the way, partly because we're open source - like, for
example, the Chromium base library, which is part of our C++ software
environment - our base library is regularly used in other projects, even things
that are totally unrelated to browsers, because it provides a high-quality
implementation of a lot of basic things that you need to do. And so that code
is being used in so many places we would never have anticipated and has done
honestly more good in the world than it would do if it was just part of a
really excellent browser.

07:13 SHARON: Something that someone on my first team told me was, if you've
changed anything in base, that probably is going to get run any time the
internet gets run, somewhere in that stack, which, if you think about it, is so
crazy.

07:26 ELLY: Oh, Yeah. Absolutely. Early in my career, I added a particular
error message to part of the Chrome network stack. And that network stack, too,
is one of those components that gets reused in a lot of places. And so
occasionally, I'll be running some completely other program. Like, I'll be
running a video game or something, and I'll see that error message that I added
being emitted from this program. And I'm like, oh, my code is living on in a
place I would never have really thought of.

07:51 SHARON: Oh, that's very cool.

07:51 ELLY: Yeah.

07:51 SHARON: Yeah.

07:51 ELLY: It's one of those unique open-source experiences in my book, of
seeing your own work being used like that by other folks you wouldn't have
anticipated.

07:57 SHARON: Yeah, that's very cool. So something I think I've heard you say
before that I thought sounded very cool was the open-source dream. So can you
tell us a bit more about what that is. What is that vision? It sounds very
nice.

08:09 ELLY: Yeah, so I talked about this a little bit. And earlier, I cautioned
against conflating open-source and free software. But it really is more of the
free software dream than the open-source dream, in some sense. That dream is
this idea that if we have software that is made available for free, under
licenses that let people modify it and make derivative works and keep using it,
that over time, everyone will get access to really high-quality and
freely-available software. And we will have a situation where the software that
people need is built by their communities, built by the people who are in those
communities, instead of being something that they have to buy from a company
that makes it. It'll be something they can instead produce for themselves. And
over time, I think that this has really played out in that way. If you look at
the state of operating systems today, for example, there are these really
high-quality, freely-available open-source free software operating systems that
are readily available and anyone can use, and they really do meet the needs for
a lot of folks. And then, in fact, it kind of circles back to where Linux is a
high-quality, free software open-source operating system that Google can then
turn around and make really good use of to build something like Chromium OS,
which is another free software open-source project that uses Linux as one of
its major components. And then we get to produce a product that the Chromium OS
engineering team would have had to spend a lot of time if we weren't able to
make use of that existing Linux kernel work. So you get into this cycle of
giving back and sharing and benefiting from the effects of other people
sharing. That's the free software dream to me.

09:57 SHARON: It does - yeah, that sounds great. And for sure - I try to use
open-source options when I can. When I edit these videos, I use something
open-source. It feels appropriate for what we're doing here. So, yeah, that
sounds like it would be - it's a good system that everyone contributes to and
everyone benefits from. And that's really nice.

10:10 ELLY: Yeah, absolutely.

10:16 SHARON: So going away from that towards the more less open-source part,
so what kind of things in Chrome, the browser, are not open source? You
mentioned a couple of things earlier. Can you tell us a bit more about some of
those things?

10:27 ELLY: Yeah, I'm going to caveat this by saying that I don't personally
work on the stuff I'm about to talk about. And so my knowledge is more
superficial. There's a couple things I'm pretty confident about. So one is, for
example, there's a few video formats that Chrome can play that Chromium cannot
play because Google has agreements with the companies that make those codecs
that allow us to basically license and embed their thing and ship it as part of
Chrome. But those agreements, we can't really extend them to everyone who might
make a Chromium browser. And so it ends up in a situation where there is a
closed-source component that's included in Chrome to make that possible. I'm
struggling to think of another example right off the top of my head. I believe
that there's also a couple things in Chrome that are integrating with Google
APIs, where they're features that are Chrome-specific because they're
Google-specific. And one of the things that is generally true between the two
products is that Chrome will have more Google integrations and more Google
magic and more Google smarts than Chromium will. And so I think some of those
are actually closed-source components that come from Google that get embedded
into Chrome. But because they're a closed-source, we wouldn't want to put them
into Chromium.

11:37 SHARON: Right. It seems like, yeah, I can sign into Chrome. I don't
expect that I'd be able to sign in with my gmail.com into, say, Chromium. I'm
not sure it's actually part of it, but that's a guess.

11:49 ELLY: Yeah, so that does work, except that you need to - any Chromium
distributor needs to go and talk to - basically, talk to the sign-in team to
get an API key that allows their browser to sign in. There is a process for
doing that. It doesn't actually require any closed-source code components. But
there is still a thing where you have to talk to the accounts team and
basically be like, hey, we're a legitimate web browser, and we want to allow
users to sign in. Because we don't want a situation where bots or malware are
doing fake user sign-ins from - pretending to be Chromium. That's bad.

12:25 SHARON: Right. That makes sense. Yeah, and I think because of where
Chrome and Chromium are positioned, I think there will be some interesting
comparisons and differences between Chrome, Chromium, and other internal
google3 projects. So that's kind of the term for things that are closed-source
Google - the typical Maps, Search, all that stuff - and also comparing Chromium
to other open-source projects. So we've talked a bit about the similarities and
differences between Chrome and Google internal. Are there any other things you
can think of that are either similar or different between Chrome the project
and the people who work on it and how people do things internally at Google?

13:11 ELLY: Yeah. So internally at Google, there's this very powerful, very
custom-built whole technology stack around the projects. There is a continuous
integration system. There's an editor. There's a source control system. There's
all of this stuff. Within Google, all of that is custom. And it's all fitted to
Google's needs. And a lot of it is just built from scratch, frankly. Whereas
for Chromium, we're using essentially off-the-shelf open-source stuff to meet a
lot of those needs. So, for example, for version control, we're just using Git,
which is I think the most popular version control system in the world right
now. It's definitely open source. And our build system, for example, which is
like GN and Ninja put together, those are both free software open-source
projects. Admittedly, both of them were, I think, started as part of Chromium
because we had those needs. But they, themselves, are free software components
that anyone else can also use to build a Chromium. And the reason why that's
done that way - like, why doesn't - it's actually a really good question. Why
doesn't Chrome, which is a Google project, use all of this amazing
infrastructure for engineering that Google has? And the answer is, we want the
Chromium project to be possible to work on for people who don't work at Google.
And so we can't say, oh, hey, whenever you're going to make a change, you have
to commit it into Google's internal source control system. That wouldn't work
at all. So we're almost - because we want to be an open-source project, and
because we want to have contributors from outside of Google, we end up almost
pushed into using this pretty open free software stack, which I - to be honest,
from my perspective, has a lot of other benefits. When we have new folks
joining the team, we can actually offer them tools they're already pretty
familiar with. They don't have the feeling that new Googlers sometimes get,
where they're totally disoriented. Like, everything they know about programming
doesn't apply anymore. We actually be like, hey, here's Git. You know how to
use this. Here's Gerrit, which is another piece of open-source software that we
use. They may not have used Gerrit before, but a lot of projects do. And so
they might have run into it previously. So it has pluses and minuses,
definitely. So that's a big difference. There's also a bit of what I would say
is a cultural difference more than anything else because most Google projects
that are not open source - so I'm not talking about things like Android or Go
or something like that - but projects that are really just not open source,
like Search, their ecosystem of discussion and culture and stuff is very much
inside Google. Whereas for Chromium, we constantly are getting ideas and
suggestions and code changes and stuff from outside of Google. And so we also
tend to have perspectives from outside of Google in our discussions more often
as we work on Chromium. So part of that is at the level of, if we're going to
make a change, we would have maybe input coming in on that change from Mozilla
even. They're a group we collaborate with a ton on web standards. And so we
would have their perspective in the discussion. Whereas if we were working
entirely within Google, we might not have those external perspectives. So
culture-wise, I feel like Chromium has more perspectives in the room sometimes
when we're thinking about stuff.

16:26 SHARON: That makes sense because browsers exist across other companies
too, and there's a lot of compatibility and standards and stuff. So just in
that nature of things, you have to have a lot more of this collaboration. If
you make a change, it'll affect all of the embedders maybe, and then you have
to think about this. And, yeah, there's a lot more discussion - [INTERPOSING
VOICES]

16:42 ELLY: Yeah, absolutely.

16:42 SHARON: If you're Search, you're like, OK, we're going to, I don't know,
do our thing.

16:47 ELLY: Yeah, you have more - I don't know if "autonomy" is the right word.
But, yeah. I want to caveat this by saying I'm not on Search. And so maybe it's
totally different. But that's how it looks to me as a person who works on
Chrome.

16:59 SHARON: Yeah. Yeah. And I think in terms of actual development and making
code changes and stuff, I think probably the biggest difference is that because
anyone can download the source repository and make changes and all that, the
actual programming and changes you do, you do those on a computer. Maybe that's
a machine you SSH into or a cloud top or whatever. But you have to actually
download all of the code. Whereas with all of the google3 stuff, everything
happens in a cloud somewhere. So everything is all connected, and you just do
things through the browser pretty much.

17:29 ELLY: That's very true. Actually, there's another important facet that
just occurred to me, which is, because Chromium is open source - and in
particular, some open-source projects will use this model where they send out a
release every so often. So they'll be like, we're shipping a new major release
of our program, and here's the source that corresponds to that. So there are
companies that do that. But we actually do what's called developing in the
open. So our main Git repository that stores our source is public. Which means
that as soon as you put in a commit, or even if you just put it up for code
review, that's public. Everyone on the internet can see what we're doing live,
which is really pretty interesting in terms of its effects on you. So for
example, if you're in - you're working inside google3, and you're like, I have
this really cool, wild idea, I'm going to go and make an experimental branch
and just make a prototype of it and see what happens, you can just go do that.
It's not a problem. But if you're working in Chromium, and you go and make your
wild prototype experimental branch, you have a pretty good chance that
someone's going to notice that. And then maybe you get a news story that's
like, hey, Chromium might be adding this amazing feature. And you're like, oh,
no, that was my wild, experimental idea. I didn't intend for this to happen.
But now people have really picked up on it, and people outside of the company
that you've never met are starting to get excited about something that you
never really intended to build and just wanted to try. So it's a different way
of working. You're sort of always in the public eye a little bit. And you want
to be a little bit more considerate about how something might look to people
way outside of your team and outside of your context. Whereas teams that are
inside google3 I don't think have to think about that as much.

19:07 SHARON: Yeah, I mean, for me, I've only really worked in Chromium full
time and all that. And I've just gotten used to the fact that all of my code
changes are fully public and anyone can look at them. Whereas I think people
who work in anything that's not like that - people in the company you work, I
can see it. But not just anyone out there. So I don't know. I've gotten used to
it, but I think it's not a typical thing to [INAUDIBLE].

19:30 ELLY: Oh, yeah. Absolutely. And in fact, this is something that folks who
are transferring into Chrome from other parts of Google sometimes have a little
difficulty with, is if you're used to writing a commit message where maybe the
only description in the commit message is go/doc about my project, for Chromium
that doesn't fly because only Googlers can actually follow those links. And so
the commit message to a non-Googler doesn't say anything. And so you actually
have to start thinking, how am I going to explain this whole thing I'm doing to
a non - to a person who doesn't have any of this Google-specific context about
what it is. You go through this little mental - you cross this little mental
bridge where you actually are forced to reframe your own work away from, what
are Google's business goals, and towards, how does this fit Chromium, the
open-source project, that other people also use? It's interesting and
occasionally a little frustrating, but interesting and usually really
beneficial.

20:26 SHARON: Yeah, for sure. And I think from people I've talked to, it just
seems like another, briefly, difference between internal Google stuff and
Chromium is that internal Google just has a ton of tools you can use.

20:37 ELLY: Yes, absolutely.

20:37 SHARON: Which both means a lot of things that are maybe a bit challenging
in Chromium are probably easier, but also maybe finding the right tool is hard.
But -

20:42 ELLY: Oh, yeah. That is very much the case. I have only limited
experience working inside google3. But I definitely have experienced the
profusion of tools and also the fact that the tools are just honestly amazing.
And it makes total sense. Google has many, many engineers whose whole job is to
build great tools. And Chromium is just not that big of a project. We just
don't have that many folks that are working on it. The folks who do build
infrastructure work for Chromium do amazing work, but there's not hundreds of
them. And so it's not on the same level.

21:12 SHARON: Yeah. And what you said earlier makes me have - gives me - has -
makes me wonder - and this ties us into the next thing - of other open-source
projects, they just do a release, and they don't maybe do development in the
open. And having not actually worked on other open-source projects really, I
kind of assumed that this development in the open was the norm. So how common
do you think or you know that that practice is?

21:45 ELLY: Gosh, I would really be guessing, to be honest with you. But I
would say the development in the open is by far the norm these days. And when
you see projects that follow the big release model instead, the way that looks
is they'll be like, hey, version 15 is out, and here's the source for
version 15. You can look at it. But the development, as it happens, happens
internally. I would tend to associate that with being maybe big company
projects that have a lot of confidentiality concerns. So for example, if you're
building the software that goes with some cool, new hardware for your company,
you don't want to start checking that software into Git publicly because then
people are going to read it and be like, ooh, this has support for a
billion-megapixel camera. That must be coming in the new thing. And so I think
that the big release model might be, these days, more prevalent when people are
doing hardware integrations, where there's other components that are shipping
at a fixed time and you don't want your source to be open until that point. But
honestly, the developing in the open model is, I think, much more common these
days. Historically, back in the '70s and '80s, when you would buy an operating
system and it would come with source, that was just a thing that you got as
part of the package, then it was much more of the source is released with the
OS model. Whereas these days, because distributed development is so easy with
modern version control systems, it's just so common to just develop in the open
like we do.

23:11 SHARON: Oh, cool. I didn't know that. So compared to other open-source
projects, what are some similarities and differences that Chromium has to
others that you may be familiar with?

23:25 ELLY: Ooh. All the ones I'm familiar with are quite a bit smaller than
Chromium. And so it's going to be hard to talk about it because, frankly -

23:32 SHARON: That's probably the common difference, though, right? Probably
very few are as big as Chromium.

23:32 ELLY: Oh, yeah. So in particular, one of the hardest problems in open
source - in running an open-source project is managing how humans relate to
other humans. The code problems are often relatively easy. The problems of how
do we make decisions about the direction of a project that maybe has a hundred
contributors who speak 10 different languages across a dozen time zones, that's
a hard problem. And so I often talk about the idea between open source, open
development, and then open governance. And so open source is just, like, you
can see the source. Open development is you can see the development process. So
the Git repo is open. The bug tracker is open. The mailing lists, where we do a
lot of our discussion, are open. So we do open development. But then you have
this next step of open governance, where the big decisions about where the
project is going are made in the open. And for Chromium, some of those are made
in the open, especially when it's really about the web platform or that kind of
thing. But some of them are not. For example, if we're deciding that we're
going to do some cool new UI design, that design and the initial development of
it might not necessarily be - or sorry, the development would be done in the
open, but the designing of it might not. That might be a discussion between a
few UX designers who all work at Google in a Google internal place. And so
Chromium has a bit of open governance but not all the way. A lot of smaller
projects have super open governance. So they'll literally be like, hey, should
we rewrite this entire thing in Rust? And they'll make that decision by arguing
about it on a mailing list, where everyone can see. And that's totally, totally
fine. Because Chromium is so big, we can't make those kinds of decisions by
having every Chromium engineer have their opinion and just post. It would be
complete chaos. And because we're big and prominent, a lot of the work that we
do is very much in the public eye. And so even discussions that are maybe
relatively speculative - like that example I gave before, where you have an
idea and you're like, wouldn't it be neat if we did this? It's easy for that to
turn into people inferring what Google's intentions are with Title Case, like,
Big Important Thing, and turning that into a lot when you would not have
intended it to be that way. And so we do end up keeping our governance
relatively on the closed side compared to other open-source projects I've
worked on. Other than that, in terms of engineering practices and what we do to
get the code written, we uphold a super high standard of quality. And in
particular - which is not to say that most open-source projects don't, because
they totally do. But Chromium, in my opinion, is really, really thoughtful
about not just, hey, how should code review work, but really evolving stuff
like, how should we bring new developers into this project? What should that
feel like? Those are discussions that we have. And I often feel like those are
discussions that other open-source projects don't talk about as much. What else
is different for us? I'm not sure. I think that those are some of the big ones.
The differences in scale are such that it's almost hard to talk about. The
difference between an open-source project that maybe has 5 contributors and one
that has 500 is very, very large.

27:07 SHARON: With the open governance thing you mentioned, something that that
made me think of is maybe Blink Intents, where you submit a thing to a list and
then that gets discussed. So that's part of the Chromium project, I think,
right? That falls under that category.

27:20 ELLY: Yep. Yep.

27:20 SHARON: And so that's where, if you want to make a change to Blink, the
rendering engine, you do this process of posting it to a list, and then people
weigh in.

27:25 ELLY: Yeah, absolutely. So Blink really does do open governance in a way
that I, honestly, very much admire. Blink and the W3C and a lot of these groups
that are setting standards for the internet do do open governance. Because,
frankly, it's the only way for them to work. It would not be good or healthy
for the web if it was just like, we're going to do whatever - whatever we,
Google, have decided to do and good luck everyone else. That would be very bad.
So yeah, Blink definitely does do open governance. But when it gets to things
that are more part of the browsers' behavior and features, we tend to have the
governance a little more closed.

28:08 SHARON: Right. And I think an example of Blink being more open governance
is the fact that BlinkOn is open to anyone to participate to. And that's the
channel that we're posting this on right now. It just happened to make sense
that I figured most of the audience who is watching Blink [INAUDIBLE] already
are interested in these, too. So that's why - [INTERPOSING VOICES]

28:27 ELLY: Yeah, absolutely.

28:27 SHARON: And for people who may not have - may have found these videos
that don't know about BlinkOn. That's what that is.

28:34 ELLY: Yeah. And just in that vein of open governance for Blink,
especially, there's also this idea of being a standard and then having things
be compatible with it. So the web platform is a collection of standards. And
other browsers have to implement those standards, too. And so for example, if
we make up a standard that is very difficult or impossible for, like, Firefox
to implement, that's not good. That's fragmenting the web platform. That's a
bad thing. Whereas the Chromium UI, like how the omnibox works in Chromium, for
example, isn't a standard. It doesn't matter whether Firefox or Edge or Opera
or whoever have the same omnibox behavior as us, right? And so there's much
less of a need to all agree. And instead, it's almost a little bit better to
have some variety there so that users can get a little bit more of a choice and
that collectively more things get tried in that vein. So there's places where
agreement and standardization are really important. And then there's places
where it's actually OK for each individual browser to go off on its own a bit
and be like, hey, we thought of this cool, new way to do bookmarks. And so we
have built this. And it doesn't matter whether the other browsers agree about
it because bookmarks are not a thing that interoperates between browsers.

29:44 SHARON: Yeah, that makes sense. So now let's talk about some of the
actual details of what it's like to work on Chromium and make changes, write
code, and new ideas. So I think you mentioned a few things, like bug tracking.
That's all public, in the open, apart from, of course, security-sensitive
things and other [INAUDIBLE] are hidden. What else is there? Code review - that
was Gerrit. You mentioned that. So You can see all the comments that everyone
leaves on everyone's changes.

30:16 ELLY: Oh, Yeah. And for better or for worse, by the way. It's good to
bear in mind that if you're like - you're going to type like a slightly jerk
message to someone on a code review, that's going to be preserved for all time,
and everyone's going to be able to see it.

30:29 SHARON: Yeah. Yeah. Be nice to people. [CHUCKLES] Version control -
that's Git. Probably people will know about that. Something that might be worth
mentioning is that a lot of people who contribute to Chromium, and if you look
at things like Gerrit and Chromium Code Search - that's also public, of
course - looks a lot like Google internal code search, but obviously it's open
source. So a lot of people have @chromium.org emails.

31:00 ELLY: Yes.

31:00 SHARON: So why are there separate emails? Because you can use at a
google.com or a GMail or any email. So why have this @chromium.org email thing?

31:05 ELLY: Yeah, so there's a few different reasons for that. So chromium.org
emails are available to members of the project, which is a little bit
nebulously defined, but it's definitely not just Googlers. And so there's a
couple reasons why people like having those. So for some folks, it's sort of a
signal that you are acting as a member of the open-source project rather than
acting with your Google hat on, if you like. And so for example, I help run the
community moderation team for Chromium. And so when I'm doing work for that
team, I'm very careful to use my chromium.org account because I want it to be
clear that I'm enforcing the Chromium community guidelines, which are something
that was agreed upon by a whole bunch of Chromium members, not just Googlers.
And so I'm not enforcing Google's code of conduct. I'm enforcing Chromium's
code of conduct in my role as a Chromium project person. So sometimes you
deliberately put on your Chromium hat so that you can make it clear that you
are acting on behalf of their project. Some folks - and I'm also one of these
folks, by the way - just happen to really be big fans and supporters of free
software and of open source. And so if I have the choice between wearing my
corporate identity and wearing my open-source project member identity, I might
just wear my open-source project member identity and decide to actually
contribute that way. And so a lot of the folks who've been on Chromium - or
have been on Chrome, I should say, for a while, that's part of their reasoning.
They joined because they were excited to work on something that was open. And
so they have this open-source identity, this Chromium identity, that they use
for that. There's a third factor, and this touches on one of the sometimes less
pleasant parts of working in open source, which is our commit log and our bug
tracker and all of that stuff are public. And what that means is that everyone
on the internet can go see them. And that is often great, but it's occasionally
not great. So for example, if you go and make an unpopular UI change, people on
the internet know that that was you. And that might not be something that
you're necessarily super ready to deal with. So for example, way, way, way, way
early in my career, I made a change to Chromium OS because I was working - I
was on the Chrome OS team as a brand Noogler. So this is I've been at Google
maybe five or six months. I made a change to Chrome OS. Somebody happened to
notice it and take issue with it. I don't even remember what the change was or
the issue. But they happened to notice it and take issue with it. They showed
up in our IRC channel, because we used IRC at the time, which was also public
because the whole project was very open like that, and really just started
yelling at me personally about it. And I'm like, this is not a cool experience.
This is something that if this was a Google coworker of mine, I would be
talking to HR about this. But it's actually just a random person on the
internet. And so there are some folks who use their Chromium username as a
little bit of a layer of insulation almost, where it's like, I want to work on
this project, but I don't - maybe my Google username has my full name in it. I
don't necessarily want every change I make to be done like that. And so if you
don't do that, you can end up in a situation where you make a change, and then
it's really attributed to you as though it was your personal idea and you did
this bad thing. And that's not a risk that everyone wants to take as part of
doing their work. And so sometimes people have a chromium.org account really
because they want an identity that's separate from their Google account - that
has a different name on it, that has different stuff like that. And so one of
the things that I'm always cautious to remind folks of on my team is, if you're
working with someone who has a chromium.org account, always use that
chromium.org account when you're speaking in public, always, always, always,
because you don't want to break that veil if someone is relying on it.

35:09 SHARON: Right. Yeah, that makes sense. And I think, in general, whenever
you are signing up for interacting in these public spaces, generally, I think
it's encouraged to use your chromium.org account. So for example, Slack, which
is the modern - current IRC often -

35:27 ELLY: It hurts my soul to hear you say that.

35:32 SHARON: Well - [LAUGHS]

35:32 ELLY: I'm a die-hard IRC user. I've been using IRC for 30 years. And I
was one of the few people who was I think very sad when we decided to move off
IRC. But you're right, that it is the modern IRC option.

35:44 SHARON: I think a lot of people are very die hard about IRC. So, you
know, but modern or not, that's what's currently being used.

35:49 ELLY: Absolutely.

35:55 SHARON: So Slack is where anyone can join and discuss Chromium stuff. And
generally, that kind of thing, you're encouraged to use your chromium.org
account.

36:01 ELLY: Yeah, absolutely. And to be fair to Slack also, the Slack has
probably 30 times as many people in it as the IRC channel ever did. So I think
that it's pretty clear that Slack is more popular than IRC was. But, yeah, no,
we use our Chromium identities a lot, really, really on purpose. And to be
honest, I would like it if we use them even more. Sometimes you will see folks
who actually have both identities signed up. So they'll have their google.com
and their Chromium, and that's always confusing for everyone. So if it was up
to me, I would say everyone has a Chromium identity, and they'd just all use it
when they're contributing.

36:39 SHARON: Yeah, that's definitely one of these unique two Chromium
[INAUDIBLE] pain points of someone [INAUDIBLE] use their maybe - often, they're
the same for most people. But sometimes they're different. Sometimes they're
very subtly different, and it's -

36:53 ELLY: Absolutely.

36:53 SHARON: you end up sending your [INAUDIBLE]...

36:53 ELLY: I also - I have met a couple folks who the Google username they
really wanted wasn't available, but it was available for chromium.org. And so
they picked a shorter, cooler username for chromium.org, which is totally -
totally fine to do. But then, every time you have to remember, oh, I know them
by this longer Google username, but actually they use this shorter username for
Chromium.

37:13 SHARON: Yeah, you have to remember their real life name. You have to
remember their work email. And then now you have to remember another work
email.

37:19 ELLY: Well, we have software that can help with that a bit.

37:25 SHARON: Yeah, for sure. So as part of that, and that's, in a way - a
thing that to me feels very related is there's a thing called being a committer
in Chromium. So what does it mean to be a committer? And what does it entail?

37:37 ELLY: Yeah, so committers are basically people who are trusted to commit
to CLs, for want of a better way of putting it. So the way the project is
structured, anyone can upload a CL. And anyone anywhere on the internet can
upload a CL. It has to be reviewed by the OWNERS of the directories that it
touches or whatever. But there are some files that are actually, like, OWNERS
equals star. So for example, the build file in Chrome browser, because
everybody needs to edit it all the time, it just has OWNERS equal star. And
there's a comment that's like, hey, if you're making a huge change, ask one of
these people. But otherwise, you're just freely allowed to edit it. And so if
the committer system didn't exist, anyone on the internet would be allowed to
edit a bunch of parts of the project without any review, which is pretty bad.
And so there's this extra little speed bump where it's like, you have to send
in a few CLs to show that you're really a legit person who's contributing to
the project. And once you've done that, you get this committer status, which
actually allows you to push the button that makes Gerrit commit your change
into the tree. And that's what it does mechanically. We culturally tend to have
it mean something a little different than that, but it's - culturally, it's
like a sign of trust of the other project members in you. So getting that
committer status really means, we collectively trust you to not totally screw
things up. That's what it is. And so you have to be a committer to actually be
in an OWNERS file, for example. You can't be listed as an owner until you're a
committer. Because if you're not a committer yet, we're not really - if we're
not trusting you to commit code, we're not really going to trust you to review
other people's code. And, yeah, when you're new joining the project, it's
actually a pretty big milestone to become a committer. You become a committer
after you've been working for anywhere from three to six months, I would say.
And it's definitely this moment of being like, yeah, I've really arrived. I'm
no longer new on the project. I'm now a full committer.

39:51 SHARON: Can you briefly tell us what the steps, mechanically, to becoming
a committer are?

39:51 ELLY: Yeah, so you need to have landed enough CLs to convince people you
know what you're doing. And there is no hard and fast limit, but it's like - it
should be convincing. And so I often hear maybe 15 to 20 of nontrivial CLs is a
pretty good number. Having done that, you need someone to propose you or
nominate you for committership. So there's actually - there's a mailing list
for having these discussions. And so whoever's going to nominate you, who has
to already be a committer, they'll send mail to that list, basically being
like, I would like to nominate this person for committer. There's a comment
period during which people can reply. And then if there's nobody who is raising
a big objection to you being a committer, after - I don't know what the actual
time period is - but after some amount of time, the motion carries with no
objections, and then your Chromium account becomes a committer. I think Google
accounts can also be committers as well, but I've only ever done this process
for Chromium accounts. And so those threads - what's going on in those threads
is mostly people endorsing the request. So let's say that I have someone who's
new on my team who I want to propose as a committer. I'll start the thread
nominating them as a committer, and then I'll go and talk to maybe two or three
of the people who have reviewed a lot of their changes, and I'll be like, hey,
would you endorse this person for a committer? If so, please post in this
thread. And so in the thread, there will actually be a couple of replies that
are like, plus 1, or, yes, this seems like a good fit. Very rarely, there might
be a reply, which is like, hey, I saw some - I saw some stuff on this CL that
shows that maybe this person isn't quite ready. We had a whole bunch of back
and forth comments, and eventually it really didn't seem like they understood
what I was asking for. And I feel like they're not really ready yet. Sometimes
that will happen. But usually the threads - by the time someone's nominating
you, you're already in good shape. So that's the mechanical process. And then
there is - it might actually just be Eric, individually, who goes through and
flips the bits on people being committers based on the threads. I'm not sure.
But there's some process by which those threads turn into people being
committers.

42:14 SHARON: OK, cool. Is there an analog of this either internally at Google
or in other open-source projects? Because internally at Google, there's the
concept of readability, which means you are vouched for that you know how to
code in this one language, which has some similarities. That's maybe a similar
thing. Are there any similar notions in other projects you've seen?

42:38 ELLY: Yeah, so many projects have this notion of being a member. And that
often combines our notions of committer and sometimes code owner. And so they
might - or for some open-source projects, you'll actually hear "maintainer" as
the thing. And so they'll be like, only people who are project members can
upload changes in the first place. And only people who are maintainers can
merge those changes. So that little speedbump on entry is pretty common.
Because it's a fact of life that if you are on the public internet and you have
no barriers to entry, you're going to have spam in your community no matter
what you do. And so that kind of split is super, super common. For some
projects that don't do open development, the entire thing might happen inside a
company or inside an organization anyway. And then there is no notion of
committer status because you're just hired onto that team and then you can
commit. But for projects that do open development and free software projects,
there is often a sense of, these are the people who are roughly trusted to land
code. And for a lot of projects, especially bigger ones, there's actually a
two-tiered model, where maybe you have people who are domain experts on a
specific thing, like, they maintain some subsystem. And they're trusted to make
whatever changes they need or approve other people's changes in that area. But
then at the wider scale, there's what's often called a steering committee or a
core group or something. And those groups have authority over the whole project
and the direction of everything that's going on. And so you'll often see that
kind of model in larger projects. At smaller scales, it's often literally a
list of one to five people who all have commit access to the same Git repo, and
there's no - no structure on top of that. But for bigger projects, governance
becomes a real concern. And so people start thinking about that.

44:35 SHARON: All right. Now, let's switch topics to talking about the more
day-to-day logistics of working on Chromium. So if you're not a Googler, don't
work at Google, to what extent can you effectively contribute to Chromium, the
project?

44:48 ELLY: Yeah, so that depends where you're coming from, both whether you're
part of another large organization, like maybe you work at Microsoft, you work
at Opera, Vivaldi, one of those companies, or if you're really an IC lone
contributor. If you're in a large organization, probably your org will have its
own structure around how you should contribute anyway. And so you might just
want to talk about that. So I'll really focus on the individual contributor
angle. And so for engineers specifically, like if you're a programmer who wants
to contribute to the code base, that's awesome. The best approach I think is
really to find an area that you're passionate about because it's so much more
fun and enjoyable to contribute when you're doing something you care about. So
find an area you care about. Get in touch with the team that works on that
area, either through their mailing lists or find their component in Monorail or
find them in the OWNERS files or whatever. Get in touch with those folks. Ask
them what are good places for you to contribute as a new person. That's often a
really great way to get started. And you'll have a person you can go to for
advice to be like, hey, how do I go about doing this thing? My experience has
been that Chromium contributors are pretty much all super helpful. And so
they're very willing to just give you guidance or do whatever. And you'll then
know who to send your code reviews to.

46:01 SHARON: Cool. Yeah. And if you're not an engineer, what are some ways you
can also contribute?

46:06 ELLY: Yeah, so there's a whole bunch of these. And by the way, these all
apply to basically every open-source project, so not just Chromium
specifically. So open-source projects, if you are a good writer, if you enjoy
doing technical writing or you enjoy doing UX writing or you want to do that
kind of thing, almost every open-source project out there is looking for people
to contribute documentation. And Chromium is no exception at all to that. So
high-quality documentation, we love that stuff. Or even if you're just honing
that craft and you want to practice, Chromium is not a bad spot to do that. If
you're a UX designer or a visual designer, a lot of open-source projects will
actually appreciate your contributions of you bringing in, like, hey, I thought
of a way that this user experience could feel or how the screen could look or
something like that. They'll often appreciate that kind of input or design
work. If you are someone who speaks multiple languages, translations are
another great way to contribute to open-source projects. A lot of open-source
projects don't have access to the same kind of - Chromium has access to a
translation team within Google who do a lot of our translations. A lot of
open-source projects don't have that. And so contributing translations of
documentation, of user-facing interface, stuff like that, can be super
valuable. And the last thing I'll say, which can be done by really anyone - you
don't even need special skills for this one - is try early releases of stuff.
So try development branches. If you're a Chrome user, try running Beta or Dev
or Canary. And then when something doesn't feel right or when it's - when it
doesn't work for you or it crashes or whatever, file bugs. And try to get
practiced at filing good bugs, with details and info and steps to reproduce the
bug and stuff like that. That's such a huge help as a developer of any
open-source projects - to get that early-user feedback and be able to correct
problems before they make it to the stable channel. And on Chromium, I've run
into a few folks who just - their main contribution to the project is really
just that they file great bugs all the time. There's a few folks who all they
really do is they run Canary on Mac, and they notice when something doesn't
feel quite right. And so they file stuff that's like, maybe the engineering
team wouldn't necessarily have noticed it. But when someone calls it out, we're
like, oh, that actually does feel kind of janky, and now we can go fix that.
And getting that feedback early is so, so valuable. So there's a lot of
different ways. Those are some, but there's plenty more, too.

48:21 SHARON: OK. Cool. Yeah, and a few things on that. If you want to really
try out random things, you can go to chrome://flags, play around there, see
what happens. In terms of going back a bit for being an engineer, there's other
web-adjacent stuff that you can do that we won't get into too much now. But
that can be things like adding web platform test, web standard stuff. And for
people who are into security, we have a VRP, Vulnerability Rewards Program. But
if you know about that, probably you're into the whole security space. This is
not how you're going to - maybe this is how you heard about it, and you want to
get into it. But, anyway -

48:59 ELLY: Yeah. I will say, if you're a security researcher and you aren't
familiar with the Chromium VRP, you should go take a look because it's -
Chromium is a really interesting project to audit for security. And the VRP can
make it very worth your while to do so if you find good bugs.

49:12 SHARON: Mm-hmm. Yeah. And going back a bit earlier to being an engineer,
like an IC, who is not at Google or any of these other big companies, there are
other barriers to entry to being a contributor, right?

49:28 ELLY: Oh, yeah.

49:28 SHARON: So I definitely encountered this after my internship. I worked on
Chrome. I was like, hey, I know what's going on now at the end of it. A couple
things we didn't finish. I'll go home, and I will keep working on this - good
intentions. And I got home, got my laptop, which was a pretty good laptop, but
still a laptop. I downloaded Chrome. That took a very long time. I built it for
the first time, which always takes a bit longer. But that took so long. And
even the incremental builds just took so long that I was like, OK, this is not
happening. I'm in school right now. I've got other things to worry about. So
how feasible is it for a typical person, let's say, to actually make changes in
Chromium?

50:05 ELLY: Yeah, that is unfortunately probably the biggest barrier to entry
for individuals who want to make technical contributions. Obviously, it doesn't
affect you if you're contributing documentation translations, whatever. But if
you're trying to modify the code, yeah, the initial build is going to be very
slow, and then the incremental builds are going to be very slow. And a lot of
the ancillary tasks are slow too, like running the test suite or running stuff
in a debugger. The project is just very big. And that's something that I think
a lot of folks on the Chromium team wish we could reduce. But Chromium is big
because the web is big and because what people want it to do is big. And so
it's not just big for no reason. But it does make it harder to get started as a
contributor. I've had this experience, too. I have a modern laptop sitting on
the desk over there. And it takes seven to eight hours to do a clean Chromium
build on that. Whereas on my work workstation, which has access to Goma,
Google's compile farm, it takes a few minutes. And the large organizations that
contribute also all have compile farms for the same reason. It's just so slow
to work when you're only doing local building and don't have access to a ton of
compilation power.

51:12 SHARON: Mm-hmm. Yeah. I wonder if we could, I don't know, do a thing for
people who are individuals who contribute more. Probably that would be really
hard to do. Probably people have thought about it. But, yeah.

51:24 ELLY: It would be nice if we could. I don't know what the challenges
would be offhand, but it would be very cool if we could somehow make that
available.

51:30 SHARON: All right. That all sounds very cool. I know I learned a lot.
Hopefully some of you learned a lot, too. I think if you are working within
Google, it's really easy to not really interact with any of this more
open-source stuff, depending on which part you work on. Maybe you work on a
part that's very Google Chrome specific. I know before I was working on
Fuchsia, so that was before Launch. So that was not really something we were
open to the public about anyway. And a lot of even the typical Chrome tools I
was unfamiliar with. So I think depending on which part you work on, this
stuff - it's all there, but you might not have had a chance to interact with.
So thank you, Elly, for telling us about it and giving us some context about
free and open-source software in general.

52:08 ELLY: Yeah, of course.

52:08 SHARON: Is there anything you would like to give a shout out? Normally,
we shout out a specific Slack channel. I think in this case, the Slack in
general is the shout out. Anything else?

52:20 ELLY: The Slack, in general, definitely deserves it. Honestly, I'm going
to go a little bit larger scale here. I'm going to shout out all of the folks
who have contributed to Chromium, both at Google and elsewhere. It is the work
of many hands. And it would not be what it is without the contributions from
the folks at Google, the folks at Microsoft, folks at Yandex, folks at Naver.
All of these different browsers and projects and all of the different
individuals that have contributed, like everyone in the AUTHORS file - so shout
out to all of those folks. And also, I really want to shout out the open-source
projects not even part of Chromium that we use and rely on every day. So for
example, we use LLVM, which is a separate open-source project for our
compilation toolchain. And I think I would not be exaggerating to say that
Chromium couldn't exist in its current form without the efforts of a bunch of
other open-source projects that we're making use of. And so I'm really hopeful
and optimistic that Chromium can live up to that. We're standing on the
shoulders of a lot of other open-source projects to build the thing that we've
built. And I'm hopeful that, in turn, other projects are going to stand on our
shoulders to build yet cooler stuff and yet - yet better programs and build a
yet better open-source community. So shout out to all of the authors of all the
open-source software that Chromium uses, which is a lot of people. But they
deserve it.

53:37 SHARON: Yeah, for sure. It's very cool how it's very - all very related.
And even within Chrome, I think people stick around longer than typical other
projects. And it's cool to see people around, like a decent number of them,
from before Chrome launched. And that's probably [INAUDIBLE] to a generally
more positive engineering culture. So that's very good.

53:58 ELLY: I think so. But I'm biased, of course.

53:58 SHARON: Yeah, maybe. [LAUGHS] Cool. You mentioned mailing lists a bunch.
Any favorites that you have?

54:08 ELLY: Oh, yeah. chromium-dev is the mailing list of my heart, I would
say. It's the main open-source development mailing list for us. It's a great
place for all of your newbie questions. If you're just like, how the heck do I
even check out the source, that's a good place to ask. The topic-specific
mailing lists, especially net-dev and security-dev, are really good if you have
questions in those specific areas. But honestly, all of the mailing lists on
chromium.org are good. I haven't yet encountered one where I'm like, that
mailing list is bad. So check them all out.

54:33 SHARON: Cool. All right. Check out every single mailing list. Sounds
good.

54:38 ELLY: Yeah, every mailing list, every Slack channel.

54:38 SHARON: All right. Great.

54:38 ELLY: You're all good.

54:38 SHARON: Every Slack channel, I think - yeah, I'll add myself to the rest
of them. All right. Well, thank you very much, Elly.

54:45 ELLY: Of course.

54:45 SHARON: Thank you for chatting with us. And see you all next time.

54:51 ELLY: All right. Thank you, Sharon. Easter egg - in the second part of
this video, Elly is drinking soda.