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.
