Google's Android work far from finished

As a wise man once noted, the waiting is the hardest part.

It's been nearly six months since Google sent ripples through the mobile phone industry with the announcement of its plans to develop Android, a Linux-based operating system. But after an initial splash, Google has been pretty quiet. So much so, in fact, that several representatives of companies within Google's Open Handset Alliance professed frustration at the ambiguity of some important details at the CTIA 2008 conference this week in Las Vegas.

Much is still up in the air, just a few months before the first phones are expected to arrive. Google has yet to make crucial decisions about the code base that will accompany Android; such as, which applications are required to make it an Android phone? How will that base be maintained into the future? And how much freedom will Android developers and partners really have to tweak the software?

Google is aiming high with Android. "Android has two goals: First, to be an excellent mobile platform on its merits, and second, to be open and open source," wrote Dan Morill, a Google engineer, on the Android Internals discussion board last week. But in this new world of advanced mobile computing, those goals can conflict.

The details of how Google chooses to release Android will make a huge impact on how it is received by the world. And Rich Miner knows it. Miner is in charge of Google's wireless business and along with Andy Rubin co-founded the original Android. He is presiding over a huge development project within Google, as the company works to develop a brand-new mobile operating system using the Linux kernel, code contributed by OHA members and internally developed code.

Much of the reason for Google's low profile since the November Android announcement is that the company wants to make sure it has everything nailed down before moving forward, Miner said in an interview this week. To date, it has released a software development kit, and is encouraging Android development with cash prizes.

Which applications will be included with Android, Google's first mobile operating system?

(Credit: Open Handset Alliance)

As of now, Google and its OHA partners have agreed on a basic set of parameters for Android, such as the screen resolution to be used and how the software will support various keypad styles like the classic 12-button phone or the BlackBerry-like QWERTY keyboard.

Beyond that, things are still very much in flux, although Miner points out that protracted debate is necessary to make sure all members of the OHA are happy with the final implementation.

"We've all lived through Java and similar initiatives where we've witnessed fragmentation, and it's a major goal to make sure we don't repeat mistakes we all have scars from in the past," Miner said.

Indeed, the need to avoid "fragmentation" came up multiple times in a 30-minute discussion with Miner. Carriers, handset makers, and chip developers clearly want a Linux-based mobile operating system that's pleasing to the eye and allows developers to build applications that can run across different phones. However, Android isn't the first attempt at this idea; it's more like the fifth.

The reason that many others have fallen aside is because a common platform was taken in dozens of different, incompatible directions. Miner was reminded of Sun, who used to hope that Java would be a "write once, run anywhere" tool that lets any application written for Java run on any device. Instead, different companies chose to implement Java in different ways, defeating some of the purpose.

Google, smartly, wants to avoid that. But avoiding fragmentation requires rules and regulations that might not seem so open.

"Open" is relative
For example, what basic applications will handset makers be required to include to call it an Android phone? "(We'll do) what worked well in the early days of PC cloning, we'll all pick a subset of applications that are good challenging applications" as requirements for shipping an Android phone, Miner said. But, the final decisions have not been made on which applications will make the cut.

Different handset makers, carriers, and chipmakers have different ideas about how Android phones should look, feel, and work. Everyone wants something that's easy to implement, but that lets them develop their own identity. Few companies in this industry really wants to be another HP/Dell/Acer clone maker, beholden to Google for incremental advances in features, capabilities, and presentation.

That's part of the reason why Android's open-source plans have attracted attention. AT&T, previously an Android holdout, is now showing signs that it might be interested in Android because the carrier can tweak Android to favor its services, according to AT&T Wireless President Ralph de la Vega.

It's not clear exactly how AT&T might do that, but his comments raise some questions. If, say, a music player running on an Android AT&T phone can only access AT&T's cellular network, or an AT&T-only music service, that application might not work with a Sprint phone.

So, might Google then decide to include a standard media player with Android that prohibits that kind of exclusion? In a way, that's open, since it's preventing AT&T from using its position as the largest carrier in the U.S. from locking developers into its network. But in another way, it's not open, since Google would be placing limits on what its partners could do with Android.

There are other questions about the level of Google's participation in the open-source community. The company will release Android under the Apache 2.0 software license after the first phone is released to the public, Miner said.

Google will open-source just about all of Android's components under the Apache 2.0 license.

(Credit: Open Handset Alliance)

That means that Google-developed pieces, like its Dalvik virtual machine, will be free for use by any developer. But Google has also made changes to dozens of existing open-source projects.

And all of those changes might not be appropriate for those projects, creating "forks" that Google will have to maintain. In the same discussion thread, Jean-Baptiste Queru, another Google engineer, acknowledges that a lot of the pieces of Android might not be useful for the rest of the community.

"I fully expect some of our changes to be fundamentally specific to Android, and fully expect that we will decide that we prefer Android to have those changes while the code maintainers upstream would rather not have those changes in their code," Queru wrote. This isn't unusual, but it will be harder for Google to create a vibrant open-source community around Android if developers aren't interested in Google's code.

Google also seems to be leaving the exact details of its open-source strategy until later, which is a bit unusual. "Our plan is that once we reach version 1.0, we will turn our attention to the squishier issues of releasing source," Morill wrote.

It's getting close to crunch time for Google's Android. To borrow a sports analogy, they're in the third quarter; plenty of time left, but it's time to develop a sense of urgency and figure out a plan for the current situation.

Google wants Android to be an open-source project so that it can marshall the open-source community's ideas and let its partners put their own stamp on the software. But it must also prevent Android from turning into a "25 operating systems for 25 carriers" mess of incompatible fiefdoms that defeats the very purpose behind Android's creation.

Its trump card might be that Android, and the Open Handset Alliance, are not the U.N.

This is not a democratic process; Google is the final authority on anything discussed within the OHA, Miner said. "That's the difference between a standards body and an engineering team."

After all, it's Google first mobile operating system. You always remember your first one.