There is a moment in every growing robotics company’s life when it stops writing robot code and starts writing dashboards. The fleet gets bigger, customers want live video and uptime reports, and suddenly the startup that set out to build clever machines is maintaining a custom back end, a database, and a web UI instead. Florian Pestoni, founder and CEO of InOrbit.AI, has a name for this: the build trap.
His company’s answer, released this week, is to give the trap away. InOrbit has open-sourced OpenRobOps (ORO), which it describes as “an open-source robot operations and fleet management software designed to support scaled deployments.” The Mountain View company, founded in 2017, is best known as a pioneer of what it calls federated orchestration — letting organizations run mixed fleets of robots from different makers through one operations layer.
The standard is the story
The part that should outlast the news cycle is what InOrbit attached to the release. The company claims OpenRobOps is the industry’s first reference implementation of ISO 21423, a standard aimed at making robot operations software interoperable across heterogeneous fleets. “OpenRobOps gives robotics developers a production-grade, open-source foundation to escape the build trap, delivering the industry’s first ISO 21423 reference implementation and bridging the interoperability gap,” Pestoni said in the launch announcement.
Reference implementations matter more than standards documents, in practice. A PDF describing how fleet software should behave can be ignored for a decade; working code that passes real traffic becomes the de facto template. If InOrbit’s implementation holds up under use, ISO 21423 gets a concrete anchor, and any company building to it starts from the same baseline.
The timing is deliberate. RoboBusiness 2026 is running this week in Santa Clara, with InOrbit’s RobOpsCon following it — the annual gathering of the robot-operations crowd, where fleet software pitches get their most skeptical audience.
What’s actually in the box
OpenRobOps arrives as production-grade code rather than a skeleton, according to InOrbit. The feature list covers the unglamorous essentials of running robots at scale: high-throughput telemetry ingest designed for unreliable networks, real-time spatial tracking with live camera visualization and teleoperation (including a robot-locking mechanism so only one operator grabs a machine at a time), configuration-as-code so teams can manage alert rules and telemetry sources through Git workflows, automated incident remediation that tries autonomous recovery before escalating to humans, and an edge-to-cloud hybrid architecture.
That last one is worth dwelling on. Robots in warehouses and hospitals operate on networks that drop out, and a fleet manager that assumes constant connectivity fails exactly when it matters. Edge-to-cloud designs that keep functioning locally and reconcile later are becoming the expected shape of the category, not a differentiator.
Why an orchestration vendor would open-source its core
The obvious question: why would a company whose product is fleet software give the fleet software away? The bet is a familiar one from other corners of infrastructure software. InOrbit’s commercial layer sits above the open core — managed deployment, enterprise support, integrations — while the open-source release expands the pool of developers whose systems already speak InOrbit’s dialect of robot operations. It also pressures robot OEMs, who InOrbit says increasingly face customers demanding full-featured fleet managers alongside the hardware.
That pressure is visible across the industry. When Universal Robots rebuilt its platform around Gen 7, the pitch was explicitly that the robot should be the place where fleet-level software connects, not an island. And as humanoid deployments scale from pilots into factory floors — the direction UBTech’s Liuzhou build pointed when we covered it earlier this month — the number of machines needing unified oversight stops being a rounding error.
OpenRobOps was first announced in February 2026; the difference now is that the code exists for anyone to run, fork, or ignore. Whether competing robot makers adopt a standard anchored by a potential competitor is the open question. The alternative — each of them building their four-hundredth fleet dashboard — has been tried, and Pestoni is betting the industry is tired of it.
Cross-references: our coverage of Universal Robots’ Gen 7 platform and UBTech’s Liuzhou humanoid factory. For the safety side of scaled deployments, see Agility’s work on making Digit stop safely.]
