Archive for June, 2008

Q&A: Google’s open-source balancing act

Posted on June 30th, 2008 in Uncategorized | No Comments »

Chris DiBona’s job–manager of Google’s open-source programs–is a balancing act.

Google consumes a lot of open-source software for its own highly profitable business. But as he oversees the search powerhouse’s open-source work, DiBona has to ensure that the company reciprocates. It can’t be all take and no give.

Chris DiBona, Google’s manager of open-source programs

(Credit: Stephen Shankland/CNET News.com)

Free and open-source software advocates can be powerful allies–but also vocal critics. For example, some have critized Google for its lack of support for the Affero GPL license, which can require those using software for a publicly available network service to share modifications they’ve made to an AGPL software project.

DiBona thinks Google strikes the right balance, though, by offering its own modifications back to many open-source projects, advocating the philosophy in general, and trying to nurture the next generation of open-source programmers.

DiBona has been steeped in open-source software for more than a decade. Before his job at Google, he worked for Slashdot, still an influential virtual water cooler for open-source discussion. Slashdot was part of Linux server maker VA Linux Systems, which had a spectacular initial public offering in 1999 followed not long after by a drastic cutback.

DiBona will be preaching the open-source gospel at the Google I/O conference Wednesday–”open source is too good to be true and thus must be magic,” according to the agenda–but I sat down with him beforehand to hear his view of open-source software at Google.


What’s the view of open source within Google?

I asked myself, “Who am I trying to address?” The world of open-source business? No. The world of the open-source enthusiast? No. I’m really looking to work with open-source developers. We came up with these goals for our group: to support open-source development in general, which means to support open-source infrastructure; support the release of open-source code, from Google and in general; and to create more open-source developers, because especially when I started, there was a perception that Google took a lot of people from the open-source world and then went away. It was partly true, because people would come here and say, “Wow, I’ve been working on my open-source project forever, and I want a new problem,” and we have a very good class of new problem. So they kind of went away.

That was too bad. The last thing we wanted as a company was to hurt the release of open-source software, because we consider it pretty important. We use a ton of it. Every engineer we bring on–how much open-source do they want to use? We have new packages and new libraries being brought into the company all the time. It’s our group’s job to track that. As we brought people in, we wanted to be sure more open-source developers were being created. So that’s where we came up with the Google Summer of Code, and now we have a high-school flavor of that as well. I think we’ve made a very real impact in creating new people in the open-source world.


I’m curious about maintaining a balance between contributing back to upstream projects vs. maintaining your own internal forks. How do you go through that evaluation?

Google considers some projects more important than others. Obviously the Linux kernel is incredibly important. Every time you use Google, you’re using a machine running the Linux kernel. We have a fairly large kernel team, and we employ people whose job is just to work on the external kernel. Andrew Morton is a good example of that. We try to make sure those guys patch out (submit their modifications to the main open-source project) whenever they can. It’s usually more dictated by the engineer’s time than it is any lack of desire on our part. I always wish we were able to release more, but it takes time for an engineer to do that. For the larger efforts, it’s a little easier because there are more personnel on it.

The same thing goes for our compilers (software that translates programmers’ code into instructions a computer understands). The great thing about our compiler team is they patch as a matter of their jobs. They’re always patching out things from the compiler work we do internally to the outside world. We recently released the new linker, Gold–Ian Lance Taylor works for us on our compiler team. He’s been on the GCC team forever. He used to be at Cygnus (a company that developed GCC). We have a lot of ex-Cygnus people.

Then there are Googlers who just want to patch into an existing projects. They found a bug, they want to add a feature. That takes no time at all. Our team looks at the first couple patches an engineer wants to send out, makes sure the engineer knows what they’re doing with the outside world, then they’re basically given free rein to do that. They keep us posted on what they’re patching. We want to make sure our code gets out to the projects as fast as possible because projects keep on iterating. If you don’t get your patches in, they won’t get accepted, because they’ll be too old or won’t matter. If you’ve got a patch, getting it out there fast is better for us, because then as that project iterates and comes back into the company, we don’t have to reapply a patch.


What are the most important open-source projects you ingest?

The kernel, compilers–GCC, the Python interpreter. Python is very important to us. Google App Engine–it’s a Python hosting system, basically. Java is very important to us, and that’s become open-source now. We have some very good Java people working for us–Josh Block, Neil Gafter–they’ve got a great handle on that technology.

Once you get past those three projects–the compilers, the languages, the kernel–then you go to the libraries. For us that’s OpenSSL, zlib, PCRE. MySQL is hugely important to us. Past that, it starts tapering off pretty quick.


Has the open-sourcing of Java changed anything for you?

Not really. I think it had more impact on the outside world than for us. Java is a fairly mature language now. We’ve been using it for a long time. Before, it was the JCP (the Java Community Process to govern Java’s future)–it had the rubric of openness around it. It was never really not so open. There are questions around what open source means now around Java, specifically J2ME (Java’s mobile edition for gadgets such as cell phones) and the TCK (the technology compatibility kit).


Are you using a super-uber-customized Linux kernel, or are you guys pretty much vanilla?

I don’t think there’s such thing as a customized Linux kernel anymore. The kernel is incredibly flexible. It’s got all these different architectures. I think the Linux kernel itself is this ubercustomized thing.


But do you have a lot of in-house customizations?

Not a lot. Google is exposed to some interesting hardware before the rest of the world. So internally we’ll be sampling code for that hardware. So that’s pretty custom stuff. But eventually that goes to the outside world. We funded some work with a group in Berkeley called Xorp to bring high-speed Broadcom networking chip functionality to Linux. It’s not in our interest to keep control of it ourselves. So is it customized? Absolutely. But is it heavily customized? I don’t think it is as heavily customized as you might think.


Is it true you still use 2.4 kernels?

In some places, sure.


How about for the core search product?

I don’t know how it’s partitioned out. When you think of Google, you think of search being on top of a kernel that’s static. It’s not always like that. It differs on data centers. I think 2.6 predominates, though.


There’s been discussion about reciprocity. When General Public License (GPL) version 3 came out, the Free Software Foundation dumped the Affero clause out of GPLv3 and split it out into a separate license. Eben Moglen (co-founder of the Software Freedom Law Center and then counsel to the Free Software Foundation) said, to paraphrase, “If Google starts getting too parasitic, then we’ll re-evaluate it.” How worried are you of getting a negative perception of using more than you contribute?

I do worry about this. I think it is a largely incorrect perception. You can always give out more, and there are always people who will never be satisfied. Could we be giving back more? Sure. One of the ways I ameliorate that problem is (through) projects like the Summer of Code. Google is releasing every year, not counting Android or the really large open-source projects like GWT, a new project every two or three weeks. Or patching hundreds of projects a month. I conservatively estimate we’re releasing about a million lines of code a year from the company.

If you talk to open-source developers–people who are working on projects–I think they understand that. It came back to who do we want to interact with. I always felt the enthusiast community would understand that eventually, and I think that’s true. There are some people who are upset with us because we didn’t embrace the Affero-style GPL, but it’s not practical for us to do so. When they had an Affero-style clause in GPLv3, the thing I told Eben was, “Listen, you can adopt whatever you want. We’ll still keep on backing up the FSF and the SFLC as much as we can, but it means we won’t be able to use that license inside, because it won’t be practical for us to do so.” I think that’s a very realistic response. The Affero GPL is out there. That’s great for the people who use it. It’s just not for us.

That’s the thing about free software. You’re not obligated to use it. We have enough fine-grained control within the company that we don’t use things we don’t want to use.


What are your preferred licenses?

We generally release under the Apache License–Apache 2. We think it has the fairest language of the licenses. And the GPL requires a lot of management–more than we have time for to run a project well under that license–patch flow and all that. Apache 2 encourages people to take the thing and run with it. That’s what we’re going for when we release code, whether it’s to have people adopt technologies we really like, or for API examples. That said, we’ve released things under the GPL, LGPL, GPL version 3, BSD. We default to the Apache License.


To what extent to you subsidize gurus to sit around and work on important projects?

We’ve got people like Jeremy Allison and Andrew Morton and some of Guido (van Rossom)’s time. He’s been working pretty heavily on Google App Engine and Mondrian. It’s more common that we…try to make open source a part of their job, so they’re patching out to the libraries they use. We think that’s more healthy than having people whose job is just working on an open-source project.


You use open source a lot internally. Do you have some kind of intellectual property vetting or review before you use it?

We do. There are two ways we do this. When somebody wants to bring a piece of code in from the outside world–open-source or commercial–you need to put it inside a special directory we call “third party.” They’re required to put in a file called readme.google (that describes) where they got that software, how it’s licensed, what category that license falls under. We look for things that are obvious. There are some projects that have dubious intellectual property provenance, and we know those, and we know the people who run them, and we tend not to use those ever.

Since Google doesn’t distribute a lot of software, we have it easier than companies that ship hardware and software. We have a couple situations where that does happen–the Google Search Appliance, some of the downloadable applications. Those get a little extra attention. Similarly, when we have larger projects like Google Android, we have a higher ceremony–every two weeks we get together and see if the license picture has changed.

The tracking model works really well for us. We have tools written where a program manager or a release manager can turn on a certain level of warning within the build tool and it will tell them what open-source software they have and how they have to comply with it. At that point we set up a mirror for them as they get closer to release.

So that’s the first way we track things. The second way is whenever a Googler puts in a changelist now–this is something we’re just starting to do–we compare it against all known open-source code on the Internet using our Code Search product. We compare the changelist that comes from your average Google engineer against that database of code and we look for intersections. When we find an intersection, we take a look and see if it’s truly a copy. And if it is, we make sure it’s in the right directory and that it’s properly labeled. And we call up the engineer if it isn’t and make sure it gets tagged properly so we can do the right thing by these licenses.

That tool is kind of in its infancy. We’re trying to figure out ways to automate what it does. But it’s great because it scales programmatically. Our group’s goal is not to break builds or stop development. It’s to enable developers to use as much open-source as possible. We think it’s healthy, because then they’re not writing that code, they’re writing other code.


Do you vet code for patent or copyright?

No. We have legal people on our lists. We have two main lists that track these things. Open-source licensing for incoming code and open-source releasing for outgoing code. Legal has a presence there. Patents are incredibly tricky.


Is it easier to get hired at Google if you have experience maintaining your own open-source product or patch?

If you have made a name for yourself in open source, clearly it helps. If you have a healthy project in open-source, I believe it helps. One thing I see on hiring committees is when somebody has an open-source history, it’s really great. You can just look at that history. Interviews are great, but they’re not very deep. They’re only 45 minutes long. So how can you really get a feel for if a person is good at programming, at computer science?


Or at social relations, for that matter.

Open source really reveals that incredibly quickly. You can look at their code, at their activity on mailing lists, how they deal with bugs from real people, and real user problems. That’s an incredible resource.

The Summer of Code isn’t really a recruiting program. If it is, it’s a really expensive one. Last year we created about 2 million lines of open-source code across the 900 students who took part. Of those probably a third are going to stick around with their projects, because the rest have to go back to college.

We have a couple students who have been in the program two or three years. The whole point is to support kids over the summer so they can go and program and not get some other job that has nothing to do with computer science. It’s our fourth year doing it. This year we’ve go 1,109 students doing it across 95 countries.

Review: 2009 Hyundai Sonata Limited

Posted on June 30th, 2008 in Uncategorized | No Comments »

Hyundai got high marks from many auto reviewers for the last generation of its Sonata sedan, but it fell short on the car tech front. But now the 2009 Hyundai Sonata is here, and it looks good for catching up with and surpassing its nearest competitors. We weren’t surprised to find a navigation system in a Toyota Corolla we reviewed recently, but when we saw the LCD in the Sonata’s dashboard, we only kept on our feet because we had a little advance warning. It was the iPod integration and the voice command system that really floored us. We had the top-of-the line Limited V6 model, which comes with an engine offering more than adequate power for the little sedan. We were only troubled by the transmission’s gear hunting, the soft ride, and the overly powered steering.

Read the review.

Move your body, charge your phone

Posted on June 30th, 2008 in Uncategorized | No Comments »

(Credit: Crave Asia)

There are several ways one can harness natural energy. In addition to the sun, wind, tides, and geothermal activities, the human body itself is increasingly being used to produce energy charge all sorts of electricity-hungry devices.

Music company Orange and GotWind, a firm specializing in renewable energy, have teamed up to create a device called the Dance Charge. Weighing 180 grams (about 6.3 ounces), you strap it around your arm. Dance Charge then uses the kinetic energy generated by your body in motion to juice up your phone.

It also uses a system of weights and magnets to produce electric current to top up the storage battery, which can later be used to charge your handset. A prototype of the device will be shown and tested at this year’s Glastonbury Festival.

(Source: Crave Asia)

Touched down in the land of the Delta Blues

Posted on June 29th, 2008 in Uncategorized | No Comments »

The Crossroads, where legendary bluesman Robert Johnson is said to have sold his soul to the devil in return for his musical talent, is at the intersection of US-61 and US-49 in Clarksdale, Miss.

(Credit: Daniel Terdiman/CNET News.com)

CLARKSDALE, MISS.–When in Rome, as they say.

As part of Road Trip 2008, my journey through the South in search of several weeks’ worth of stories, I had accepted an invitation to come to this tiny town in northwest Mississippi for the opportunity to visit one of the most important Blues clubs in the country.

It turns out that the club, the Ground Zero Blues Club, is co-owned by actor Morgan Freeman and the father of a friend of mine. Lured by the opportunity to talk with the two of them about airplanes–since I’d heard that Freeman and his business partner were avid pilots–I’d not really thought too much about the Blues.

The truth is, I’m not much of a Blues aficionado myself. To be sure, I’ve seen a few shows in my day: B.B. King in Jerusalem; John Lee Hooker once or twice; and a couple of other concerts. And I’d certainly listened to my share of Stevie Ray Vaughan.

The stage at the Ground Zero Blue Club in Clarksdale, Miss. The club is home to nightly Blues shows and is co-owned by attorney Bill Luckett and actor Morgan Freeman.

(Credit: Daniel Terdiman/CNET News.com)

But when I planned to come to Clarksdale, Blues was not my highest priority.

Silly me.

In the end, Freeman wasn’t in town, as he is in New York performing in a play. But my host, attorney Bill Luckett, treated me to an evening at his club, and I will readily admit that it was an experience to remember.

For one, the club is a flash-point for fans of the Blues. And Clarksdale, home to the Crossroads, where legendary bluesman Robert Johnson is said to have sold his soul to the devil in return for great musical talent, is why. Right there, at the intersection of US-61 and US-49, now appropriately across the street from a fried chicken chain, there’s a can’t miss it sign with a bunch of guitars held aloft and the word “Crossroads” for all to see.

But there’s no actual Blues being played there. And good thing, too. In keeping with Mississippi’s reality as one of the poorest, most neglected states in the nation, the Crossroads site is right next to a several abandoned lots and there’s rubble everywhere. As Luckett told me, someone had said to him recently that Clarksdale was reminiscent of Beirut. And I can sort of agree.

Back to the Ground Zero Blues Club, though.

We spent Friday night there, listening to a signer called Razor Blade wail away. And it was just great. He was the real deal: Old, weathered skin, a rich deep voice, a great fedora on his head and an unbelievable apprentice helping him out.

The exterior of the Ground Zero Blues Club, which I drove to in my Subaru Outback 2.5 XT. The club is only eight years old, but has the look of a club that has been running continuously for many, many years.

(Credit: Daniel Terdiman/CNET News.com)

The kid, a 15-year-old named, I believe, Anthony, knocked our socks off. He came out on stage, looking tentative and playing a little timidly at first. And then, suddenly, he just started jamming, and everyone in the place was blown away. This is a major talent in the making.

The club itself is only eight years old, but already it is attracting visitors from all over the country and the world. I’m sure Freeman’s involvement is a big part of that, but it’s mainly because it’s home to the real Blues: unpretentious, fantastic music that appeals to a diverse crowd that mixes with little regard to the racial politics that have always been so prevalent in Mississippi.

This was certainly a departure from what most of Road Trip 2008 has been about. But how could I come to the cradle of the Delta Blues and not make a stop to actually listen to some?

I couldn’t, that’s how.

Afterwards, I got back on the road, heading for New Orleans on US-61, the Blues Highway and a lush green respite from the Interstates that I’ve mostly had to drive on this journey.

Please stay tuned to the rest of Road Trip 2008, here on this blog, and on my Twitter feed, and my Qik channel.

Q&A: Google’s open-source balancing act

Posted on June 29th, 2008 in Uncategorized | No Comments »

Chris DiBona’s job–manager of Google’s open-source programs–is a balancing act.

Google consumes a lot of open-source software for its own highly profitable business. But as he oversees the search powerhouse’s open-source work, DiBona has to ensure that the company reciprocates. It can’t be all take and no give.

Chris DiBona, Google’s manager of open-source programs

(Credit: Stephen Shankland/CNET News.com)

Free and open-source software advocates can be powerful allies–but also vocal critics. For example, some have critized Google for its lack of support for the Affero GPL license, which can require those using software for a publicly available network service to share modifications they’ve made to an AGPL software project.

DiBona thinks Google strikes the right balance, though, by offering its own modifications back to many open-source projects, advocating the philosophy in general, and trying to nurture the next generation of open-source programmers.

DiBona has been steeped in open-source software for more than a decade. Before his job at Google, he worked for Slashdot, still an influential virtual water cooler for open-source discussion. Slashdot was part of Linux server maker VA Linux Systems, which had a spectacular initial public offering in 1999 followed not long after by a drastic cutback.

DiBona will be preaching the open-source gospel at the Google I/O conference Wednesday–”open source is too good to be true and thus must be magic,” according to the agenda–but I sat down with him beforehand to hear his view of open-source software at Google.


What’s the view of open source within Google?

I asked myself, “Who am I trying to address?” The world of open-source business? No. The world of the open-source enthusiast? No. I’m really looking to work with open-source developers. We came up with these goals for our group: to support open-source development in general, which means to support open-source infrastructure; support the release of open-source code, from Google and in general; and to create more open-source developers, because especially when I started, there was a perception that Google took a lot of people from the open-source world and then went away. It was partly true, because people would come here and say, “Wow, I’ve been working on my open-source project forever, and I want a new problem,” and we have a very good class of new problem. So they kind of went away.

That was too bad. The last thing we wanted as a company was to hurt the release of open-source software, because we consider it pretty important. We use a ton of it. Every engineer we bring on–how much open-source do they want to use? We have new packages and new libraries being brought into the company all the time. It’s our group’s job to track that. As we brought people in, we wanted to be sure more open-source developers were being created. So that’s where we came up with the Google Summer of Code, and now we have a high-school flavor of that as well. I think we’ve made a very real impact in creating new people in the open-source world.


I’m curious about maintaining a balance between contributing back to upstream projects vs. maintaining your own internal forks. How do you go through that evaluation?

Google considers some projects more important than others. Obviously the Linux kernel is incredibly important. Every time you use Google, you’re using a machine running the Linux kernel. We have a fairly large kernel team, and we employ people whose job is just to work on the external kernel. Andrew Morton is a good example of that. We try to make sure those guys patch out (submit their modifications to the main open-source project) whenever they can. It’s usually more dictated by the engineer’s time than it is any lack of desire on our part. I always wish we were able to release more, but it takes time for an engineer to do that. For the larger efforts, it’s a little easier because there are more personnel on it.

The same thing goes for our compilers (software that translates programmers’ code into instructions a computer understands). The great thing about our compiler team is they patch as a matter of their jobs. They’re always patching out things from the compiler work we do internally to the outside world. We recently released the new linker, Gold–Ian Lance Taylor works for us on our compiler team. He’s been on the GCC team forever. He used to be at Cygnus (a company that developed GCC). We have a lot of ex-Cygnus people.

Then there are Googlers who just want to patch into an existing projects. They found a bug, they want to add a feature. That takes no time at all. Our team looks at the first couple patches an engineer wants to send out, makes sure the engineer knows what they’re doing with the outside world, then they’re basically given free rein to do that. They keep us posted on what they’re patching. We want to make sure our code gets out to the projects as fast as possible because projects keep on iterating. If you don’t get your patches in, they won’t get accepted, because they’ll be too old or won’t matter. If you’ve got a patch, getting it out there fast is better for us, because then as that project iterates and comes back into the company, we don’t have to reapply a patch.


What are the most important open-source projects you ingest?

The kernel, compilers–GCC, the Python interpreter. Python is very important to us. Google App Engine–it’s a Python hosting system, basically. Java is very important to us, and that’s become open-source now. We have some very good Java people working for us–Josh Block, Neil Gafter–they’ve got a great handle on that technology.

Once you get past those three projects–the compilers, the languages, the kernel–then you go to the libraries. For us that’s OpenSSL, zlib, PCRE. MySQL is hugely important to us. Past that, it starts tapering off pretty quick.


Has the open-sourcing of Java changed anything for you?

Not really. I think it had more impact on the outside world than for us. Java is a fairly mature language now. We’ve been using it for a long time. Before, it was the JCP (the Java Community Process to govern Java’s future)–it had the rubric of openness around it. It was never really not so open. There are questions around what open source means now around Java, specifically J2ME (Java’s mobile edition for gadgets such as cell phones) and the TCK (the technology compatibility kit).


Are you using a super-uber-customized Linux kernel, or are you guys pretty much vanilla?

I don’t think there’s such thing as a customized Linux kernel anymore. The kernel is incredibly flexible. It’s got all these different architectures. I think the Linux kernel itself is this ubercustomized thing.


But do you have a lot of in-house customizations?

Not a lot. Google is exposed to some interesting hardware before the rest of the world. So internally we’ll be sampling code for that hardware. So that’s pretty custom stuff. But eventually that goes to the outside world. We funded some work with a group in Berkeley called Xorp to bring high-speed Broadcom networking chip functionality to Linux. It’s not in our interest to keep control of it ourselves. So is it customized? Absolutely. But is it heavily customized? I don’t think it is as heavily customized as you might think.


Is it true you still use 2.4 kernels?

In some places, sure.


How about for the core search product?

I don’t know how it’s partitioned out. When you think of Google, you think of search being on top of a kernel that’s static. It’s not always like that. It differs on data centers. I think 2.6 predominates, though.


There’s been discussion about reciprocity. When General Public License (GPL) version 3 came out, the Free Software Foundation dumped the Affero clause out of GPLv3 and split it out into a separate license. Eben Moglen (co-founder of the Software Freedom Law Center and then counsel to the Free Software Foundation) said, to paraphrase, “If Google starts getting too parasitic, then we’ll re-evaluate it.” How worried are you of getting a negative perception of using more than you contribute?

I do worry about this. I think it is a largely incorrect perception. You can always give out more, and there are always people who will never be satisfied. Could we be giving back more? Sure. One of the ways I ameliorate that problem is (through) projects like the Summer of Code. Google is releasing every year, not counting Android or the really large open-source projects like GWT, a new project every two or three weeks. Or patching hundreds of projects a month. I conservatively estimate we’re releasing about a million lines of code a year from the company.

If you talk to open-source developers–people who are working on projects–I think they understand that. It came back to who do we want to interact with. I always felt the enthusiast community would understand that eventually, and I think that’s true. There are some people who are upset with us because we didn’t embrace the Affero-style GPL, but it’s not practical for us to do so. When they had an Affero-style clause in GPLv3, the thing I told Eben was, “Listen, you can adopt whatever you want. We’ll still keep on backing up the FSF and the SFLC as much as we can, but it means we won’t be able to use that license inside, because it won’t be practical for us to do so.” I think that’s a very realistic response. The Affero GPL is out there. That’s great for the people who use it. It’s just not for us.

That’s the thing about free software. You’re not obligated to use it. We have enough fine-grained control within the company that we don’t use things we don’t want to use.


What are your preferred licenses?

We generally release under the Apache License–Apache 2. We think it has the fairest language of the licenses. And the GPL requires a lot of management–more than we have time for to run a project well under that license–patch flow and all that. Apache 2 encourages people to take the thing and run with it. That’s what we’re going for when we release code, whether it’s to have people adopt technologies we really like, or for API examples. That said, we’ve released things under the GPL, LGPL, GPL version 3, BSD. We default to the Apache License.


To what extent to you subsidize gurus to sit around and work on important projects?

We’ve got people like Jeremy Allison and Andrew Morton and some of Guido (van Rossom)’s time. He’s been working pretty heavily on Google App Engine and Mondrian. It’s more common that we…try to make open source a part of their job, so they’re patching out to the libraries they use. We think that’s more healthy than having people whose job is just working on an open-source project.


You use open source a lot internally. Do you have some kind of intellectual property vetting or review before you use it?

We do. There are two ways we do this. When somebody wants to bring a piece of code in from the outside world–open-source or commercial–you need to put it inside a special directory we call “third party.” They’re required to put in a file called readme.google (that describes) where they got that software, how it’s licensed, what category that license falls under. We look for things that are obvious. There are some projects that have dubious intellectual property provenance, and we know those, and we know the people who run them, and we tend not to use those ever.

Since Google doesn’t distribute a lot of software, we have it easier than companies that ship hardware and software. We have a couple situations where that does happen–the Google Search Appliance, some of the downloadable applications. Those get a little extra attention. Similarly, when we have larger projects like Google Android, we have a higher ceremony–every two weeks we get together and see if the license picture has changed.

The tracking model works really well for us. We have tools written where a program manager or a release manager can turn on a certain level of warning within the build tool and it will tell them what open-source software they have and how they have to comply with it. At that point we set up a mirror for them as they get closer to release.

So that’s the first way we track things. The second way is whenever a Googler puts in a changelist now–this is something we’re just starting to do–we compare it against all known open-source code on the Internet using our Code Search product. We compare the changelist that comes from your average Google engineer against that database of code and we look for intersections. When we find an intersection, we take a look and see if it’s truly a copy. And if it is, we make sure it’s in the right directory and that it’s properly labeled. And we call up the engineer if it isn’t and make sure it gets tagged properly so we can do the right thing by these licenses.

That tool is kind of in its infancy. We’re trying to figure out ways to automate what it does. But it’s great because it scales programmatically. Our group’s goal is not to break builds or stop development. It’s to enable developers to use as much open-source as possible. We think it’s healthy, because then they’re not writing that code, they’re writing other code.


Do you vet code for patent or copyright?

No. We have legal people on our lists. We have two main lists that track these things. Open-source licensing for incoming code and open-source releasing for outgoing code. Legal has a presence there. Patents are incredibly tricky.


Is it easier to get hired at Google if you have experience maintaining your own open-source product or patch?

If you have made a name for yourself in open source, clearly it helps. If you have a healthy project in open-source, I believe it helps. One thing I see on hiring committees is when somebody has an open-source history, it’s really great. You can just look at that history. Interviews are great, but they’re not very deep. They’re only 45 minutes long. So how can you really get a feel for if a person is good at programming, at computer science?


Or at social relations, for that matter.

Open source really reveals that incredibly quickly. You can look at their code, at their activity on mailing lists, how they deal with bugs from real people, and real user problems. That’s an incredible resource.

The Summer of Code isn’t really a recruiting program. If it is, it’s a really expensive one. Last year we created about 2 million lines of open-source code across the 900 students who took part. Of those probably a third are going to stick around with their projects, because the rest have to go back to college.

We have a couple students who have been in the program two or three years. The whole point is to support kids over the summer so they can go and program and not get some other job that has nothing to do with computer science. It’s our fourth year doing it. This year we’ve go 1,109 students doing it across 95 countries.

Review: 2009 Nissan GT-R

Posted on June 29th, 2008 in Uncategorized | No Comments »

It must be Christmas, because a 2009 Nissan GT-R showed up in our garage. Just like how we spent 1973 transfixed by commercials for the Vertibird Rescue Ship toy, we slathered over every specification sheet and photo of the new GT-R since the concept was shown at the 2005 Tokyo Auto Show. And in each case, we finally ended up at the controls of one. The GT-R is definitely the biggest, baddest toy on the block.

The GT-R is essentially a race car made for the street. Production cars don’t generally squeeze 480 horsepower out of a V-6, or have the transmission mounted at the rear axle. And the incredibly rigid suspension feels as if it was made for a race car. The car looks impressive and brutish, a theme that carries into the cabin and the driving feel. The Corvette Z06 has some scary competition in the GT-R.

Read the review.

Research: Old data centers can be nearly as ‘green’ as new ones

Posted on June 28th, 2008 in Uncategorized | No Comments »

SANTA CLARA, Calif.–Revamping existing data centers can achieve energy efficiency close to those built from scratch to be greener, according to an early report Thursday from Accenture, which analyzed results of case studies backed by the Silicon Valley Leadership Group.

The energy savings explored, if widespread, could prevent the release of carbon dioxide equivalent to taking 8 million cars off the road, researchers said.

Data center energy use could double by 2011, amounting to $7.4 billion in U.S. electricity costs and requiring the equivalent of 10 new power plants, according to the Environmental Protection Agency.

“Just because you’re not (running) a new data center doesn’t mean you can sit back,” said Teresa Tung, senior researcher at Accenture Technology Labs, which pooled results of studies in which Lawrence Berkeley National Laboratory and tech heavyweights including Yahoo, Sun, and Oracle collaborated.

Online activity may exist in the cloud, but for each e-mail sent or movie downloaded, a “little puff of carbon” is emitted somewhere on the back-end, as Sun vice president of engineering Subodh Bapat has described.

Projected growth in IT power consumption outpaces that of any other industry, noted Ray Pfeifer, chair of data center efficiency for the Silicon Valley Leadership Group, which organized a summit at Sun’s headquarters, where study results were presented.

“People are saying there are five fuels: coal, nuclear, gas, and oil. But efficiency is the fifth fuel.”

–PK Agarwal, CTO for state of California

Many tech leaders fear the sector will suffer from rising energy costs and anticipated California caps on carbon emissions.

Some consider their data center details to be trade secrets, but more are opening up to each other to try to reduce the industry’s carbon footprint. Case in point, some say, are the collaborative demonstration projects, which put into practice recommendations on data center efficiency (PDF) presented to Congress in 2007 by the EPA.

New data centers using the suggested technologies could achieve 79 percent infrastructure efficiency, according to Tung of Accenture. Older data centers applying the tweaks weren’t far behind at 74 percent efficiency.

A holistic approach to IT transformation can reduce the electrical use of data centers better than individual site improvements, Tung added.

Useful systems included airflow management with variable fan drives and water side economizers. In addition to promoting consolidation and virtualization, researchers underscored the importance of better managing virtual environments.

Standards are needed to improve security and optimize the virtual environment, said David Thompson, chief information officer at Symantec, which he said saved $40 million through consolidating data centers last year.

Sun Microsystems has reduced its number of data centers from a dozen five years ago to seven today, said chief information officer Bob Worrall, adding that he’d like that to drop to three data centers in the next several years.

“People are saying there are five fuels: coal, nuclear, gas, and oil,” said PK Agarwal, chief technology officer for the state of California. “But efficiency is the fifth fuel.”

The full report of the data center demonstration projects’ results is set to become available July 11.

Other data center hosts for the case studies were Symantec, NetApp, Synopsys, the U.S. Post Office, and Digital Realty Trust. Also participating in the research were SynapSense, APC, Cassatt, IBM, Liebert, Modius, Power Assure, PowerSmiths, Rittal, SprayCool, the California Energy Commisison, and PG&E.

Google Grab bag: Gmail limits and more

Posted on June 28th, 2008 in Uncategorized | No Comments »

Here’s a roundup of recent juicy Google tidbits:

Q&A: Google’s open-source balancing act

Posted on June 28th, 2008 in Uncategorized | No Comments »

Chris DiBona’s job–manager of Google’s open-source programs–is a balancing act.

Google consumes a lot of open-source software for its own highly profitable business. But as he oversees the search powerhouse’s open-source work, DiBona has to ensure that the company reciprocates. It can’t be all take and no give.

Chris DiBona, Google’s manager of open-source programs

(Credit: Stephen Shankland/CNET News.com)

Free and open-source software advocates can be powerful allies–but also vocal critics. For example, some have critized Google for its lack of support for the Affero GPL license, which can require those using software for a publicly available network service to share modifications they’ve made to an AGPL software project.

DiBona thinks Google strikes the right balance, though, by offering its own modifications back to many open-source projects, advocating the philosophy in general, and trying to nurture the next generation of open-source programmers.

DiBona has been steeped in open-source software for more than a decade. Before his job at Google, he worked for Slashdot, still an influential virtual water cooler for open-source discussion. Slashdot was part of Linux server maker VA Linux Systems, which had a spectacular initial public offering in 1999 followed not long after by a drastic cutback.

DiBona will be preaching the open-source gospel at the Google I/O conference Wednesday–”open source is too good to be true and thus must be magic,” according to the agenda–but I sat down with him beforehand to hear his view of open-source software at Google.


What’s the view of open source within Google?

I asked myself, “Who am I trying to address?” The world of open-source business? No. The world of the open-source enthusiast? No. I’m really looking to work with open-source developers. We came up with these goals for our group: to support open-source development in general, which means to support open-source infrastructure; support the release of open-source code, from Google and in general; and to create more open-source developers, because especially when I started, there was a perception that Google took a lot of people from the open-source world and then went away. It was partly true, because people would come here and say, “Wow, I’ve been working on my open-source project forever, and I want a new problem,” and we have a very good class of new problem. So they kind of went away.

That was too bad. The last thing we wanted as a company was to hurt the release of open-source software, because we consider it pretty important. We use a ton of it. Every engineer we bring on–how much open-source do they want to use? We have new packages and new libraries being brought into the company all the time. It’s our group’s job to track that. As we brought people in, we wanted to be sure more open-source developers were being created. So that’s where we came up with the Google Summer of Code, and now we have a high-school flavor of that as well. I think we’ve made a very real impact in creating new people in the open-source world.


I’m curious about maintaining a balance between contributing back to upstream projects vs. maintaining your own internal forks. How do you go through that evaluation?

Google considers some projects more important than others. Obviously the Linux kernel is incredibly important. Every time you use Google, you’re using a machine running the Linux kernel. We have a fairly large kernel team, and we employ people whose job is just to work on the external kernel. Andrew Morton is a good example of that. We try to make sure those guys patch out (submit their modifications to the main open-source project) whenever they can. It’s usually more dictated by the engineer’s time than it is any lack of desire on our part. I always wish we were able to release more, but it takes time for an engineer to do that. For the larger efforts, it’s a little easier because there are more personnel on it.

The same thing goes for our compilers (software that translates programmers’ code into instructions a computer understands). The great thing about our compiler team is they patch as a matter of their jobs. They’re always patching out things from the compiler work we do internally to the outside world. We recently released the new linker, Gold–Ian Lance Taylor works for us on our compiler team. He’s been on the GCC team forever. He used to be at Cygnus (a company that developed GCC). We have a lot of ex-Cygnus people.

Then there are Googlers who just want to patch into an existing projects. They found a bug, they want to add a feature. That takes no time at all. Our team looks at the first couple patches an engineer wants to send out, makes sure the engineer knows what they’re doing with the outside world, then they’re basically given free rein to do that. They keep us posted on what they’re patching. We want to make sure our code gets out to the projects as fast as possible because projects keep on iterating. If you don’t get your patches in, they won’t get accepted, because they’ll be too old or won’t matter. If you’ve got a patch, getting it out there fast is better for us, because then as that project iterates and comes back into the company, we don’t have to reapply a patch.


What are the most important open-source projects you ingest?

The kernel, compilers–GCC, the Python interpreter. Python is very important to us. Google App Engine–it’s a Python hosting system, basically. Java is very important to us, and that’s become open-source now. We have some very good Java people working for us–Josh Block, Neil Gafter–they’ve got a great handle on that technology.

Once you get past those three projects–the compilers, the languages, the kernel–then you go to the libraries. For us that’s OpenSSL, zlib, PCRE. MySQL is hugely important to us. Past that, it starts tapering off pretty quick.


Has the open-sourcing of Java changed anything for you?

Not really. I think it had more impact on the outside world than for us. Java is a fairly mature language now. We’ve been using it for a long time. Before, it was the JCP (the Java Community Process to govern Java’s future)–it had the rubric of openness around it. It was never really not so open. There are questions around what open source means now around Java, specifically J2ME (Java’s mobile edition for gadgets such as cell phones) and the TCK (the technology compatibility kit).


Are you using a super-uber-customized Linux kernel, or are you guys pretty much vanilla?

I don’t think there’s such thing as a customized Linux kernel anymore. The kernel is incredibly flexible. It’s got all these different architectures. I think the Linux kernel itself is this ubercustomized thing.


But do you have a lot of in-house customizations?

Not a lot. Google is exposed to some interesting hardware before the rest of the world. So internally we’ll be sampling code for that hardware. So that’s pretty custom stuff. But eventually that goes to the outside world. We funded some work with a group in Berkeley called Xorp to bring high-speed Broadcom networking chip functionality to Linux. It’s not in our interest to keep control of it ourselves. So is it customized? Absolutely. But is it heavily customized? I don’t think it is as heavily customized as you might think.


Is it true you still use 2.4 kernels?

In some places, sure.


How about for the core search product?

I don’t know how it’s partitioned out. When you think of Google, you think of search being on top of a kernel that’s static. It’s not always like that. It differs on data centers. I think 2.6 predominates, though.


There’s been discussion about reciprocity. When General Public License (GPL) version 3 came out, the Free Software Foundation dumped the Affero clause out of GPLv3 and split it out into a separate license. Eben Moglen (co-founder of the Software Freedom Law Center and then counsel to the Free Software Foundation) said, to paraphrase, “If Google starts getting too parasitic, then we’ll re-evaluate it.” How worried are you of getting a negative perception of using more than you contribute?

I do worry about this. I think it is a largely incorrect perception. You can always give out more, and there are always people who will never be satisfied. Could we be giving back more? Sure. One of the ways I ameliorate that problem is (through) projects like the Summer of Code. Google is releasing every year, not counting Android or the really large open-source projects like GWT, a new project every two or three weeks. Or patching hundreds of projects a month. I conservatively estimate we’re releasing about a million lines of code a year from the company.

If you talk to open-source developers–people who are working on projects–I think they understand that. It came back to who do we want to interact with. I always felt the enthusiast community would understand that eventually, and I think that’s true. There are some people who are upset with us because we didn’t embrace the Affero-style GPL, but it’s not practical for us to do so. When they had an Affero-style clause in GPLv3, the thing I told Eben was, “Listen, you can adopt whatever you want. We’ll still keep on backing up the FSF and the SFLC as much as we can, but it means we won’t be able to use that license inside, because it won’t be practical for us to do so.” I think that’s a very realistic response. The Affero GPL is out there. That’s great for the people who use it. It’s just not for us.

That’s the thing about free software. You’re not obligated to use it. We have enough fine-grained control within the company that we don’t use things we don’t want to use.


What are your preferred licenses?

We generally release under the Apache License–Apache 2. We think it has the fairest language of the licenses. And the GPL requires a lot of management–more than we have time for to run a project well under that license–patch flow and all that. Apache 2 encourages people to take the thing and run with it. That’s what we’re going for when we release code, whether it’s to have people adopt technologies we really like, or for API examples. That said, we’ve released things under the GPL, LGPL, GPL version 3, BSD. We default to the Apache License.


To what extent to you subsidize gurus to sit around and work on important projects?

We’ve got people like Jeremy Allison and Andrew Morton and some of Guido (van Rossom)’s time. He’s been working pretty heavily on Google App Engine and Mondrian. It’s more common that we…try to make open source a part of their job, so they’re patching out to the libraries they use. We think that’s more healthy than having people whose job is just working on an open-source project.


You use open source a lot internally. Do you have some kind of intellectual property vetting or review before you use it?

We do. There are two ways we do this. When somebody wants to bring a piece of code in from the outside world–open-source or commercial–you need to put it inside a special directory we call “third party.” They’re required to put in a file called readme.google (that describes) where they got that software, how it’s licensed, what category that license falls under. We look for things that are obvious. There are some projects that have dubious intellectual property provenance, and we know those, and we know the people who run them, and we tend not to use those ever.

Since Google doesn’t distribute a lot of software, we have it easier than companies that ship hardware and software. We have a couple situations where that does happen–the Google Search Appliance, some of the downloadable applications. Those get a little extra attention. Similarly, when we have larger projects like Google Android, we have a higher ceremony–every two weeks we get together and see if the license picture has changed.

The tracking model works really well for us. We have tools written where a program manager or a release manager can turn on a certain level of warning within the build tool and it will tell them what open-source software they have and how they have to comply with it. At that point we set up a mirror for them as they get closer to release.

So that’s the first way we track things. The second way is whenever a Googler puts in a changelist now–this is something we’re just starting to do–we compare it against all known open-source code on the Internet using our Code Search product. We compare the changelist that comes from your average Google engineer against that database of code and we look for intersections. When we find an intersection, we take a look and see if it’s truly a copy. And if it is, we make sure it’s in the right directory and that it’s properly labeled. And we call up the engineer if it isn’t and make sure it gets tagged properly so we can do the right thing by these licenses.

That tool is kind of in its infancy. We’re trying to figure out ways to automate what it does. But it’s great because it scales programmatically. Our group’s goal is not to break builds or stop development. It’s to enable developers to use as much open-source as possible. We think it’s healthy, because then they’re not writing that code, they’re writing other code.


Do you vet code for patent or copyright?

No. We have legal people on our lists. We have two main lists that track these things. Open-source licensing for incoming code and open-source releasing for outgoing code. Legal has a presence there. Patents are incredibly tricky.


Is it easier to get hired at Google if you have experience maintaining your own open-source product or patch?

If you have made a name for yourself in open source, clearly it helps. If you have a healthy project in open-source, I believe it helps. One thing I see on hiring committees is when somebody has an open-source history, it’s really great. You can just look at that history. Interviews are great, but they’re not very deep. They’re only 45 minutes long. So how can you really get a feel for if a person is good at programming, at computer science?


Or at social relations, for that matter.

Open source really reveals that incredibly quickly. You can look at their code, at their activity on mailing lists, how they deal with bugs from real people, and real user problems. That’s an incredible resource.

The Summer of Code isn’t really a recruiting program. If it is, it’s a really expensive one. Last year we created about 2 million lines of open-source code across the 900 students who took part. Of those probably a third are going to stick around with their projects, because the rest have to go back to college.

We have a couple students who have been in the program two or three years. The whole point is to support kids over the summer so they can go and program and not get some other job that has nothing to do with computer science. It’s our fourth year doing it. This year we’ve go 1,109 students doing it across 95 countries.

Subaru announces the Stella electric concept car

Posted on June 27th, 2008 in Uncategorized | No Comments »

The Stella concept has an electric powertrain.

(Credit: Subaru)

Subaru announced today a follow-up to its R1e electric mini-car, a bigger electric car built on its Stella platform. The Stella is a four seat car sold in Japan, narrow but tall. The electric Stella concept uses a 40 kilowatt electric motor powered by lithium-ion batteries. This powertrain gives it a maximum speed of 62 miles per hour and a range of 50 miles.

Subaru built the electric Stella concept to test out a car with more practical interior space than the R1e. Five of the Stella concepts will be used at the G8 Hokkaido Toyako summit in July, while one will be used by the Japan Post Group to deliver mail around Toyako. This real-world test is similar to the deal Subaru made to provide two R1es to the New York Power Authority.