The More You Tighten Your Grip...

By Zigurd Mednieks
April 7, 2011

Two events have recently given Android, an otherwise spectacularly successful project, a black eye:

  • Motorola's Xoom tablet launched late, under-cooked, over-priced, and mis-marketed. Consequently Xoom sold in disappointing numbers.
  • Andy Rubin, the leader of the Android project at Google, recently announced that publishing the source code of Android Honeycomb will be delayed.

Let's take a look at why that happened, and whether and how it could be different.

An overview of Android governance and licensing

First, let's take a look at how Google governs the open source Android code and how Google and its partners use it in products.

The Android Open Source Project (AOSP) is the open source project that provides access to the Android source code that roughly corresponds to the Android system that shipped with the most recent new release of Android in a device, excluding the proprietary Google applications, and excluding proprietary code created or licensed by the handset manufacturers.

AOSP includes a complete tool chain, and has build options that enable anyone to build and run the AOSP system on some commercially available Android devices. For this reason, AOSP is a remarkably open and accessible system for mobile handsets.

The AOSP source code lags Android development inside Google. That is, Google develops new versions of Android without disclosing source code until the new version ships on a commercial product. Android, therefore, does not enable contributors outside of Google and some select partners to contribute substantially to the development of Android, and Google retains complete control over the content of the AOSP project, over product planning, and over AOSP project governance.

All Android applications run on AOSP, and all parts of the Android system that are included in AOSP provide functionality identical to commercial products. It's even easy to install the proprietary Google applications to a device running AOSP to get a very close approximation of a commercial Android system that you can modify and port (but not sell) in any way you please.

AOSP does not include a suite of applications, among them Android Market, GMail, and Google Maps and Navigation, that are not open source projects, but that are included in most commercial Android devices. While, through some simple bootlegging, individuals can create systems that function like commercial Android products, manufacturers cannot legally provide a complete Android product without licensing the closed-source Google applications.

Google has never publicly stated all the reasons behind the approach of mixing nearly complete openness in the core Android system with proprietary applications and an opaque set of manufacturer and carrier relationships. The effect has been that Google retains power over which manufacturers and carriers get to make and distribute Android mobile phones and tablets. In hindsight it is hard to say the strategy and the execution of the strategy were less than highly successful, with every first tier OEM except RIM and Nokia making Android handsets, and every carrier's stores selling them.

Google has faced some challenges in retaining control over Android, including cases where carriers have concluded deals that seem to be a threat to Android's purpose in spreading the use of Google's services to mobile phone users. For example, some Verizon Android handsets come with Microsoft's Bing search installed in a way that replaces Google Search. The replacement is incomplete and awkward, and is an insult to customer experience. Even in cases that are less of a bad idea, and less of a thumb in Google's eye, Android has been bastardized by some manufacturers trying to enhance it. It's enough to make lesser companies think twice about open-sourcing their mobile operating systems.Give Google lots of credit for the openness they have shown so far.

Honeycomb, handsets, Xoom, and Google TV

Android has been a smashing success in handsets, but Google has stumbled sometimes.

More recently, Google has broken with past practice in not releasing source code to Honeycomb. The stated reason is that "compromises" were made to get Honeycomb to market faster - the "you would't like me when I'm compromised" defense, one supposes. The reality is likely to be more complex: Google may be obligated to give some manufacturers a head start, or they may worry that more-aggressive manufacturers would put more resources on a Honeycomb product than their closer partners, embarrassing them with more-finished products, or be less cooperative in the effort to get Honeycomb products to market.

"The more you tighten your grip, Tarkin, the more star systems will slip through your fingers."

Google's unwillingness to release Honeycomb source code has dismayed many. But, looking beyond what is probably a temporary disenchantment with the way Android is opened up through AOSP, we wonder: Is it still to Google's advantage to be so conservative about revealing Android source code and how tightly relationships with manufacturers are controlled?

Honeycomb came to market in a hurry, with compromises, and Google TV failed within the same development and go-to-market strategy that made Android mobile handsets a success. TVs and tablets are not dominated by the same manufacturers as mobile phones and are not distributed through a tightly controlled channel as phones are, being sold in the U.S. primarily in carriers' shops, and with carriers' approval. Is the same tight control over who makes and sells Android products other than phones the right approach to these product categories and markets?

Would opening Android source code faster, engaging more contributors to the Android Open Source Project, and providing a transparent process for licensing the proprietary bits that would enable products on an equal footing with most Android mobile phones make Android a better platform? Would this more-open Android be more likely to succeed in cases where, it seems, Google's ambitions exceeded its ability to develop Android inside a closely controlled model? There are some reasons to think so.

The likeliest counter-arguments to greater openness and transparency in the partnering process are:

  • It's hard to argue with the success of the way Android has been run and AOSP governed, so far.
  • Tablet and other markets are not as big, or important, as mobile handsets, and therefore changing the Android development model for these markets amounts to taking one's eye off the ball.
  • Manufacturers outside the top tier are unimportant.

All these hold true if a continuation of the early stages of mobile handset success is the main objective, but that is difficult to support: Google has, in fact, stumbled with Android outside of mobile handsets. Manufacturers have run ahead of Google and created tablet products that filled the gap before Honeycomb was ready, and Google hasn't taken advantage of the opportunity in that.

Tablets are likely to eat in to the market for PCs, and achieve numbers comparable to smartphones and PCs. But licensing the supposedly open Android system isn't as transparent as licensing Windows for PCs. ViewSonic, Creative Labs, and Archos, to name a few, are reputable manufacturers, but they have been locked out of using Honeycomb in their tablet products. Barnes & Noble's Nook e-reader has proved to be a popular Android tablet, after some simple hacking. By attempting to pick winners in markets outside of mobile handsets, Google has eliminated upside surprises in the Android tablet business.

How might the development of Android tablets have played out differently if more first-tier manufacturers than just Samsung had been able to "bend the rules" and deliver Android tablets before Honeycomb shipped, and with Google's proprietary applications? First, it's obvious that Google's other partners in developing tablets would feel less taken advantage of. Unlike Samsung, others such as LG and Motorola waited to deliver their Honeycomb tablet products, subsequently felt they could wait no more, and ended up pressurizing Google into a too-soon release of Honeycomb.

Greater participation requires earlier openness in the development process. Greater participation would very likely yield a smoother evolution of Android. Some of the Android tablet products that predate Honeycomb are a pleasure to use. It is very likely that a more-open consortium of manufacturers would have made Android's entry into tablets timelier and smoother. One way it could have happened: Google could have put the Android Compatibility Package, which enables earlier version of Android to run Honeycomb applications, to good use as a way of introducing important Honeycomb features and kept Honeycomb under wraps until it was really ready.

Were the decisions that guided Android to the top of the mobile handset heap right? Manifestly yes, moreover, early in Android's development, Android had to shake things up in Linux: Evolving from an existing Linux userland would have been a dead end. Android not only had the right approach at first, it had leadership with iron determination to do what it took to achieve a different result than other Linux phone OS projects. But now that Android is branching out to other markets, and now that Android has a following of developers and device makers that is larger than Google can engage one-to-one in selective projects, the governance, licensing, and development models for Android need to change.

Openness scales better

Here are some specific steps Google can use to change the way Android is developed and brought to market:

  • Create an open beta program for Android that would give device-makers and developers a look at next-generation Android systems early enough to plan their hardware and software products.
  • Move the Android Market application to the Android Open Source Project, allow Android system makers to redistribute the proprietary Android applications, and put all the proprietary Android applications in the Android Market so that all Android devices are on an equal footing.
  • Elevate the Android compatibility test to an official qualification for allowing systems that pass the test to include Google's proprietary applications.
  • Make greater use of Android's capabilities in enabling diverse hardware and software configurations that apps can query and adjust for, to enable a wider range of price and features in Android hardware.
  • Make licensing terms transparent for all parts of a commercial Android product, and open to all who qualify.

A more open Android will inevitably lead to failed products. Some manufacturers shouldn't be making some Android products. But, the current regime could not prevent Verizon and Samsung from creating a misbegotten Bing-loaded Android, and it couldn't stop Motorola from shipping too soon. One has to question the ability of Google to actually prevent bad user experiences, as they claim to be doing by delaying the release of Honeycomb source code.

Customers will have to discern a bad Android from a good one whether Android is more or less open. A more-open Android, however, will lead to a greater chance of some manufacturer hitting the sweet spot in tablet price and capability sooner, and might have led to a viable Google TV. As we come to a phase in Android's development where we are likely to see Android Media Player and Android Car and Android Thermostat and Android Washing Machine, Google is going to be under more pressure to scale-up the way Android partnerships with developers and manufacturers are managed. Greater transparency and openness are the simplest ways of making the wide dispersal of Android throughout a large variety of settings as fast and as successful as possible.


You might also be interested in:

News Topics

Recommended for You

Got a Question?