LI2006 Why Should the CXO Care About Open Source Geospatial ?

Adena Schutzberg moderated a fascinating panel discussion on "Why should the CXO care about open source geospatial products ?"  The panelists included quite a diverse group of people with open source geospatial experience including Dave McIlhagga, President of DM Solutions, Chris Holmes, Vice President of The Open Planning Project, Gary Lang, VP of Engineering at Autodesk, and Brian Timoney, Principal of The Timoney Group.

Why is Open Source Geospatial Successful ?

Dave McIlhagga identified two key requirements that in his opinion make open source projects successful, a grass roots developer community and a thriving business sector which relies on the technology.  Dave believes that both of these are realities of the open source geospatial community.  Dave made the point that open source geospatial is a "quiet reality".  Most people would be quite surprised at how extensive and widespread the use of open source geospatial software is.  From Dave's perspective Autodesk's support for the Open Source Geospatial Foundation has added credibility wrt the quality of open source geospatial software and has contributed to bringing open source geospatial out of the back room.

Autodesk and Open Source Geospatial

Gary Lang outlined the history of Autodesk's involvement with the open geospatial community.  Gary lead the internal discussion within Autodesk that lead to Autodesk's decision to open source MapGuide.

Autodesk, which has of course worked extensively with corporate partners, found working with an open community a different experience.  For example, there was an intensive discussion within the community about naming, what to name the foundation and what to name the projects contributed by the MapServer community and by Autodesk.  For Autodesk the mechanics of the naming discussion in the context of an open community was different to what Autodesk was familiar with, but one that Gary emphasized at the end of the day was a valuable experience for Autodesk. 

Geoffrey Moore's Core and Context

But I think Gary's most interesting point related to applying Geoffrey Moore's core and context model to when to open source and when not.  In a nutshell, core is anything that leads to competitive differentiation and context is everything else, things you have to do but that are not differentiators.  From Autodesk's perspective web mapping is context, in other words it isn't a critical differentiator among the geospatial vendors.  Since open source is very good at context, as Linux and the Apache web server experiences have shown, it made business sense to Autodesk to contribute its web mapping source to the Open Source Geospatial Foundation and invite other geospatial vendors to do the same.

Geospatial Consumer

Brian Timoney offered some interesting perspectives from the perspective of a geospatial consumer as opposed to a geospatial vendor.  One of the most important benefits he sees of open source geospatial software is that it is significantly easier to find developers with general IT development tool experience than with specifically geospatial development tool experience.  For example, PHP developers are easier to find than ArcObjects programmers.  Secondly, open source applications can run just fine on very cheap hardware so that the proportion of the IT spend on hardware is plummeting.

Open Standards and Open source

Chris Holmes discussed the difference between open standards and open source. For example, HTTP, XML, SOAP, WSDL, WMS, WFS, GML are open standards. You can find both open source and closed source products that support these standards.  Open standards ensure that the pieces fit together but say nothing about how each piece is implemented - basically, software as Lego.  The implementations can be closed or open source.  For example, the WS-I is an organization dedicated to ensuring that Microsoft and J2EE web services interoperate based on W3C standards for web services.

In my experience, open standards attracts open source.   I think it relates to Gary's point about context.  Innovation is the source of market differentiation and standards always lag innovation. When you see well-developed standards you are likely dealing with context, which is where open source does well.

Barriers to OS Adoption

Adena asked the panel what they saw as the barriers to the adoption of open source gespatial by the IT market.  Dave pointed out that one of the problems for customers has been finding out who to talk to.  The OSGEO foundation has now made this a lot easier, but he sees education still as a priority.   Brian made  a really interesting point, that open source is the opposite of a "drug dealer" model, that all the pain tends to be up-front.  Chris made the point that many of the folks looking at open source geospatial these days are not from the traditional geospatial market, but represent the geospatial-enabling market and that many IT folks in this area often already have open source experience so that for these folks there may be less of a barrier.  Gary feels that the barrier's largely mental.  Most folks are already using open source geospatial, whether they know it or have admitted it, so the barrier is largely an irrational fear factor.

 

Comments

[Jason Birch]

Hi Geoff,

You said: "When you see well-developed standards you are likely dealing with context, which is where open source does well."

This is certainly one of the places where open source does well. :)

In my experience open source thrives in areas where there are open standards because each project can bite off the chunk of a large problem that is most important to them. This kind of core competencies focus works well for open source, and would work well in proprietary companies if lock-in wasn't seen as a competitive advantage. Unfortunately it's up to the market to remove that competitive advantage. Another strength for open source is in areas that are either relatively simple, or have a large mindshare (ie. are cool). In these areas, open source is often an innovator rather than an implementor. For instance, open source blogging and bulletin board software often have innovative features far in advance of their proprietary counterparts.

Standards are a completely different area. Standards bodies are typically made up of commercial entities, which restricts open source involvement. It also means that standards are slow to evolve because first, companies need to be forced by the market to put time into standards development and, second, because it is in each company's best interest to develop a standard that is easiest to implement within their software stack. I'm not saying that there are no egos or vested interests in open source, but interoperability is a crucial component of most open source projects' business. You often see ad-hoc standards between open source projects developed much quicker than traditional processes, and with a tighter real-world focus. An example of the speed at which this works is the work on a standard web map tiling scheme that started in email, then moved to FOSS4G, and continues offline. Another is the development of the GeoRSS standard. Neither of these are official standards, but both will provide needs that are not being met by the traditional standards process.

Jason