Dear Google: Here's your roadmap out of Android Honeycomb hell

Google's Honeycomb tablet OS is rife with problems. But the issues extend to the entire Android ecosystem. Here's how they can dig their way out.

Well, my tough love article on Android Honeycomb yesterday has fuelled the fires on an interesting pair of responses from my ZDNet colleagues. I suspect that with the chord that it has struck with a lot of folks that at least a few more are still in the works.

Ed Burnette, probably one of the smartest guys I know when it comes to Android development, suggests that Honeycomb isn't rotten to the core, but rather, the fundamentals are good, and it needs a year of tweaking and another generation to become appropriately productized.

Okay, I agree with that on principle.

However, he also notes that Google's tablet OS has been the unfortunate recipient of "Malignment" by writers like myself and WSJ's Walt Mossberg (who essentially issued the kiss of death to Honeycomb's LG's G-Slate today) and John Paczkowsi that are giving the software a terrible reputation a la the mass condemnation of Microsoft's Windows Vista from a few years ago. Riiiiiiiiiiight.

Also Read: Is Honeycomb Android's Vista? (Dev Connection)

Look, Ed. There's a big difference between Vista and Honeycomb -- Vista was a product based on 20 years of development and success with previous OS products by Microsoft and a much, much larger scale project that was plagued by substantial cases of managerial misalignment and organizational differences between the goals of the Consumer division and the Server division.

Members of the mainstream and technology press, myself included, were fully justified by beating the hell out of Microsoft for releasing it in the state it was in. The implementation was awful. Even Ballmer himself was pretty much forced to admit it when Windows 7 came out.

Also Read: Ding Dong, The Vista's Dead!

On the other hand, Windows Server 2008 was excellent, worked pretty much flawlessly and used the same kernel and drivers and basic systems architecture as Vista. The difference? Once it left the "Core" team at the company and got in the hands of the consumer division, it got mucked up, and it took Microsoft some time to clean up their act and put out a unified front and a clear strategy for both the Server and Desktop products with Server 2008 R2 and Windows 7.

Google has a totally different set of problems. First, Android is an operating system that has only been under development realistically since 2003. While it is based on heavily on Java and Linux, to suggest that it is a mature product even in its smartphone implementation -- where it is currently enjoying a vast amount of success is a stretch.

By comparison, Apple's iOS has only been productized since 2007, but we have to remember that the technologies it uses is based on continuous work by successive generations at NeXT and Apple since 1985.

As sophisticated and as powerful the technologies in Android are, there's an awful lot of continuity and stability that Cupertino has to its advantage which Google doesn't have the benefit of relying on. Google doesn't build OSes traditionally as part of its core product strategy. This is a completely new game for them, relatively, compared to Apple and Microsoft.

Additionally, Apple has virtually no hardware variation to contend with because there are no OEMs. Nobody has to build custom kernels and software overlays to support 40+ branded flavors of iPhones and iPads. Google, on the other hand, has many OEMs that do. And it appears that if you want to stabilize your experience and get the most out of Honeycomb today, you need to root your device and swap out your kernel.

That's just fine if you're a developer like Ed that knows exactly what's going to blow up in his face or a very knowledgeable end-user like Scott who enjoys tinkering with Linux and firmware and are willing to work around issues to make things work.

Also Read: Motorola XOOM versus Galaxy Tab 7, A Study in Usability

But consumers aren't Android developers like Ed Burnette or veteran Linux system admins like Scott Raymond. If Google really thinks they can air their dirty underwear on their front porch and expect consumers to try it on like they do with GMail and other "Perpetual Beta" products, then they have all of their priorities completely out of whack.

[Next: Google, Here's Your Sign.]»

The Wharton School at the University of Pennsylvania has a very concise analysis of this conditionon their blogwhich I think is well worth reading.

Honeycomb is not ready for the average consumer. The operating system software itself is in a state of heavy transition, the applications at large are not properly optimized for it, the ecosystem is not being properly curated and the hardware OEMs and the carriers themselves are not being given appropriate guidance or the tools to help them succeed with their products.

But all of this can be fixed. To do that, however, Google needs to make some very substantive changes.

First, I think that Google needs to adopt a standard for running Android using hardware abstraction methods, such as through a Type 1 mobile hypervisor. I've beaten this horse to death before, but now that I've seen the abortion of Honeycomb first hand and hearing numerous reports of how stability varies greatly from hardware OEM to hardware OEM, I think they need to give this serious consideration for the entire platform.

Also Read: Android Virtualization, It's Time

Once a mobile hypervisor is included as part of the entire Android stack, Google needs to distribute the "Kasherized" gold master virtual machine image as part of its release schedule which all smartphones and tablets should be based on, and a clear, well-defined compatibility matrix as well as requirements that the carriers and manufacturing licensed "Google Experience" devices must follow which should include mandatory set timelines for over-the-air updates of the official VM.

Additionally, a clear End of Life roadmap for devices that cannot take an updated hypervisor or run a newer version of the VM needs to be published, so as not to string the consumer along in the hopes they'll get an official update.

If the community at large wants to address those folks it's fine, and you should give them all of the tools to do this -- but don't make people wait a year to hope their device will get an update from the OEM.

And by the way, Google, release the damn source you're giving to your OEMs to the community at large regardless of the condition it's in. That would help a great deal.

This is a proven recipe for participation, engaging your developer community and Open Source software improvement, as evidenced by successful projects such as Ubuntu.

I would expect, for example, that with this new software release methodology, that phones and tablets of the same hardware generation from all the OEMs running a standard hypervisor should be able to update their OSes over a 30-day timeframe, after a gold master image is released, allowing for branding changes and built-in value-added applications.

Next, Google needs to impose order on the chaos that exists in Android Market. Not only does the Market itself on Honeycomb need significant refinement, but the apps need to be cut off by what APIs the VM is running on the device. For example, if this system were in place today, native 3.0.X apps should get their own section (as they do now) and then I would cut off anything that won't correctly run on Gingerbread.

Throw all the legacy junk in the garbage where it belongs.

This is the only way the OS is going to get any kind of application quality control. It's worked successfully for Apple on iOS on their App Store, and it will work for Google and Android. Any developer who cares about their code and monetization whatsoever will ensure that their smartphone app conforms to run on a gold master 3.x or 2.x VM.

Next, Honeycomb and Gingerbread, Smartphone and Tablet need to have a consistent, uniform user experience. Nobody who uses an Android smartphone should have to mentally context switch between that and a tablet because the UI's are radically different.

Google needs to run a bunch of serious usability studies to figure this out, as opposed to letting developers and engineers decide what they think is good for us. Apple can afford that level of arrogance because it has decades of experience in this. Google doesn't. They need to learn what customers want, and learn it quickly.

There's a bunch of other things which Google can do to ensure the success of their smartphone and tablet OS, but I think this is a good start. Talk Back and Let Me Know.