Short answer

There is no single open-source program called "free ArcGIS." ArcGIS is a suite, and the open-source replacement is a small stack of focused tools: QGIS for desktop work, GDAL/OGR for data conversion and batch processing, PostGIS for the enterprise database, GRASS and SAGA (and WhiteboxTools) for heavy analysis, and GeoServer/MapServer + PostGIS + a JS map library for publishing. Mapped tool-for-tool, this combination covers the large majority of what geology, terrain, and Earth-data teams do in ArcGIS Pro, ArcToolbox, ArcGIS Server, and ArcGIS Online.

The mapping, component by component

Desktop: QGIS replaces ArcGIS Pro

QGIS (current LTR in the 3.x line) is a full desktop GIS: multi-format loading, on-screen digitising and topological editing, an expression-based styling engine, the Print Layout composer for cartographic output, and Atlas for series mapping (the equivalent of ArcGIS Data Driven Pages). Its Processing toolbox is the real workhorse — it exposes hundreds of algorithms, many of which are thin wrappers around GDAL, GRASS, and SAGA, so you call best-of-breed engines through one consistent interface. QGIS reads and writes the Esri formats you will be handed (shapefile, file geodatabase via the OpenFileGDB driver, lyr styling is the main gap) so interoperability is rarely the blocker.

Data engineering: GDAL/OGR replaces much of ArcToolbox

A large fraction of ArcToolbox is data conversion, projection, clipping, and raster math. ogr2ogr (vector), gdalwarp (raster reproject/mosaic/clip), gdal_translate (format and type conversion), gdaldem (slope, aspect, hillshade, roughness), and gdal_calc.py (raster algebra) cover those at the command line, scriptably, with no licence. Because they are commands, they are reproducible and automatable in a way that point-and-click ArcToolbox runs are not.

Database: PostGIS replaces the enterprise geodatabase

PostGIS turns PostgreSQL into a spatial database with geometry/geography types, GiST spatial indexing, and a rich function library (ST_Intersects, ST_Buffer, ST_Union, ST_Transform, topology, raster). It is the open-source counterpart to an enterprise (SDE) geodatabase: a single authoritative store that QGIS, scripts, and web services all query. Versioned editing and the full Esri enterprise management layer are where it differs, but for analysis and shared storage it is fully capable and widely used in production.

Analysis: GRASS, SAGA, WhiteboxTools replace Spatial Analyst

For terrain and hydrology — the bread and butter of geological work — the open-source tools are strong:

  • GRASS GIS: r.watershed (flow accumulation, drainage direction, basins), r.slope.aspect, r.fill.dir, r.viewshed, v.surf.rst interpolation.
  • SAGA: Fill Sinks (Wang & Liu), Channel Network and Drainage Basins, Topographic Wetness Index, and a deep terrain-analysis library.
  • WhiteboxTools: a fast, well-documented terrain and hydrology toolset with breach-depression algorithms often preferred over simple sink filling.

All three are callable from inside QGIS Processing, so you do not leave the desktop to use them.

Publishing: GeoServer/MapServer + web clients replace ArcGIS Server and Online

To serve data, GeoServer or MapServer publish standards-based services — WMS, WFS, WMTS, and increasingly OGC API - Features — backed by PostGIS. On the client side, Leaflet (simple), OpenLayers (full-featured, projection-aware), and MapLibre GL (vector tiles, GPU styling) build the web maps. This trio replaces both the server publishing role of ArcGIS Server and the hosted web-map role of ArcGIS Online, at the cost of running the infrastructure yourself.

Cloud and remote sensing

For Earth observation, Google Earth Engine (free for research/non-commercial), the Copernicus / Sentinel ecosystem, and STAC-indexed cloud-optimised GeoTIFFs with the rasterio/rioxarray and geopandas Python stack cover large-scale analysis. This is increasingly where the work happens, and it is largely open-source-native rather than ArcGIS-shaped.

A worked migration example

Say an ArcGIS hydrology workflow is: clip a DEM to a basin, fill sinks, run flow direction and accumulation, derive streams, and publish the result as a web layer. The open-source equivalent:

# 1. Clip + reproject the DEM
gdalwarp -t_srs EPSG:32630 -cutline basin.gpkg -crop_to_cutline \
  -tr 10 10 -r bilinear dem_src.tif dem.tif

# 2-4. In QGIS Processing toolbox:
#   SAGA "Fill Sinks (Wang & Liu)"  -> filled DEM
#   GRASS "r.watershed"             -> flow accumulation + drainage direction
#   threshold accumulation -> stream raster -> r.to.vect to lines

# 5. Load streams to PostGIS for serving
ogr2ogr -f PostgreSQL PG:"dbname=geo user=me" streams.gpkg \
  -nln hydro.streams -lco SPATIAL_INDEX=GIST
# then publish hydro.streams via GeoServer as WMS/WFS

Every step is reproducible and free, and the GRASS/SAGA algorithms are comparable to or, in the case of depression handling, often more sophisticated than the Spatial Analyst defaults.

Where ArcGIS still wins

Be honest about the gaps, because choosing on ideology rather than fit is its own mistake:

  • Enterprise integration and administration. ArcGIS Enterprise offers turnkey identity, sharing, and permissions that you would otherwise assemble from several components.
  • Specialised extensions. Some niche capabilities (certain network/utility, parcel fabric, and specific industry solutions) have no exact open-source equal.
  • Vendor support and accountability. A support contract and a single throat to choke matters to some organisations.
  • Hosted sharing. ArcGIS Online is a one-click hosted experience; the open-source equivalent means running GeoServer and a tile cache yourself.

The right question is never "which is best" in the abstract but "which fits this workflow, team, data volume, and auditability requirement."

Validation when adopting an open-source stack

  • Reproduce a known result. Run an existing ArcGIS analysis output through the open-source path and compare values, not just appearance.
  • Round-trip formats. Confirm that data handed to and received from Esri-based partners survives conversion (geometry validity, field names, CRS) with ogrinfo checks.
  • Pin tool versions. GRASS/SAGA algorithm defaults change between versions; record versions so results stay reproducible.
  • Prototype the riskiest step first. Usually that is a specialised analysis or a publishing/integration requirement, not the everyday mapping.

Bathyl perspective

We assemble the stack around the project lifecycle, not the brand. In practice that is QGIS plus GDAL and PostGIS for almost everything, GRASS or WhiteboxTools when the terrain analysis demands it, and a GeoServer or vector-tile layer when the deliverable is a web product. The deciding criterion is whether the result can be inspected, repeated, and handed off — which open-source tools, being scriptable and transparent, tend to support well.

Related reading

Sources