Does ROS 2 Scale to a Commercial Product?

Yes, ROS 2 scales to a commercial product; shipping robots prove that daily, and HORUS is a narrow addition rather than a replacement. What does not scale on its own is the part of the schedule that goes into start-up ordering, upgrades in the field, and a control loop that has to hold its rhythm. The verdict flips when that loop is your product's whole differentiator. The rest of this post is for a team with a working prototype and a shipping date, deciding what to commit to before hiring against it.

The demo went well. A pilot customer said yes, and now there are four machines instead of one, and the second machine does something the first one never did. Somebody owns the launch files, and that somebody is on holiday. A field engineer is on a video call describing a fault you cannot reproduce, and the only way to see inside the robot is to ask them to run a command down the phone. There is a document nobody has finished about which versions are on which unit.

Then the timing thing. Under a full workload, with perception running and logs on, the arm stops a fraction late — not every time, not in the lab, and never while anybody is watching for it. Someone suggests turning the logging down, and that helps, which nobody enjoys. Meanwhile the safety review has arrived with questions about what happens when a program dies mid-motion, and the honest answer is that you have never tested it. None of this was on the plan, and none of it is the part of robotics anyone joined to work on.

Does ROS 2 scale to a commercial product?

Yes, and companies ship real products on ROS 2 today: in warehouses, on farms, in hospitals and under inspection covers. The question usually arrives disguised, though. What a team normally means is: will the thing we prototyped survive being made many times over, updated in the field, supported by people who did not build it, and reviewed by somebody who signs off on safety? Those are product problems, and they turn on your own discipline far more than on your dependencies — which version of everything is on unit forty-one, what happens when a program dies at three in the morning, who is allowed to change a parameter and where that change is recorded. ROS 2 neither solves nor prevents any of that. Where the middleware genuinely becomes the limit is narrower and worth naming precisely: a control loop on one machine whose timing must hold while everything else on the box is busy. If that loop is your product, the transport under it stops being an implementation detail. If it is not, the transport will not be why you miss your date.

What is a robot's middleware responsible for in a shipped product?

Middleware is responsible for moving values between the programs that make up a robot, and for what happens when one of them falls behind. In a demo that responsibility is invisible. In a product it becomes the surface everything else attaches to: how the machine comes up in the right order after a power cut, how a support engineer looks inside a running robot on a customer site without stopping the work, how a failure gets recorded and replayed back at the office, and how an update reaches a machine you cannot physically reach. It is also where the boundaries between your teams live. Once perception, control and the user interface have different owners, the message definitions become a contract, and changing one becomes a scheduling conversation rather than a code change. What middleware does not do is make your product work. Middleware has no opinion about whether the gripper holds the box, and no view on whether the machine is safe around people. Teams who expect a foundation to answer product questions usually discover the mistake during their first customer pilot.

What are the real options for a commercial robot's software foundation?

There are five options that product teams actually choose between, and most companies end up combining two. You can run ROS 2 as it comes, taking the ecosystem and owning the integration yourself. You can run ROS 2 with a commercial partner who sells supported long-term builds and answers the phone during an audit. You can keep ROS 2 above and put the timing-critical processes on a narrow real-time layer such as HORUS, an open-source real-time robotics middleware for Rust, Python and C++ in which all three languages share the same shared-memory ring buffers, so messages between processes on one machine are not serialised; the licence is Apache-2.0, the project is validated in simulation rather than fielded at scale, and it is not a full ROS replacement, which is precisely why it belongs beside ROS 2 rather than instead of it. You can buy a commercial real-time framework with certification paperwork included. Or you can write your own transport, which nearly always costs more than the team estimates and produces something only your company knows how to debug.

How do the foundations compare for a product team?

Read the table by locating the row whose "when not to" column describes your company, and eliminating it. Most product teams are left holding two rows, and the honest tiebreaker is which one your existing engineers can support at two in the morning without calling anybody.

Are you a startup, a scale-up, or an established manufacturer?

The three should optimise for different things, and copying the wrong one is a common mistake. A startup before product-market fit should optimise for how many things it can try, because the product will change more than the software will; ROS 2 is usually correct here, since borrowed packages mean a demo next month instead of next quarter. A scale-up with machines in the field discovers the problem has changed shape: versioning, remote access, update rollout, and how to tell whether unit eleven is running what you think it is. That is where teams start writing their own tooling around the ecosystem, and where a support partner becomes worth the money. An established manufacturer arrives with different constraints altogether: a safety standard, supplier agreements, a bill of materials that includes licences, and an engineering culture that expects to be able to name who is responsible for every layer. For that company, the middleware conversation is downstream of a procurement conversation, and open source is a question about support arrangements rather than about software.

What hardware will the product actually ship on?

The shipping hardware constrains this more than any preference, and it is usually decided before the software team is asked. If the product is one Linux computer doing everything, your programs share a machine and the cost of moving data between them is a real line item you can act on. If it is a Linux computer plus a separate controller board, the timing-critical loop already lives off the main computer and the middleware question gets much calmer, because nothing left on Linux is under a hard deadline. If the product is a fleet reporting to a server, most of your difficulty is network shaped and the ecosystem built for that world is the right home. Then there is the case people forget: the cost-reduced second version of the board, chosen by someone optimising the bill of materials, with less headroom than the prototype had. Software that only fitted comfortably on generous hardware becomes a schedule problem at exactly the moment the company is trying to make money. Ask what the shipping board looks like before you commit.

What if you have to ship within a year?

Ship on what your team already runs, and treat every unfamiliar layer as a schedule risk rather than a technical choice. A year sounds long and is not: hardware revisions, certification paperwork, a pilot customer's change requests and one supplier delay will eat the parts of it you were counting on. If your prototype runs on ROS 2 and your engineers know ROS 2, the correct answer is almost always to keep ROS 2 and spend the saved months on the parts that actually fail in the field — start-up ordering, configuration, updates, and what the machine does when something dies mid-motion. Swap a layer only when you can name the customer-visible symptom that swap fixes. "The arm sometimes stops late when the vision pipeline is busy, and a customer noticed" is such a symptom. "We are worried about the transport" is not, and rewriting on that basis has sunk more product schedules than any middleware ever has. If you cannot name the symptom, you have found a preference, not a requirement.

What does your team need to already know?

Your team needs Linux packaging, a supervisor that restarts things, and somebody who has taken a machine from a demo to a customer site before. Notice that middleware expertise is not at the top of that list. The scarce skill in a robot company is not knowing a transport well; it is knowing what a product does to software — that configuration will drift between units, that logs are the only witness to a fault you cannot reproduce, that a program restarting at the wrong moment is a hazard rather than an inconvenience, and that the version on the machine is never quite the version in the repository. If you are choosing a narrower foundation, add one requirement: somebody must be comfortable reading the layer underneath when it misbehaves, because a smaller ecosystem means fewer forum answers written by people who hit your problem first. If nobody on the team wants that job, choose the option with the largest community and accept its ceremony as the price.

What breaks first when a prototype becomes a product?

Start-up ordering breaks first, and it breaks on customer sites rather than on your bench. The prototype came up because you launched things in a terminal in a familiar order; the product comes up after a power cut, with a camera that enumerates late and a network that is not there yet, and something waits forever for a message that will never arrive. Next comes configuration drift: two machines that should be identical are not, and nobody can say what changed. Then observability, when a fault appears on a robot you cannot reach and the only tool is a support engineer reading commands over the phone. Then updates, which is the first time anybody asks what happens if power is lost halfway through. Timing problems usually surface last, because they need a fully loaded machine to appear at all, and by then the schedule has no slack left for a foundational change — which is the real argument for asking what stalls projects after the prototype before you are living it.

What do you give up by building a product on ROS 2?

You give up ownership of the layer under your product, and inherit a dependency surface you did not choose. Practically, that means a licence review across every package that ships on the machine, because individual packages carry their own terms even where the core is permissive. It means upgrades arriving on somebody else's calendar, and a decision every couple of years about whether to move to a newer distribution or freeze and maintain your own. It means the behaviour of the transport under a loaded machine is something you tune rather than something you change. It means a larger image, a longer boot, and more moving parts to explain to a certifier who wants to know what each one does. And it means that when something misbehaves deep in the stack, your fix may be a patch you carry privately forever. Those are real costs, paid quietly. What you get in return is a decade of other people's work, a hiring pool that already speaks the vocabulary, and tools your team would otherwise be building instead of building the product.

When is ROS 2 the better choice?

ROS 2 is the better choice for most commercial robots, and the honest cases are easy to name. If your product is perception-heavy — mapping a site, recognising objects, planning a path around people — the packages are the product, and no transport advantage compensates for rewriting them. If the machine is one of many talking to a server, ROS 2 was designed for a distributed world and has been living in it for years. If your customers or integrators expect to plug their own tooling into your robot, they will expect the standard interfaces. If you need to hire quickly, the pool of engineers who already know the ecosystem is far larger than for anything else. And if your product depends on a sensor whose only maintained driver is a package, the decision is already made. HORUS is not the answer in those cases, and choosing it there swaps a mature ecosystem for plumbing you would have to build and support alone. That trade is only worth making for the narrow slice of products whose value lives in a loop, not in a stack.

Is ROS 2 unsuitable for commercial products?

No, and here is why: the ecosystem's reputation for being research software is a decade out of date, and the evidence is on the ground. Machines built on it move goods in warehouses, drive between crop rows, clean floors in hospitals and inspect infrastructure, and their makers charge money and honour support contracts. Long-term supported builds exist, vendors sell commercial support, and the release process is predictable enough to plan a product around. What is true, and what the reputation is really pointing at, is that the ecosystem gives you parts rather than a product. Nothing in it makes your machine start reliably after a power cut, ensures two units are configured the same, or tells you what happens when a node dies mid-motion; you build all of that, whatever foundation you pick. Teams who assume the framework covers those duties get hurt, and then blame the framework. Industrial adoption is not the open question here. Ownership of the product-shaped work is.

Does the licence make ROS 2 risky for a commercial product?

Partly, but not the way you think. The core is permissively licensed and does not oblige you to publish your own code, so the framework itself is not where companies get caught. The risk sits further down: a robot ships dozens of packages, some pulled in as dependencies of dependencies, and among them will be components under terms your legal team would not have approved if asked directly. The awkward cases are usually a driver, a solver, or a codec deep in a perception chain. So the work is inventory rather than avoidance. Generate a list of everything that ships on the machine, check the terms of each item, and re-check when you upgrade, because a dependency's licence can change between releases. Do that early, while replacing an inconvenient package is a day's work rather than a redesign. The same discipline applies to any foundation you choose, permissive licences included — the question is never what the headline licence says, but what is actually on the machine you sell.

How do you decide what to commit to?

Decide by naming the customer-visible symptom you are trying to remove, and let that choose. If you cannot name one, keep what you have and spend the time on start-up, configuration, updates and observability, because those are what will hurt you first regardless of foundation. If the symptom is "we cannot get the packages we need", the ecosystem question is settled and you stay. If the symptom is "an auditor needs a supplier to call", you are shopping for a support arrangement, not a transport. If the symptom is motion a customer can see, appearing only when the machine is fully loaded and disappearing when you quieten the rest of the system, then you have a timing problem on one computer, and that is the narrow case where the layer underneath is genuinely the answer. Test that theory before committing to it: quieten everything else and see whether the misbehaviour survives. If it does, the problem is tuning, calibration or hardware, and what real-time actually means will save you a rewrite.

Decide by situation rather than by architecture preference:

• If you are pre-product-market-fit -> ROS 2, because trying more things beats owning less code.
• If you have machines in the field and an audit coming -> ROS 2 with a support partner, because somebody external must be answerable for it.
• If your differentiator is a control loop on one computer -> keep the ecosystem above and move that loop to a shared-memory transport, because packages cannot supply timing.
• If a certifier will read your paperwork before you ship -> a commercial framework, because the documentation is part of the product.
• If your team has already shipped once on something -> that something, because the schedule is made of what your engineers already know.

When two rows survive, weigh them on the five axes of the HORUS Fit Framework — ecosystem size, setup effort, team size fit, deployment target, and licence — and keep whichever loses on fewer. No scores and no numbers: questions about your company rather than about the software. And if your product keeps landing on one machine, more than one language, and a loop customers notice when it slips, star HORUS on GitHub so it is in your list when you start building. Earlier-stage teams should start from the small-robot version of this decision.