Over the holidays there was a flurry of excitement, particularly among OpenStreetMap fans, prompted by Ed Freyfogle’s announcement that Nestoria were switching from using the Google Maps API to using an OpenStreetMap tile service provided by MapQuest. The switch was prompted by Google’s announcement in April of last year that they would be introducing some volume limits on the usage of the free Maps API:
“We are also introducing transaction limits on the number of maps that may be generated per day by commercial Maps API web sites or applications. These limits are documented in the Maps API FAQ and will take effect on October 1st 2011. Commercial sites that exceed these limits may be required to purchase additional transactions or a Maps API Premier license…
…Not for profit applications and applications deemed in the public interest (as determined by Google at its discretion) are not subject to these limits.” (My italics)
Nestoria have been a long term supporter of OSM and as Ed says the introduction of the new charging regime was the trigger to move away from Google:
“Having always envisioned that we would someday move to OSM, this was the nudge that pushed us over the cliff.”
The new limit is 25,000 map sessions per day averaged over a quarter, which equates to 9m sessions per year. Google expect 0.35% of the sites using the free Maps API to be impacted which I reckon is between 1200 and 1400 sites. Big respect to the Nestoria guys for growing their business to this level but perhaps a note of concern for the many passionate advocates of geo (myself included) on the economics of incorporating map services in applications where revenue per page is on the low end of the spectrum.
I don’t know why Google chose to introduce these limits, it could be about the costs of delivering the service (hardware, bandwidth/power or data licenses where Google is using 3rd parties) or it could be a drive by the commercial team to increase sales of Enterprise licenses. Probably a bit of both. It sounds like the commercial approach may have been a bit less than optimal but no doubt Google will adjust their approach (and possibly their pricing) if they want to retain some of these large usage sites or we may see the more aggressive introduction of context sensitive advertising directly into the map although we have heard little more about the trials of map ads in Australia.
OSM advocates have been understandably chuffed that Nestoria considered OpenStreetMap to be as good or better than that offered by Google and it’s data providers, no doubt OSM has come of age as a viable royalty free source of geodata. In my opinion the focus on open vs traditional geodata ignores the broader scope of Google’s Map API which offers quite a bit more than just a map tile service – geocoding, directions, Streetview, local search and perhaps most important colossal scalability. What interests me about Nestoria’s decision is the choice of MapQuest rather than going with a self hosted tile service based on OSM which they explained:
“When we realized it was time for us to make the move we faced one big decision – should we use someone else’s OSM tiles or should we render and serve our own? We called in an expert to advise us. OSM expert, and former Nestoria blog interviewee, Andy Allan … Rendering has the advantage that you can make the map look exactly the way you want. When done well this can produce phenomenal results … but unfortunately it’s no small technical undertaking, especially when we’ve also got a property search engine to run.
We concluded the only viable path was for us to leave the rendering and serving to experts and use someone else’s OSM tileset… Luckily however several companies have stepped in to fill this gap –CloudMade has for several years offered an OSM tile layer for all to use. In 2010 MapQuest released a similar service. While we are longtime fans of CloudMade (we use their tiles on our Where Can I Live? service), for their global infrastrucutre and speed we decided we’d prefer to use MapQuest’s OSM tiles.
What’s in this for MapQuest? I imagine that the publicity and goodwill are worth quite a lot to them (but that was what many people thought was the motivation behind Google’s free API for the last 6 years). Presumably the cost and complexity that Nestoria identified are shared across a large user base for the tile service but as uptake grows the costs of servers and bandwidth must become a factor in the economics of their free tile service. I wonder how long it will be before the bosses at AOL (ultimately the very commercially astute Arrianna Huffington) start looking to monetise the usage of their infrastructure? Will it be “in map advertising”, alongside the map advertising or is their some other model? At least if you have architected your service in the way that Nestoria have, you can quite easily switch from the MapQuest service to someone else’s if the terms change in the future.
I can imagine a scenario where a number of the 1200 odd commercial sites switch to MapQuest or Cloudmade only to find that these guys with much shallower pockets than Google will struggle to support their levels of usage and functional needs (routing requires a quite a lot of processing for example) on a free model. Of course they can then start to roll their own map services with something like MapBox or building their own tile service and hosting it in the cloud but then they will start to incur the direct costs plus the overheads of supporting their service. The guys from MapBox promoted their service as an alternative on twitter:
“With our new add-on packages, you can easily bump up your storage + bandwidth ds.io/A12Drf And it’s 12x cheaper than Google Maps”
When I queried this they quoted their cost per thousand extra map views at $0.32 compared to Google’s $4.00 but I think that ignores the Google’s free service offering 2.25 maps per quarter before you hit the charge or the need to have quite a lot of technical skill and understanding to set up a tile service. That said MapBox is an interesting open source based service that woud appear to offer a low cost solution to serving tiles with the benefit that you can style those tiles to your own designs. I’d be interested to understand the economics of this kind of business model, presumably over time it will get driven down to pretty low prices but will never be free. Look at web hosting, prices for a small site ca be as low as £2/month and you can get quite a powerful server from Amazon for about £35/month but as far as I know no one is offering large chunks of infrastructure and bandwidth for nothing.
So is this the beginning of the end of Free? Not quite yet, but maybe it’s time to recognise that a free ride may not last for ever and perhaps we need to think a bit about what price we are willing to pay for a map service. This comment on the Nestoria blog from another business affected by the change in Google’s usage terms summed it up for me:
“In our case, that meant paying $200,000-$400,000 a year for maps…
Google got their pricing off by at least an order of magnitude. I don’t know many companies making more than a couple of dollars per thousand views. Had they charged us $0.20 per 1,000, we would have gladly paid.
In the end pricing is a trade off between the value to the purchaser and the costs of production/delivery, even competitive pressures cannot reduce long term costs to zero unless the providers find a different revenue model, which could bring us back to “in map adverts” and I doubt many large commercial users of maps would want to be potentially hosting adverts for their competitors in return for free or very low cost maps.
I wonder whether within a couple of years a modest fee say $250-500 per million maps will become the going rate for a high availability map service with some additional costs for directions and other features. Time will tell.
5 thoughts on “The beginning of the end of Free?”
Great post! As one of the MapBox developers, I think I can add a bit more detail here:
The 1200-1400 number for affected Google Maps sites seems a bit low. It might be my tired Sunday-afternoon math, but that’d mean around 342,857 API users – there’s probably more than that.
A few things cannot be underestimated: the freeness of OSM data is not an overriding factor – it’s the cost of running the servers. What you’d usually consider to be a good web server will be crushed under the load of importing an OpenStreetMap planet, and further crushed by traffic and updates. With all of the technology in the world, it still takes very expensive systems days to import the database.
So, free data does not mean, by any leap of the imagination, a free service. On the contrary, it’s really, really expensive to run a worldwide map – it’s like hosting YouTube, except more computationally intensive. Here the whole ‘runs on your own hardware’ thing dies when you need 32 gigs of ram.
At MapBox we’re trying to do some straightforward, transparent pricing. We use CloudFront as a CDN and Amazon servers as a backend. So, the costs for data transfer there are well known, and then there are the additional costs of storage and backups to factor in. So, there’s very little mystery in where the money’s going, and no Porsches purchased. In short, there’s no funny money involved on either side, or plans to monetize in some other fashion, like ads.
The original numbers versus Google were a bit unfinished: what we’re really comparing the service to is Google’s Premier service, but it’s a difficult comparison to make because their pricing is opaque. There’s a variable cost of being a Premier customer (generally six figures) and after that a negotiated cost of tiles under that contract.
> Yes we do need to add server costs, but for just their own web traffic, is that cost so much?
In short, yes. Maintaining a planet import is a high fixed cost. Traffic is another thing, and can be addressed with CDNs, but no, you are not going to get away with a £35 server here.
I think that vectors are generally overplayed and misunderstood. Or not understood. It’s not a matter of, say, making a ‘vector basemap’ and sending it around: you still need to distribute tiles. And for most road-based zoom levels, the vector data is larger than the rasterization: so the image tiles are more efficient, not less.
So, vectors really don’t get us anywhere closer to a serverless environment: they just change the type of server. And they’re far from a silver bullet for styling or performance: you’re still doing rasterization, regardless of whether it’s in C++ with Mapnik on the server, or in C++ with Skia in Canvas (or WebGL) on the client.
Tom
Thanks for joining in the conversation.
The 1200-1400 sites was based on a guestimate of 3050-400k sites using the API, I agree that may be on the low side.
We are all agreed that providing map tiles requires resources which ultimately have to be paid for, the MapBox service looks like excellent value for money to me. I expect you will get take up from a number of sites particularly those who want to take advantage of the opportunity to personalise the rendering of their tiles.
Vectors vs tiles? I think the debate will run for a while, it’s may not be just about bandwidth and distributing rendering but also about the opportunity to have instantaneous interaction within the client.
Steven
I don’t disagree. Running tile servers to service lots of web developers requires costly resources, and offering this for free, is something which isn’t very economically viable long-term, although the availability of free OpenStreetMap data may mean that we see more companies like MapQuest trying to do so anyway (as some kind unsustainable land-grab)
But there is another way, which you hit upon by talking about MapBox. If we imagine as a thought experiment… that installing and configuring a tile server was improved to the point of being super-easy. Not necessarily Mapnik but some amazing software, which scales well, pulls in OSM updates robustly, and runs on your own hardware (not quite there with MapBox, but it’s going in the right direction).
Then if nestoria wanted to run their own tile server to service just their own web traffic, in our thought experiment the cost to do so would be ~zero man hours plus the bandwidth/server rental costs. I reckon they would go for it. And many other companies using maps would too.
Yes we do need to add server costs, but for just their own web traffic, is that cost so much? Or would nestoria worry about this as much as they worry about the cost of serving a wordpress blog on their company homepage? OK maybe their tile traffic would be a little more intensive than that, but certainly at the moment (end of thought experiment)….
…by far the most significant cost is in man hours spent installing rendering software, configuring, tuning performance and fixing things when the update fails etc. There’s room for improvement there, and so I think the “run your own tile server” approach will become more and more attractive (but no. Not technically free. I agree)
Going back to vectors reduces bandwidth constraints more. It’s pushing more demands on to the client yes, particularly if visual results are to be as good as anti-ailiased rendered tiles. Very do-able already for mobile (Try UK travel Options). Attempts on the web remain less convincing (definitely a feeling of winding back the geo-clock). Kothic.js is interesting (rendering on the browser in JavaScript!). Maybe this is the future, but for now it’ll probably still defeat most browsers.
Harry
Wearing my geo.me hat I know that a map session in Google terms is loading the javascript API, once it is loaded and cached in the user’s browser they can pan, zoom and route as much as they want.
Even with Open Data and Open Source Software to generate and serve the tiles you still need real physical infrastructure, power and bandwidth to run a service and I haven’t found a free source for that yet! Somehow money has to flow back to whomever is serving the tiles and paying for infrastructure, it may be through fees or it could be advertising revenue or there could be some other model that I don’t understand but this geo-ecosphere won’t be sustained purely through goodwill.
Going back to vectors being unpacked on the clients sounds like an almost complete revolution of the geoclock, maybe modern mobile devices have got the poke to cope, I suspect my old 3G would have gasped it’s dying breath trying that. Some positives and some negatives in that approach, hybrid may be the answer but then you still need the tile cache.
I was pleased the wired journalist (article) managed to reasonably accurately describe commercial relationships with OSM (hallelujah! A journalist that gets it!), however I had a slight quibble with the title “Open Source Maps”. Sure, most of the software is open source, but more fundamentally the project is about open data. To call it open source maps, feels like missing the point ever so slightly.
That said… This news is actually a lot more about software than I originally thought. It’s kind of interesting that the google charges (probably?) force developers to hunt, not just for free tiles, but for other web map display technology too. See the question about google page view measurements posed in my blog post and the comments here. If you have to switch away from the google maps so-called “API” (mostly a javascript library) and over to OpenLayers/Leaflet/Mapstraction as well as switching tile servers, then this makes switching all the more painful. It kind of muddies the waters. We have a lot of explaining to do, to developers who are not familiar with the distinction (today for example).
But the flip-side of this is that software innovations (especially open source projects) will receive a boost as smart developers look for ways of reducing dependencies. I’m confident we’ll see a push towards improving the ease of rendering your own tiles, and even saying bye bye to tiles. Particularly on mobile, map displays are going vector. This is all dependant on access to raw geo data…. and I know a good place to get that!