Instead, he says the developer community would have to develop those features. Tseng wouldn't let us see an Android phone, although he did say that he has been using one 'for months' as his primary phone. It's possible that Google has deferred all of the power and capability of Android to the user base, which would be disastrous.
The platform seems to be less a competitor to the Blackberry or iPhone and more like a marginal gadget such as the Chumby Wi-Fi radio, which also relies almost entirely on user-created open source apps for innovation. Many of these apps are clunky and poorly designed. Still, the results of the development challenge reveal that there is hope for the platform, even if the specifics are still sketchy. Google has been saying for some time that the first Android-powered devices will ship by the end of 2008.
There's another major challenge in store for Android, however. If the OS does support innovative APIs for multitouch, haptics and other features, and if the developer community creates some truly innovative apps, Google must also contend with the complexities of dealing with mobile phone carriers.
In most cases (other than the Apple iPhone), carriers dictate not only what services are offered on a phone, but which software. For example, on the Motorola Q in the US, Sprint dictates exactly how you can download and use a ringtone. You can't just download any ringtone and use it on the phone. Google seems to think that mobile carriers support open-source software just as much as it does, which is not true.
Energy initiatives
Google's energy initiatives are clearly designed to be an example. Some, in fact, seem a bit superfluous or over-the-top in terms of practical implications. For example, any employee can 'check out' a hybrid car – located in an openair shade port that is itself powered by a solar array on the roof – for a few hours. Considering there are just a handful of cars but the company has over 19,000 employees, it's hard to see how the hybrid car strategy is anything but an example to help encourage environmental awareness.
Similarly, six buildings and two parking garages at Google have solar arrays on the roof. In total, 9,612 panels provide about 1.6 megaWatts of power. They provide about 30 per cent of peak power usage, so it could be said that two out of every 10 computers is powered by solar energy.
Sign up for breaking news, reviews, opinion, top tech deals, and more.
The reason the arrays only provide 30 per cent of the total power has to do with the energy density of the office buildings. It's much higher than that of a typical home due to how many lights are on all day and the number of computers and other electrical components running.
Google App Engine
Looking back in time decades hence, it might be possible to say that Google officially built 'the computing cloud' on April 7, 2008. That's when the company released Google App Engine (formerly known as Big Table), an infrastructure for companies to host their applications on the web instead of internally.
There are several advantages to the cloud: easier maintenance, reliable archives, anywhere access and a common UI. Of course, App Engine also has a few intangibles and disadvantages, including privacy concerns when a company hands over its data to a web host, offline access (which Google counteracts with Google Gears), speed of access over the Internet and such hard to predict factors as programming environment.
Pete Koomen, the product manager for App Engine, says the project has been underway since the summer of 2007. When we talked to Koomen, it was unclear whether the company even had any customers using the project. "The motivation behind App Engine is to combat the challenges of developing applications," says Koomen.
"When you decide to build an application, you have to define and provision machines, configure SQL and Apache, configuring files – none of this is rocket science, but it takes time and money. The second challenge is when an app starts to get traffic it's difficult to scale – with SQL for example, you might have to shard up machines, de-normalising data – and a lot of this is not taken into account when they first start out."
Koomen says App Engine is the result of Google itself bundling and scaling applications – a trial by fire, so to speak – which benefits from its distributed server architecture. Essentially, this means any app will run with the resources it needs at the time of operation and scales automatically. Failover, load balancing and distributed data stores (data split over multiple machines) all contribute to the scalability. Developers can use Google authentication and email APIs.
Today, it runs only on Python, but Google is working on expanding the language offerings quickly. So far, most of the activity in the App Engine project has been related to research docs and requests submitted by users – it's still unclear exactly who is or will be using it, especially in light of the success of Amazon web services like EC2.
How many of these projects will be a raging success for Google is hard to tell. Android seems like it's an early platform that is untested and carriers may decide to abandon ship. Machine translation and computer vision are ongoing projects, but early demos for visual search show promise.
Universal search is a fully functioning part of its search platform today that is already evolving. These projects are key to understanding Google's future and legacy in technology – which is sure to be great indeed.