Fighting Fragmentation with Mobile Virtualization
Last week Motorola and T-Mobile announced the launch of a new and innovative Android-based smartphone, the Cliq. This attractive, feature-rich slider handset happens to build on a chipset and firmware that feature OKL4 inside. Definitely cool, but not the focus of this blog entry.
The buzz about this new handset comes from Blur, the social media UI Motorola developed to run on top of Android. Blur aggregates messaging streams and content from Twitter, FaceBook, MySpace, Picasa and a dozen other portals and services. Like many new applications and services, Blur aspires to provide both an end-user experience AND a developer platform.
The dual nature of Blur has prompted cries of Foul and Fragmentation from a number of industry voices, especially from fans and followers of the underlying Android platform. At issue is that instead of augmenting Android, Blur could take on a life of its own, distracting developers and further fragmenting the already splintered smartphone software segment.
The potential for Android fragmentation has existed since Google launched the platform. The search giant and its partners in the Open Handset Alliance (OHA) chose the permissive Apache license to govern Android. Apache offers comfort to manufacturers (OEMs) but worries many that without other strong governance, those OEMs will fork Android to suit their own needs.
I won't argue the merit of these fears, nor of OHA's anti-fragmentation pledge. Instead, let's look at the issue from the OEM point of view. OEMs live in a crowded, noisy, competitive marketplace. To stand out, handset OEMs need to build and market highly differentiated devices with clear, branded added value. However, some of the leading mobile platforms run counter to that need. On one hand, they provide a rich user experience. On the other, they lock OEMs into a narrow look and feel and branding - a phone built with these platforms is first an instance of that software, and second, a product of the OEM. This type of commoditization, akin to the desktop PC marketplace, is anathema to mobile handset design.
So, it is completely comprehensible why OEMs would seek to customize, re-skin and re-brand a platform like Android. However, the further an OEM takes Android from its off-the-shelf architecture and APIs, the more difficult it becomes for ISVs and developers to target that device with the platform SDK and standard software.
I would like to posit an alternative to the trend (Full Post)