You are already using open-source. I’ve said that time and again to various audiences. The most committed Microsoft and Esri users will immediately balk, but it’s easy to knock the objections down. Azure? Linux abounds. Esri? GDAL under the hood. And what does the “Py” in ArcPy stand for? Oh yeah, Python, the open-source programming language. You’re already using open-source, even if you don’t know it.
I’ll be charitable and say that “using” could be a strong word, but it’s certainly fair to say you are relying on open-source, whether you know it or not.
The reason that’s fair to say is because open-source is everywhere and there is a study to demonstrate it. I’m not sure how I missed it when it came out in 2024, but Harvard published a rigorous study on the value of open-source. They surprised even themselves when they came up with a $9 trillion estimate of the global value of open-source, using a replacement value approach. I won’t get into the details here, but you can click through to the academic paper that details the approach.

What it found was bits and pieces of open-source in platforms and software all across the tech industry. It’s worth noting that the study did not account for operating systems, so the value may actually be much higher. Those bits and pieces add up to real value because, if they were summarily yanked out, the platforms and software that use them would at least be degraded if not fail outright. The study looked at all open-source, not merely geospatial, but the point is the same. Open-source is everywhere and you’re already relying on it.
Since I began dabbling with open-source geospatial tools in 2006, I have encountered the usual FUD about the “risks” of open-source. They run from the xenophobic – “You don’t know what foreign nationals touched that code” (As if commercial vendors haven’t been offshoring for 20 years) – to the ridiculous claims about cybersecurity risk which can be easily countered (Bottom line: all software has vulnerabilities, regardless of provenance), to lifecycle concerns about availability of support and similar issues. The lifecycle argument can have some merit depending on the maturity of the open-source project being discussed. But, when you consider the scale of open-source usage in commercial platforms (including SaaS), the argument is easily turned back (“How do you deal with that in the open-source you use?”).
What I find interesting, and which the Harvard study lays bare, is that the real risk with/to open-source is almost never discussed amongst the FUD – sustainability. Many organizations that use and derive value, directly or indirectly, are exclusively takers – relying on the free-as-in-beer nature of open-source which doesn’t explicitly require users to support projects in any way. Paul Ramsey has discussed this far better than I can and I recommend you watch one of his talks on the subject.
Taking without supporting puts a strain on the people who work on open-source. Sure, they don’t ask for anything in return, but there’s an ethical component to be considered. And, if you are not moved by ethics, we now have a number: $9 trillion. If open-source is treated like the software equivalent of truffula trees, then $9 trillion in value could end up like a thneed factory. Maybe that’s far-fetched and alarmist, but it’s much less so when you consider just your small share of that $9 trillion.
So what can you do to mitigate that risk? The answer isn’t “stop using open-source” or “demand your vendors stop using open-source.” Remember, that $9 trillion is replacement value. The answer is to support open-source or make sure your vendors are doing so. You can start by asking to see a software bill of materials (SBOM) for the software/platforms that you use. Fair warning: many of your vendors won’t have that. The fallback is to simply ask them what they do to support the open-source software they use in their products. Don’t accept “we don’t use any” as an answer.
QGIS Australia offered a list of things that can be done to support open-source. It’s a great place to start.
1) Hire OSS developers and include in their position description a remit to spend time maintaining the software.
2) Mentor your current staff to become OSS contributors from current OSS developers.
3) Engage OSS contributors to maintain or develop features in your chosen software
4) Become a sustaining member or donate to the project
5) Sponsor and attend your project’s events and conferences
In short, integrate open-source into your lifecycle management, operationally and financially, as you would any other software. I’ve done that in the past in previous career stops and am considering creating a workshop on the topic for future FOSS4G events. In the meantime, open-source software is a fact of life. You are already using it and relying on it. Go learn about it. Knowledge is the antidote to FUD. I am not suggesting you should replace any tool you are currently using with open-source, but the decisions your vendors make affect your operations. Learn more so you can advocate for yourself and, in turn, the open-source community.
Finally, since I’ve mentioned Esri in this post, it’s only right to also mention that they’re doing a good job supporting the GDAL project, so, if you’re an ArcGIS user, you can feel good about that.