Digifesto

Last week I attended the OpenLayers sprint hosted by MetaCarta in Cambridge, Massachussetts. It is likely that you’ve never heard of OpenLayers. Here’s how the website describes it:

OpenLayers is a pure JavaScript library for displaying map data in most modern web browsers, with no server-side dependencies. OpenLayers implements a (still-developing) JavaScript API for building rich web-based geographic applications, similar to the Google Maps and MSN Virtual Earth APIs, with one important difference — OpenLayers is Free Software, developed for and by the Open Source software community.

OpenLayers is a flexible, powerful library that can read, display, and write geospatial data (or “maps,” as they call them on the streets) in a number of formats. You can load it to a web page in a compressed, single file version, or look at the whole, unobfuscated library and tweak things to your liking.

What’s strange, then, is why in a world where for web development “mashup” has become synonymous with a Google Maps application, OpenLayers–which has in many cases identical functionality–has so few users. Even at The Open Planning Project, where several of us work on OpenLayers development, most of my colleagues turn to Google Maps for their web mapping needs instead.

While at the sprint, I had several of fruitful conversations with the other developers about why this is the case. Here are the explanations that those conversations brought up.

• Data. The single best reason to use GoogleMaps instead of OpenLayers is that GoogleMaps gives you access to their now ubiquitous base layer bundled with their JavaScript for controlling the map. If an OpenLayers user wants to use that base layer, they need to import the JavaScript that implements their API along with the map. The OpenLayers library then becomes redundant–it’s just an extra 100 KB of Javascript on the page, when the user could just use the Google code instead.
• Documentation.  The other big advantage GoogleMaps has are its beautiful tutorials. Basically all OpenLayers has going for it in terms of docs are the somewhat inscrutable natural docs and a suite of examples. The documentation is designed for OpenLayers developers, not as a way of making OpenLayers easy for users. That naturally scares a lot of people..
• Design. The default UI for the various OpenLayers controls suffer from indifference to design. Neither prettified nor minimalist, the best word I can think of for it is “literal.” In principle, web applications that use OpenLayers can easily re-theme their maps. EveryBlock does some nice work along these lines. But in practice, redesigning OpenLayers is actually labor intensive when you include how long it takes to figure out how to do it. The Community Almanac project we’ve been developing at OpenGeo, for example, still uses the default zoom control, even though the rest of the site has had some wonderful design work done for it. OpenLayers could be made much more appealing right out of the box.

What do these three things have in common? They are outside the realm of the normal activity of its development community, which is made up primarily of engineers from places like TOPP, MetaCarta, and Camp-to-Camp. Data, documentation, and design are not our forte. Many would argue that accumulating, styling, and hosting free data is completely out of OpenLayers’ scope. But nevertheless, these issues are exactly what’s holding OpenLayers back from being a widely used tool across the web. Its ultimate success depends on the community’s finding a way to overcome them.