Should we care? Seriously. What tech titan hasn't been a megalomaniac? Bill, Steve, Zuck, Jack Ma , the folks who have tried to change the world want control. And understanding that control is ephemeral in this day and age, where sustainable competitive advantage may be measured in seconds, still, for the all the talk about open source and collaboration, the natural inclination appears to be that what's mine is mine and what's yours is mine. They are talking the talk but not walking the walk.
So it comes as no surprise that Google's subtle but firm grip on Android, as the following article explains, is more firm than subtle. And for good, strategic reasons. They are locked in a death match with Amazon, Apple, Facebook and maybe a couple of others. They do not want to appear threatening - at least to you and me and the others whose custom they seek - but that does not mask the fierce determination with which they view the competitive landscape and the behavior necessary to win and secure it.
The ultimate question is whether most people will even notice. We appear willing to trade some personal control for convenience and reliability. And maybe that's not a bad trade. It's just usually helpful to be aware that you've made one, is all. JL
Ron Amadeo reports in Ars Technica:
Android is open - except for all the good parts
Six years ago, in November 2007, the Android Open Source Project (AOSP) was
announced. The original iPhone came
out just a few months earlier, capturing people's imaginations and ushering in
the modern smartphone era. While Google was an app partner for the original
iPhone, it could see what a future of unchecked iPhone competition would be
like. Vic Gundotra, recalling Andy Rubin's initial pitch for Android,
stated:
He argued that if Google did not act, we faced a Draconian future, a future
where one man, one company, one device, one carrier would be our only
choice.
Google was terrified that Apple would end up ruling the mobile space. So, to
help in the fight against the iPhone at a time when Google had no mobile
foothold whatsoever, Android was launched as an open source project.
In that era, Google had nothing, so any adoption—any shred of market
share—was welcome. Google decided to give Android away for free and use it as a
trojan horse for Google services. The thinking went that if Google Search was
one day locked out of the iPhone, people would stop using Google Search on the
desktop. Android was the "moat" around the Google
Search "castle"—it would exist to protect Google's online properties in the
mobile world.
Today, things are a little different. Android went from zero percent of the
smartphone market to owning nearly 80 percent of it. Android has arguably won
the smartphone wars, but "Android winning" and "Google winning" are not
necessarily the same thing. Since Android is open source, it doesn't really
"belong" to Google. Anyone is free to take it, clone the source, and create
their own fork or alternate version.
As we've seen with the struggles of Windows Phone and Blackberry 10, app
selection is everything in the mobile market, and Android's massive install base
means it has a ton of apps. If a company forks Android, the OS will already be
compatible with millions of apps; a company just needs to build its own app
store and get everything uploaded. In theory, you'd have a non-Google OS with
a ton of apps, virtually overnight. If a company other than Google can
come up with a way to make Android better than it is now, it would be able to
build a serious competitor and possibly threaten Google's smartphone dominance.
This is the biggest danger to Google's current position: a successful,
alternative Android distribution.
And a few companies are taking a swing at separating Google from
Android. The most successful, high-profile alternative version of Android is
Amazon's Kindle Fire. Amazon takes AOSP, skips all the usual Google add-ons, and
provides its own app store, content stores, browser, cloud storage, and e-mail.
The entire country of China skips the Google part of Android, too. Most Google
services are banned, so the only option there is an alternate version. In both
of these cases, Google's Android code is used, and it gets nothing for it. It's easy to give something
away when you're in last place with zero marketshare, precisely where Android
started. When you're in first place though, it's a little harder to be so open
and welcoming. Android has gone from being the thing that protects Google to
being something worth protecting in its own right. Mobile is the future of the
Internet, and controlling the world's largest mobile platform has tons of
benefits. At this point, it's too difficult to stuff the open source genie back
into the bottle, which begs the question: how do you control an open source
project? Google has always given
itself some protection against alternative versions of Android. What many
people think of as "Android" actually falls into two categories: the open parts from the Android
Open Source Project (AOSP), which are the foundation of Android, and the closed
source parts, which are all the Google-branded apps. While Google will never go
the entire way and completely close Android, the company seems to be doing
everything it can to give itself leverage over the existing open source project.
And the company's main method here is to bring more and more apps under the
closed source "Google" umbrella.
Closed source creep
There have always been closed source Google apps. Originally, the group
consisted mostly of clients for Google's online services, like Gmail, Maps,
Talk, and YouTube. When Android had no market share, Google was comfortable
keeping just these apps and building the rest of Android as an open source
project. Since Android has become a mobile powerhouse though, Google has decided
it needs more control over the public source code.
For some of these apps, there might still be an AOSP equivalent, but as soon
as the proprietary version was launched, all work on the AOSP version was
stopped. Less open source code means more work for Google's competitors. While
you can't kill an open source app, you can turn it into abandonware by
moving all continuing development to a closed source model. Just about any time
Google rebrands an app or releases a new piece of Android onto the Play Store,
it's a sign that the source has been closed and the AOSP version is dead.
We'll start with the Search app, which is an excellent example of what
happens when Google duplicates AOSP functionality.
In August 2010, Google
launched Voice Actions. With it, the company introduced "Google Search" into
the (then) Android Market. These were the days of Froyo. The above picture shows
the latest version of AOSP Search and Google Search running on Android 4.3. As
you can see, AOSP Search is still stuck in the days of Froyo (Android 2.2). Once
Google had its closed source app up and running, it immediately abandoned the
open source version. The Google version has search by voice, audio search,
text-to-speech, an answer service, and it contains Google Now, the company's
predictive assistant feature. The AOSP version can do Web and local searches
and... that's it.
Google first demoed
its cloud music service at Google I/O 2010, and sure enough, that's about
when the AOSP music app was frozen in time. To this day, it still looks and acts
like a Froyo app.
Play Music has gained access to Google's cloud music storage, along with a
huge music store and subscription option. Play Music has also gone through
several user interface redesigns, gaining Equalizer and Chromecast support. The
two apps are so different now, it's hard to imagine that they once were the same
thing.
Calendar
Google Calendar was one of the more recent apps to get the closed source
treatment. The way this process is pitched
to the Android community is always rather amusing: The stock calendar is now
available to everyone! We can now do updates from the Play Store! There are more
features! (Oh, and by the way, it's closed source now.)
Since this was a recent split, there isn't much of a difference between the
two versions. Google Calendar will sync notifications across devices, and it's
gotten a cool new icon. I wouldn't expect the AOSP calendar to get these updates
anytime soon.
Keyboard
Even the keyboard is not safe from closed source creep. A few months ago,
Google added
Swype-like gesture typing to the stock keyboard, which was released as a new
app in the Play Store called "Google Keyboard." Guess where the source code for
that is? Not in AOSP. Above, you can see the settings for the two keyboards. The
Google Keyboard has options for swipe typing, and AOSP doesn't—it was abandoned
as soon as Google Keyboard was released.
Gallery/Camera
The Camera and Gallery are actually a single APK (Android application package
file). The AOSP version is called "Gallery2.apk," and Google's version is called
"GalleryGoogle.apk." As you can see in the above picture, Photospheres are
exclusive to the Google version—the innovative camera mode is not available on
AOSP. The open source version also omits any Google+ album integration. The
normal behavior is to display cloud-based Google+ albums alongside local
ones.
Here, though, we've got to give Google some credit. While the AOSP version
hasn't kept up in terms of features, the new design introduced in 4.3 has made
it to the Android source code.
The future
While it hasn't yet been released, the next app out the door is the stock SMS
app. Although folks are clamoring for Google Hangouts to integrate
text messaging and really go after iMessage, that would mean you'd be moving
Android's SMS functionality to a closed source app. Once Google does make the
switch, I predict that in one or two Android versions, you'll see the SMS app
disappear as a default app, similar to what Google did when it killed the stock
web browser in favor of Chrome (though most of Chrome is still open source).
When Hangouts does integrate SMS, the AOSP messaging app will be completely
abandoned. Messaging already seems halfway down the path to retirement. (It
hasn't seen a significant updating since its big redesign in Android 4.0.) So
when this finally comes to pass, you'll know what the subtext will be: the open
source texting app will be dead.
Also next on the chopping block is the open source Gallery. In leaked
pictures of KitKat, the next version of Android, there is a new icon called
"Google Photos." "Gallery," which alphabetically should be between "E-mail" and
"Gmail," is suspiciously absent. While we've never seen Google Photos before, it
shares the same icon as a current Google app called "G+ Photos." It looks like
the AOSP Gallery is going to die and be replaced by a service with a closed
source app that heavily depends on Google+. It's the ultimate expression of
Google's new walled garden.
Locking-in manufacturers
While Google is out to devalue the open source codebase as much as possible,
controlling the app side of the equation isn't the company's only power
play.
If a company does ever manage to fork AOSP, clone the Google apps, and create
a viable competitor to Google's Android, it's going to have a hard time getting
anyone to build a device for it. In an open market, it would be as easy as
calling up an Android OEM and convincing them to switch, but Google is out to
make life a little more difficult than that. Google's real power in mobile comes
from control of the Google apps—mainly Gmail, Maps, Google Now, Hangouts,
YouTube, and the Play Store. These are Android's killer apps, and the big (and
small) manufacturers want these apps on their phones. Since these apps are not
open source, they need to be licensed from Google. It is at this point that you
start picturing a scene out of TheGodfather, because these
apps aren't going to come without some requirements attached.
While it might not be an official requirement, being granted a Google apps
license will go a whole lot easier if you join the Open Handset
Alliance. The OHA is a group of companies committed to Android—Google's
Android—and members are contractually prohibited from building
non-Google approved devices. That's right, joining the OHA requires a
company to sign its life away and promise to not build a device that runs a
competing Android fork.
Acer was bit by this requirement when it tried to build devices that ran
Alibaba's Aliyun OS in China. Aliyun is an Android fork, and when Google got
wind of it, Acer was told
to shut the project down or lose its access to Google apps. Google even made
a public blog
post about it:
While Android remains free for anyone to use as they would like, only Android
compatible devices benefit from the full Android ecosystem. By joining the Open
Handset Alliance, each member contributes to and builds one Android platform—not
a bunch of incompatible versions.
This makes life extremely difficult for the only company brazen enough to
sell an Android fork in the west: Amazon. Since the Kindle OS counts as an
incompatible version of Android, no major OEM is allowed to produce the Kindle
Fire for Amazon. So when Amazon goes shopping for a manufacturer for its next
tablet, it has to immediately cross Acer, Asus, Dell, Foxconn, Fujitsu, HTC,
Huawei, Kyocera, Lenovo, LG, Motorola, NEC, Samsung, Sharp, Sony, Toshiba, and
ZTE off the list. Currently, Amazon contracts Kindle manufacturing out to Quanta
Computer, a company primarily known for making laptops. Amazon probably doesn't
have many other choices.
For OEMs, this means they aren't allowed to slowly transition from Google's
Android to a fork. The second they ship one device that runs a competing fork,
they are given the kiss of death and booted out of the Android family—it must be
a clean break. This, by design, makes switching to forked Android a terrifying
prospect to any established Android OEM. You must jump off the Google cliff, and
there's no going back.
Any OEM hoping to license Google Apps will need to pass
Google's "compatibility" tests in order to be eligible. Compatibility ensures
that all the apps in the Play Store will run on your device. And to Google,
"compatibility" is also a fluid concept that an Android engineer once internally
described as "a club to make [OEMs] do what we want." While Google now has
automated tools that will test your device's "compatibility," getting a Google
apps license still requires a company to privately e-mail Google and "kiss the
ring" so to speak. Most of this is done through backroom agreements and secret
contracts, so the majority of the information we have comes from public spats
and/or lawsuits between Google and potential Android deserters (see: Acer).
Another point of control is that the Google apps are all licensed as a single
bundle. So if you want Gmail and Maps, you also need to take Google Play
Services, Google+, and whatever else Google feels like adding to the package. A
company called Skyhook found
this out the hard way when it tried to develop a competing location service
for Android. Switching to Skyhook's service meant Google would not be able to
collect location data from users. This was bad for Google, so Skyhook was
declared "incompatible." OEMs that wanted the Google Apps were not allowed to
use them. Skyhook sued, and the lawsuit is still pending.
Testing the waters with bloatware
For most OEMs, leaving the Google ecosystem and still being successful is
nothing more than a pipe dream. One way for an OEM to experiment with a
Google-free existence without incurring the wrath of Mountain View is to produce
alternative versions of Google's apps. This is what most of us dismiss as
"bloatware." Bloatware works as a software engineering "what if" thought
exercise, where OEMs set out to replicate all of Google's core apps to see just
how hard life outside of the walled garden would be.
Samsung does a particularly "good" job of this, going as far as having its
own user account system, backend syncing, and app store. It also maintains the
most complete set of alternatives to Google apps. A lot of these, like Internet,
E-mail, and Calendar, have roots in AOSP, but Samsung continued to add features
long after Google abandoned them for closed alternatives.
On a phone with Google apps, it seems silly and redundant to have two
calendar apps. But many OEMs view bloatware as an important strategic fallback—a
"Plan B"—for if things ever get really bad. If Google does something out of line
and an OEM is forced to leave, the company needs at least something to show
prospective customers. OEMs include them with their shipping phones—because,
hey, why not?—and gain valuable feedback. While this creates redundancy and adds
to user confusion, a few users might even like the OEM's version of a core
app.
With such a huge list of alternative apps, it might seem like Samsung is
poised to jump ship at any moment, but replicating the Google apps is only a
small portion of the massive effort it would take to break free of the Google
ecosystem. The aspect of Android that an OEM really wants is the gigantic
third-party app selection. Google knows this is its biggest weakness, and the
company has started working to make the app ecosystem Google-dependent as
well.
We previously explored Play
Service's update implications, but it is a huge weapon in the fight against
Android forks. Play Services is a closed source app owned by Google and licensed
as part of the Google Apps package. Any feature you see move from "normal"
Android to Google Play Services is also moving from open source to closed
source. This app pulls off the neat trick of not only enticing users with
exclusive, closed source features, but locking in third-party developers with
Google's proprietary APIs as well.
Taking the Android app ecosystem from Google seems easy: just get your own
app store up and running, convince developers to upload their apps to it, and
you're on your way. But the Google APIs that ship with Play Services are out to
stop this by convincing developers to weave dependence on Google into their
apps. Google's strategy with Google Play Services is to turn the "Android App
Ecosystem" into the "Google Play Ecosystem" by making a developer's life as easy
as possible on a Google-approved device—and as difficult as possible on a
non-Google-approved device.
If you use any Google APIs and try to run your app on a Kindle, or any other
non-Google version of AOSP: surprise! Your app is broken. Google's Android is a
very high percentage of the Android market, and developers only really care
about making their app easily, making it work well, and reaching a wide
audience. Google APIs accomplish all that, with the side effect that your app is
now dependent on the device having a Google Apps license.
Google Maps API
The Google Maps API allows you to use Google's map data in your application.
It's extremely handy for things like overlying the weather on top of a map or
showing location in a travel app. The only problem is, it's part of Google
services and not part of Android. Relying on the Maps API means your app will
not work on a non-Google-approved device.
In response to this, Amazon was forced to license mapping data from Nokia and
build a working clone
of the Google Maps API. The company even has an instruction page
dedicated to migrating your app from Google Maps. Again, Google is all about
making life easy in its ecosystem and extremely difficult outside of it. If you
want to run on the Kindle, you now need to support two different Maps APIs.
It's a terrible situation for the Android forker, in this case Amazon, who
now has to deal with either paying license fees to Nokia forever or going out
and mapping the entire planet on its own. Amazon is also now required to keep up
with Google's break-neck pace of development: Amazon's Maps API supports Google
Maps API v1, but Google is already up to v2. If you're a developer and depend on
some new feature in the Maps v2 API, Amazon doesn't support it yet. Now you have
even more work to do.
Google Cloud Messaging
Google Cloud Messaging (GCM) is the easiest way to do push notifications on
Android, but you'll never see it on AOSP. GCM was recently added to Play
Services at I/O 2013, and it now includes not only receiving notifications, but
also pushing messages upstream. It's responsible for the newly added ability to
sync notifications across devices. Developers often use GCM to push breaking
news out to devices or to notify an app that new data is available and a sync
should be performed.
While Google Maps may seem like it would be used in a small amount of apps,
many more apps need push messaging in order to be any good. This is another
feature that Amazon was forced to copy in order to not be left behind. Its
version is called "Amazon
Device Messaging," and it only works on Amazon devices. Just like the Maps
API, you'll be doing extra work and testing for a very small subset of users.
Every feature of GCM might not be in Amazon's version, so you'll have extra work
to figure out ways around that.
Location APIs
At Google I/O 2013, Google revamped the
Android location APIs and released them as part of Google Play Services. In
other words, Android's top-tier location services are now closed source. If the
above history is any indication, the open source location stack will be left to
rot. The added features include the Fused Location Provider, a "complete
rewrite" of Android's location algorithms, Geofencing (which lets you define
locations on a map that will trigger events in an app when the user enters
them), and Activity recognition, which uses accelerometer data and fancy
algorithms to determine if the user is walking, biking, or driving—all without
turning on the GPS.
It made complete sense to put the Maps API and Google Cloud Messaging into a
proprietary app, as those services depend on Google servers to function.
However, moving over the entire location stack feels like a massive power grab
on Google's part. There are now two methods to get location: the good, low
power, closed source Google way, and the crappy, battery expensive, open source
way.
In-app purchasing
The best in-app purchasing on Android is done through the Google Play Store.
If a developer wants their app to work on a Kindle or in China, however, they'll
be stuck having to find another solution. This is another feature where, if you
want to have a viable AOSP fork, you'll have to replicate it, which is just what Amazon
did with the Amazon In-App Purchasing API. Samsung is
even in on the party, having introduced an in-app purchasing API two years
ago.
Play Games
Play Games is another proprietary API that solves a lot of difficult problems
for mobile developers. It provides easy access to user accounts, leaderboards,
achievements, cloud saves, anti-piracy, and (on Android) real-time multiplayer.
The best part is that works on just about everything: Web apps, iOS, and
Android. Well, everything except AOSP, which is not supported. This is
yet another thing a third-party app could depend on and an alternate Android
distribution would have to replicate.
Amazon has a set of game APIs called "GameCircle," but
it's not a drop-in replacement for Play Games, the way the Amazon Maps API is. A
developer will have to spend time making a completely separate multiplayer
implementation work.
Supporting lock-in by supporting iOS
The borderline-evil-genius part of Google's strategy is that 90 percent of
the Google APIs are also supported on iOS. Now, put yourself in the shoes of a
developer deciding whether or not to use Google's APIs: many of Google's
solutions offer best-in-class usability, functionality, and
ease-of-implementation. Google supports both major mobile platforms, so it will
cover a very high percentage of your potential user base. The only bad
part is that it won't work with an Android fork, but any AOSP fork is going to
be a tiny sliver of your possible target devices.
Most developers probably say "yes" to Google APIs, and the next question is
what should they do about the Kindle and other Android forks? Developers are
largely on their own to find a replacement API solution, which might be out of
date and might not work perfectly with their existing app. If this other
solution isn't a perfect drop-in replacement, the developer will have to figure
out how to design their app around the missing feature. Since this is such a
small amount of users compared to their current iOS + Android user base, is it
even worth it to try to figure out this separate ecosystem? Will they get a
return on their time investment? It would be easy to say "the hell with forked
Android" and skip all the extra work and Q/A that would entail.
Samsung isn't going anywhere
This is the section that shows why Amazon can live without Google and Samsung
can't. While Amazon is a Google-API-copying machine, Samsung doesn't have many
answers for third-party developers that currently rely on Google. Any
speculation about Samsung leaving the Google ecosystem is premature until you
see it licensing map data or building a cloud messaging API.
Amazon has done a decent job of keeping up, but the company was born on the
Internet. Servers and software are the company's forte, so building out a bunch
of cloud services isn't a huge change. Samsung Electronics is, well, an
electronics company—building a cloud infrastructure and a bunch of APIs isn't in
its DNA. So while Amazon can whip this together in a few years on the back of
its cloud services platform, Samsung has much more of an uphill climb ahead of
it.
Samsung has made a tiny bit of progress. As mentioned, the company has its
own SDK for in-app purchases. Interestingly, it also has an advertisement SDK,
but ads actually make money. Google supports ads on Android, iOS, Android forks,
and even Windows Phone.
A "look but don't touch" kind of open
If a company even wanted to consider forking Android and creating a viable
commercial competitor, they would have to replicate everything in this
article. Even then, you've only broken even. You would still have to
give your users a reason to switch from Google's Android to your fork of
Android.
Google does everything in-house. The company gets Maps and all of its cloud
services basically for free. Any company trying to follow in these footsteps
will probably have to outsource something on this list. Amazon having
to license Nokia's Map data is an excellent example. Google sells ads against
Maps—it actually makes the company money—while Amazon has to pay a
per-user fee for its mapping data. This is the kind of radically different
income situation an Android forker will be facing on a daily basis. Google's
services cost less than nothing, and anyone competing will end up
paying a monthly fee to some other company.
If a company does manage to fork Android and make something compelling
outside of Google's ecosystem, there's the little matter of nearly every
manufacturer being contractually barred from manufacturing a device that runs
the new OS. Even if this new Android derivative is better, for an OEM jumping
out of the Google ecosystem, it's probably more trouble—and risk—than it's
worth.
While Android is open, it's more of a "look but don't touch" kind of open.
You're allowed to contribute to Android and allowed to use it for little
hobbies, but in nearly every area, the deck is stacked against anyone trying to
use Android without Google's blessing. The second you try to take Android and do
something that Google doesn't approve of, it will bring the world crashing down
upon you.
As a Partner and Co-Founder of Predictiv and PredictivAsia, Jon specializes in management performance and organizational effectiveness for both domestic and international clients. He is an editor and author whose works include Invisible Advantage: How Intangilbles are Driving Business Performance. Learn more...
0 comments:
Post a Comment