| # 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 ([email protected]) |
| and Elly |
| ([email protected])](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. |