Deciding Between FOSSGIS and Proprietary Software in the Enterprise

FOSSGIS (Free and Open Source Geographic Information Systems) is an umbrella term for Open Source GIS projects. In the following article, Tim Sutton (QGIS project chair and director at Kartoza Pty Ltd.), explains how and why FOSSGIS makes its way into an enterprise environment.

Is FOSSGIS ready for the enterprise environment or is proprietary software better?

Let's start with the hypothesis that, as a GIS professional, you wish to ‘tool up’ with the optimal set of software and hardware needed to carry out your duties. Having good instrumentation to measure what is the ‘best’ software is thus critical. In my mind, there are two main considerations at play when measuring optimality. The first is cost. This encompasses both the ‘sticker price’ of a given product and the attendant costs of using and deploying a product in a production environment. Hardware, training, overheads in deployment/provisioning within the enterprise, the efficiency of the toolset (as relates to worker hours needed) for carrying out tasks, and so on, all contribute to the costs of your deployment.

The second consideration for measuring optimality of FOSSGIS is functionality. This relates to the tooling that a particular software package or suite of software packages provide. From a GIS professional’s perspective, the toolset should cover aspects of their workflow. This includes functional requirements such as: spatial data storage, data editing and creation tools, cartography and visualisation capabilities, print production, and the ability to publish to mobile devices and the web.

Generally, cost and functionality, which we shall discuss in more detail below, are organisational constraints when selecting a toolset. These constraints often operate in tandem to drive the choice for the software stack used in production. They tend to be the dividing lines in the debate around which solution (proprietary or FOSSGIS) is better for an organisation. It is often the case that proprietary vendors will downplay the costs of their offerings, whilst focussing on the rich functionality, including auxiliary functions such as the provision of support and maintenance releases etc. In contrast, FOSSGIS emphasises often, as demonstrated in Figure 1, their cost saving advantages over that of proprietary enterprise vendors. The opposite extremes also exist; proprietary software that is cheap or even free; Open Source software that is costly; proprietary software that has a limited feature set; and Open Source software that has an extremely broad feature set.

The discourse around FOSSGIS for enterprise is, unfortunately, often characterised by both sides with a sentiment of Fear, Uncertainty, and Doubt (FUD). As a result, it is easy for the GIS professional to get enmeshed in a kind of ‘software zealotry’ or mindset of attachment which limits ‘followers’ from exploring alternatives. Proponents of open source will often promote the use of FOSSGIS and try to dissuade others from using proprietary alternatives. Despite the good intentions, this ‘zealotry’ is an unhealthy approach which merely serves to polarise the GIS communities at a time when it is beginning to serve the requirements of existing and new enterprise users. Rather, it is better to formulate a response based on the merits of a situation instead of using a predefined response.

In this regard, it is time to propose a more pragmatic approach to the consideration of FOSSGIS to meet enterprise requirements. This new approach, which is based on fitness for purpose, looks at problems and solutions holistically, and does not predetermine a solution based on organisational preferences for a particular software development model. Thus, deciding if a FOSS offering is ‘better’ becomes a more clinical process of reviewing your requirements and your budget, and evaluating the competing GIS product offerings based on the sum of value each brings to your organisation. Although this may sound like an entirely logical approach, very often important decisions are made which defy this logic.

Cost of FOSSGIS

The ‘Free’ in Free and Open Source Software does not refer to financial cost. Rather it refers to ‘freedom’ - in particular, the freedom to procure, provision, modify and redistribute the software both in binary and source code forms. Proponents of FOSS often view this ‘freedom’ as a critical factor in the selection of a software toolset. Rather, ‘Free’ should be considered as part of the functionality set of a software product - it provides opportunities to extend the software based on one’s needs, and, therefore, it manages the distribution of that software under a different model to that provided by proprietary software. This is in contrast to the approach of proprietary vendors who promote the superiority of their product (i.e. drawing on their support networks, their proprietary tools, and their extensive knowledge bases etc.)

Consider a scenario where the functional requirements for an organisation are equally serviced by both FOSS and Proprietary Software, and the differentiator for a decision comes down to cost alone. In this case, it would be unrealistic to describe the FOSS offering as free since one will need to consider the whole cost of deploying software in an organisation. If we consider the following matrix which compares both models (including factors such as training, licensing, hardware, installation/provisioning, support and customisation), we will see that, generally, there is only one area where FOSSGIS offers a zero cost advantage: licensing.

Among other considerations, it should also be noted that most Open Source licenses do not preclude the sale of the software. Rather, the license mandates that the software source code is provided together with the binary software (or in an easily accessible manner); for example, QGIS is available as an official download for free from the QGIS website. It is also available from commercial support providers in the QGIS community who make their own (unofficial from the perspective of the QGIS project) builds available to their paying customers.

Considering the above-mentioned costs associated with FOSSGIS, it becomes evident that a review would be needed across the different outlay areas when comparing a FOSSGIS offering with that of a proprietary vendor to identify what the expected costs will be. Proprietary vendors are at an advantage in offering pricing, since they can generally offer a ‘one stop shop’ for all the core services around their product. In the FOSS world, on the other hand, customers may need to either approach different vendors for different aspects of the required services, or to search for a vendor who offers the somewhat elusive ‘all in one’ solution. This can, however, also be seen as an advantage, especially since one can ‘go to market’ to find an optimally priced support company.

Functionality of FOSSGIS

Making a list of the required functionality will provide a much better entry point for a comparison between two competing solutions. In my own business, I frequently encounter organisations that have taken the feature set of a proprietary vendor and then requested Open Source projects to replicate them. This is the wrong approach. It would be better to compile a list of the critical features, and then poll Open Source projects on the availability of those features. There is another key, but often overlooked, aspect of feature comparisons. In the Open Source world, it is often relatively trivial to introduce missing features into the product. If, for example, nine out of ten of your critical features are available and the last is missing it is often still more cost effective and efficient to pay a developer to implement the missing feature for you.

In measuring the optimality of FOSSGIS for enterprise purposes for functionality, it is also important to review the ecosystem of tools surrounding a project. In QGIS, for example, there is a rich ecosystem of plugins that extend the functionality of the software. These plugins also often address specific vertical market requirements that you would not find supported in the core project. Proprietary vendors often edge out FOSS projects in terms of the vertical market add-ons that they provide. Decision-makers should, therefore, investigate the availability of these industry-specific functionality requirements first. In general vertical applications (e.g. specific to the mining sector, military etc.) tend to be better provided for by proprietary vendors. This is a symptom of the fact that projects like QGIS rely on an interested community with the appropriate technical knowledge to build the software. Therefore, the more generic the functionality, the more likely that volunteers will be enticed to contribute to it.

Nevertheless, in relation to the QGIS project at least, there appears to be a trend towards the formation and funding of interest groups which are focused on developing a specific functionality (e.g. for wastewater management, cadastral management etc.) As well as including application features in a functional requirements matrix, decision-makers should also consider factors such as the ease of deployment, the ability to work without license managers and other encumbering technologies. Furthermore, decision-makers should also consider the ability to go to the market, the ability to hire a developer of your choice to support feature development, and the availability of resources for training, developer documentation, how-to’s, and so on.

The support of feature development is one of the big advantages of working with Open Source projects since users are able to ‘upstream’ new features and bug fixes directly themselves. Although many consumers shy away from this idea initially, the ability to deploy software which is malleable to an organisation’s needs and productivity gains is one of the key functional areas that should be included in an enterprise GIS decision matrix. QGIS, for example, regularly receives contributions from developers who have been funded by an organisation to implement a specific feature needed to support that organisation’s work. Thankfully, in most cases at least, the time periods between initial development funding, seeing the feature or bug fix in the code base, and then made available to the organisation to use is generally very short. Bug fixes and trivial changes can be landed within the upstream project within hours or days and can be made available to the tester the following day if one makes use of nightly builds. Even in the more conservative cases, where reliance is made on long-term supported versions of QGIS, bug fixes can be made available to official QGIS installers within a month.

A Mature and Pragmatic Selection Approach for 2018

As mentioned earlier in this article, in 2018, a more pragmatic and mature approach to the selection of a GIS toolset for an enterprise is required. Hardline rhetoric and sales patter, something which was pervasive in the earlier years of the ‘Open Source vs proprietary software’ debate, needs to be put aside. Instead, decision-makers need to address technology choices from the point of view of cost and functionality at a much deeper level (i.e. beyond simply the sticker price and feature list provided by a particular software product).

What I would like to show in future articles is that FOSSGIS can be a cost-effective alternative, with a very rich feature set that can address an organisation’s needs. It simply requires that decision-makers approach the selection process in a broad and open-minded way.

This article was published in GIS Professional February 2018