google Interview: How open source changed Google - and how Google changed open source

sincity · December 18, 2013

http://cdn.mos.techradar.com/art/magazines/Linux/Issue%20177/LXF177.iview.2-470-75.jpg

Google has just celebrated its 15th birthday, and much of its success is thanks to Linux and open source software.

This gave us the perfect excuse for our sister magazine Linux Format to ask Google's Chris DiBona, about how open source has changed Google, and how Google has changed open source.

Sadly, he couldn't comment on the KitKat name for Android 4.4.

Linux Format: After nine years at Google, including the launch of Android, what's changed for you?

Chris DiBona: Ah, well, when I got to Google, it was 1,800 people, and now we're topping 44,000. As you grow like that, everything grows, right? You get more developers who want to use more source code, you get more repositories, because nine years ago we didn't have that many to worry about. Now I have to worry about all of them. We didn't have Android or Chrome when I started, and it's been difficult to kick off those projects in a way that's consistent with the goals of the project and open source.

Think about Android alone. It tops 400 Git repositories, and so we had to write all this new tooling that's all open source as well, such as Repo [Android's repository management tool] and Gerritt [a web-based code review system]. And then Git itself wasn't working for us anymore because it wasn't scaling when we'd have an operating system release. So we ended up hiring most of the Git team - there's like only one or two core committers now for Git who don't work at Google, and that's keeping Git running on our back-ends, but also keeping the clients out there up to date and everything working.

So now, for instance, there's a Google team that maintains what you think of as Git in Debian. And that ensures that when a Debian, Mac or Windows user uses Git to pull Android - or to pull really any of our Git-based projects - that they're using the most recent version of Git. It's fairly complex, the way all the things weave together now.

LXF: What was originally envisaged as your role at Google? Did Google think 'We're going to have 100 open source projects and we need someone to manage them?'

CDB: If it were just 100 that would be one thing. I think technically, I've released a little over 3,700 projects since I started - large and small, mostly small obviously. For every Android there's a thousand smaller projects. Little tools that find their ways out there and patches galore. So when they hired me, they just knew they needed somebody who would care about this stuff professionally to come in and sort of keep things on an even keel.

LXF: How do you manage the open source compliance in a project such as Android?

CDB: I don't run Android but I do help them. For Android we were very lucky in that we were able to really make compliance part of the tooling and part of the build system early.

LXF: Years ahead of its release?

CDB: Yeah, about three years ahead. We worked with the Android team and we actually provide infrastructure for the Android team worldwide, as well as all the Android partners and the rest. We're able not just to say to them, 'Hey! You should be in compliance!' Because it's kind of not enough. We're able to say, 'Here's how you can stand in compliance.'

And in fact, we're at the point where if you're shipping an Android device, even if you have no contact with Google whatsoever, and no real desire to even care, it is actually work to come out of compliance with Android because it will fill in the 'About' boxes for you, it will do a lot of things for you that the open source licences demand of you. So when you see an Android device that's out of compliance - I mean literally letter of the law out of compliance - it can be rare.

Even if somebody is completely and wholly ignorant of what open source licences require. And in some ways that's the best case, right? Even in a company like Google where we have staff in place, as new repositories are created, as new projects are started - we're not always pretty. We have to be extremely up to date on what the company is doing, so that we can make sure that when it comes to the time to launch a product that they're able to do so in compliance with open source licences and, frankly, using the most up-to-date versions of open source software - they can be up to date on bugfixes and that sort of thing.

We try to get in early, so that we're not seen as a barrier to launch because if we're slowing down launches, we're failing in a company like Google, and we don't want to be that group.

http://mos.futurenet.com/techradar/art/magazines/Linux/Issue%20177/LXF177.iview.3-420-90.jpg

LXF: Is that kind of compliance in the DNA of people that work at Google?

CDB: Yes and no. You have to realise that open source licences can be extremely complex. You don't necessarily want engineers to become experts at licences, because if they're doing that sometimes they're not developing quickly because they're worrying too much about these interactions. We try to give them broad guidelines and smart tooling so they know the implications of that which they're building. We try not to have them become experts in licensing because it's a scale just like any other: if you're good at this do you have the capacity to be good at this other thing too? Maybe, but I'd rather have them concentrate solely on product development and all the rest.

LXF: Has Google's approach to open source changed over those nine years?

CDB: Sure. It's funny because depending on the project, they have different perspectives on open source.

LXF: So ChromeOS has a different perspective than Android?

CDB: I'd say so, yeah. I mean ChromeOS is a different approach to operating system development than Android. It's funny because if you're going to ship a browser, for instance, there are certain plugins that you want to make more secure, but those plugins are by their nature closed source - things like Flash.

If you want a ChromeOS box to render Flash content and do it in a secure way, well, we had to cut a special deal with Adobe that would allow us to ship that version of Flash in that way. And that's something that doesn't show up in Chromium or ChromiumOS, right? It just shows up in ChromeOS. And so you have these funny borderlands between open source and proprietary software and how does that work?

Similarly, if you want to cut a deal with one of the content producers in the USA, in Europe and the rest, they want to know that they have that whole "secure path" and to ensure that you have to make sure that the deal does not interact poorly with the open source licences in an operating system or program. That can be extremely tricky.

On top of that is our standards work. We have one part of the company that is advocating for encrypted media extensions, for instance, so that they can ship Netflix players and that kind of thing, and then you also have Ian Hickson, who works for me, saying that that doesn't belong in the Web WG (Web Hypertext Application Technology Working Group) specification for HTML 5.

LXF: So who makes the decision?

CDB: This is the interesting thing about a company like Google. We can have both. Or we can have neither, depending on your perspective. We will sometimes have things that look conflicting, but they're not really. There's nothing wrong with us wanting the Web WG HTML 5 specification to be a pure document that doesn't depend on patent-laden technologies, like you'd find in some specifications, and also have an ancillary specification that adds to HTML 5 that allows for it. You can drive yourself crazy.

LXF: Are you allowed to have an opinion on these kind of subjects, or do you remain objective?

CDB: I always let one thing guide my actions and to date that's served me well. And it's this: I don't care, OK, if I like a project, or what it does for a user, or if I'm the user of that project so long as they're in compliance with open source licences - in spirit and in letter - I'm fine. I don't have to like it so long as they're compliant - so long as they're not disrespecting my friends in open source software. As long as our colleagues in open source software are being served well, I don't have to like it, because I like being in compliance. I am that kind of regulator, and as long as that which I regulate is healthy, I'm happy.

LXF: And that includes something as contentious as DRM in the HTML 5 specification?

CDB: It's extremely contentious. What I end up doing more often than not in those cases is ensuring, as much as I can, that the two teams treat each other nicely, you know don't call each other names, or whatever, and don't try to force the issue in unhealthy ways with each other.

LXF: And as long as they're both in compliance, you're happy?

CDB: As long as they're both in compliance, we're happy. That's actually never been a problem. They all know that that's something that's important too, so that's never really been a problem. The trick is when people are working on conflicting or competitive projects with each other; it's very difficult to keep them from turning that into a personal problem. As an engineering manager this is something that's true.

LXF: What if there's a philosophical difference?

CDB: It's funny because people say 'Oh, it's just software, you shouldn't worry about it'. Or 'It's just business, you shouldn't worry about it'. But what people seem to forget is that software and business are personal. It's how we get through our day. It's an important part of our lives so trying to keep things in perspective is really important. Now, you could say 'Does that make you a sellout Chris?' But I don't feel it does because given that the overall actions of the company have been, in my opinion, really strong and on the side of the angels, I think it's OK for us to have these discussions, especially internally.

LXF: What do you spend most of your time working on now?

CDB: I have a team of about 30 or so people working for me, and that's on various aspects of compliance and the Summer of Code, as well as tooling and infrastructure. I end up doing people management. Acquisitions compliance takes up a fair bit of time. When you have as many engineers as we do, and you have as many programme managers as we do, and project managers; people inside the company have to care about their careers and make sure that they're happy at a company like Google. So looking after promotions and calibration is something I think is really important, but not as exciting for your readers.

http://mos.futurenet.com/techradar/art/magazines/Linux/Issue%20177/LXF177.iview.1-420-90.jpg

LXF: Do you get to influence policy?

CDB: Yes and no. I mean, I'm a director in the company. That means I'm not in charge. Larry is in charge, and then we have a bunch of people who are way more senior than I am. But I'm able to help out in a lot of ways, help people find their way careers and that's actually really rewarding.

LXF: What do you think has been Google's biggest contribution to open source?

CDB: I think that the three biggest projects we've released are Android, Chromium and Go. If you asked me ten years from now which one I'm proudest of, I'm going to have a hard time answering, because Android has had incredible impact.

LXF: There's Summer of Code as well!

CDB: Well, Summer of Code is a very personal thing that's affected thousands of people. Android and Chromium have affected millions, or even a billion people. But from my nerd heart, my programmer's soul, I look at things like Summer of Code; and I look at things like Go; and I look at things like even GCI, our High School programme. I think these things are what makes open source persist in ways that even Android and Chromium do and don't. Chromium and Android are market forces at this point.

LXF: They are the proof that open source is legitimate?

CDB: They're fundamental. Beyond legitimacy. There have always been people over the last 20 years who've said open source is a cancer, or not legitimate, or the enemy. They say things like this and that always sort of misses the point for me, because open source is everywhere, right. And if we want it to continue to be everywhere and continue to help computer science move forward, we have to continue making it and keep it fundamental. The way we do that is through languages and through platforms like Android. By improving established open platforms like the web through things like Chromium.

You have to realise that before Chrome launched, people were still launching browsers where one tab could bring down the whole OS. That's really hard to do now. That's considered silly. And where JavaScript performance didn't really matter. We were able to change that with Chrome in a way that users obviously found useful. But it also forced people who are working off of WebKit and Gecko to take another look at performance and security.

If we hadn't done that, the web would be in a much worse state right now because there's a lot of malware around the web; there are a lot of people looking to trick you on the web. But because of Chromium, we focussed on this stuff early enough that it saved - in my mind - what the web could be.

Can you imagine if you didn't have the malware protection and the process isolation of Chrome, that Chrome brought to other browsers? Can you imagine surfing the web the way it is right now? It's pretty grim. There's a lot of malware. You end up basically funnelling people into fewer and fewer sites, and therefore fewer and fewer viewpoints and all the rest.

LXF: Do you think Google would have existed without open source or without Linux?

CDB: Probably. But I don't think the web would exist without open source and Linux. So there would have been no Google. It would have been something different, but without open source driving the internet there would have been no internet for Google to crawl, much less to run ads against, and much less to enforce our ideas around Android and Chromium. I think they're one and the same.

LXF: Of Summer of Code's 1,200 students and 60 countries, 271 students have been/ are in India. Do you think the next ten years is going to see a shift in where and how technical innovation originates?

CDB: I hope so. Every year that goes by we see more people from outside of the US take part. The US still has a healthy proportion - 250 or something - but it's amazing to see where people pop up - like Sri Lanka. Even during the civil war we still had Tamil and other Sri Lankan students taking part in the Summer of Code; it's like, how did it transcend borders in that way in that country? And so, Sri Lanka has always been really interesting to us in ways that even India and China are not.

Here's basically a very small nation, and if you look at it, there's a couple of universities that really glommed onto Summer of Code as a way of expanding their curriculum. Think about that. 79 Computer Science students in a small university in a small country in the midst of a civil war, all doing remarkable work. This is the promise of the internet and computer science made flesh.

LXF: Is that how you'd imagined Summer of Code to be?

CDB: Not really. I don't want to portray myself as like a visionary. I never saw Summer of Code like that. I saw Summer of Code as a way that we could bring new people into open source. People we never would have seen before, because we were literally financing students so that they wouldn't have to go home and do something random that isn't Computer Science over the summer. So for me it was just a way of keeping computer scientists engaged for the summer and, hopefully, on open source.

And it turned into something much more than that. Something more revolutionary than that in my opinion, and that's really a testament to the open source teams that have shown up and mentored, and all the rest. Remember, for every open source developer in the Summer of Code, there's a mentor and a project. Without the mentors, it wouldn't work.

The only thing Summer of Code does, that's revolutionaryâ€¦ is it pairs up an experienced open source developer who's used to working remotely with other people with a neophyte developer. That's the remarkable thing because in the end that student can always go to their mentor and they can say, 'I'm having a problem.' Or the mentor can watch the incoming change list and say, "You're having a problem. If you do this and this, you're be doing good. If you do this and this, you're going to be doing bad." You don't even get that in most jobs!