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.

Here is a great article from GovTech regarding TriMet‘s use of open source software to benefit their operations. Bibiana McHugh, TriMet’s IT Manager of GIS, was interviewed for this article. (TriMet is currently an OpenGeo Suite Enterprise Edition client.)

From the article:

McHugh replaced Esri ArcSDE, ArcIMS and MapObjects with open source products GeoServer, OpenLayers and PostGIS. At the time of the switch, the agency was considering whether or not to add Esri’s ArcServer. ‘ArcServer was going to be a big investment for us, and it didn’t really align with our standards. The existing platform, ArcIMS, wasn’t really meeting our needs,’ Bibiana McHugh said. ‘After laying everything out, GeoServer immediately popped to the top. It was clear this was an option that could meet all of our needs, save a lot of money — and it aligned with all of our Internet software standards.’

This article ends up like a manifesto of the benefits of using open source software in a mission-critical environment. Whether talking about control of code, flexibility of architecture, or even just price, I don’t think we could have said it any better.

Open Source Software Helps an Oregon Transportation Department for GIS, website.evelopment (GovTech)

The GeoNode community recently welcomed the Center for Geographic Analysis at Harvard University (CGA) to its growing community of institutional participants. CGA has announced that it is incorporating GeoNode components into its WorldMap web mapping system, with an eye towards stronger user collaboration and better tools for data management and editing.

From the GeoNode site:

CGA was committed to building WorldMap using open source technologies. While supporting user roles and collaboration requires major development efforts, CGA was able to quickly achieve results thanks to WorldMap’s open source, interoperable architecture. By working with OpenGeo to use GeoNode as the basis for new capabilities, CGA received immediate access to key open source components supporting collaboration, mapping, metadata management, and more

While OpenGeo remains firmly committed to developing GeoNode, the number of contributors is swelling far beyond OpenGeo’s ranks. Along with OpenGeo and Harvard CGA, the GeoNode community now includes Global Earthquake Model Foundation (GEM), World Bank, and the Australia-Indonesia Facility for Disaster Reduction (AIFDR). With additional input comes a growth in users, testers, and developers, contributing to the overall sustainability of the project and benefiting all who use it.

Read more about this collaboration.

One of the interesting mysteries of the open source ecosystem, for me, has been the relative paucity of open source “vertical applications“. A “vertical application” is a system tailored to a fairly particular use case, usually requiring multiple software components tied together: an example might be a dental records management system, or a library management system.

Open source has thrived in the IT infrastructure space, churning out general purpose software like databases and operating systems and programming tools while rarely meeting very specific user needs.

(Some exceptions that I know of: the Mamook system for managing co-op students; the Koha open source library system; and Specify natural history collection system.)

The lack of vertical applications is even stranger when you note that, in terms of unit costs, vertical applications are often carry some of the highest price tags in the software world! A dentist might spend hundreds of dollars on Microsoft Office, a rigorously engineered highly polished piece of desktop software, but thousands of dollars on a fairly slipshod dental office management system.

Given all the money floating around vertical applications, open source efficiencies could make the market a lot more competitive. We know it! All too frequently, a group of programmers sits in the pub, sipping beer, calculating that “if just 25 dentists spent their money on an open source application, then every dentist could use it for free”.

But somehow that never happens.

First, building a vertical application requires domain knowledge. The reason there are so many good open source programming tools is that programmers already have the domain knowledge necessary to build good programming tools. Open source dental tools require a dentist (or several) to invest a fair amount of time guiding the development of the tools. Those that have such entrepreneurial and technological bents generally set up side businesses selling software to other dentists.

The vertical application problem is even more keen for governments, whose vertical applications are traditionally built or bought at costs in the seven-figures-and-up range. Ask a government why they don’t spend a little extra money to make their system modular or reusable in other jurisdictions, and they will (rightly) point out that they are not a software company. Their job is providing a public service (like running the jail, or driving the busses) not providing a meta-service of software development. Software is the means, not the ends.

To break out of the logjam, an outside entity needs to fill the role that is usually held by the software company:

• inform the customers of what can be done;
• aggregate development funds to make a large product from many smaller contributions;
• communicate and understand the technical issues of software development;
• manage the process of finding the “least common denominator” of necessary and collectively useful features or standards.

In addition, this entity should have organizational goals that are aligned with the project participants: public service; improved access; and better community value.

This entity looks a lot like our parent organization, OpenPlans.

Over the past year OpenPlans has increasingly taken on this role in important vertical application developments. The Open311 project and the Open Trip Planner are both niche vertical applications where having a non-profit entity work to coordinate efforts, provide communication, and aggregate development funds is a big help.

And (lest I hide our light under a bushel) OpenGeo is doing similar work with the GeoNode project by providing the technical core in a collaboration that includes the World Bank and other international development and emergency preparedness organizations.

Everyone knows what needs to be done in order to build these new open source vertical systems. The difficulty is taking the first step and saying “let’s work together, let’s get this done together.” I think there is a place for the “IT nonprofit” organizational model to help make some of these dreams a reality.

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.

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.