Collaborative Mapping: The Business Thread

Since I was speaking at Where 2.0, which is a good bit more business oriented than most conferences I attend, I felt that it could be interesting to start to make the business case for how collaborative mapping could succeed.  I didn’t have time to do more than throw out a few ideas, but I think it’s important to start thinking about this.  I fully believe it will happen, though I’m not sure of the time frame at all.  But it’s almost inevitable, since the economic end result is a more efficient allocation of resources.  The only question is whether there will be enough incentives along the way.

At the core is the idea that there will be a series of ‘tipping points’, where it will be cheaper for an organization to fund a collaborative map than it is to buy the data from the commercial provider at the accuracy that they need.  The last clause is important, because there are many cases where one just needs data as a base for other information.  Many google maps mashups just need some context to display the information they’re showing.  So if there is a route to get from one tipping point to the next for different sets of organizations than a collaboratively built map will emerge as competitive if not better than those made by commercial providers.  There will be no middle man who bundles all the functions of mapping together and extracts rent after having done the work.  Instead there will be a diversity of organizations, including private companies, government, and individuals, who all work together to make accurate, up to date maps.

Currently the idea of a collaboratively built maps is still quite radical.  The work is being done mostly by amateurs (in the best sense of the word) and ‘true believers’, who know that it’s the right way to build open maps.  No traditional geodata providers seem to feel threatened at all, at least not yet.  This is very much like the early days of open source software, it was seen as some purist movement that would never have a big effect on anything.  But people stuck with it and ended up building a huge economic engine of change.  I am a true believe who is sure that collaborative mapping can become a more efficient way to build geospatial data, fully supported by a variety of business models.  So I’ve been thinking about how we can move from being rebels to becoming the default way of getting things done, as open source software has.  It took 20 years to go from starting the movement to mainstream success, and I think we can follow in their footsteps and do it even faster (and indeed leverage open source software as a base to build it upon)

Let’s start by fast forwarding to a future where we have economically successful collaborative maps.  Then from there we can look back and see how we might get there, what tipping points would be involved.  We are currently in a stage where business models around open source software are maturing.  Building software still costs money, even if it’s open source.  But there are a variety of ways to make money even with a collaborative base.  The key for me with this is that the functions of traditional software company have been decoupled from one another – you can buy support on open source software from one place, a manual on it from somewhere else, and then get training on how to use it from a third organization.  None of the functions of a software company have gone away, they’ve just been split up in to smaller pieces, and there is competition in the market for each of them.  Thus making them more efficient and more competitive.

The biggest providers of commercial geospatial data also wrap up a lot of functionality in to one package:

  •  pay people to go out and drive the roads to keep the database up to date.
  • Find and acquire data from public sources
  •  Process the raw data, doing quality assurance
  •  Ensure that the information is up to date – ie give people someone to sue if it goes wrong
  •  Services and Consulting – ‘analysis and proprietary research’, ‘business plan reviews and testing services.’ from
  • Geolocated yellow pages – ‘placing your business on the map

Since the commercial databases are not open there is no way to separate out this functionality.  With a collaborative map one could imagine niche companies doing one of them, or new companies that combine some of the processes here with other functions.  Navigation is an obvious one, and indeed TomTom is starting in on this with their MapShare.

So you could have a company that just goes out and drives the roads and turns over the data / adds it to the collaborative map.  Clients who want an area of the map more up to date could pay them directly.  You could also have small businesses who want to be sure that people get accurate directions to them.  We could even imagine ‘a man with a van’, but instead of for moving it’d be for driving roads with a GPS, and perhaps some camera’s strapped to the roof.  There then could be a company whose expertise is processing raw GPS data.  GM or FedEx might sell the data from their vehicles under permissive terms, and then a company could do a bunch of algorithmic analysis on the data to extract roads, and contribute those to a collaborative map.

Then there could be a class of companies who just provide guarantees.  Someone you can call up if there’s a problem, get a service level agreement.  They in turn would have internal people to drive roads, or contract out with the other companies when they needed a certain area to be at the accuracy they’ve agreed to provide others.  You have this in the open source software world, with companies like SpikeSource that test how things work together and give someone a number to call if things go wrong.

And of course the other big open source business model is to provide new services on top of open source software.  See Google and Yahoo! and most new internet companies.  They contribute to the underlying software to run the parts that they keep private.  Indeed those very same companies could become significant contributors collaborative mapping – they already spend significant money in licensing fees from commercial data providers, and if it made economic sense to put the money in to a collaborative map they likely would.

One could also imagine a company whose sole purpose is to do accuracy assessments of collaborative maps.  They would play a very key role, in that they’d be able to answer the question for companies ‘should I invest in collaborative mapping?’.  I maintain there is a tipping point for just about every organization, but it will be very painful if the area they need mapped has very poor coverage and they have a small budget.  So for a small fee there could be a company that lets you know how much investment it would take to get the area of interest to the accuracy that the organization needs.

Ok, this post is already long enough, I’ll continue soon with more on the business case, what steps might evolve us to a place where collaborative mapping is simply the smarter economic choice.  But my main point for this post is that it is possible to decouple the function of ‘ownership’ of a set of geospatial data from the functions that are needed for its upkeep.  Indeed such a decoupling could easily lead to a more efficient market around the upkeep of the data.  One thing we neglected to mention as well is that a collaborative map opens up the potential for non ‘expert’ contributors to do valuable work, as long as the structure is set up to minimize vandalism and the like.

Collaborative Mapping Redux

So after a lengthy hiatus, it’s time for me to get back in to the whole collaborative mapping thing.  I’ve been thinking about such things a lot lately, and didn’t have time to get to most of it at my Where 2.0 presentation.  We’ve also been making progress in GeoServer to support all kinds of collaborative mapping – put the power in the hands of users to determine their workflows and permissioning.  I’ll roughly break things up as I did in my talk – the premise is that the grass roots remapping can’t be stopped, but that there may be ways to help it go faster.  We’ve got Open Street Map, obviously the clear leader with an amazing community.  But while something like a collaborative street map may have wikipedia type properties – where it makes sense to have a single community crystallize around one – there are many, many more maps to be made than just road maps.  And while there are lots of software packages that aren’t MediaWiki (what runs Wikipedia), there are practically no options for collaborative mapping.  So The Open Planning Project (TOPP), my employer, has been putting a lot of effort in to making GeoServer a better platform for collaborative mapping.  We’re looking to make it a flexible platform for different communities to experiment with a variety of workflows, figuring out what works for them.  The 1.6.0-beta1 release should show off some of what we’ve been working on.

The low hanging fruit seems to be simple reporting functionality.  I’ve been talking to several different non-profit groups, and many just want an interface for users to throw some information on the map – a point and a description, like Google Earth.  But they don’t want to be passing KML files all around.  Which speaks to one way I’ve been articulating where we’re going with GeoServer – ‘cvs for the geospatial web’.  We give you a central location where you can do insert, update and delete on your data.  And our latest improvements are to do the versioning – history, diff, rollback – so you can keep editing the geospatial information and not be worried about non-experts corrupting it since you can always revert changes.  We’re building this on top of the WFS-T standard, and let normal WFS-T clients use versioning transparently – that is their edits will go through fine, and will get versioned with out them even knowing.  Version aware clients will be able to take advantage of the additional functionality – getting a log and a diff, doing a rollback, ect.  Ideally we have a variety of clients – web based, mobile based, desktop, ect.  Past the basics we’re thinking about a lot of workflow customization.

So the next few posts will explore in more depth some of the economic aspects, some ideas on the technical side – what further tools and functionality would be helpful, and the legal ground we need to clear before collaborative mapping can really take off.

Google and the Geospatial Web: A smaller piece of a much, much larger pie.

Well, I’ve been back from Where 2.0 for awhile, and as usual blogging hasn’t been the highest priority, but there was one topic that I’ve been really wanting to write about.

And that is that Google seems to be legitimately moving in a more open direction with regards to geospatial. I’ve rarely been overtly critical of their lack of openness, but it’s always been a source of frustration for me. And as I got to know more people there I definitely realized that their lack of collaboration wasn’t the result of any malicious intent, it was simply a perceived lack of resources – they felt they didn’t have time to put effort in to standards and working with others. And I’ll be the first to admit that it takes more work to be open and collaborative.

But I do say ‘perceived’, because the thing I’ve found again and again doing the ‘open’ thing is that it’s an investment that pays off in the medium and long term. Working alone definitely allows you to move faster in the short term, but working with others leaves you much better off in the longer term.

With regards to Google’s geo portfolio, the way I’ve always termed it is they could have a huge piece of a small pie or a sizeable piece of a much, much bigger pie. What pie is it we’re talking about? What I’ve referred to as the Geospatial Web, though I’m trying to call it the geoweb, since that term seems to be taking off more. They are obviously the clear leader, with Google Earth and Maps, specifically KML and mashups – as those both allow more geospatial data to get out in the world. And they could just push KML and their platform and do quite well. But it would be a silo. It wouldn’t be like the web, it’d be a greatly expanded and easier to use Geography Network. Much, much better and bigger, but still a single platform. It could potentially even become a platform like Windows, truly dominant, but the point for me is it still wouldn’t be as big as it could be. It wouldn’t be the World Wide Web, where innovation comes from all over building something far bigger than any single company could possibly make on their own.

The bigger pie is the vision of a true Geospatial Web, that diverse individuals and organizations all contribute to, and where technical innovations come from all over. To achieve this there must be an underpinning of open standards, that others can contribute to. There must be an ecosystem of companies and services, business models and startups and dot-orgs. The ecosystem can be dominated by an entity, but can’t be entirely dependent on a single entity, as would be the case if Google defines the software and the format and the search engine. But if this open geoweb is nurtured and encouraged the right way we’ll get exponential growth. Citizens will start demanding that governments and organizations data put their data on, just like we’ve seen happen with eGovernment on the WWW. It will become a default, and people will look at you weird if you have geospatial data that’s not on it.

I think it’s not crazy to aim for the majority of all spatial information to be available on it. It will be a much bigger pie than one that Google owns, as more and more people will feel comfortable making their data available, since it’s a public resource instead of clearly benefiting a single company. And it also allows further innovations to come from the outside. Google has a ton of smart people, but they don’t have all the smart people in the world. They can afford to let innovation come from elsewhere (though I’m sure they’ll probably just buy up the best ones), because they’ll start to do what the company does best: search. There’s no reason to own a geoweb when you can own the way most people find information on The geoweb.

Of course, even with search Google could constrain it to their web, as they did when geo search came out – it was called KML Search and only could find KML. What they are going for now is much more ambitious, and indeed a bit more risky. And so I applaud them for it – they are putting a stake in the ground that says ‘our best ideas are not behind us’. They are going to be a leading force in a much bigger pie, and turn this open collaboration in to a really good long term investment.

Ok, I’ve gone on speculating about things, I probably should give a bit of evidence. I admit that it’s pretty subtle, but based on it and a few conversations my gut tells me that they are legitimately on the level. At least for now, that’s not to say that some corporate decision could move things in an opposite direction: such is the fate of a publicly traded company. But they seem to be trying to do some work that will be hard to undo.

First, KML Search is now referred to as ‘geo search’, and is crawling not just KML but also GeoRSS, with more formats likely coming soon. This is one of the most important pieces to me, and was the announcement that excited me much more than StreetView. It is admitting that it’s ok for people to use other formats, even though KML is super nice and easy to use. Yes, more formats may confuse my grandmother (one of the eloquent arguments used by Google folks in the past for why we should all just use KML), but more formats also means extending an olive branch that says you can work with others.

Second, Google is an active sponsor in OGC’s OWS-5. I had been a bit skeptical of their throwing KML over the fence to OGC. Yes, it’s nice the copyright is with OGC, but it’s kind of meaningless to me unless KML actually aligns with the other open standards. And OGC would likely try to do that, but then it remains a question if Google would actually support the new standard. Or if they’d have this covert control over it with the ability to exclude any decisions they didn’t like by just not including an implementation in Google Earth and Maps. But they are sponsoring OWS-5 which will fund several server and client implementations to flesh out a new KML spec that incorporates other OGC standards. The OWS testbeds are the best way to develop specs in the OGC, and putting real money up for this definitely indicates for me a commitment to making KML a true open standard, not just a rubber stamped pseudo-standard. The one piece that I’m not sure on is how much they’ll have engineers working with OWS-5 to try out the new spec ideas on Google Earth and Maps. If they have a couple people show up at the kickoff meeting who are set to work on it for the next few months I will be very happy.

Third, John Hanke’s speech at Where 2.0 was the first time I had heard the Google geo team really tell the world that they want to work with others. Some of it was subtle, but there was definitely a flavor of openness and collaboration that I’d not felt before. Previous speeches would always come back to the innovations they’re doing, how great KML is, ect. There was little acknowledgment of an outside world, which could come across as fairly arrogant – that not only are we doing things the best way, we haven’t even looked in to how anyone else might do since we must be doing things the best.

And finally, in private conversations many googlers have talked about a more open shift in the past 6-9 months. There were always a few voices for that, but it sounds like a tipping point has been reached and there is now a critical mass. The voices are heard and effort is being oriented in that direction. I think it’s an investment that will really pay off for Google, and though I’m going to continue to work to push them in to ever more open directions (maybe even to be able to talk to them about what they’ve got in the pipeline without signing an NDA? Ah, to dream ;), count me as a skeptic who is becoming more and more convinced that we’re going to build a true, open, collaborative geoweb.

Where 2.0 slides

Hey, just wanted to throw a quick post up with my Where 2.0 slides. The slides are not too exciting, I need to learn to make prettier slides (or at least to try to spend more time on doing that), but I think the talk ended up decently. I plan to do blog posts of the new thoughts – the main thing I had fun with was thinking through how collaborative mapping will make business sense in the future, and how we’re going to get to tipping points where things will shift in bursts. It wasn’t exactly what I submitted as an abstract originally, but Schuyler hit on many of those thoughts, so I oriented my talk to expand on some of the points he didn’t have time to fully explore in his excellent keynote. Unfortunately I didn’t get to the legal part, time was tight after the lightning talks. But look for blog posts on the newer stuff, and I’m contemplating doing another tech talk, about this and more, which would get it on video for all to see.  Thanks to Brady and the whole O’Reilly crew for letting me talk, and for putting on a great conference.