OpenGeo

As we prepare our new Enterprise offering around the OpenGeo Suite (PostGIS, GeoServer, OpenLayers, GeoExt), I have been researching open source business models. The more I read, the more I am convinced that the problem is not one of the open source company providing value, it is one of convincing customers that they are in fact receiving value.

The best discussion of open source business I have seen is the beekeeper model, written up by James Dixon of Pentaho software. It is well worth reading the whole article, but the idea is neatly summarized in this diagram:

The open source community is the bee hive. The company provides care for the hive, and processes the results into the kinds of products that customers expect. In open source, as with bees, customers are not really interested in the details of production (they may even find it kind of frightening), but they are interested in the final product.

The problem with this model, and really with all open source business models, is that customers don’t perceive the value in the non-software activities. And the reason they don’t perceive value is that the proprietary software model has conditioned them to believe that the only thing of value they receive from a vendor is the software. The documentation, the packaging, even the marketing information they show the boss, these are all perceived as zero-value wrapping to the item with real value, the software.

In fact, if you look at the expenditures of public software companies (and annual reports spell out this information) you’ll find that less than 20% of expenses are for actual software development.

When you take that attitude and transpose it to open source software, there’s a problem, because the software is free. And the extra services provided by the open source company are perceived to be, if not zero value, of very very low value relative to the software. This leads to a chicken-and-egg problem I have mentioned previously, where customers can’t use perfectly good software because it is perceived as “risky” without a professional-looking corporate entity behind it, but where they also won’t pay for the value-added service of providing that professional-looking corporate entity.

“Why should I pay so much money for free software?!?”. Why indeed. Imagine the feel of an unprocessed honey comb in your hand, the honey dripping down between your fingers and the bees still alighting on the frame. Open source companies provide value beyond bits and bytes, and that value is what shows up in the price tag.

OpenGeo’s mission to bring participation and openness to the geospatial domain extends beyond software to geospatial data itself. We have been working on tools for collaborative mapping in our mission-driven time for years. Western Australia’s Landgate agency shares this enthusiasm for crowdsourced data managing. It recently took leadership in the area by funding a proof of concept using a collaborative mapping user interface with a versioned geospatial back-end.

Our live demo is an augmentation of an application we originally built for Livable Streets. Chris Tweedie of LandGate adapted it for their purposes.

The Versioning Stack

The application uses the full OpenGeo stack. Data is stored in PostGIS and served using version-enabled GeoServer. The base map tiles are cached using GeoWebCache. The client-side JavaScript code is from the Vespucci project, built using OpenLayers.

WFSV is an extension to the WFS standard for requesting geographical features over the web that supports versioning requests, like requesting a feature at a specific revision or a log of changes to the data. OpenGeo has developed these extensions in-house, but we hope for them to one day be accepted as an OGC standard. A version-enabled GeoServer supports WFSV; client side support for WFSV requests is available in the WFSV sandbox of OpenLayers.

Below is a quick walkthrough of the features of the demo.

The Guided Tour

You can access most of the versioning functionality through a feature’s popup. Try clicking on any of the features on the map to open its popup, and notice the History link.

History. Clicking on the History link shows you the feature’s history–the revisions at which the feature was created and edited–in the sidebar.

The client requests the information for the history log from GeoServer using a WFSV GetLog request. Each revision in the response comes with its “commit message”, date, author, and other useful information.

In addition to viewing the full list of revisions, you can select two revisions and see the differences between the two by clicking the Compare Versions link.

Differences. The “compare versions” view shows the differences in a feature’s attributes and geometry across two revisions. Changes in attributes appear in the table at the top, changes in geometry in the thumbnail maps below.

The information used in displaying the differences comes from two requests. One is a WFSV GetVersionedFeature request that gets the state of the feature at the first revision. The second is a WFSV GetDiff request, whose response is the WFS-T transaction (Update) that would transform the feature from the first revision to the feature from the second revision.

The thumbnail maps are each bona fide OpenLayers maps, with their own WMS background layers (drawing from the same GeoWebCache as the master map) and with Vector layers that display two OpenLayers features–one corresponding to each revision.

Rollback. When a the Roll back these changes link is clicked from the Diff view, the client issues a WFSV request to the server that triggers the rollback.

Next steps

We built this application as a proof of concept for Landgate. But there is much more work to be done, which we will take on when we find the funding or spare hours for it.

We think that version-support in map applications is critical to collaborative mapping, just as versioning is critical for environments like Wikipedia. Non-traditional ways of building maps will require non-traditional tools, and the ability for crowds of people to review data, both through inspecting the present state of the data, and reviewing its history.

We are eager to polish the design of our collaborative mapping UI’s. One way we will be pursuing this is to take lessons learned here and bring them to our new web mapping UI project, GeoExt. Ideally, we would like to see the UI components from this application available as GeoExt components that can be used to quickly build new applications.

Last but not least, we are always looking for opportunities to improve out backend versioning support. With Paul Ramsey on our team, we have the potential to build versioning natively into PostGIS/PostgreSQL (whereas it is currently managed by GeoServer itself). We would love to be able to expose the advanced versioning features of other spatial databases–like Oraclae 11g Workspace Manager and ArcSDE’s versioning–to any user on the web through WFSV.

Perhaps not in Antarctica, but being used to map Antarctica. The ArcheoGeek reports PostGIS, GeoServer and OpenLayers, all components of the OpenGeo Suite, are being widely used in the research community of the British Antarctic Survey.

A general observation- almost everyone talked about using some combination of geoserver/postgresql/openlayers. Other packages were mentioned in passing, but these were the big 3, the packages du jour.

Thanks to OpenGeo’s Whit Morris and Jonah Bossewitch from the Columbia Center for New Media Teaching and Learning (CCNMTL) the two organizations co-hosted the NYC Open Mapping Sprint last weekend.

Jeremiah Trinidad-Christensen opened space for the sprint in Columbia University’s Lehman Social Sciences Library. There, most of OpenGeo’s international team met with people from Columbia, MetaCarta, NOAA, and beyond.

Highlights

OpenLayers developer Chris Schmidt came to the sprint. He joined members of our own JavaScript team and a developer from CCNMTL in working towards the upcoming OpenLayers 2.8 release. Several patches were also made towards GeoExt core.

Our GeoServer team made progress cleaning legacy code from the GeoServer codebase. This work eases the lives of plugin developers who would otherwise have to modify core classes. Look for configurable extensions building on these improvements starting to be available in GeoServer 2.0.

Lastly, we took some time to explore PostGIS’s geocoder project, which uses the TIGER United States census data set. Existing commercial geocoding services are tied to restrictive terms of service agreements. At OpenGeo, we are interested in providing a more open geocoding option. Please let us know if you or your organization would like to support these efforts.

Update: Now also in Directions Magazine.

Paul Ramsey has written an article for the Open Source Business Resource. Money quote:

Open source geospatial holds a number of lessons for other vertical markets. First, frontal assaults on the leading proprietary vendor are unlikely to succeed. In their core areas, the leading vendor has an advantage in technology development and existing mind-share. Usually, building enough technology to compete with a leading vendor head-to-head takes years of development, and a partially functional product will be ignored.

Second, disruptive changes in technology provide opportunities for open source. Most leading vendors carved out their advantage on the desktop during the 1980s and 1990s. The transition to web-based services has opened a temporary gap in the marketplace where existing vendors have a smaller technology advantage, and their marketing advantage is limited to their existing universe of customers. Open source can become the core for new service-based companies competing with proprietary software vendors.

Finally, new markets for capabilities are the most fertile opportunity of all. In geospatial, its expansion into daily life, through vehicle and device tracking, low cost aerial imaging, and handheld mapping, is growing the market exponentially. New developers and managers, without long-held preconceptions, are making technology choices. On a level playing field, open source Internet technologies are regularly winning.