ÜberMobile


Google Copies Microsoft, Not Apple, To Fix Android Fragmentation

Google Copies Microsoft, Not Apple, To Fix Android Fragmentation

Summary: At its I/O conference today, Google made a move to help solve the much-discussed fragmentation of the Android mobile OS.

SHARE:

This is smart, and long overdue. Google said today that it will begin releasing an Android Platform Development Kit (PDK).

This will give Android device makers access to coming versions of Android 2-3 months before its official release.

As is well-documented, most Android devices are way behind. 65% today run Android 2.3 Gingerbread which, with the release of 4.1 JellyBean today, now lags 3 versions behind.

The PDK isn't a cure-all, but it will hopefully allow OEMs to release new smartphones and tablets running up-to-date versions of Android.

This will also help them update their older smartphones and tablets sooner, too (though there the mobile carriers remain bottlenecks).

How is this like Microsoft? With its open Windows hardware ecosystem, Microsoft also faces problems of fragmentation and also failure-to-upgrade. Indeed, Windows XP remains more popular than Windows 7, despite being more than a decade old (it was released in fall 2001).

That's not because PC makers are bad at releasing new hardware on the latest OS. They are actually quite good at that, due to all beta versions that Microsoft provides early, all of the testing support it offers, and all of the ecosystem marketing that Microsoft in general does.

No, the reason XP is still so popular is because enterprises still go out of their way to erase Windows 7 from a new PC and re-install XP, in order to make it easier to manage and to support old, XP-only software.

Releasing an Android PDK several months in advance is a small step towards replicating the Microsoft ecosystem model, something Google would probably only grudgingly admit to be doing.

Apple, by contrast, has no hardware partners. It hires contractors to help make hardware that it alone designs and sells. Thus, it doesn't need to give early access to iOS to third-party hardware makers. It does allow developers to get new versions of iOS 2-3 months before it is released to users of its iPhone or iPad, though. Fortunately, that's all the time that some developers need.

Google I/O-Mostly for Consumers

Google's major announcements at I/O - the Nexus Tablet, the Google Play, Project Glass - are all aimed primarily at winning consumers by beating Apple and Amazon.

But any reduction in Android fragmentation is a double win for enterprises. As noted above, enterprise IT hates fragmentation more than consumers because it adds work for them on the Mobile Device Management (MDM) side and also increases insecurity.

Because of the Consumerization of IT, though, Google's consumer-oriented moves also impact the enterprise. The $199 Nexus 7 tablet will quickly find its way into organizations via BYOD. Even if Amazon comes out with a $149 Kindle, as rumored, I think we'll see more Nexuses be more accepted inside companies because it will run a more standard, easy-to-manage version of Android than Amazon's tablet.

Looking forward a year or two, Google Glass could pioneer a better sort of tech tool for field service applications than the ruggedized laptops and tablets used today. It's $1,500 price tag, while high, doesn't look bad compared to pricey ruggedized gear. And when Glass actually becomes available to end users, as opposed to developers, its price will no doubt drop.

Topics: UberMobile, Smartphones, Security, Mobility, Mobile OS, Microsoft, Hardware, Google, Apple, Android

Eric Lai

About Eric Lai

I have tracked technology for more than 15 years, as an award-winning journalist and now as in-house thought leader on the mobile enterprise for SAP. Follow me here at ÜberMobile as well as my even less-filtered musings on Twitter @ericylai

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

1 comment
Log in or register to join the discussion
  • Fragmentation

    "enterprise IT hates fragmentation more than consumers" - This is a double entendre, just so you're aware.

    Fragmentation is a huge problem because of the necessity of maintaining code across major versions and the vulnerability of unpatched systems among minor ones. When a backend implementation changes, the user doesn't care much, but it might affect the software they use. Similarly when the GUI changes, the user needs to be retrained, but developers don't need to update their code.

    The compatibility features in Windows XP and beyond (Compatibility Mode, SxS, etc.) is a step forward in maintaining usability of code. I would argue that improving the detection of versions in the case of Compatibility Mode would be helpful but that's not the huge issue it once was. The most commonly mentioned problems now are large changes in the GUI between versions. Regardless of whether or not the new GUI is a usability improvement over the previous version, retraining costs will be a factor in adopting new versions, which provides a difficult problem for GUI designers. Even if the change is slow and gradual a user upgrading from version M to version Q will still be hit with huge changes.

    Therefore it makes sense to maintain features between versions as upgrades occur. I'm not suggesting we need to keep the DOS style from Windows 3.1. Rather that while an OS is expected to remain active, its GUI features should be maintained in the newer versions, which runs completely counter to the philosophy being employed in Windows 8.

    If you make the new GUI an option, but add minor features that are similar to the major changes elsewhere, it would be easier for most users to understand the changes once they are mandatory. For example: Rather than forcing the ribbon on Office users all at once, they might have the option of choosing the "old" or "new" style when they first launch the program, but add ribbon-like features elsewhere in the program. Later on when a major update is installed they might be given the option again and decide "yeah, I'd like to try that." Of course these minor changes shouldn't impact user productivity, otherwise you'll be giving them another reason not to upgrade.

    Simply giving the person the option is not enough though. Show them the changes that will be made and explain why things were changed in the dialog being presented. They probably won't care, but it'll make them feel more comfortable, because the changes weren't simply "because I said so." People don't like to be forced into new things when they don't understand that there was actually a reason behind the modification.

    If such a strategy were to work, then the maintenance of older major versions could be dropped sooner, without negatively impacting the mass majority of users. I think this could change the way we approach old code by helping to remove the reasons legacy support is needed in the first place. When you consider that this idea primarily causes storage rather than processing overhead, and that dropping maintenance of older code sooner would offset development on such versioning features, it seems to me like this is a win-win solution for both the end-user and the developer. Perhaps such a philosophy wasn't possible in earlier days, but with cheap hard drives commonly exceeding 500 GB, space is generally no longer an issue.
    Zatronium