Underexposed

MOUNTAIN VIEW, Calif.--Google didn't invent open-source programming or pioneer the mobile-phone software market, but when it comes to its Android project, don't accuse Google of playing follow the leader.

Although the company has long used open-source software within its internal operations, Android is Google's highest-profile attempt so far to use the collaborative programming method to change how computing is done outside the company's walls.

Andy Rubin, head of Google's Android project.

(Credit: Stephen Shankland/CNET News.com)

Google is hardly the first company to try using open-source software to shake up the industry. What's notable is Google's willingness to ruffle feathers in the open-source world, including those of potential allies such as Red Hat, with its approach.

Google is bucking some open-source conventions by avoiding the fashionable General Public License (GPL) to govern the software and creating the software internally before involving outsiders. At the same time, though, it's been easing gradually into the mainstream open-source fold.

"Initially their approach was almost like a proprietary product approach," said John Bruggeman, chief marketing officer of Linux seller and Android partner Wind River. "I think they have adjusted all elements of that strategy as they go. It's much more open-source friendly, more developer friendly."

And though Google's path might be somewhat different, the company has a decidedly ordinary open-source destination in mind: building a broad, cooperative community to thwart a Microsoft hegemony.

Andy Rubin, the Google engineering director leading Android, likens today's chaotic hodge-podge of mobile phone software to the early days of personal computers. In mobile phones, though, Microsoft has begun offering integrated software ranging from office applications and a Web browser at the high level down through the operating system kernel at the low level, and that full suite has a powerful appeal to phone manufacturers.

"It's a repeat of what happened in the PC industry. We want to make sure there's an alternative," Rubin said. But Google doesn't want to be the sole gateway to its software. "We wanted to make sure there's not a single source, (so) if a carrier or user or third party encountered a problem, they could fix it themselves."

Android is massive open-source project--or at least it will become one when the first phones start shipping later this year. The recent version 2.6.24 of the Linux kernel has about 8 million lines of code, but about 8.6 million lines of Android's 11 million are open-source, Rubin said.

Android components that will emerge as open-source software include Nuance's speech-recognition software and PacketVideo's music and audio decoder. Google also has been working to obtain hardware specifications to support mobile-phone chips from Qualcomm, Broadcom, and Sirf, he said. "You'll see our stuff being the first Linux on Qualcomm," Rubin said.

Closed first, then open
But that open-source release will be complex. Depending on how it manages the task, Google could face praise or scorn later this year when it unleashes that code upon the world. The hardest part is not just sharing the code, but in integrating outside developers into a project that's been growing within a company's confines.

There's nothing technically wrong with an open-source project that's solely run by a single company, but it's rarely any company's open-source goal. It's not likely to attract outside coders who want to make a name for themselves by adding important new features or corporate allies that might fund their own contributions.

Google's closed start doesn't sit well with Red Hat Chief Technology Officer Brian Stevens, whose company is among the most aggressive advocates of open-source software.

"I think that decreases their chance of success more than it increases it," Stevens said. "It's preventing the participation of many smart developers who want to get involved in the development of the Android platform...The community comes at the early inception of a product, not when you decide you're ready to ship a product."

Mike Schroepfer, Mozilla's vice president of engineering, added that in general, corporate attempts to make open-source projects out of proprietary software are often hampered by an unwillingness to share control.

"People think publishing the source code is the hard part, but the harder thing by far is having open participation in the decision-making--distributing authority outside your four walls," Schroepfer said. "Where some of these really go wrong is when people aren't empowered and their voices don't matter, they're not going to do participate."

Google won't face the challenges of full-on proprietary software going open-source, though, said Redmonk analyst Stephen O'Grady: the open-source move is part of the Android plan, not a development that arrived years later.

The open-source hand-off
Google has its reasons for the closed start.

"We want to get to the point where it's stable enough," Rubin said. Then, after the open-source change, "We want it to be thriving."

The software components that constitute Android.

(Credit: Google)

The company is working on the hand-off to the outside world. Android already is a project whose development is distributed among the Open Handset Alliance members collectively backing Android, for starts, as well as among multiple international Google offices. "We're learning how to do a large-scale distributed effort," Rubin said.

The company also has a team more 10 strong working on external developer relations for Android, Rubin said. That team that will grow larger once the code is released and absorbs the Google "maintainers" in charge of Android components, such as its Dalvik virtual-machine software for running applications written in Java.

Google's team under open-source project manager Chris DiBona, combined with some from the Android project, will work with outside programmers, Rubin said. "The developers I have on core development of this, when it gets open-sourced, will move over and will be coding for the open-source tree," or code base, he said.

Google also is taking a community-centric approach to defining what Android is. Project maintainers get to accept or reject contributions, as is common in the open-source realm. What's new is that Google will offer a certification test suite that's based on those maintainers' work in order to maintain compatibility among different versions of Android.

"If it passes, then they get to use the Open Handset Alliance Android trademark name," Rubin said. "We're not saying you can't branch. We're saying you don't want to branch."

Licensing choices
Google has been criticized for not working with existing open-source projects. In addition, Sun Microsystems has expressed concern that Google's development of Dalvik could fragment the Java world so that Java software for running Android applications wouldn't work on other Java phones and vice versa.

A sample Android application, AndroidGlobalTime

(Credit: Google)

But Google chose to go it alone with Dalvik and some other projects for one big reason, Rubin said: it wanted to avoid the GNU General Public License (GPL). The pioneering license that serves in effect as the manifesto of the Free Software movement requires that software projects derived from a GPL product also be released under GPL. That concept in effect requires reciprocity: if you use GPL code and distribute the resulting software, you must contribute your changes back to the GPL code base.

Google didn't want to raise that issue, uncharitably referred to as the GPL's "viral" nature, for phone makers that might want to add proprietary features as a way to differentiate, so it chose the less confining Apache License, Rubin said.

"The thing that worries me about GPL is this: suppose Samsung wants to build a phone that's different in features and functionality than (one from) LG. If everything on the phone was GPL, any applications or user interface enhancements that Samsung did, they would have to contribute back," Rubin said. "At the application layer, GPL doesn't work."

Of course, giving back is precisely one of the intents of the license, which Richard Stallman initially wrote to govern a clone of Unix that couldn't be made proprietary; many companies have embraced the GPL, including initial skeptics such as Wind River. And other embedded-computing efforts are using GPL software more widely.

"It's a pretty conservative interpretation," Bruggeman said of Google's GPL stance.

Open-source advocates long have wrestled over whether it's better to permit companies to make code proprietary, as the Apache License permits, or to compel them to keep it open, as the GPL requires. Even though Android uses the Linux kernel, which is governed by the GPL, don't expect Google's position to put an end to this debate.

For that matter, don't expect Rubin's present thoughts to be the final word. The company has shown itself willing to change.

"Here's what I think. No. 1, they're learning as they go," Bruggeman said. "No. 2, they learn really fast."