Interview with Google's Chris DiBona

We have this picture that circulates, Google's first quote datacenter unquote: it's a jokey thing - you see things like disc drives housed in Legos. That was mostly Linux, but it also had a couple of Sun workstations – it was Stanford, so Suns were everywhere. But by the time that we became a real company it was pretty much Linux through and through for the operating system.

We were all engineers, and it was a very natural thing to say: well, this stuff just works, let's use it. It wasn't so much a religious as a practical decision.

I think that it was really healthy because when we consider creating new services and products we're not afraid of considering the open source options. Open source gets exactly the kind of treatment that it deserves here. What's funny about Google, though, is it's not open source versus proprietary, so much as it's open source versus let's create it ourselves.

The thing about open source, it's kind of like it is yours. You can do all the things that you can do to your own code to open source: you can ship it, you don't have to pay any money or anything, you can fix any bugs, you can have a new feature. These all sound like trivial things, but you can do them all without getting permission, without having to check with anybody, without having to go to your legal team. Once the code's in your company, people are going to be able to use it like their own. And that's incredibly powerful.

Considering that Google does an insane amount of software development, if we had to have some of the restrictions that heavily proprietary [code] would present us, we couldn't develop at the speed that we do.

We've been real clear that we use Linux, and that we use MySQL. We actually don't use the Apache web server very much at all, although when we buy companies, usually they're running Apache, so there's this transition period where they're running Apache. But the real strength for open source software at Google is actually not anything beyond Linux and MySQL so much as the libraries themselves.

The OpenSSL stuff is super important; as a company, the last thing you want to be doing is creating cryptography software. It saves us a lot of work, but more importantly, it's mature code. It's a very bad idea to use new cryptography code, because it hasn't been proven, it hasn't been attacked.

I was hired at Google because they decided they needed an open source person, quote unquote, and they didn't really know what that meant yet. They wanted somebody to look after their use of open source, and also, uniquely, they wanted somebody whose job it was to ensure that open source itself was healthy. We broke that down into three main parts: helping out people who were making code; creating new people to create open source code; and releasing open source code ourselves.

The bread and butter of the [open source] group [is that] we make sure that Google continues to use open source in a very healthy way, in line with the licenses, and [that] we're able to interact with the outside world and open source developers very efficiently. There are literally hundreds of Google engineers who are patching and sending in bug reports, sending in bug fixes, all the time.

I think it was organic more than anything else. Google has been very public in the fact that we have three primary languages, and that's C++, Java and Python. So as part of that we try to bring on staff people who are the world leaders in those projects - Josh Bloch and Neil Gafter for Java, Guido on Python, Ian Lance Taylor and Matt Austern. We do that because having those people on staff, those projects can continue to move forward, and that's good for us; and also our use of the projects informs the directions sometimes where these projects can go.

So, seeing Linux in an environment like Google informs the direction of Linux in a lot of ways, because you get to see it in an extremely high-load, high-availability environment that you don't really see that often, and you see it on commodity hardware here. So that's really good for the outside world that Andrew [Morton] gets to see that, and that Andrew can really code whatever he wants.

Contracts per employee are very different. What we've done in general in the company is that any Googler can use their 20% time on open source software, and we administer that work here in our group. Andrew Morton and Jeremy Allison are really interesting because they came in with a pre-established duty to their software, and we want to make sure that the code they release is considered above board and beyond reproach. So folks like that, we go a little bit extra, and we say: OK, what do you actually need to be able to continue to patch and be comfortable working here?

What it comes down to is we have incredible policies in place to allow Googlers to patch out, and release code, and that serves everybody in the company, and not just the stars – the open source stars I should say – we're all stars.

It's funny. Greg Stein and I had presented code.google.com to the [Google] founders, and Larry Page said: Listen, I want you to do me a favor. I want you to go and find all the computer science students who aren't coding over the summer, and I want you to make sure they code. Would you do that for me? I was kind of dumbstruck. I was like, Well, I'll try. And so I came up with Summer of Code as a way of doing it.

I knew that I personally couldn't interact with that many people, but I knew that the open source movement was very good at dealing with lots of people and code. So I contacted some of my friends, on different projects, and we spun it up

This year we had a sync-up period, so once a student's application was accepted, there was actually a long period of time, almost two months, where they could get used to their organization, and sort of understand how they do things, how they can commit code. And that was incredibly useful – not because they had extra time to code, but just because this community-bonding period is really important.

It also made the midterm judging period more efficient. So with Summer of Code, we've got initial application acceptance, a midterm and a final [judgment], where the organizations say if the student is actually doing what they said they were going to do, or if they just dropped off the face of the earth. It made those judgments way clearer. It didn't really change the failure rate all that much, it just made it faster.

I think we failed 19% of our students this year, so 81% success.

We really do take advantage of literally many hundreds of libraries, and hundreds of projects, and so we get a direct benefit that code is being written for projects that are important to us. One of the things that does happen is open source developers come here, and sometimes they stop working on open source. And we see it as being incumbent on us to replace those that we take. Also it's good to take students to show them what the real world of computer science is like.

Another side benefit is that because of Summer of Code, Google now knows all the people working on all these software projects, on which it depends. That's incredibly useful to us. Every once in a while we'll come out with a new API and there'll be some projects in the open source world that might be useful in either using that API or being a customer. You can just call them up and say, Hey guys, it's Google, we're you're pal, and let them just check it out. And then there's a small benefit to recruiting, too.

It would be hard to justify the $5 million that we spent this year for any one of them, but you put them all together and it seems to make a lot of sense. Also, we do want to give back – we do take a lot of code.

There's two things that happen. There's the code that they get, often very, very useful; there's the students themselves - they get new developers from this. Even though a lot students go back to school and you don't hear from them again, a bunch of them stick around and keep on coding.

But more importantly, if you look at organizations that have done Summer of Code, something happens to them, they become suddenly really professional in bringing people into their project. And this is a huge benefit for them, because these projects are able to be healthy and to grow.

Gears is an open source browser extension that enables developers to build web applications that can work offline. We knew that we could just release a plugin and make it good for our apps, but with open source other people can use it and feel safe to use it, and know that people can't just abandon the technology, because they have it too. It's a very powerful message that a lot of people don't always get, but it's a big deal. A lot of people have software toolkits now, but what it comes down to is ours is really popular because everyone has it, the same reason why we use open source code.

Another side of the Gears thing that's really important is that Google can't port it to more than, say, three or four browsers. But there are enthusiast communities who want that stuff, or have an alternative browser that isn't supported directly by us, and they can do it themselves.

We generally release under the Apache license. We've also released under BSD, GPL, LGPL, CPL, MPL.

Usually just whatever is best for the software - where the code is going, who we want to have use the code. For instance, we released our signaling specification for voice calls in Google Talk, and we wanted that to be able to used by both GAIM and by Adium on a Macintosh, and so that was one of the few times when we actually did a dual license, which was BSD and LGPL. That was also released as a Jabber enhancement proposal. We try not to be too religious about this stuff, and that's one of the reasons why we pick Apache: it is very friendly for both open source and for proprietary software.

A lot of people assume we use code in ways that we don't actually. We are releasing a ton of patches into the Linux kernel, so I'm really happy we're way beyond what we need to do there, and that's also true of things like OpenSSL. I have to tell you I can't get that worked up about this issue, I wish I could. We're doing so much more than the licenses have required now for so many years, that this argument kind of falls on deaf ears.

What people are really saying is: Why don't Google release more code? And I think that's a valid thing to say. I think it's kind of important they want to see Google release more code, and I agree with them.

I know that we're getting into it in a bigger way - I'm not at liberty to talk about it. There is more coming. But even if we just did what we've got today, which is enable Google engineers to release code whenever practical, that would be a pretty great and healthy thing.

I think that open source has a very important role in our culture. As we grow the company, I want to make sure that the ideals that make Google so very appealing to me, continue, because I think it keeps Google in a lot of ways good, and healthy, and pure. I know that sounds really strange, and idealistic, but that's OK. So the more open source that we use in the company, the more open source people that we attract, and the more open source code that we release, I think that it's really good for Google spiritually.