Final ranked assessment of an open, self-hostable shelter + construction stack

Open-source IFC toolkit and geometry engine. Parses, writes, and transforms IFC while providing C++ and Python bindings plus a dense CLI surface for conversion, diffing, validation, and automation.

This is the BIM law-engine. If it vanished, the OpenBIM stack would be materially weakened. Domain fitness and standards alignment are near-maximal because it sits directly on the IFC semantic and geometric layer. Composability is maximal through its APIs and command-line tools. Governance is strong but not perfect due to bus-factor and funding concentration risk, so this remains a mirror-and-fork priority.

Spatial extension for PostgreSQL that adds storage, indexing, and querying for geospatial data. It is the spatial ledger and query engine underneath the geo layer.

Together with IfcOpenShell, this forms the dual spine: BIM semantics on one side and geodata on the other. Standards alignment is maximal because this is one of the core open geospatial substrates. Maturity is maximal due to long-standing production use. This is a non-negotiable backbone component for parcel, site, district, city, and regional computation.

Full desktop GIS for visualization, editing, analysis, cartography, and orchestration across vector, raster, database, and service layers.

This is the primary geospatial desktop client and the practical front-end to PostGIS and GeoServer. It is extremely mature and deeply interoperable. The main structural caveat is plugin sprawl: critical workflows should be documented and minimized rather than buried inside fragile plugin chains. Governance remains strong through the OSGeo structure and broad community base.

GPL OpenBIM authoring environment built in Blender and oriented around native IFC workflows for modeling, documentation, and structured data work.

This is the canonical IFC-native authoring environment in the stack. Its score sits just below IfcOpenShell because the conceptual backbone remains the library layer, while Bonsai is the principal interface for authoring and documentation. Strong privacy, licensing, and governance characteristics keep it firmly in the backbone zone, with complexity and training overhead as the main friction points.

Desktop environment for point-cloud and mesh visualization, alignment, segmentation, comparison, and QA across common open geometry formats.

This is the main point-cloud and geometric reconciliation environment where reality and model meet. Domain fitness is extremely high because construction and as-built workflows live or die on the ability to inspect, compare, and correct geometry. The only meaningful tax is that automation typically requires disciplined CLI wrapping around a GUI-first culture.

AGPL photogrammetry engine that turns image sets into maps, orthos, DEMs, point clouds, and meshes through CLI-first workflows.

This is the reality-capture engine for drone-scale acquisition. The AGPL materially strengthens anti-enclosure posture. Composability is high because the system is CLI-first and pipeline-friendly. It belongs in the backbone because as-built capture, terrain reconstruction, and visual site truth are not peripheral functions in a sovereign construction stack.

Real-time Linux CNC controller for mills, lathes, routers, robot arms, plasma cutters, and other digitally controlled fabrication hardware.

This enters the backbone only when local fabrication is counted as part of the shelter and construction remit. In that scenario, it completes the loop from model to machine. The dominant risks are safety, tuning, and hardware-integration complexity rather than capture or enclosure. Where fabrication is externalized, it remains optional rather than structural.

Parametric CAD environment with workbenches spanning BIM, FEM, CAM, and general engineering geometry.

This is the parametric knife of the stack. It is not the primary BIM authoring environment, but it becomes crucial wherever custom assemblies, detailed geometry, or FEM pre/post work is required. High composability and maturity make it a durable bridge between the BIM side and the engineering-analysis or fabrication side.

Open whole-building energy simulation engine used to model energy consumption, water use, HVAC behavior, and envelope performance.

This is the core energy-physics engine. Domain fitness is very high because resilient shelter cannot ignore thermal and energy performance. Standards alignment is lower only because its working formats are domain-specific rather than IFC/OGC-native. Maturity is maximal due to long institutional continuity and broad industry use.

Open server for publishing geospatial data through OGC-aligned services such as WMS, WFS, WCS, and WMTS.

At district, city, or regional scale, this is the standard publication layer for geospatial services. It scores lower on deployability because secure Java server operations are heavier than desktop or library workflows. That does not reduce its importance at larger scales; it means only that it is optional for micro-nodes and core for broader infrastructures.

GPL finite-element solver for structural and mechanical analysis with long-term engineering pedigree and serious simulation depth.

This is the heavy structural truth engine for nodes that need real analysis rather than aesthetic design confidence. Domain fitness is high but not universal because it presumes a trained engineering layer. It belongs in the core analysis guild, not necessarily in every minimal deployment.

Open SDK and application layer that bridges building geometry and workflows into EnergyPlus and related energy-analysis pipelines.

This is the glue from geometry to energy simulation. It scores high on composability because the SDK and measure system support automation and repeatable modeling workflows. It is core where energy modeling is active, but it remains a bridge rather than the underlying physics engine.

Open photogrammetry suite with IGN/ENSG lineage, strong research depth, and serious capability for reconstruction workflows.

This is the specialist or special-operations photogrammetry tool. It is powerful and deeply scriptable, but the skill floor is materially higher than ODM. It is best positioned as a secondary engine for redundancy, edge cases, and expert workflows rather than the universal front-line capture engine.

Web interface and task orchestration layer for drone image processing, built around ODM and capable of running offline and self-hosted.

WebODM is useful and often practical, but it is not the backbone—the backbone is ODM itself. The page score intentionally penalizes privacy and governance relative to ODM because convenience installers, hosted offerings, and platform gravity can shift real-world usage away from self-hosted discipline. The safe interpretation is optional UX surface, not stack spine.

MIT-licensed TypeScript/WebAssembly runtime and component stack for high-performance BIM applications, viewers, and fragment-based workflows.

This is technically excellent but strategically high-vigilance. Composability is near-maximal, and standards alignment is strong, yet governance and capture risk are visibly higher due to single-company platform gravity and a permissive license that allows easy enclosure. The correct role is companion runtime alongside independent IFC engines, never sole substrate.

GPL finite-element analysis package with solver and pre/post processing, often useful as an independent second engine for verification.

This remains valuable primarily as a secondary FE engine. Its role is not to replace Code_Aster but to provide diversity, cross-checking, and compatibility with certain established workflows. It is strong, but not structurally central to the same degree as the BIM, geo, or primary physics backbones.

Mobile field data-collection environment for QGIS projects with offline capability and optional synchronization pathways.

This is useful but not structural. It fits well as a field collection client when tight cloud discipline is maintained. The penalties on privacy and governance come from the practical gravitational pull of QFieldCloud and convenience-first synchronization pathways. It belongs in the toolbelt, not in the ontological spine.