Open Source Comes for the Robot Fleet Stack
InOrbit's OpenRobOps gives developers a production-grade foundation for fleet management—and the first reference implementation of ISO 21423.
By The Robotics Desk
Walk into any large warehouse or manufacturing plant running autonomous mobile robots today and you will find a quiet crisis humming beneath the surface. Every robot vendor ships its own fleet manager. Every operator ends up maintaining a fragile patchwork of custom dashboards, proprietary APIs, and hand-rolled databases. InOrbit, the Mountain View, Calif.[1]
InOrbit released OpenRobOps—described by the company as "an open-source robot operations and fleet management software designed to support scaled deployments." Distributed under the Apache 2.0 license, it is free for academic researchers, robotics startups, and commercial enterprises to adapt, embed, and deploy without licensing fees. [1]
The timing is deliberate. As fleets of autonomous mobile robots grow, customers increasingly expect equipment manufacturers to provide full-featured fleet managers with common functionality. The result, according to InOrbit founder and CEO Florian Pestoni, is that many OEMs fall into the "build trap," spending years developing and maintaining custom back ends, databases, and user interfaces instead of focusing on their core innovations. [1]
The build trap is not a new problem in software. Entire industries have watched promising teams disappear into infrastructure work—rebuilding the same pipes, the same dashboards, the same alert logic—rather than shipping anything that moves the needle. Robotics, still a comparatively young sector operating at the intersection of hardware constraints and enterprise expectations, has been particularly susceptible.
OpenRobOps arrives with a feature set that targets exactly those rebuilt pipes. The platform includes a high-throughput telemetry ingest pipeline built for unreliable networks, real-time spatial tracking with live camera visualization and teleoperation, configuration-as-code management within Git CI/CD workflows, automated incident remediation that detects anomalies and executes autonomous recovery, an edge-to-cloud hybrid architecture that runs fully on-premises or air-gapped at the edge, and native Open-RMF interoperability connecting physical and simulated fleets into multi-fleet traffic systems. [1]
The ISO 21423 specification establishes the communication and data exchange standard for industrial mobile robots and fleet managers—a long-awaited common language for machines that have, until now, largely refused to speak to one another across vendor lines. [1]
Pestoni sits on the ISO working group and serves as a representative for ANSI, the U.S. national body. "Working with leading enterprises in manufacturing, logistics and other industries, I have seen firsthand that federated orchestration is essential to scaling automation," he said. "I'm proud of the collaborative work that led to this landmark international interoperability standard," he added. "With OpenRobOps, we are helping take this from theory to market practice." [1]
Standards bodies move slowly by design—deliberate, consensus-driven, built to last. The gap between a ratified specification and working software sitting in a developer's repository can stretch for years. A reference implementation collapses that distance. It transforms a document into a thing you can run.
The standard made its first public appearance at Automate 2026, where 10 different companies participated in a demonstration of multi-vendor orchestration based on InOrbit Space Intelligence, InOrbit's flagship product. That demonstration was the first public demonstration of ISO 21423. [1]
InOrbit has drawn an explicit comparison between OpenRobOps and the Robot Operating System, which acted as a catalyst for robotics development by saving researchers and engineers countless hours of rewriting low-level code from scratch. Steve Cousins, executive director of the Stanford Robotics Center, member of the InOrbit.AI board of directors, and former CEO of Willow Garage, said of ROS: "When we created ROS, our mission was to give roboticists an open ecosystem so they could stop re-inventing basic device drivers." His assessment carries weight. [1]
"OpenRobOps creates the same shift for robot operations and fleet management, while also enabling standards-based interoperability," Cousins said. [1]
The ROS parallel is flattering, and it is also instructive. ROS did not win because it was the most technically sophisticated option available. It won because it was good enough, freely available, and adopted early by researchers who then carried it into industry. Community gravity, once established, is hard to displace. The question for OpenRobOps is whether the same accumulation is possible at the operations layer—further up the stack, closer to business logic, and subject to far more commercial pressure.
The conference brings together practitioners to share lessons learned and network with top industry operators. This year's agenda includes four themes: orchestrating heterogeneous fleets of AMRs, humanoids, cobots, and fixed automation; scaling data pipelines for physical AI; decentralized intelligence for large fleets; and a hands-on OpenRobOps workshop. [2]
Those themes map closely onto the hardest operational problems currently facing teams running robots at scale. The shift from centralized, deterministic control to on-robot decision-making—what the RobOpsCon program describes as coordination protocols without a single point of failure, safety guarantees, and observability when intelligence is distributed across hundreds of nodes—is not a future concern. It is the present reality for the largest deployments already in the field. [2]
The data pipeline track reflects a quieter but equally significant shift: large deployments are becoming the most productive data-generation infrastructure available. Capturing, labeling, and routing high-fidelity telemetry at fleet scale to feed embodied model training and close the sim-to-real gap is the kind of work that requires exactly the sort of standardized telemetry ingest that OpenRobOps provides. [2]
There is a self-reinforcing logic here that is worth sitting with. A common operations layer produces standardized telemetry. Standardized telemetry feeds better models. Better models close the sim-to-real gap. Closing that gap accelerates deployment. More deployments generate more telemetry. The loop is familiar from software, but in robotics it runs through physical space, which has a way of punishing assumptions that pure software tolerates.
InOrbit claimed that it pioneered federated orchestration—enabling organizations running heterogeneous fleets to bridge the gap between business intent and physical execution. OpenRobOps is the open-source expression of that claim: a production-grade operations foundation that, by the company's account, allows teams to bypass years of back-end development and redirect engineering capacity toward robots that do something useful in the world. [1]
Whether OpenRobOps achieves the kind of community density that ROS did will depend less on its feature list—which is already substantial—and more on whether the robotics industry decides it is done rebuilding the same basement for the tenth time. The Apache 2.0 license removes the licensing friction. The ISO 21423 reference implementation removes the standards friction. What remains is the oldest friction in platform adoption: convincing a community of engineers, each with strong opinions about their own infrastructure, that someone else's foundation is worth standing on. [1]