Tuesday, December 12, 2006

Open Source Geospatial Software Provides an Enterprise Alternative for Small Agencies

In the past several years, I have encountered a variety of public utilities and municipalities that have fewer than 10 technical staff members. Each of these clients spoke with me about making the transition to the right enterprise GIS for their size organization. Typically, I prefer to drive requirements discussions away from technology and toward the functionality that the client needs to improve his business. However, most of my clients are decision makers who nearly always hold preconceived opinions about which would be the right technology to solve their particular problems.

One recurring theme in those discussions has been the unwillingness to try open source software (OSS) technology as an alternative to license fee-based proprietary technology. Even though OSS has been on the market for years and despite the established developer and user communities for many OSS products, my clients offer a standard set of objections to using OSS. They worry that OSS is not robust or well-performing. Managers at small agencies judge that their staff cannot support non-proprietary products and believe that there is no enterprise-class support for the software. Finally, these managers and their GIS advisors already 'know' that their CAD data cannot support geospatial applications. Despite these issues, a large proportion of small agencies and utilities will find that they already have what it takes to implement and support basic geospatial OSS that can help grow support for GIS in their enterprise.

Before discussing the pros and cons of open source, OSS should be defined as separate from open standards and open application programming interface (API) technologies. Web-based mapping tools such as the services offered by Google, Yahoo and Microsoft have open APIs that can be accessed by anyone on the Web, but they use only some open standards, and end-users have no access to the source code. ArcGIS, MicroStation and AutoCAD are software products that may follow open standards. However, they do require a purchased license to use the programming interfaces and are definitely not open source or open API, and you don't get any source code. These products require license fees for anyone to customize them. By its nature, OSS has open APIs and it should follow open standards. The defining characteristics that differentiate OSS from proprietary tools are that anyone with a computer and an Internet account can download the source code of an OSS application and use it with no licensing fees.

Any question about whether or not OSS GIS tools are ready for 'prime time' should be put to rest. The geospatial OSS market offers thick-client, Web-based, and database geospatial OSS, all with established user communities. GRASS has been on the market for over a decade in one form or another. The University of Minnesota's MapServer matured into an enterprise toolkit several years ago and is now a popular open source alternative to proprietary Web-mapping tools. The MySQL and PostGRES OSS relational databases both offer geospatial modules to store GIS data. Small groups like Refractions Research and large companies such as Autodesk released geospatial OSS tools. Autodesk's move with MapGuide Open Source created a stir, because a major geospatial vendor committed to fostering projects in the open source community that are intricately tied to its proprietary product line. This ongoing expansion of geospatial OSS alternatives contributes to the education of different market segments in the application of OSS while continuing to grow the community of geospatial professionals who support and use OSS tools.

Small utilities and municipalities have few technical staff members. This low staff number is cited as one reason for avoiding OSS. In these agencies, managers may have lost sight of the inherent value of the type of individual who takes a technical position at a small agency and sticks with it for years. Over time, these individuals become experts at optimizing their day-to-day routine by picking up a variety of skills and hobbies that help them effectively do a job that would require several people at a larger organization. Also, these staff members rely on personal relationships with similar employees at other organizations to share stories and knowledge about how to work smarter and more efficiently. OSS developers typically describe themselves as tinkerers and hobbyists. OSS users develop well-networked communities that use online forums, instant messaging and conferences to connect and share information about free GIS software that can help them do their jobs. The resourceful, independent individual with a diverse skill set who works at a small municipality or utility perfectly mirrors over half of the geospatial OSS developer and user community members whom I have met.

Especially when moving to one of the proprietary geospatial database formats, two obstacles arise that often prevent small agencies from moving to a Web-based GIS that would be visible throughout the enterprise. The overestimation of technology need and the expense of complex data conversion processes prevent some agencies from moving forward with GIS implementations. In the drive to sell software licenses, many product companies promote the need to build the biggest and best geospatial dataset to support long-term operations. Simultaneously, the industry professionals who work with these products have been trained that a specific conversion pathway is required to get the paper maps and CAD files at these small agencies to the perfect state of GIS readiness.

Both of these items are great for selling software licenses, but ignore the same basic precept: Small agencies typically have meager technology budgets that prohibit developing either a fully networked enterprise dataset or the ideal CAD to GIS data conversion process. Unfortunately, these agencies fall into a trap that prevents them from developing geospatial applications and disseminating information about the use of GIS throughout the enterprise. When this impasse is reached, small agencies should look to geospatial OSS as a great way to put maps and map-related information on the Web. Many CAD file formats can now be displayed through popular OSS packages without conversion to a GIS format. Through some of these toolkits, the user can also display schematic CAD files that are more useful to some utility data consumers. While data imperfections are a problem, publishing them to a carefully chosen, broader audience though an intranet application should engender interest and action that should eventually help justify funding to get the imperfections fixed.

Another common objection to OSS is the perception that if the software breaks, there is no one to sue. If a technology manager implements a solution to support mission critical enterprise processes, that solution needs to have a warranty or maintenance contract or else the technology manager is the only person who takes the blame if the implementation fails. Enter Autodesk. In addition to offering a robust line of proprietary products with a well-established user base, Autodesk decided to build and release MapGuide Open Source. MapGuide is rapidly growing a dedicated developer community. For those users who successfully implement the technology and then want someone else to support it, Autodesk offers enterprise licensing. Refractions Research, DM Solutions Group and other smaller consulting companies with open source experience may also offer customers enterprise support contracts for geospatial OSS. With this type of licensing, small agencies can download the software, try it out and eventually purchase enterprise maintenance and support if the technology becomes accepted and critical in the enterprise. The barrier of having no external support for OSS except for a vague 'community' has been removed.

While the broader information technology industry has built many business cases that show that OSS implementations have a total cost of ownership (TCO) similar to that of proprietary software implementations, TCO studies have yet to be done in the geospatial market. Given that a small organization can now implement free geospatial software using their existing data with the ability to later purchase enterprise support, we will likely see several good case studies comparing OSS to proprietary tools in the near future. With the liberal licensing on some geospatial OSS, I hope an industrious company will develop a 'map server in a box' appliance. Such an appliance, coupled with a basic methodology to package up an organization's available data, would greatly accelerate the adoption of geospatial OSS and further decrease the TCO for geospatial open source. Add enterprise support to the existing combination of diverse geospatial OSS functionality, established user communities and low cost of entry, and the implementation of geospatial OSS becomes an obvious strategy for facilitating the adoption of GIS at small agencies and utilities.