Programming languages haven’t changed much over the years: the latest languages to take over large swathes of the industry (Java and C#) are unashamed about being cleaned-up versions of C++, which itself was a melding of C with object concepts. What has changed immensely recently is the state of the art in how large programs are built and tested, the “build chain”.

We don’t talk about this much because it isn’t very client-facing, but thanks to the efforts of Justin Deoliveira and Tim Schaub, OpenGeo has a quite robust build environment. Early on in the development on the OpenGeo Suite we found that the number of steps necessary to move from a particular version of the code to an installable and testable artifact was very high—so high that cycles of test/fix/re-test were just too long.

So we automated this chain, and not just the build. Our software is now automatically built out from source code all the way to installers (for Mac OS X and Windows) and packages (for Ubuntu Linux and CentOS Linux) and machine images (for Amazon AWS) every hour. The industry term for what we’re doing is called “continuous integration“.

The complexity of a system that builds multiple components (GeoServer, PostGIS, PostgreSQL, GeoExt, etc.) in multiple languages (C, Java, JavaScript) on multiple operating systems (Linux, OS X, Windows) is quite substantial, but it is all worth it to be able to incorporate a bug fix into a new installer in short order without human intervention. As we have many clients who are depending on our software for their deployments, this reliable turnaround is critical.

Our system has grown so large that we are now devoting a full-time engineer (welcome, Michael Weisman) just to maintaining and improving it. In time, we plan to add even more components and functions into the mix, such as continuous builds of GDAL and continuous unit testing of all components against multiple databases. The benefits in flexibility, quality, and development speed is well worth the investment.

So if you’re looking for us, you’ll find us building on the chain.

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.