Yesterday evening, I had the pleasure of participating in a panel discussion on Clubhouse, hosted by Todd Barr and Jordan Cullen, and including Will Cadell of SparkGeo. Clubhouse seems to be a really convenient venue for setting up such a forum with low barriers to entry, so that was enjoyable. The topic of the discussion was “Geospatial ROI” and we talked about various ways to articulate the value of geospatial (the data and the concept) and GIS (the toolset to exploit geospatial).
One topic that we didn’t have time to get to, but has been at the front of my mind for a while is the “return on non-investment” with regard to open-source tools, geospatial or otherwise. Open-source has been mainstream for quite some time and platforms like Github make it easier to publish, manage, and maintain open-source tools. As a result, it’s easier than it’s ever been to find and use open-source tools to solve your problem.
Additionally, the number of permissive open-source licenses available means that more open-source is getting embedded into traditional proprietary, commercial software tools. An example of this is GDAL, the open source library used for geospatial data translations and many other functions. A quick look a its listing of software tools that use GDAL shows that a number of proprietary tools and SaaS platforms make use of GDAL. What’s not shown, and probably never can be accurately quantified, is the number of bespoke systems built by integrators large and small and sold via the billable hour, or by public sector entities that are using GDAL to drive value delivery and mission execution. I’ll continue to use GDAL as an example throughout this post but this topic applies more broadly.
When discussing open-source in terms of ROI, what do I mean by “investment?” There’s the traditional meaning: money. GDAL is totally free to use, so it requires no monetary investment to get started. That means it also requires no procurement process to get started, either. This theoretically means one can begin realizing value from GDAL relatively quickly, with the investment of effort to integrate it into existing workflows. Because of its open-source license, it’s easy to deploy. There’s no need for license metering or other calisthenics to ensure one is not “over-deployed” in terms of seat count. In a cloud environment, systems can freely scale with GDAL on board with no further licensing considerations.
Depending on one’s workflow, integration can be non-trivial, so let’s not pretend that part of the investment doesn’t exist, but it would still exist if GDAL were a paid commercial product. So the reduction of monetary cost and business process overhead flattens the investment while also potentially expanding the value realization due to the unlimited deployability of GDAL. Viewed through this lens, return on this non-investment is pretty easily quantified and amounts to shooting fish in a barrel.
But how does an organization that is realizing value from open-source ensure that it is supporting the projects that it uses? In a traditional purchase, the user pays money to the vendor and attempts to realize as much value as possible. The vendor generates revenue to fund its operations. Generally, everyone gets what they need. Open-source software is community-developed and relies on community support. Many projects have corporate sponsors (good) or a large, active community of contributors (also good), or both. But many small projects, like GDAL, don’t have that.
In the mid-2000s, I was a contributor to a small open-source project called zigGIS. It was an ArcGIS extension that added support for PostGIS to ArcMap. It was pretty interesting and we had big plans. As the project gained traction, it began to eat into the work day for the three of us who were supporting it. We didn’t have a lot contributors lining up to help, so we took the hard decision to convert it to a proprietary license to try to get it to pay for itself. It didn’t work and the product limped along until Esri built support for PostGIS into the platform, at which point, we shuttered it.
In hindsight, taking zigGIS proprietary was the wrong choice, but we were out of ideas. A small project that gains even a bit of traction can very quickly become taxing to its maintainers. But, looking again at GDAL, the list of software that uses it makes one thing clear: it is mission-critical. It drives much of the data translation in ArcGIS. If you are an ArcGIS user and you do any data translation, you are also dependent on GDAL. Aside from the value you generate, that dependency is another reason you should ensure that GDAL, or any other open-source project you may use is supported. (How do you know? Most open-source licenses require that a copy of the license be distributed with the software. Many commercial tools place these in a folder in the install location or in a scroll window in the about box. If such a thing exists, your software is using open-source and so are you.)
Supporting open-source generally takes two forms: contribution of effort or contribution of money. Depending on where the maintainers live or how much effort they’ve put into it, taking monetary contributions can be quite difficult. “Contribution of effort” doesn’t always need to mean “code.” It can mean helping keep documentation up to date or localizing for other languages, or building deployments, or number of other things. As a user who realizes you are deriving value from open-source, here are a few things you can do to encourage a bi-directional value chain.
- When you realize that a commercial tool you use is using open-source under the hood, contact your vendor rep and ask them what projects they are using and ask them how they are supporting the projects in return. Do they provide funding? Do they provide infrastructure such cloud instances or devops tools? Do they encourage or require their staff to contribute back to the projects at a certain level? They don’t have to do all three, but they should do at least one. If they don’t, keep asking the questions. Encourage colleagues to do the same and generally raise the noise-level of the issue with the vendor. Advocacy is another way to support open-source.
- How does your organization support open-source? This is relevant whether your organization makes a product that uses open-source or derives value via billable projects. Generally, the questions are the same as those you’d ask a vendor but you have a lot more agency if you find the answers unsatisfactory. In that case, be a part of the solution by helping to develop a plan that encourages staff to contribute – not to a fork of the project in your organization’s private repo, but to the core project.
Do some ROI analysis to estimate how much the company would spend to license commercial equivalents and propose budgeting a fair amount into your organization’s next IT budget to make monetary contributions. (This is the approach I took for QGIS, the GDAL barn raising, and QGIS Mac installer projects). Present the plan to leadership and push to get it adopted. Doing this will accomplish two things: you will gain the experience of aligning resources for your organization and your leadership will better understand that open-source tools are real resources that require first-class consideration alongside proprietary purchases. - What if you are a public sector organization? This can be trickier because it’s harder for these types of organizations to contribute monetarily and they often have serious constraints in how they allocate FTE labor. Working your procurement shop, you can begin to write language into your procurements requiring vendors and integrators to account for how they use and support open-source tools in the solutions they deliver to you.
Smarter people than me have been talking about this issue for years (hat-tip to Paul Ramsey and Howard Butler to name just two), but it’s an important one and I don’t feel like I’ve done enough to help. I get to think about how I’ll rectify that, but the discussion of geospatial ROI reminds me that open-source tends to be a glaring hole in such considerations.
