OpenGeo Suite – A Milestone

On May 28th OpenGeo announced the release of the OpenGeo Suite. They also describe their open pricing structure for support of the suite.

This announcement represents a milestone for open-source geospatial software. If you are of a technical nature and are expecting a detailed discussion of the technical advantages of the OpenGeo Suite, you should probably stop reading now. The OpenGeo Suite is a milestone because it establishes a fair pricing model that addresses what, in my opinion, has been the primary barrier to the adoption of open-source GIS in many enterprises: risk.

Am I saying open-source GIS is risky? No. The products included in the suite have gelled into a commonly used core of tools implemented in many places. In fact, some of those products (PostGIS, GeoServer, OpenLayers) are part of a pro bono project I am working for a small town. They are stable, robust, proven and highly capable. So why do I state risk as a barrier to adoption?

Many very capable technical people recognize the quality of the tools included in the OpenGeo Suite. However, the adoption of any technology platform in a well-run enterprise must usually pass muster with senior management who have the responsibility for allocating and managing resources. Many times, this would be CIO and/or the CFO. For these people, a strong business case must be made to justify platform adoption/switch. In this situation, the vendor model is attractive because vendors usually come prepared with pricing that shows what products will be received and what level of support for those products can be expected. As we all know, your actual mileage may vary here but these arrangements generally represent a contract that is binding to a certain extent and can help mitigate risks associated with the implementation and integration of a software platform.

For example, ESRI has been very successful in addressing these concerns with the implementation of ELAs in many large organizations in both government and the private sector. These agreements make technology available to the users that need them while simultaneously helping to better fix the cost of implementing the ArcGIS platform in an organization.

The funny thing about risk is that, for all the tools and techniques out there for quantifying it, a large portion of it is still based on perception. In general, the perception of risk equals the presence of risk.

I have seen this dynamic at work first hand with regard to open-source software (both geospatial and otherwise) in a few instances. The common themes I have observed (and tried to overcome) are:

1. Lack of reliable support – For most organizations, information technology is a tool that they use to do something else. They are generally uninterested in delving heavily into software development themselves and fear that committing to open-source may cause them to need to bring in additional developers should changes or updates be needed. This business stance is perfectly legitimate and is one that must be recognized and accepted by the open-source community. To simply say “You have the code. Make the change and contrib back.” puts many organizations into a situation they don’t want to get into in the first place. So there are a lot of organizations that are looking for someone to call when something doesn’t work correctly.

2. Lack of integration between projects – There can be some legitimacy to this. Many open-source projects are indeed independent entities. Many are also coupled together (such as GeoServer and GeoWebCache) but integration of products, if needed, may very well fall to the user if there is no prior association between the projects. Obviously, you can make the changes you need and contribute them back to the projects but see item number one for how many organizations view that whole process. You can also bring in a consultant to do the integration but the long-term O&M of that becomes a concern.

3. Security – There is a concern that, due to the crowd-sourced nature of open-source software, that malicious code could be inserted and that the implementing organization would need to scrub the code to ensure against this, leading to the need to have in-house experts that can understand the code. This stance speaks more to the mentality of the person who thinks this way than it does to any real problem with open-source. I can’t begin to explain the psychology but, having worked against it, I can say that people who think this way are very hard to dissuade. They feel that buying pre-compiled, closed-source, proprietary software is safer because the purchase transaction at least gives them some recourse in the event that something malicious happens. I suspect these people have never actually read a EULA.

4. Cost – I saved the biggest for last. Nobody with funding authority in any enterprise believes in a free lunch (or free beer) and with good reason: it doesn’t exist. Everything costs something. I have seen many a technical staff get shot down on proposing open-source solutions because they lead off with “it’s free!” All that says to senior management is that you haven’t done your homework and they stop listening at that point. They know that the piper gets paid somewhere and they need to know how much and what they get in return for it. In many cases, open-source looks nebulous from an ROI standpoint and that rolls back to the first three issues. In solving them, who is going to do it and how much will it cost and what capability do I get in return?

There are other topics that have come up with regard to implementing open-source GIS that I have observed, but these four themes tend to always recur in some form or another.

This leads me back to the OpenGeo pricing model. It systematically addresses all of these concerns for a price that is straightforward. Those who have worked with open-source for a while know that the openness extends to being able to choose how to get the support you need. Paul Ramsey addressed this topic here so it’s always been there for those willing to their homework. I find the OpenGeo model preferable because it provides peace of mind with regard to the integration and testing of the suite as a whole. Numerous installations have demonstrated that the tools included in the suite work well together but that’s not the same thing as saying that you have specifically tested them and verified their integration and can support the implementation of the suite.

Additionally, and James alludes to this, the support draws from developers and contributors to the projects themselves. In most vendor technical support models, you are not getting access to the actual development teams. It is also important to note that OpenGeo supports integration with some proprietary tools and, at the enterprise level, for clustering and security. It also includes broad service-level definitions and discounted services rates (20% – 40% depending upon edition).

For many organizations, the question of adopting open-source GIS has been less about quantifying return on investment than it has been about quantifying the investment in the first place. The technical advantages of the tools in the OpenGeo Suite are readily apparent for many. I have spoken to a few people in the past who have found the features in PostGIS, GeoServer and OpenLayers in particular compelling but have shied away from adoption because of questions about total cost, including support and lifetime O&M.

In my opinion, the OpenGeo pricing model represents a milestone because it finally marries the compelling technical capabilities of the tools in the suite with a clear, straightforward, and fair pricing/support model that quantifies costs of adoption/maintenance (if you use OpenGeo) and compares to proprietary vendor ELAs in an apples-to-apples fashion. This now gives an enterprise the tools it needs to do a true side-by-side cost/benefit analysis between open-source and proprietary geospatial tools and should begin to dispel misconceptions about the readiness of open-source geospatial tools for enterprise applications.