Chris DiBona, Google's open source program manager, gave the opening keynote at the Open Source Developer's Conference. Builder AU caught up with him to discuss why Google uses open source, how the company open sources its software and what it is like to be a comic book character.
By utilising open source, Google's Chris DiBona says the company is able to control its own destiny without having issues with vendors or relying on external parties for development and allowing the company to tinker with its own code.
DiBona, Google's open source program manager, gave the opening keynote at the Open Source Developers' Conference 2008 in Sydney today. Builder AU caught up with DiBona after his keynote to discuss why Google uses open source, how the company open sources its software and what it is like to be a comic book character.
How does Google control its destiny with open source?
DiBona: Basically, we use it.
The problem with commercial software is that generally you can't control what you do with it.
There's very specific terms around how you use it, where you use it, how you can ship it or not ship it, how you can use it or not use it on the web — who you can show a website to.
I'm sure being in Australia that you've seen a website that says: "I'm sorry, you're in Australia, I can't show you that".
Open source software doesn't have that kind of restrictions.
If you're a company, using open source software is a great start for doing what you want with your computer — and that's what we do with it.
As the licence guy for Google, do you spend much time looking at proprietary licences?
Actually I do and it's horrifying to me. Horrifying is probably too strong a word.
Commercial software often has restrictions on it that are very, very difficult to track. Not just user limits or client connection limits, but things like thread limits, or machine/CPU limits, or data storage limitations.
All sorts of things that are very troubling for us.
Because our datacentres are incredibly large, and so having [costs] based on the number of cores that you might run something on is very dangerous for us.
We do have some commercially licensed software, absolutely, but we try to keep that to a minimum.
It's hard to track and it's something that I don't envy commercial organisations on at all.
How important do you consider tracking as an issue for Google, as you mentioned in the keynote that that is why you don't like reciprocal licensing agreements?
When you ship a product that has GPL or LGPL software, you need to maintain a mirror on your site somewhere.
We maintain those for the company and we have written all the software for tracking the use of open source software, so it's not that hard for us to do it, but it is time-consuming. That's what's hard about those things.
With commercial software that's true of everything you do [and] it multiplies after a while.
It's not that we don't like reciprocal [open source] licence agreements, we release tons of software under it, it's just that it's easier when we release software to release it under Apache and BSD style licences.
We can say to you: "Take it, please, just take it", it's really very nice.
When a piece of Google software reaches the stage of being released as open source, what is the process for that?
So they come to us and they say: "Hey, I want to release this Google software", and depending on where they are on their cycle of development, it's easy or hard.
Sometimes people say "I want to release something" and they have some dependencies that they didn't realise and we say "You can and here's what it'll look like for you".
Most releases, especially the smaller ones, three or four days later they've been given permission from us and we run it through legal and different stuff like that. So it's very, very easy for people to release software.
Patches are even easier, we usually approve those within the hour.
Most of the new projects are approved within two or three days.
For the larger projects like Android and Chrome, they're more complicated, they're bigger and they have a lot of sub-components and that kind of thing. We have to provide a level of infrastructure for them.
For Android we maintain 150 Git repositories for them. We have a lot of software to maintain the repositories and that kind of thing.
They are a bit more work, but that's what we are here for. But it can all be measured in days over the measurable lifetime of the product.
Why did Google create Google Code? Why does the world need another SourceForge?
We felt that just one place, with nowhere else for people to go, was a problem.
I think SourceForge is pretty wonderful, and I worked at VA Linux Systems when it was started.
[But] one company having so much of the infrastructure of open source in it, is power.
Which is why I am happy to become a backup, people can keep developing on SourceForge or whatever. I think it is too important to let any one company maintain that much infrastructure for open source.
Is Apache the default licence for Google?
So when something isn't Apache, what is the reason for that?
It's usually dependencies or the projects that we want to have adopt that software are under different licences.
When we released the libjingle project, the projects that wanted to consume it were GPL and BSDs, and so we released under those licences as opposed to the Apache licence. As at the time, the GPL could not consume Apache software.
What we often do in those cases is we will often do a patent clause along with it that says that any Google patents that are in this software, we will give a licence to you and any of your users.
The patent stuff is really important to our group, and we try to bring it to the other licences permissively whenever we can.
Usually when we pick up a licence, we want to be compatible. When we release things for Firefox, releasing under the BSD makes sense — and so forth.
We release under CPL, EPL, BSD, GPL v2 and GPL v3 and a variety of others.
You mentioned in the keynote that Australia has a lot of mentors and not many students in the Google Summer of Code, is this due to Summer of Code being held during the northern hemisphere summer?
This is a problem. The change of seasons is tricky for us, if you look at the number of computer science students in the northern vs. southern hemispheres — it's hard for us to justify having a southern hemisphere version of it.
For a country of about 20 million people, you have an oversized representation of mentors and about a regular size representation of students per capita. So you're doing OK from a Summer of Code students/per capita point of view, so that would lead me to believe that during a southern hemisphere version of it, it wouldn't make a difference.
That said, the high school orientation version of the Summer of Code that we do is southern hemisphere timed, it's done usually in our winter during December-January. That works out pretty good.
One thing we noticed when we looked at it, was that southern hemisphere universities don't have as long a break as the northern hemisphere universities over summer, on average. It's a little shorter, and you have a longer inter-quarter break.
It's a cunning world.
What is your stance on the AGPL after your previous kerfuffle over the licence?
The AGPL as you know is a web clause, so we don't use it inside Google, we don't allow it because it is very hard to track interactions sometimes.
We've had some AGPL projects in the Summer of Code, so it's a fine licence, but it's not for us.
You've become a comic book character, is that a tick off the nerd dream list?
You'll laugh, but a lot of people read that comic, man. I never expected that many people to read that comic book, it's telling people we've got a web browser.
Did you see the parodies that people did, like the Godfather parody? They were so funny.
But we love it, and they made me a little thinner.