Excerpt: How Google bought Android—according to folks in the room
By mid-2005, Android was acquired and the future looked bright. But just six months earlier, things weren’t quite as rosy. In January of that year, the startup was desperate for cash and their main task was the same as for most startups: getting funding. After the pivot from a camera OS to an open source phone platform, they still had the daunting task of actually building a product, which meant they’d need more money to hire a large enough team to do the work.
So the company focused on three things. First, they needed a demo to show what was possible. Next, they needed to articulate their vision and create a pitch deck to help explain that vision. Finally, they needed to take the demo and the slide deck on the road to pitch their story to potential investors.
Demo time
The first job for Andy McFadden (known to the team as “Fadden”) when he joined was solidifying the demo, a prototype phone system that Brian Swetland and Chris White had been working on. It wasn’t actually functional (for example, it showed a stock ticker on the home screen which used a set of hard-coded symbols and stale data). But the demo represented a vision of what the product could be when it was actually implemented.
One of the apps that Fadden added to the demo was a simple calendar application. This early demo project would come back to haunt him. After many intervening years of working on things throughout the Android platform, he ended up helping out with the Android Calendar app. Time waits for no man… but calendar apps do.
The mobile opportunity
As the team honed their vision, they created a slide deck to explain it. These slides painted a picture of the opportunities that they saw for Android in the marketplace, as well as a picture of how Android would make money for the investors.
The slide deck in March of 2005 had fifteen slides, which was enough to capture the attention of VCs as well as Google.
The pitch deck got interesting by the second slide, which compared PC and phone markets. In 2004, there were 178 million shipments of PCs worldwide. During the same period, there were 675 million phones shipped; nearly four times as many units as PCs, but with processors and memory that were as capable as PCs were in 1998.
This potential in mobile hardware was a point that Dianne Hackborn, then at PalmSource and eventually on the Android team, was also thinking about. The mobile industry was ready to pop because there was finally enough power for there to be a real, capable computing platform: Dianne said, “You could see the writing on the wall. The hardware was getting more powerful, and the market was already bigger than PCs.”
The presentation also identified the problem of the growing cost of mobile software. The cost of hardware was going down, but that of software was not, making it a larger and larger proportion of the per-handset cost. But handset manufacturers were not experts in software platform development and didn’t have the skill set or interest in providing the increasing capabilities required to differentiate their software from that of their competitors.
An open opportunity
The second major point in the pitch deck was that there was a gap, and an opportunity, in the market for an open platform. That is, Android would be an operating system that was free and available to manufacturers through open source. Companies would be able to use and distribute this OS on their own phones, without being beholden to a software provider and without having to build it themselves. This open approach was something that was simply not available at that time.
Microsoft provided a proprietary OS that manufacturers could license and then port to their hardware. Symbian was primarily used by Nokia, with some uptake from Sony and Motorola. RIM had its own platform, which it used only for its own BlackBerry devices. But there was no alternative out there for manufacturers that wanted a capable smartphone without either building their own OS, putting significant effort into customizing an existing one, and/or paying a high licensing fee.
Even more problematic, the systems that were available failed to provide an ecosystem for applications. Symbian provided some of the core infrastructure for an operating system, but the UI layer was left as an exercise for the manufacturer, resulting in an application model for phones where apps written for one flavor of Symbian wouldn’t necessarily run on some other variation, even on phones from the same manufacturer.
The Java programming language, known in the server and desktop PC world as “write once, run anywhere,” could possibly have provided this kind of cross-device application capability, but Java ME fell far short of this in the mobile space. While it did provide at least the same language across devices (much as Symbian provided the same language of C++ for all of its implementations), Java ME addressed the wide variety of form factors and architectures in phones by providing different versions of the platform, called profiles. These profiles had different capabilities, so developers needed to change their applications to run on different devices, and often that approach failed when capabilities were drastically different across devices.
Linux to the rescue!… Almost. Texas Instruments (TI) provided an open platform based on the Linux OS kernel. All manufacturers needed was Linux itself, reference hardware from TI, and then a huge host of other modules that manufacturers had to acquire, license, build or otherwise supply to create their own device. As Brian Swetland put it, “You could use TI’s OMAP chips to build a Linux phone. So you needed TI’s OMAP and then forty components from forty different vendors of middleware. You put all these together and you integrated them all and then you’d have a Linux phone. And that was just absurd.”
Android wanted to provide the world’s first complete open handset platform solution. It would be built on Linux, like TI’s offering, but would also provide all of the necessary pieces so that manufacturers would have only one system to adopt in order to build and ship their devices. Android would also provide a single programming model to application developers, so that their apps would work the same across all devices on which the platform ran. By having a single platform that worked across all devices using it, Android would simplify phones for both manufacturers and developers.