Earlier this year Esri released a white paper highlighting the benefits of open source and open specifications. No, that wasn’t a joke; the article is real, and well worth a read. It is a solid summation of open source in the marketplace and discusses the differences between open source software and open standards (what Esri calls “open specifications”). But more fundamentally, in this paper, Esri makes a bold and sensible claim that may surprise some people:

Deciding between open source and ArcGIS is not an either/or question. Esri encourages users to choose a hybrid model, a combination of open source and closed source technology, based on their needs.

The paper goes on to talk about Esri’s integration with various open source projects, from their ArcGIS Editor for OpenStreetMap, to their integration of Python into ArcGIS 10 (ArcPy), to their Geoportal Server, which is hosted on SourceForge. On the use of hybrid technology, we are in firm agreement. From the beginning, we have designed our software with integration in mind. For example, the OpenGeo Suite can connect to a number of proprietary databases, including ArcSDE, Oracle Spatial, IBM DB2, and Microsoft SQL Server, and the list continues to grow. In addition, with GeoCat Bridge you can publish data from ArcGIS Desktop to the web with the OpenGeo Suite.

Why would we advocate for proprietary systems? Simply put, we always suggest using the right tool for the job. Esri has great desktop tools, but on the server side there are faster, more reliable, more flexible options that support more standards. It can make sense to use ArcGIS Desktop and then use GeoCat Bridge to publish directly to the OpenGeo Suite. Or to use ArcSDE for data collaboration, then connect to the OpenGeo Suite to serve to the web. We know you have options when choosing any piece of software: Apache Tomcat versus IBM WebSphere, PostgreSQL versus Oracle Spatial, QGIS or uDIG versus ArcGIS Desktop, and, of course, the OpenGeo Suite versus ArcGIS Server. While we feel that open source holds the best route forward for software development, we are happy to give advice on the pros and cons of various architectures. The OpenGeo Suite Enterprise Edition clients use a variety of solutions that meet their needs. We’ll be publishing some white papers in the near future to help you compare the different software options in the marketplace; and we applaud Esri for their moves toward open source, and appreciate their candor in promoting a hybrid model.

Lots and lots of presentations on day two! The day started with another plenary session, featuring speakers from OpenStreetMap, Inspire, and ESRI.

First, ESRI’s Michael Gould made the case for ESRI as an “open” company, though I do not think he made the sale with most folks in the audience. ESRI’s participation in 52 North, while interesting, doesn’t produce much software that attendees at the conference actually use. And the pitch for building open source extensions on top of the ESRI platform sounded like the Microsoft message box from — even the beast from Redmond has gotten more subtle over the past years. Curiously, he did not mention (or perhaps my cloth ears did not hear him mention) that ESRI funded a good deal of work on GDAL in the past year, a project which most attendees actually do get a lot of use from.

I have talked to many ESRI employees over the years who are brimming with enthusiasm for really engaging with the open source community, but it seems like the executive direction remains firmly lodged in an earlier era. Here’s some personal, unsolicited advice for ESRI if they truly want to be an “open” company:

• End closed data formats now. Open FGDB, stop promising it, just do it.
• End closed styling formats now. LYR files lock map creation processes into the ESRI stack.
• End ST_GEOMETRY on databases that have their own spatial type. Existing client software for Oracle Spatial and PostGIS supports the native types, ST_GEOMETRY is a transparent attempt to prefer access to the ESRI client suite.

The open source community wants to be interoperate. To build systems where the components work together cleanly, without hacks and cludges. That requires open formats. Documenting them is not even necessary, just make them comprehensible and readable (e.g. the ArcView 3 .avl and .apr files).

After Michael, Ivan Sánchez gave an entertaining talk about utility optimization, as it relates to open source and open data, via game theory. And the end, he concluded that the optimum strategy was use of share-alike (GPL) licensing, a conclusion sure to rile at least 50% of the audience (because who doesn’t like to argue about licenses?).

Finally, Ioannis Kanellopoulos from JRC gave a run down of state of the INSPIRE initiative. If you take anything away from his talk, take this: SOAP bindings for W*S services are optional. Repeat, optional. Over.

After the plenary, I banished myself to Room 6 for a day-long festival of talks on PostGIS. I gave an introductory talk on PostGIS, learned about the state of the PostGIS raster-in-database projects (intriguing), and gave a talk on advanced PostGIS techniques.

The PostGIS raster project has moved from a notion to an implementation over the past year, with the ability to load data directly, alter it in place, and do some basic analytics. I am very impressed with the API decisions and the clean way it integrates with the rest of the spatial functionality. My only concern now is performance — will it be possible to perform massive analytical runs, or will the trade-off for the design elegance be a painful performance hit?

The last PostGIS talk of the day was a fun dual talk from Marc Jansen and Nicklas Aven, on web interfaces for visualizing spatial SQL. People take a run at this regularly (I did one four years ago) but Nicklas’ is the most complete I’ve seen yet, and really understands that the goal is creating a compelling teaching tool. Check out postgisonline for yourself.

Tomorrow I will be at the OpenGeo booth with the rest of our lively crew. Stop by, pick up a shirt, and tell me how wrong I am about ESRI, I can’t wait to hear from you!

When describing the OpenGeo Suite, I am often asked one of two questions (depending on who I am talking to): “why not just use ESRI” or “why not just use Google”.

The answer to the first question depends on the person asking, ranging from the “ability to economically scale out to larger user loads” to more managerial things like “having multi-vendor options and flexibility in tool choice”.

The answer to the second question is was the subject of a recent article in Ovum, which notes:

The key exposures for agencies using the free map platforms relate to some natural consequences of the services being provided for free. These include:

• lack of assurances regarding the continuous provision or reliability of the service or that it will remain available for free in the future
• lack of control over the content displayed by the vendors on the platform - particularly advertisements
• lack of control over how the vendors use data that is provided by agencies
• the requirement to indemnify the vendors from any claims arising from the agency’s use of the service.

The market runs from the cloud-based web services (Google, Bing) through to self-managed proprietary (ESRI), and there is a gap in the middle where customers need the flexibility and scalability of the consumer services married with the feature richness and control of self-managed software.

And that gap, in the middle of the “market sandwich”, is where we plant our flag.