Back to Mobile View

Skip to Content

TUAW Deals

Is Android forked? Give Amazon a chance

For such a seemingly simple concept, "open" sure is a contentious term these days.

I've previously written at length on TUAW about the topic of Android's openness and, semi-relatedly, the GNU Public License. Last week, news came that Google is making serious changes in how it manages the Android ecosystem, and those changes have led many commentators to conclude that Android's much-touted "open" nature is, and always has been, little better than a sham.

I believe, however, that there are genuine ways in which Android is more open than most operating systems, and that these differences could have surprising ramifications for what happens next as Google wrestles its partner OEMs for control. We may see an Amazon-branded version of Android that does not have Google's blessing, and with it, an Android fragmentation issue that makes dealing with the current ecosystem look like child's play.

To explain how I came to these conclusions, we'll need to explore exactly what it is that makes Android different from the likes of iOS, BlackBerryOS and Windows Phone 7. But first, let's examine the news in question. In Do Not Anger the Alpha Android for Businessweek, Ashlee Vance and Peter Burrows wrote:

Playtime is over in Android Land. Over the last couple of months Google has reached out to the major carriers and device makers backing its mobile operating system with a message: There will be no more willy-nilly tweaks to the software. No more partnerships formed outside of Google's purview. From now on, companies hoping to receive early access to Google's most up-to-date software will need approval of their plans. And they will seek that approval from Andy Rubin, the head of Google's Android group.

Vance and Burrows claim that among the partner plans Google is trying to put a stop to are a Facebook-led version of Android, and Verizon Android handsets replacing core Google services, like email and mapping, with Microsoft's competing Bing options. There's also speculation that Amazon's new Android Appstore might be the first step towards a fully Amazon-branded Android device.

UPDATE: since I finished writing this post, Andy Rubin has responded to the Businessweek post, calling it "misinformation" and that "[o]ur approach remains unchanged: there are no lock-downs or restrictions against customizing UIs" and calling the delay in the release of the Android 3.0 source code a "temporary delay" and not a "change in strategy." However, as Jason Kincaid wrote at our sister site TechCrunch, this doesn't quite debunk everything Businessweek claimed. There's still a strong incentive for OEMs to want that early access to new versions, and Rubin does not specifically refute Businessweek's claims that this early access comes with strings attached.

What does "Android is open" even mean any more?

By this point, you'd be forgiven for thinking that Android's purportedly open nature was nothing more than a myth, a smoke-and-mirrors act. That's certainly a popular opinion on many Apple blogs, and I cannot argue that the way Google has used the term as a marketing gimmick does feel downright disingenuous.

But if we tune out the marketing rhetoric (which, as a geek, I wasn't paying much attention to in the first place) and examine the technicalities of Android distribution, we find there is more to it than meets the eye. Android is built on a fundamentally different legal platform to iOS, and this key difference has far-reaching ramifications.

Technically, Android is an Open Source operating system. As Google's Andy Rubin expressed in a famous tweet, anyone with the right (free) tools can get the source code, compile it, and have a running OS. They can even make changes if they'd like and give their changed version to anyone they want.

This is all perfectly legal because Google releases the code under the Apache license, which gives anyone who downloads it very broad rights to make derivative works. In this regard, it is very different from iOS, which (although it contains a few Open Source pieces, such as WebKit and the Mach kernel) is almost entirely under Apple's control. There is no way for a third party to download the source code to iOS (or Mac OS X) and repurpose it to their own ends.

Rubin's tweet makes it all sound simple, but his assertion comes with important caveats.

  • Caveat 1: It's not the latest source code. Google only releases software to the public internet on its own schedule. This is usually shortly after the software launches, but (in the case of the new tablet-friendly Android 3.0) not until some unspecified point in the future. This works to stop competitors from getting sneak peaks at future Android developments. In the past, Google has granted some partner OEMs earlier access, but if Businessweek's sources are correct that early access will come with significant strings attached in the future.

  • Caveat 2: It's not all of Android. Most, but not all, of Android is open source. Key parts, including the Market app store, email and IM clients, the map viewer, YouTube interface and more are closed source and must be licensed from Google if you want them on your device. If you download the public source from Google, you don't get these. If you wanted to build a device using open source Android alone, you'd need to replace these bits with different code.

  • Caveat 3: You can't call it Android. "Android" itself is a trademark controlled by Google.

  • Caveat 4: It won't run on real phones. A download of the Android source code won't give you everything you need; hardware vendors such as Motorola and HTC still have to write, deploy and test drivers for the chips and other hardware they use in their phones.

Within these bounds, anyone -- you, me or (more importantly) big companies like Amazon and Facebook -- is free to use the current Android source as they see fit. This could involve downloading it all and using it as a base from which to build a new OS. In software development jargon this process of producing a new, distinct product from an existing codebase is called forking (as in a fork in the road, with increasing separation between the two versions as time goes on). More on this in a moment.

The question of user freedom

To Google's credit, Android supports considerably more user configuration and manipulation than most competing mobile platforms, such as iOS. Apps can hook deep into the OS's settings to, say, control ringer volume based on time and location (Locale) or can replace the system-wide keyboard (e.g., Swype). Even small things like custom SMS tones or third-party browsers being allowed to override the default http:// handler so links in other apps load in them rather than the system browser are ways in which Android can claim to be more open to user modification than iOS is. Consider the popularity of jailbreak apps for iOS, such as SBSettings or custom SMS tone utilities; these are not worthless features.

There's also the biggie, which is the ability to "sideload" apps -- in other words, to install apps via means other than the official store, such as manually downloading an app directly from a developer. If Apple supported that, then almost all complaints about the App Store's sometimes controversial acceptance policies would be neutered because it would no longer be the ultimate gatekeeper between developers and users (disregarding the jailbreak app store, Cydia, for a moment). Of course, it would immediately lose the iron-clad and highly profitable grip it has over the iOS ecosystem; I don't expect Apple to ever relinquish that willingly, and I cannot imagine any likely circumstances under which it could be compelled to.

It's important to note that no part of Google's changes in how it interacts with OEMs affects these aspects of Android's openness. On the contrary, the OEMs and in particular the carriers have a history of curtailing these features; see, for example, AT&T's disabled sideloading, un-removable pre-installed "crapware" or Skype's brief period of being exclusive to Verizon handsets. Many bloggers have commented that Android is "open... to carriers messing about with it," generally to the detriment of the user experience. Viewed from that angle, a move by Google to stop this behaviour is a positive change for most users, assuming they don't end their official support for things like sideloading, which is an admittedly big assumption. We have no current evidence they would do so.

What about Android OEMs like Samsung, HTC and Motorola?

If anyone has been the victim of a bait-and-switch here, it's not Android users. It's the OEMs and the carriers. They were sold an OS they could manipulate and customize, and now they've lost that. This reduces them to mere commodities. It makes it hard for, say, Motorola to make its phones stand out from everyone else's devices. Everyone is using the same CPUs, the same memory. Screens are all of roughly the same size and the same resolution. The bottom line is that they are all baking cakes from the same ingredients. Up until now, one way for them to make their cakes more appealing was through custom UIs -- putting different icing on top -- such as HTC's Sense or Samsung's TouchWiz. Now, Google is telling them they won't be able to continue such efforts.

I have to admit, I find it difficult to feel too sorry for them. It was obvious from the start that Android was not a fully open source codebase like Linux, and that Google was hanging on to control of several key elements. If they actually based multi-year product strategy on marketing hype whilst not carefully examining the legal technicalities... well, that's a paddlin'.

Where now for Amazon?

The launch of Amazon's own Android "Appstore" (note the lack of a space, presumably to try to defend against copyright issues) was seen by many as a shot across Google's bow. It would seem that, with Google locking down Android source distribution, Amazon is left without much room to maneuver. However, Android being mostly open source does give it the option of going the full monty and creating a full-blown fork.

To do so it'd have to address a number of problems. It'd need replacements for apps, such as the email client, but that's not insurmountable. Amazon would have to source alternate data for the search engine and mapping apps, but Microsoft would doubtless be happy to have Bing fill in the gaps. It'd need a replacement app store, but it already has that of course. It wouldn't be able to call it "Android," but Amazon has huge brand strength of its own -- arguably strong enough to carry a device to success without that name.

On the one hand, this could be a huge win for consumers. Amazon is arguably the company in the best position to compete with Apple's iTunes service in terms of vast numbers of lodged credit cards and plenty of licensed music and video content to choose from. To date, legally purchasing media on Android devices has been a weak part of the experience. Amazon could change that. This would also be indirectly good for iPhone users, because strong competition almost always results in more rapid progress than stagnant monopolies.

However, it would also present a far more serious risk of fragmentation than has yet taken place. As it stands, apps written for core Android would work on a forked copy, but if the two versions diverged that might not be the case forever. Even without that factor, app devs today already have to choose between the Amazon Appstore and the official Google Market, with no easy way to centrally manage customers, payments, invoicing, etc., and an onerous requirement to keep two systems up to date with the latest version of the app, making pricing changes, changing app descriptions and so forth. Such problems might mean any efforts by Amazon would never gain a foothold.

If it chooses to take the fork in the road, Amazon might not be alone. There's a tantalising suggestion in Businessweek's article that Facebook is also considering a self-branded Android device, and if Facebook is unhappy with Google's changes, it's logical to suppose it's at least considering a fork. If nothing else, it serves as a useful stick to beat Google with in any tense negotiations, similarly to how Apple allegedly holds detailed talks with Bing every so often.

And what about the current Android OEMs? David Barnard of App Cubby wrote in a series of tweets:

"It has come to our attention that App Cubby is one of the most interesting and outstanding contents provider" Thanks Samsung, I'm flattered. Amazon sent me a similar email back in October of last year. Is Samsung building their own App Store, or just building custom Android apps? "...there could be potential fit for us to start exploring win-win global mobile service distribution partnership opportunities"

Update: David asked us to clarify that this was an unsolicited spam email sent to a large number of iOS developers and that he was being sarcastic about being flattered.

It's not impossible that, in attempting to get a grip on the Android ecosystem, Google will end up pushing its former partners into forever moving it out of reach. It's even possible that these firms could form a consortium that eventually rivals Google for control over the platform. Open source software is a slippery business.

A footnote about the GPL

The GPL is, in my experience, a much misunderstood and often maligned license amongst Mac bloggers. Too much weight is placed on the consequences of GPL compliance being perceived as user-hostile without seeing the benefits that its strict rules bring.

Well, here's one potential benefit. If Android was entirely licensed under the GPL, then anyone with an Android device could demand the full source to that device immediately. Google wouldn't legally be able to withhold the Android 3.0 source (although often companies flout the law -- warning, NSFW language.) The GPL, in other words, leaves as little room as possible for the interpretation of "open." It is the lack of such guarantees associated with the other Open Source licenses that Android uses that has allowed this situation to exist.



For such a seemingly simple concept, "open" sure is a contentious term these days. I've previously written at length on TUAW about the...