Our old enemy was proprietary platforms. Should it now be proprietary data?
Turns out maps matter.
That's always been the case for me. I'm a map freak. I own hundreds of paper maps in various specialties, plus many atlases, books on geography, geology and other geo-obsessions. But I'm no longer an edge case, because maps are proving to be essential on smartphones, which today approaches a billion or more people. Digital maps on phones are now among the core portfolio of smartphone apps, alongside voice, text, calendar and contacts. What could be more mobile about a phone than a map to help the user look things up and get around?
In appearance and function, smartphone maps evolved from standalone GPS units, which were limited to location lookup and turn-by-turn directions in both text and voice form. But maps on phones grew much deeper, because boundless amounts of memory, intelligence and usage-based heuristics could be located in the cloud, and delivered to the app and the user through an API over a live data connection.
Nobody has done more with cloud-based mapping than Google. By the middle of this year, Google-made or -based map apps were the primary sources of location and navigation information for users carrying all kinds of mobile devices—especially Android and Apple mobile devices. Among smartphones, that pair alone comprised about a 90% market share in the US.
In September 2012, however, Apple released iOS 6 and the iPhone 5, both with a new Maps app that did not use Google as a data source. The new Google-free Maps app quickly turned into Apple's worst fail since the Newton. Initial sales of the iPhone 5 were good, as were installs of iOS 6. But then came reports of the new Maps app's disabilities, which were extreme. Missing were countless major points of interest, such as the entire subway systems of New York, London and Paris. Museums were moved into rivers. Dead businesses came to life, and live businesses went away. At the time of this writing (in early October 2012), iPhone 5 sales projections have been revised downward, and Apple's stock is dipping as well. The map debacle may not be the only reason, but it's still a big one.
Why would Apple do something so obviously harmful to itself? Because Google was clearly withholding essential mapping features from iOS to favor Android, and Apple needed to rid itself of a clearly hostile supplier. As an owner of both Android and Apple phones, that much was obvious to me. But news of it didn't make the mainstream press (at least as far as I know) until David Pogue reported as much in his New York Times column of September 27, 2012 (www.nytimes.com/2012/09/27/technology/personaltech/apples-new-maps-app-is-upgraded-but-full-of-snags-review.html?_r=0):
After poking around, here's what I've learned.
First, why Apple dropped the old version: Google, it says, was saving all the best features for phones that run its Android software. For example, the iPhone app never got spoken directions or vector maps (smooth lines, not tiles of pixels), long after those features had come to rival phones.
Apple has a variety of replacement data sources, starting with TomTom, the Netherlands-based maker of navigation (mostly GPS) systems. TomTom's primary data source is its Tele-Atlas subsidiary, which it acquired for 2.9 billion euros in 2008. The prior year, Nokia acquired Navteq, Tele-Atlas' main competitor, for 5.7 billion euros. Google used Tele-Atlas as a source until October 2009, when it became its own primary data source.
Google, Navteq and Tele-Atlas all deploy special vehicles on streets to create, correct and enhance mapping. In Google's case, this also has included mapping of Wi-Fi access points to fine-tune a user's location further. Microsoft, Google and Apple also have aerial views provided both by satellites and low-flying aircraft. And all are feeding their clouds and crunching up data gathered by watching what users do.
At this point, it would be easy to digress into vendor sports and handicap which of the map data sources and mobile device suppliers will win in the marketplace. But instead, I want to look at what all this says about dependencies. What we see here is the replacement of the platform with the Big Data API—let's call it a BiGDAPI—as a single source of market-making and market-breaking dependency.
Google's passive-aggressive map app game with Apple, and Apple's refusal to keep playing it, are both evidence of Google's huge leverage through its map BiGDAPI.
The term “Big Data” has been around for a long time, but has obtained buzzphrase status only in the last two years. Although much that can be said about Big Data is positive and harmless (better medicine, better science, better analytic fodder for countless good purposes), one unspoken motivation behind the buzz is obtaining high degrees of market leverage. And much of that leverage is not in harmony with the constructive motivations and practices behind free software, open source and Linux. Because, behind many of the big APIs are vast jungles of exclusive and patent-protected functionalities and restrictions around use. Such as, for example, the spoken turn-by-turn directions Google wouldn't allow Apple to use. It can be dispiriting to see platform leverage exceeded by large proprietary databases and exclusive services made available through APIs. But it's important to bring attention to what's going on, so here we are.
We also should remember that good things come from APIs. For exposing organizational competencies in purely useful ways, nothing beats them. (For a sample, take a look at the growing list of APIs at ProgrammableWeb.com: www.programmableweb.com/apis/directory.)
One hopeful force on the mapping front is OpenStreetMap.org, which has been crowdsourcing maps data for years. It has an API too (wiki.openstreetmap.org/wiki/API). Perhaps in time, free developers and users can best the sums of data currently locked up in proprietary mapping bases, and the analytics as well. But until then, it's helpful just to watch what's happening in the mapping space, and how dependent we remain on proprietary companies and BiGDAPIs over which we have little control.