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 (http://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: http://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 (http://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.
Data graphic via Shutterstock.com.
Doc Searls is Senior Editor of Linux Journal
Until recently, IBM’s Power Platform was looked upon as being the system that hosted IBM’s flavor of UNIX and proprietary operating system called IBM i. These servers often are found in medium-size businesses running ERP, CRM and financials for on-premise customers. By enabling the Power platform to run the Linux OS, IBM now has positioned Power to be the platform of choice for those already running Linux that are facing scalability issues, especially customers looking at analytics, big data or cloud computing.
￼Running Linux on IBM’s Power hardware offers some obvious benefits, including improved processing speed and memory bandwidth, inherent security, and simpler deployment and management. But if you look beyond the impressive architecture, you’ll also find an open ecosystem that has given rise to a strong, innovative community, as well as an inventory of system and network management applications that really help leverage the benefits offered by running Linux on Power.Get the Guide
- Google's Abacus Project: It's All about Trust
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Seeing Red and Getting Sleep
- Fancy Tricks for Changing Numeric Base
- Secure Desktops with Qubes: Introduction
- Working with Command Arguments
- Secure Desktops with Qubes: Installation
- CentOS 6.8 Released
- Linux Mint 18
- The Italian Army Switches to LibreOffice