Mapzen was a Samsung-sponsored experiment to promote fully open mapping alternatives in the most critical areas. First we built a great team, then we built a geocoder, a turn-by-turn navigation service, a 3D rendering engine, a vector tile service, and a drop-in-replacement for Google Play Location Services. On the data side, we built a gazetteer and a crowdsourced transit data service. By design, we built everything to survive the death of the company. The open nature of the work means the work can continue: you can still use all the software and data right now. Many on the team are doing just that in new roles at Snapchat, Mapbox, HERE Maps, the ACLU, and others. There are even a couple “baby Mapzen” companies that popped up to continue the work directly. Diana and I are about to announce a related one very soon.
Sounds like a solid legacy of survivability, right? I don’t think so. It’s not good enough. I’m not happy with the permanence Mapzen achieved.
Reset to Zero: Never Again, Thanks
Aaron summed things up well in his post on what’s next for the gazetteer:
…while “success” was the goal in many ways preventing what I call “the reset to zero” has always been of equal importance.
The “reset to zero” means that one day (like today) the Who’s On First you use and pay for as a service on the Internet goes away… and then what?
Typically it’s meant that anyone who’s wanted to use an alternative to one of the Big Dominant Geo-Services or API Providers (BDGSAP) and has built their applications or services using that alternative has had little choice but to go fishing around in their desk drawer for their BDGSAP account information and think about re-tooling everything… all over again.
That’s the “reset to zero”.
I would like to think that we have, even just a little bit, prevented this from happening again.
It would be nice to believe that it’s only been a reset to “five” (on a scale to ten) but realistically it’s probably closer to a reset to “three”.
Apart from facilitating mini acquihires, I spent December and January helping API customers move off our centralized service that was to shut down on January 31. This truly sucked and I never want to do it again. Diana and I will avoid it this time by avoiding centralized services entirely and building a protocol that, as long as it’s useful, can’t ever be shut down.
Wait What’s a Protocol?
In the mists of Internet history, computer scientists built the open protocols that we all use every day. TCP/IP defines how we communicate on the Internet. HTTP is the foundation of the web. SMTP allows us to send and receive email. Any computer on the network adhering to the rules can participate and provide value. The architects of the early Internet allowed incredible value to be realized as long as people followed the specifications. If no one finds SMTP useful anymore, it dies. But if enough people do, it lives. It doesn’t matter if Microsoft decides to stop running Hotmail or Google someday shuts down Gmail: email will survive if enough of us want to use it because of open protocols.
Chris Dixon has a great recent post about decentralization. Among other things, he looks at what happens when a centralized platform hits the top of its growth curve, and needs to grow more by extracting more data from its users (hi Mark!) and competing with its own developers: “Historical examples of this are Microsoft vs Netscape, Google vs Yelp, Facebook vs Zynga, and Twitter vs its 3rd-party clients.” These are the victors of centralization beating up on everyone else after they’ve become successful.
But there are many other ways to lose with centralization, even if your provider of choice doesn’t become dominant and start taking advantage of you like a bully. First, big companies can make successful products and decide to sunset them for any number of reasons (I put Mapzen in this category FWIW). Or a small company you rely on can succeed and get acquired just to have their product shut down. Or a small company achieves reasonable success, but decides to do something else. Or, in the most likely case, a small company fails. If you haven’t been affected by all these situations, then you haven’t been around the tech space long enough. Let’s get coffee in a few years and discuss.
Or: what if we just built systems where this couldn’t happen, instead?
After a decade of working on open source maps and trying to figure out how companies can work with open software and data communities, I want a system that will persist long after I’m gone. It should move forward indefinitely as long as there’s enough interest behind it. And it shouldn’t die if people still want to use it as it is. This is why I’m going to focus on protocols next. There are new incentives for the creation and ongoing maintenance of systems like this, and I’m excited to apply them to maps. Users of the services we build should have the right for them to continue forever if there’s enough interest, and there’s a way for us to do this.
That’s real permanence, and that’s what’s next. I’ll be back with you soon!