The Firmware Problem: Why Great Hardware Ships With Terrible Software

Walk into most manufacturing plants and ask the floor supervisor what software runs the robots. The answer will usually include a product name you've never heard of, a reference to a proprietary programming language that predates the internet, and a look that suggests this is not a question they enjoy fielding. The software running most industrial hardware is invisible, unglamorous, and spectacularly bad by modern standards. It's also one of the more interesting investment opportunities in the physical economy, precisely because its badness is structural and decades-deep.

The OT/IT Divide

Industrial environments divide the world into Operational Technology — the PLCs, motor drives, and embedded controllers that directly operate equipment — and Information Technology — the enterprise systems, data infrastructure, and software tools that most people in the technology industry recognize as "tech." These two worlds have evolved in almost complete isolation for the past forty years.

OT systems were designed with one priority above all others: determinism. A PLC controlling a stamping press cannot pause execution to run a garbage collector or process a network interrupt. The control loop must execute in the same time, every time, without exception. This requirement drove OT vendors toward proprietary, closed, extremely stable software stacks — producing systems that are extraordinarily reliable at what they were designed to do and extraordinarily difficult to extend, monitor, or integrate with anything outside their original design envelope.

The result is that most factories today are running expensive, sophisticated equipment with almost no software observability. If a robot's performance degrades subtly across thousands of cycles — as happens with bearing wear, lubrication degradation, or thermal drift — there is often no tooling in place to detect it. The data is in the device logs. Nobody reads the device logs. I've heard versions of this story from nearly every operations team I've spent time with.

The Opportunity in Industrial DevOps

Foxglove has built a developer tooling platform for robotics and industrial systems — think Datadog for robots. Their Studio product gives engineers a way to visualize, replay, and analyze the data streams coming off robotic systems in real time or after the fact. It sounds basic because it is basic: observability, debugging tools, replay and analysis. And virtually no industrial company had this before Foxglove. The insight is that the robotics development workflow is broken in exactly the same way software development workflows were broken before the DevOps era — engineers deploy changes with no systematic way to understand what changed in behavior, bugs in deployed systems are diagnosed by guessing at logs, and regressions go undetected until a customer calls.

Intrinsic, the Alphabet-backed industrial robotics software company, is attacking a different layer of the same problem. They're building a development kit for industrial robots that abstracts away the hardware-specific programming interfaces and provides modern software primitives — motion planning, sensor integration, task sequencing — in a form that software engineers, not just robotics specialists, can work with. The goal is to make robot programming feel more like app development and less like writing firmware for 1990s CNC equipment. The ambition is right. The execution challenge is that abstraction layers in industrial automation have historically broken down under the physical corner cases that production environments generate continuously.

Vention is solving the deployment side of the same problem — providing a hardware-plus-software platform that lets small manufacturers deploy robotic workcells without the specialized integration teams that enterprise automation projects typically require. Their insight is that the integration cost, not the hardware cost, is what locks most mid-market manufacturers out of robotics adoption. If you can collapse a six-month integration project into a two-week deployment, you unlock a market that the traditional automation industry was structurally unable to serve.

Why Hardware Companies Can't Hire Software Talent

The root cause of the firmware problem is structural talent mismatch, not a technology gap. The best software engineers in the world want to work on consumer applications, cloud platforms, and AI systems. Writing ladder logic in a proprietary PLC IDE, debugging CAN bus timing issues, and reverse-engineering communication protocols for decade-old servo drives is not what attracts exceptional engineers. The result is that industrial companies run chronically short of people who can bridge the OT/IT gap.

The engineers who understand the real-time control requirements of industrial systems are mostly near retirement. The engineers who can build modern software infrastructure don't speak the language of industrial automation. The companies that figure out how to bridge this gap — whether by building tools that make OT accessible to modern engineers or by creating software abstractions that let AI handle the embedded complexity — are addressing a structural market failure with forty years of technical debt waiting to be addressed.

The Investment Angle

The firmware problem is actually several overlapping markets: observability and monitoring, modern programming interfaces, remote management and OTA update infrastructure, predictive maintenance, and AI-powered parameter optimization. Each has real paying customers because the pain is real and the alternatives are either "hire an army of specialized embedded engineers" or "keep running software from 2003." The venture challenge is sales cycle and proof-of-concept requirements — industrial customers are slow to qualify new vendors. The companies that earn their way through that gauntlet are building relationships that last decades.