In light of the $5 billion EU antitrust ruling against Google this week, we started noticing a certain classic Ars story circulating around social media. Google's methods of controlling the open source Android code and discouraging Android forks is exactly the kind of behavior the EU has a problem with, and many of the techniques outlined in this 2013 article are still in use today. The idea of a sequel to this piece has come up a few times, but Google's Android strategy of an open source base paired with key proprietary apps and services hasn't really changed in the last five or so years. There have been updates to Google's proprietary apps so that they look different from the screenshots in this article, but the base strategy outlined here is still very relevant. So in light of the latest EU development, we're resurfacing this story for the weekend. It first ran on October 20, 2013 and appears largely unchanged—but we did toss in a few "In 2018" updates anywhere they felt particularly relevant. The idea of a sequel to this piece has come up a few times, but Google's Android strategy of an open source base paired with key proprietary apps and services hasn't really changed in the last five or so years. There have been updates to Google's proprietary apps so that they look different from the screenshots in this article, but the base strategy outlined here is still very relevant. So in light of the latest EU development, we're resurfacing this story for the weekend. It first ran on October 20, 2013 and appears largely unchanged—but we did toss in a few "In 2018" updates anywhere they felt particularly relevant.

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 market share, 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 when the proprietary Google version was launched, the AOSP version is usually deprecated. 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 future development to a closed source app. When Google rebrands an app or releases a new piece of Android onto the Play Store, it's often a sign that the source has been closed and the AOSP version is dead.

Search

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.