Problem: Choosing a Robot Software Stack That Won't Trap You
You're building a robot — or managing a team that is. The software stack decision you make today will shape your velocity, your vendor relationships, and your maintenance burden for years. Open source or proprietary? Both camps made significant moves in the last 18 months, and the calculus has shifted.
You'll learn:
- Where open source robotics (ROS 2, Open-RMF, Nav2) stands in 2026
- What proprietary platforms actually offer that open source doesn't
- How to match your team's situation to the right choice
Time: 12 min | Level: Intermediate
Why This Decision Is Harder Now
Two years ago the answer was simpler: proprietary if you needed support, open source if you needed flexibility. That's no longer true.
ROS 2 Jazzy reached long-term support status in mid-2024 and the ecosystem around it — MoveIt 2, Nav2, Open-RMF — has matured considerably. Meanwhile, proprietary vendors like ABB, Intrinsic (Google's robotics spin-out), and NVIDIA Isaac have pushed hard into developer tooling and simulation, blurring the line between "platform" and "ecosystem."
The result: both paths are viable at production scale. The right answer depends on what you're optimizing for.
The Open Source Stack: Where It Stands
ROS 2 + Nav2 + MoveIt 2
ROS 2 Jazzy on Ubuntu 24.04 is the current LTS combination. If you're starting a project today, this is your baseline.
# Install ROS 2 Jazzy
sudo apt install ros-jazzy-desktop
# Verify
source /opt/ros/jazzy/setup.bash
ros2 --version
Expected: ros2cli 0.18.x or later
The stack is genuinely production-ready for manipulation and mobile robotics. Boston Dynamics, Clearpath, and most warehouse robotics startups now publish ROS 2 packages for their hardware.
What's good:
- No per-unit licensing. This matters at scale — a fleet of 500 robots doesn't come with a $500K software bill.
- Hardware portability. Swap your arm vendor without rewriting your planning stack.
- Community velocity. Nav2 shipped 4 major releases in 2025 alone.
What's still hard:
- Real-time performance requires careful tuning.
ros2_controlwithcycloneddsgets you there, but it's not automatic. - Simulation integration is improving but NVIDIA Isaac Sim still edges Gazebo for visual fidelity and sensor modeling.
- Enterprise support requires a third party (Canonical, Open Robotics commercial, Ekumen).
ROS 2 with DDS middleware — nodes communicate via topics, services, and actions
The Proprietary Options: Who's Actually Competitive
Intrinsic Flowstate
Google's bet on robotics software. Flowstate offers a graphical programming environment on top of a hardened ROS 2 core. You get the openness of ROS 2 underneath with a managed layer on top.
Best for: Teams with strong product chops but lighter robotics software experience. The visual tooling genuinely reduces cycle time for behavior development.
Watch out for: Lock-in at the orchestration layer. Moving off Flowstate means rewriting your behavior trees and cloud integrations, even if your ROS 2 nodes are portable.
NVIDIA Isaac Platform
Isaac has become the default choice for perception-heavy applications — pick-and-place, quality inspection, autonomous mobile robots in complex environments. The sim-to-real pipeline using Isaac Sim + Isaac ROS is legitimately impressive.
# Isaac ROS perception pipeline (runs on Jetson Orin)
from isaac_ros_apriltag import AprilTagNode
from isaac_ros_visual_slam import VisualSlamNode
# Isaac ROS nodes are standard ROS 2 nodes — interoperable
Best for: Vision-driven applications, sim-heavy development cycles, Jetson hardware users.
Watch out for: NVIDIA hardware dependency. The SDK is free but it's optimized for — and in some cases requires — NVIDIA silicon.
ABB Ability / Universal Robots PolyScope X
Industrial arm vendors have dramatically improved their software platforms. UR's PolyScope X now supports URCap development in Python and has a well-documented SDK. ABB's Ability platform integrates with common MES and SCADA systems out of the box.
Best for: OT environments, ISO-compliant manufacturing lines, teams that need a supported path to machine safety certification.
Watch out for: Velocity. Industrial platforms move slowly by design. If you need to ship new behaviors quarterly, you'll feel the constraint.
How to Choose
The decision comes down to four factors:
Fleet size and licensing cost. Open source wins above ~50 units deployed. The math is straightforward — calculate your 3-year TCO including support contracts versus per-unit fees.
Perception complexity. If your robot needs to handle significant visual variation in unstructured environments, Isaac's sim pipeline and perception libraries have a real advantage today.
Regulatory environment. Manufacturing, medical, and logistics applications with safety-critical requirements often need certified software components. Proprietary vendors have this path documented. Open source can get there, but you're building the compliance case yourself.
Team composition. A team of 3 engineers building their first robot fleet will move faster on Flowstate or Isaac. A team with ROS 2 experience will resent the constraints of a proprietary layer and build slower, not faster.
Simplified decision path — most real situations have more variables, but this covers 80% of cases
The Hybrid Approach (What Most Teams Actually Do)
Few serious robotics teams use pure open source or pure proprietary in 2026. The practical pattern:
- ROS 2 nodes for motion planning, sensor drivers, and application logic
- Isaac ROS for perception (it's MIT licensed and runs on standard ROS 2)
- A proprietary cloud layer for fleet management (Foxglove, Formant, or vendor-specific)
- Hardware from a vendor with active ROS 2 package support
This gives you hardware portability and community ecosystem benefits while using commercial tooling where it genuinely saves time.
# Example: docker-compose for a hybrid stack
services:
ros2_core:
image: osrf/ros:jazzy-desktop
network_mode: host
isaac_ros_perception:
image: nvcr.io/nvidia/isaac/ros:latest
runtime: nvidia
network_mode: host # shares ROS 2 network with core
fleet_manager:
image: formant/agent:latest # or your vendor
environment:
- ROBOT_ID=${ROBOT_ID}
Why this works: ROS 2's DDS transport means nodes from different origins communicate natively. Isaac ROS nodes appear to your application code as standard ROS 2 nodes.
Verification
If you're evaluating a new stack, run this sanity check before committing:
# Check topic latency — critical for real-time control
ros2 run ros2doctor hello_robot
# Benchmark DDS transport
ros2 run performance_test perf_test -c rclcpp-single-threaded-executor \
--msg Array1k --max-runtime 30
You should see: End-to-end latency under 5ms for control loops, under 50ms for perception pipelines on local networks.
What You Learned
- ROS 2 Jazzy is production-ready in 2026; the "not mature enough" objection is outdated
- Proprietary platforms win on support, certification paths, and sometimes simulation tooling — not on raw capability
- Hybrid stacks (ROS 2 core + commercial perception + commercial fleet management) are the practical norm
- Fleet size above ~50 units almost always favors open source licensing economics
Limitation: This analysis focuses on general-purpose and mobile robotics. Surgical robotics and aerospace have different regulatory constraints that weight the proprietary side more heavily.
When NOT to go open source: If you need a certified functional safety stack (IEC 62061, ISO 13849) out of the box, you're building that certification on top of ROS 2 yourself. That's a multi-year project. Buy it instead.
Tested against ROS 2 Jazzy, Isaac ROS 3.x, PolyScope X 1.x. Fleet economics based on publicly available licensing models as of Q1 2026.