Forget world models. The next robotics giant will bring DevOps to Physical AI
Investors are focused on foundation models, world models, and VLAs. Meanwhile, every company deploying robots is rebuilding the same operational software from scratch because nobody is selling it to t
Robotics is having a hardware renaissance. Chips are faster, actuators are more precise, sensors are cheaper and more capable than at any point in history. NVIDIA's push into physical AI has given robotics companies access to compute that once required entire data centers. The same generative and reinforcement learning techniques reshaping software have unlocked new capabilities in perception, manipulation, and locomotion. Robots can now generalize across tasks in ways that rule-based systems never could.
Everyone building in robotics right now is thinking about the same things. Better models. World models. More capable hardware. Faster sim-to-real transfer. These are real and exciting problems, but the next great robotics software company probably isn't going to start by solving any of them. It's going to be built by solving the problem every robotics company already has: trying to ship software like a software company.
What hasn't kept pace with the hardware is the software tooling. The software layer running the majority of the world's deployed robots today—the tooling that lets you understand why a node failed in real-time, collect and query logs across a fleet, or push a software update over the air—is unsupported open source. Half a million industrial robots shipped last year, and almost every company deploying them is DIYing on top of unsupported OS, because nothing on the market covers their full software development lifecycle.
Before an agent can manage your fleet, a human needs to be able to. DevOps software for robotics doesn't exist yet.
Robotics teams are rebuilding the same infrastructure from scratch
Nearly 5 million industrial robots are operational today, and the DevOps tooling problem has been easy to defer until recently. When your fleet is small enough, a few engineers can hold it together with internal scripts and tribal knowledge. That works until the fleet grows faster than the team, or the engineer who built the workaround leaves.
The fragility of those workarounds isn't accidental; it's structural. Every robotics team that has cobbled together a deployment pipeline or monitoring system has done so on top of the same foundation: an open-source middleware project called ROS. And just as Linux became the substrate that made the entire commercial server software ecosystem possible (Red Hat, Canonical, a generation of DevOps tooling), ROS is the substrate that makes the robotics software opportunity real. You don't build the commercial layer from scratch. You build it on top of what every serious team already runs.
Robot Operating System (ROS) is the standard, open-source middleware for robotics. Over 1,500 companies use it globally, the original ROS paper has over 13,000 academic citations, and downloads hit 984 million in 2025, up 85% year over year. It handles communication between components, provides hardware abstraction, and supports a library of reusable packages for navigation, perception, manipulation, and simulation.
ROS solved a genuinely hard problem. But it was never designed to serve as the foundation for operating robots in production. Deployment, observability, lifecycle management, fleet operations—this layer remains a problem because robotics also has a software prioritization problem. Hardware talent is celebrated, roadmaps are set by what the hardware can do, and software teams tend to be smaller and lower priority. The best software engineers have spent the last decade at AI labs and SaaS companies, where the compensation is better, and the feedback loops are faster.
To make matters worse, ROS 1 lost support from the ROS core team in May 2025, resulting in the end of bug fixes, security patches, and package updates. Migrating to ROS 2 isn't a simple upgrade—it requires rewriting build systems, APIs, and networking models from scratch. Meanwhile, $8.8 billion went into robotics in Q2 2025 alone, up 263% year over year, which means more robots shipping into production every quarter, each one inheriting the same unsolved problems.
ROS can't run a production fleet
The hardware is increasingly extraordinary. The software to operate it in production is painfully antiquated.
If you try to give someone a real-time window into a running robot using the tools ROS provides, you'll hit a wall. The GUI layer was built for researchers in labs. Camera feeds fail without explanation, and the interface crashes on basic interactions that have been reported and left unresolved for years. When teams try to build something better on top of RViz2, they hit crashes in the underlying rendering engine with no documented path to resolve them. There is no stable API for building custom interfaces, and the entire Qt-based stack is being deprecated.
So every robotics company builds its own. Engineers get pulled off real work to build internal dashboards, wire up monitoring, and stitch together operator interfaces. It's work that doesn't ship product or drive innovation, and whoever wrote it gets stuck maintaining it.
The market has two tools, and a gap neither covers
Foxglove is the best tool available for robotics data visualization: bag file replay, sensor inspection, and post-run debugging. It's a developer tool, and a good one, but it wasn't built for operating a fleet in production. It has also made a deliberate bet on ROS 2 and non-ROS customers, putting its ROS 1 bridge into maintenance mode and stepping away from the majority of the production installed base.
Formant built the fleet operations layer for large enterprise deployments, with dashboards, teleoperation, and anomaly detection for teams running robots at scale. But most companies deploying robots aren't running hundred-unit fleets with dedicated robotics software teams. That part of the market is largely on its own.
Neither company is building the layer between those two things: the deployment pipeline, the log collection, and the observability that ties a field failure to a specific software version. Every company that has needed it has built its own version. That's hundreds of teams solving the same problem in isolation.
The Robotics Software Lifecycle is unowned and ready to be built
In the same way Kubernetes became infrastructure for software deployment, there is a platform company yet to be built that will become the SDLC infrastructure for robotics. Observability, lifecycle management, fleet operations, OTA updates, and version control across heterogeneous hardware—the full stack of what it actually means to run robot software in production.
The company that wins this will own the full lifecycle of running robot software in the field. Visibility into what the fleet is doing, the ability to push software updates reliably across different hardware, log collection that doesn't drop data when connectivity fails, and the intelligence to tie a field failure to the specific software version that caused it. Each layer makes the next one possible, and the switching costs build until the platform is infrastructure.
The next great robotics software company won't be the one that builds the best world model. It will be the one that makes it possible to actually run robot software in production at scale, without every team having to rebuild the same infrastructure from scratch. That company will be software-native, built by people who understand what good software operations look like and see the power in bringing it to the physical world.
If this is you, reach out to me at alex@opencoreventures.com or on LinkedIn.