Archive for the motorola Category

Android Wobbly Shaky Ground MobilestanceWhat’s Behind What Some View as Android’s Growing List of Self-Inflected Problems. Conspiracy? Complacency? Or Raw Genius At Work?

At first glance, it might appear that things are going pretty well for Android.  The free-to-license mobile OS has quickly become popular among many cash strapped mobile OEMs (original equipment manufacturers). Heavyweights such as Samsung, Sony Ericsson, LG and Motorola, along with handset newcomers Garmin and even Dell (hold for laughter) have all announced plans to develop handsets for the Google-run platform.

Supposedly, T-Mobile even managed to sell roughly one million Android-powered HTC G1’s last quarter… a respectable, yet not exactly iPhone-worthy performance (but to be fair, Apple and AT&T set an impossibly high standard with iPhone 3G, accomplishing in three days what Android did in three months – who knew AT&T would deliver on their promise of “Raising the Bar” so literally!).

Yet a quick peek below the surface reveals a conflicting scenario emerging for everyone’s favorite “Little (open-source) engine that could.”  Depending on your point of view, the OS is either plagued with systemic flaws, or designed with a profound sense of Machiavellian perfection. The exceedingly real threat of viruses, worms and other forms of malware, combined with a system seemingly “design to fragment” (read: seriously frustrate application developers) leaves one wondering if (as the conventional wisdom would have you believe) that Android’s model scales so well, and its backers so powerful and smart, that it can’t fail to become a serious contender over the long term…  or what we’re really looking at is nothing more than “Yet Another (seriously flawed) Google Beta Product.”

The issue of Android’s well-publicized “open door” security policy reared its pathogenic head again last week in the form of an all-out malware scare, and although the jury’s still out on whether or not the now infamous “MemoryUp” application did (as was accused) take over a user’s mobile, spam out its contacts and wipe its memory, or is just (as was suspected by cooler heads), merely a poorly designed, near universally-panned app… the frightening fact remains that the only thing standing between us and just such a dark reality is the relatively low profile group known as the Android Security Team.

Unfortunately for Android users, this team (of which whose public presence appears to consist entirely of one message board post dated August 18, 2008) seems to operate in a decidedly passive capacity: rather than vigilantly seeking and tracking down security flaws wherever they might appear in the system, the model works more like a ticket-based complaint counter, addressing user-submitted security threats when (and only when) the Goog Squad is alerted to their presence by the public.  It would be as if the local police force was replaced by an automated 911 system (and we all know how efficient that system can be). While it wouldn’t be 100% accurate to say that “no one’s minding the Android App store” (er, market) – there’s far more truth in that statement than many are willing to admit.

Moving on, the other significant issue facing the Android system – that of the looming threat of OS fragmentation – has (unsurprisingly) garnered scant attention in the trade press.  I say “unsurprisingly” as so far the threat of OS fragmentation is fairly complex and has yet to be an issue as, with only one Android handset on the marketplace (so far) – the HTC G1 – there just isn’t that much of a marketplace to fragment.  That said, this issue seems to have some real legs, not to mention real intrigue, and is, in our opinion, very likely to seriously impede Android application development over the long term.

Before we get into all the wide-eyed intrigue and half-baked conspiracy theories, a little background information on the subject of OS fragmentation is in order.  At its core, the issue revolves around the fact that Android, as an open source software platform, freely publishes its source code to the world under the general assumption that under “the eyes of the world’s” constant viewing, tinkering, and deploying – the software will ultimately become more robust, stable and efficient than any system created and maintained by a finite number of (paid) employees.  As is the case with a great many subjects, the devil is in the details.  It seems that when Google formally launched the Android project back in late 2007, it chose the to advocate a licensing model (Apache) whereby third parties could maintain private ownership over any modifications made to Android’s publicly-available source code, and would not be compelled (as in other open source licensing models) to turn over said software modifications or enhancements back “to the public domain” – so that (among other reasons) these modifications could (potentially) be incorporated into future versions of the software… thereby making the whole system more unified, and less “fragmented.”

So here’s where things can really get messy.  As said, mobile handset manufactures designing smartphones are turning to Android in large numbers, driven mainly by its price point (free), as well as its many innovative design features.  That said, not all of these “Android” devices will be running the same version of Android, as handset manufactures will be under extreme pressure to modify Android in order to maximize the performance of the particular hardware components making up each of their individual handset models.  This means that Android developers will soon have to create multiple versions of each Android application they develop in order to insure that their apps will run correctly on each “version” of Android in the marketplace (i.e. all the different handsets running “Android”).  This time-consuming and labor-intensive process, known to overworked software developers the world over as “porting,” significantly drives up the cost of software development.  Ultimately, Android developers will need to limit the number of Android handsets they can support as simply a matter of cost/benefit.  This well-known problem has been identified as one of the primary barriers that has held up mobile software development to date, as the current crop of Java, Symbian and BREW feature phones are simply fragmented beyond belief.

We’ve already seen the beginnings of fragmentation in the Android system, as differences in handset specifications play out over the various geographic regions – and with the sheer number of players about to enter the space in the coming year this issue is bound to accelerate dramatically.  That said, it is inevitable that that this scenario will negatively impact the development of innovative, new applications for Android over the short term.  The only real question is to what extent will Android innovation be stymied?

What makes this issue to interesting to many is that, due to advocating the Apache licensing model for Android, Google seems to be actively encouraging Android fragmentation.  Ironically, this apparent paradox was first identified by Sanjay Jha, Chief Operating Officer of Qualcomm’s chipset division (ironic in that Qualcomm is one of the founding members of the Open Handset Alliance and the Android initiative!)  who, in a  Register story that emerged out of last Spring’s CTIA conference, was quoted as saying that “Google wants fragmentation in the [mobile] industry.”

Here’s where the conspiracy theories start kicking into overdrive.  Keeping all of this in mind, some have speculated that – in a thinly veiled strategy against its old desktop rivals (Microsoft), Google would potentially benefit from Android fragmentation in that it would be prohibitively expensive for any one developer to dominate any fragmented system with a mainstay-like platform such as Microsoft Outlook or Office, both “heavy clients” that rely on sophisticated software applications running on the device’s (local) hardware (e.g. the desktop PC, or the mobile handset).   A fragmented system would ultimately favor companies like Google that favor thin client / “cloud computing” models (e.g. Gmail and Google Docs), where all the application’s heavy lifting is done on the server side (via the network), rather than on the client side (i.e. the mobile handset) – in this case the actual applications on the client/handset side usually reside in nothing more than a decent web browser.  All of this poses a very intriguing question: Could Google be subtly sabotaging device-side Android application development in favor of its browser-based / thin-client model?

Bringing this post full-circle, it is possible that both these two issues (fragmentation and security) may cancel each other out, sort of… again, ultimately resolving in Google’s favor.   The theory goes a little like this:  The folks that write software viruses, worms and other such programs do so primarily for the notoriety that comes with affecting many systems/users all at once – either with benign or malicious intent.  Platforms that don’t scale simply are unappealing to most virus writers.  Similar to the natural virus protection afforded by using a niche desktop system such as a Macintosh (sorry guys, I love ya but you’re still using what I would consider a niche product), few developers will waste their time writing a virus that only affects a (relatively) small number of people, when they can get better “bang for the buck” elsewhere.  The same forces that make it prohibitively expensive for (most) application developers to support a wide range of devices in a fragmented system will also similarly affect virus writers.  In affect, by encouraging fragmentation, Google could be enhancing Android security while simultaneously crippling many of its former rivals in the desktop space (or is this giving Google just a little too much credit?).

Thoughts?  If you have an opinion, share it… as there’s nothing like a good conspiracy to spice up the industry some!


linux penguin bluetooth headset mobile stanceConsumer Dissatisfaction and the Macroeconomics of Mobility Provide Linux with the Opportunity to Achieve in Mobile What it Failed to Reach on the Desktop: Relevancy.

Last week Verizon Wireless was just the latest big player to jump aboard the Linux train. In joining the LiMo Foundation, “an industry consortium dedicated to creating the first truly open, hardware-independent, Linux-based operating system for mobile devices,” Verizon joins existing LiMo members Motorola, Samsung, Panasonic, NEC, NTT DoCoMo, Orange and Vodafone.

The Google / Verizon Open Access Wars Continue. Verizon’s move is consistent with it’s grudging embrace of “openness,” a relatively recent development and likely result of Google’s aggressive initiatives with their own Linux-based mobile initiative, the Open Handset Alliance (whose members read like a who’s who of the mobile ecosystem), as well as the search giant’s success in influencing the latest US spectrum auction to partially adopt “open access” rules. These rules prohibit the new “owner” of the highly sought-after “C-Block” of wireless spectrum to restrict network access – based on either device or software requirements. This was a landmark ruling by the FCC that upset established business practices by the US operators (especially Verizon Wireless).

Ironically (or by Google’s design, if you buy into the hype) Verizon Wireless, who vigorously pursued legal action against the Google-backed “open access” initiative, is by default its biggest backer, as the carrier ended up spending $9.4 billion to win the auction for the “open” C-Block wireless spectrum. Maybe “ironic” doesn’t quite cut it. “Asleep at the switch?”, “Poetic Justice? or just good old “Machiavellian Legal Mastery?” So much to think about I just can’t get my head even half way around this one… hopefully a “tell-all” book will hit the market and shed some light on what really happened here between Google, Verizon and the FCC.

Regardless, Verizon asserts that among its reasoning for joining the LiMo is that, unlike the Google-led OHA, LiMo software is truly open source (whereas Google maintains a relatively tight grip over its Linux-derived Android Mobile OS). That said, both operating systems are “open enough” in that developers are free to create and distribute highly robust mobile applications unencumbered by (the current) intellectual property and financial barriers maintained by the wireless carriers and (to some extent) the handset manufacturers.

All roads lead to Linux? In addition to all of this, macroeconomic forces also seem to be contributing to an environment favoring Linux as a mobile OS. With the majority of the world’s mobile users living under severely limited economic conditions (i.e. the so-called “developing” world), an open source product such as a Linux-based handset and / or application would enjoy tremendous price advantages versus competing proprietary models – and is therefore far better positioned to compete for the majority of the world’s mobile user base.

While the US mobile industry has yet to feel any real impact resulting from all of these developments, rest assured that big changes are coming – and soon. One only needs to peruse the recently announced finalists in the Android developers challenge to get a sense the coming spike in mobile innovation. The development of rich, life-enhancing applications like Android Scan, a promising app that integrates a traditional barcode reader with existing online databases to facilitate real time product comparisons and m-commerce, would simply not be possible under without an open mobile operating system and business environment unencumbered by powerful gatekeepers.

Now, it might be tempting to dismiss Linux-based mobile initiatives due to the failure of Linux to achieve success on the desktop. The various desktop Linux operating systems also enjoyed the considerable advantages of pricing and of an open development environment, and yet none of them realized anything more than marginal successes. Why should mobile Linux be any different?

The key lies in the differences between the development and limitations of the two channels. When Linux arrived on the market most desktop users were relatively satisfied with the PC computing experience. Sure, Microsoft (and Apple) products had their problems, but most users were content with the functionality and prices associated with the leading PC operating systems and applications. The same cannot be said for the mobile data space, where most users face an entirely opposite scenario: a high (perceived) priced product delivering a wholly unsatisfying experience.

Ultimately, perhaps the walled garden model that worked “well enough” in the desktop space just isn’t up to challenge in the more demanding environment of the mobile data space – a space far more restricted in terms of device size, bandwidth, processor power, memory and display resolution – and is inherently laden with costs far greater than that of traditional wireline data networks. Perhaps it is precisely this challenge that Linux is uniquely suited to overcome, and perhaps this is why Linux – and perhaps only Linux – will be the portal that will finally fulfill the promise of the mobile channel.