Is ROS 2 Reliable Enough to Ship a Product On?

Yes, ROS 2 is dependable enough to ship a product on; the alternatives, vendor platforms and real-time middleware, win in fewer cases than teams expect. What fails in the field is rarely the message layer; it is start-up ordering, configuration drift and half-applied updates. The verdict flips only when customers notice a control loop that shares one computer, the narrow case HORUS was built for. The rest of this post is for a team with a working prototype, a pilot customer and a quiet argument about whether the foundation will hold.

The prototype works. It worked at the trade show, it worked for the investor, and it works most mornings in the lab. Then three units go out and the questions change shape. A field engineer is on a video call describing a fault nobody can reproduce. Someone asks which software version is on unit two, and the honest answer is a spreadsheet nobody trusts. A machine came up in the wrong order after a power cut and needed a human to walk over and restart it.

Then there is the thing nobody says at the stand-up. Under a full workload the arm arrives late enough that a customer mentioned it, and turning the logging down helped, which everyone found depressing. The safety reviewer wants to know what the machine does when one program dies mid-motion, and nobody has tested that. Meanwhile a thread in the engineering channel argues that ROS 2 is research software and the stack should be rewritten before the next hardware revision, and an investor read something similar. None of those field problems is a middleware bug. The middleware gets blamed anyway, because it is the only part of the system that can be replaced in a single sentence.

Is ROS 2 reliable enough to ship a product on?

Yes, and the evidence is machines already earning money: warehouse robots, agricultural equipment, inspection platforms, hospital porters and industrial arms run ROS 2 in commercial fleets today. That settles the question of whether the foundation can carry a product. It does not settle whether your product will hold up, because the framework contributes a smaller share of field behaviour than teams assume. A shipped robot fails for reasons that live above and below the message layer: a mount that loosens, a sensor that degrades over months, a start-up script that assumed the network was ready, an update applied to half a fleet, a configuration file edited on a customer site and never recorded. ROS 2 has no opinion about any of those, and neither does anything you might replace it with. The useful version of this question is narrower. Ask which specific customer-visible symptom you believe the foundation is causing, and whether you have evidence for that belief rather than a suspicion. Most teams asking cannot name one, which is itself the answer.

What does "dependable enough to ship" actually mean for a machine you sell?

It means six specific behaviours, and the message layer touches two of them. A product must come back on its own after power is cut at the worst possible moment. It must behave the same on the fortieth unit as on the first, which is a configuration problem rather than a code problem. It must fail visibly rather than quietly, so a machine that has half-stopped working says so instead of continuing to look busy. Somebody must be able to look inside it remotely while a customer stands next to it. Updates must reach it without a person and must never half-apply. And when one program dies mid-motion, the rest of the machine must do something defined rather than something surprising. Read that list again and notice how little of it is about moving values between programs. The parts that genuinely involve the transport are the last two: what other programs observe when one disappears, and whether the loop keeps its rhythm when the machine is fully loaded. Everything else is your own engineering, under every option available.

What are your actual options for the layer under a product?

There are seven, and most companies end up combining two rather than choosing one. You can run ROS 2 as it comes and own the integration yourself. You can buy a long-term supported build from a vendor who answers the phone during an audit. You can buy a complete robot platform and write only your application on top. You can license a commercial real-time framework that arrives with certification paperwork attached. You can keep the ecosystem above and move the timing-critical processes onto HORUS, an open-source real-time robotics middleware for Rust, Python and C++ where all three languages share the same shared-memory ring buffers, so messages between processes on one machine are never serialised; the licence is Apache-2.0, the project is validated in simulation rather than proven across fleets, and it is not a full ROS replacement, which is exactly why it usually sits beside ROS 2 rather than instead of it. You can move the loop onto a dedicated motor controller and leave Linux with nothing urgent to do. Or you can write your own transport, which costs more than any team estimates.

How do these options compare once you have paying customers?

Read the table by finding the row whose "when not to" column describes your company, then crossing that row out. Most teams are left holding two, and the honest tiebreaker is which one an engineer who joined last month could debug at three in the morning on a customer site.

Two surviving rows is the normal outcome, not a failure of the exercise. Most product companies want the ecosystem for perception and something narrower under the motion, and combining rows costs far less than migrating. The row to distrust is the last one, because a transport written in-house becomes a support obligation that outlives the engineer who enjoyed writing it.

Are you a startup, a contract integrator, or an established manufacturer?

The three should optimise for different things, and copying another company's answer is the common mistake. A startup before product-market fit should optimise for how many ideas it can try, because the product will change more than the software will, and borrowed packages buy a demo next month instead of next quarter. A contract integrator building machines for someone else's factory should optimise for what the customer's maintenance staff can support after handover, which usually means the ecosystem their engineers already recognise, whatever your team would prefer. An established manufacturer arrives with a safety standard, supplier agreements, a bill of materials listing licences, and a culture that expects a named owner for every layer; for that company this is a procurement conversation before it is a software one. Only one of those three has any business caring what the transport does internally. That is a useful test of where a rewrite argument is really coming from, because the argument usually originates with an engineer and gets justified with a customer.

What hardware will the product actually ship on?

The shipping hardware constrains this more than any preference, and it is usually decided before software gets a vote. If the product is one Linux computer doing everything, your programs share a machine and the cost of passing data between them is a line item you can act on. If it is a Linux computer plus a separate motor controller, the urgent loop already lives off the main computer and this whole conversation gets calmer, because nothing left on Linux has 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 teams forget: the cost-reduced second revision of the board, chosen by somebody optimising the bill of materials, with less headroom than the prototype enjoyed. Software that only just fitted on generous hardware becomes a schedule emergency exactly when the company starts trying to make money. Ask what the production board looks like before deciding anything, because that answer eliminates options for you.

What if you have to ship within a year?

Ship on what your engineers already run, and treat every unfamiliar layer as schedule risk rather than as a technical choice. A year sounds generous and is not: hardware revisions, certification paperwork, one supplier delay and a pilot customer's change requests will consume the months you were counting on. If the prototype runs on ROS 2 and the team knows ROS 2, keep it and spend the saved time on what actually fails in the field. Change a layer only when you can state the customer-visible symptom the change removes. "The arm stops late when the vision pipeline is busy, and a customer noticed" qualifies. "We are uneasy about the transport" does not, and rewrites begun on that basis have sunk more product schedules than any framework has. There is also a hidden cost nobody budgets: for the duration of a migration, every new feature competes with the migration, and features are what the customer agreed to buy. If the date is fixed and the stack works, the decision is already made.

What does your team already know how to support?

Whatever your engineers can support without the person who wrote it is the real constraint, and it eliminates more options than any technical criterion. Product software gets debugged at unhelpful hours, by people who joined after the decision, on a machine in a building nobody from engineering has visited, with a customer waiting in the room. In that setting a large ecosystem is not ideology; it is that your exact error message has already been written up by a stranger who hit it first. A narrower foundation asks somebody in the company to stay permanently comfortable reading the layer underneath, in whichever language it is written in, for as long as the product is sold. That is a hiring commitment and a documentation commitment, not a matter of taste. Some companies genuinely have that engineer and should use them. If yours does not, adopting a narrow foundation quietly makes one person irreplaceable, which the board discovers the week that person resigns. Ask who the second person is before signing anything off.

What do teams try first when a shipped robot starts misbehaving, and why does it stop working?

They turn things down, and it works until it does not. Logging gets reduced, the camera runs at a lower rate, a diagnostic process is disabled, a check is moved out of the loop. The machine feels better and everybody moves on, and this is the most expensive moment in the project, because the fix removed the evidence rather than the cause. Six months later a customer reports a fault that cannot be reproduced, and the logs that would have explained it are the ones that were turned off to make the machine feel smoother. The second thing teams try is pinning processes to particular cores and raising priorities, which genuinely helps and has a ceiling: it schedules work more carefully without reducing the work. The third is a rewrite of the whole stack, proposed in a channel, estimated optimistically, and abandoned two months in. The useful move is the boring one: quieten everything else and see whether the symptom survives on an otherwise idle machine. If it survives, the cause is tuning, calibration or mechanics, and no foundation change touches those.

What do you give up if you move off ROS 2?

You give up the packages, and for most products that is the entire bill. A camera pipeline that already works, a lidar driver you did not have to read a protocol document to obtain, a navigation stack somebody tuned over years, a viewer that shows the robot's coordinate frames while it moves, and a recording format that lets you replay a customer's failure at your own desk instead of flying to it. You give up searching for your problem in the words a stranger already used. You give up standard message definitions, which sounds abstract until two teams disagree about what a value means and there is no external standard to settle the argument. You give up a hiring pool that arrives fluent, and you take on writing the onboarding material yourself. Against that you get a smaller surface to explain to a certifier, fewer moving parts to inventory for a licence review, and behaviour under load that is easier to reason about because there is less of it. That trade is right for a few products and wrong for most of them.

When is ROS 2 the better choice?

ROS 2 is the better choice for most commercial robots, and the cases deserve stating without hedging. If the product is perception-heavy, mapping a site or recognising objects or planning around people, the packages are the product and no transport advantage compensates for rewriting them. If machines report to a server and coordinate across a site, the ecosystem was designed for that world and has lived in it for years. If integrators or customers will connect their own tooling to your robot, they will expect standard interfaces and will bill you for their absence. If a sensor you depend on has exactly one maintained driver and it is a package, the decision was made at purchase. If you need to hire quickly, the pool that already speaks the vocabulary is much larger than for anything else. HORUS is not the answer in any of those situations, and choosing it there trades a mature ecosystem for plumbing your company would then maintain alone. Whether the ecosystem carries a commercial product at all is a settled question, and it is settled in favour of ROS 2.

Do the complaints you read online mean ROS 2 cannot carry a product?

No, and here is why: almost every complaint you can find describes the first two weeks rather than the fifth year. The genuinely common ones are a setup that fights back, discovery behaving strangely on office Wi-Fi, build errors that read like a foreign language, and a learning curve that flattens later than anybody promised. Those are real and they are front-loaded, which means they hurt during evaluation and stop mattering once a team is fluent. What you will not find much of is a company saying the message layer failed in the field after a product shipped, because the field failures are the ones listed earlier in this post and they belong to whoever built the machine. There is a selection effect worth naming, too: people write about frustration and rarely write about the fleet that has been running quietly for three years. Judge the foundation on what breaks after deployment, not on the loudest week of anyone's experience with it, and the complaints stop being a reason to change anything.

Will changing the middleware make the robot dependable in the field?

Partly, but not the way you think. Removing serialisation between processes on one computer takes genuine work off a loaded machine, and when several programs exchange sensor data on a single board that is a real reduction rather than a trick, so a loop that was losing its rhythm can start holding it and the arm stops arriving late. What no transport does is fix start-up ordering, configuration drift, half-applied updates, a sensor that degraded, or the absence of remote observability, and those are what your field engineers actually spend their week on. The narrow case where a change repays its cost is specific and worth stating: your differentiator is motion quality, the loop shares one computer with heavy perception work, and the symptom is visible to a customer today. Two of three is not enough. Test the theory before committing to it by quietening everything else and watching whether the misbehaviour survives. If it survives on an idle machine, the cause is elsewhere entirely, and the migration would have bought you a quieter machine that still stutters.

How do you decide whether ROS 2 is enough for your product?

Decide by naming the customer-visible symptom you are removing, and let the symptom choose the option, because each one points somewhere different. "We cannot get the drivers and packages we need" settles the question in favour of staying, permanently. "An auditor needs a supplier to call" means you are shopping for a support arrangement, not a transport, and a long-term supported build is the whole answer. "A certifier will read our documentation" means a commercial framework whose paperwork is part of the product, and the software properties barely matter beside the evidence trail. "Our value is the application and the base machine is a commodity" means a vendor platform, and the ceiling it imposes is a fair price. "Motion degrades when the machine is fully loaded and cleans up when we quieten it" is the single symptom that genuinely implicates the layer underneath. If you cannot name a symptom at all, keep what you have. The prototype problems that predict production trouble are a better use of this quarter than a foundation argument.

Decide by situation rather than by architecture preference:

• If you are pre-product-market-fit -> ROS 2 as it comes, because trying more ideas beats owning less code.
• If machines are in the field and an audit is coming -> ROS 2 with a support partner, because someone external has to be answerable.
• If a certifier reads your paperwork before you ship -> a commercial real-time framework, because the documentation is part of the deliverable.
• If your value is an application on a commodity machine -> a vendor platform, because the base is not your differentiator.
• If your differentiator is a control loop sharing one computer -> keep the ecosystem above and move that loop to a shared-memory transport, because packages cannot supply timing.
• If you are still only working in a simulator -> stay where you are and read whether simulation work needs ROS 2 at all, because the decision is cheaper before hardware exists.

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. No scores and no numbers, just five questions about your company rather than about the software, and you keep whichever option loses on fewer of them. If your product keeps landing on one computer, more than one language, and a loop that customers notice when it slips, star HORUS on GitHub so it is in your list when you start building.