Best ROS 2 Alternatives for Commercial Products

For most commercial robots the best alternative to ROS 2 is still ROS 2; the real exceptions are vendor platforms, commercial real-time frameworks, and HORUS. Alternatives win when the product's value sits somewhere the ecosystem does not reach: a certifier's paperwork, a vendor's supported hardware, or a control loop on one computer that customers notice when it slips. The verdict flips the moment your differentiator stops being perception. The rest of this post is for a team with a prototype, a shipping date, and a reason to think the foundation under it is wrong.

The pilot went well enough that there are now four machines instead of one, and the fourth does something the first 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 look inside the robot is to read commands down the phone at them. There is a half-finished document about which version is on which unit, and nobody trusts it.

Then there is the thing nobody wants to say out loud. Under a full workload the machine hesitates in a way a customer noticed and mentioned. Somebody suggested turning the logging down and it helped, which everyone found depressing. The safety reviewer has asked what happens when a program dies mid-motion and the honest answer is that nobody has tested it. Meanwhile an investor asked why you are building on research software, a competitor claims to have written their own, and the engineering channel now has a thread about rewriting the whole stack before the next hardware revision. None of this was on the plan, and the expensive mistake available right now is answering a product question with an architecture change.

What are the best ROS 2 alternatives for a commercial product?

The best alternative is a supported ROS 2 build, and everything else on the list wins only in a case you can name in one sentence. That ordering annoys people, so it is worth being precise about why. A commercial robot's schedule is consumed by hardware revisions, calibration at volume, field updates, remote support and safety paperwork, and none of those get cheaper when the transport changes. What genuinely varies between foundations is narrow: whether somebody external answers the phone during an audit, whether the base hardware comes with a safety story attached, and whether a control loop sharing one computer with everything else holds its rhythm under load. Each of those maps to a different alternative, which is why "what should we use instead" has no single answer. If your team cannot finish the sentence "we are moving off ROS 2 because customers see ___", you do not yet have a migration, you have a preference. Preferences are legitimate and cost money, and it is better to know which one you are spending.

What does a robot's software foundation actually cover?

A software foundation moves values between the programs that make up a robot and defines what happens when one of them falls behind. In a demo that responsibility is invisible. In a product it becomes the surface everything else bolts onto: 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 fault is recorded well enough to replay at the office, how an update reaches a machine nobody can physically touch. It is also where organisational boundaries live, because once perception, control and the interface have separate owners, message definitions become contracts and changing one becomes a meeting. What a foundation does not do is make the product work. No framework has an opinion about whether the gripper holds the box or whether the machine is safe near people. Teams who expect a foundation to answer product questions usually find out during their first pilot, at the worst possible moment, and then blame the framework for the discovery.

What are the actual alternatives on the table?

There are seven serious options and most companies end up combining two rather than picking one. You can keep ROS 2 as it comes and own the integration. You can buy a supported long-term build from a vendor who answers questions during an audit. You can buy a complete robot platform and write only the application. You can license a commercial real-time framework that arrives with certification paperwork. 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++ in which 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 precisely why it usually sits beside ROS 2 rather than in place of it. You can push the loop onto a dedicated controller board and leave Linux with nothing urgent to do. Or you can write your own transport, which costs more than every team estimates.

How do the alternatives compare for a product team?

Read the table by finding the row whose "when not to" column describes your company, and eliminating it. Most 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.

Two surviving rows is normal rather than a failure of the table, because most product companies want the ecosystem for perception and something narrower under the motion. Combining rows is the usual answer and it is far cheaper than a migration: keep the packages, the vendor drivers and the tooling, and change only the layer beneath the part customers can see. The row to treat with most suspicion is the last one, because a transport written in-house becomes a support obligation that outlives the engineer who enjoyed writing it. Cross rows out on evidence from your own machines.

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

The three should optimise for different things, and borrowing another company's answer is the common failure. 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, and borrowed packages mean a demo next month rather than next quarter. A contract integrator building machines for other people's factories should optimise for what the customer's staff can maintain after handover, which usually means the ecosystem their engineers already recognise, whatever your own team would prefer. An established manufacturer arrives with different constraints entirely: a safety standard, supplier agreements, a bill of materials that lists licences, and a culture that expects a named owner 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. Notice that only one of those three has any reason to care what the transport does internally, which is a useful check on where a rewrite argument is really coming from.

What hardware will the product ship on?

The shipping hardware constrains this more than any preference, and it is usually settled before software gets a vote. If the product is one Linux computer doing everything, your programs share a machine and the cost of moving data between them is a line item you can act on. If it is a Linux computer plus a separate controller board, the urgent loop already lives off the main computer and the middleware question becomes 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 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 fitted comfortably on generous hardware becomes a schedule problem exactly when the company starts trying to make money, which is why what a small board can carry belongs in the hardware conversation rather than after it.

What if the ship date is next 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 long and is not: hardware revisions, certification paperwork, one supplier delay and a pilot customer's change requests will eat the parts you were counting on. If the prototype runs on ROS 2 and the team knows ROS 2, the right move is almost always to keep it and spend the saved months on what actually fails in the field, which is start-up ordering, configuration, updates, and behaviour when a program dies mid-motion. 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 mentioned it" qualifies. "We are worried about the transport" does not, and rewrites begun on that basis have sunk more product schedules than any framework has. A migration also has a hidden cost nobody budgets: for its duration, every new feature competes with the migration, and features are what the customer bought.

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 rules out more options than any technical criterion. A product's software gets debugged at unhelpful hours by people who joined after the decision, on a machine in somebody else's building, with a customer waiting. In that setting a large ecosystem is not ideology, it is that your exact error message has been written up by a stranger who hit it first. A narrower foundation asks somebody in the company to be 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 just a technical taste. Some companies genuinely have that person and should use them. If yours does not, choosing a narrow foundation quietly makes one engineer irreplaceable, which your board will discover the week that engineer resigns. Ask who the second person is before signing off on anything with a small community around it.

What do teams try first when ROS 2 stops fitting, and why does that stall?

Teams turn things off first, and it works right up until the machine leaves the building. Logging goes, then a visualisation tool, then a camera stream shrinks, then a background service is disabled, and each step buys back a little smoothness. Everything switched off was doing a job: the logs were the only witness to faults nobody can reproduce, and the camera stream was what made the robot see far enough. Months later nobody remembers which of them is safe to restore, so nothing is restored, and the product ships permanently reduced with a set of workarounds that new engineers inherit as folklore. The second thing teams try is more hardware, which genuinely helps and also raises unit cost forever, on every machine, for the life of the product. The third is a partial rewrite that gets abandoned halfway, leaving two conventions in one codebase, which is worse than either. All three are reasonable diagnostics and poor destinations. The switch that made the difference is naming the real problem, and that is the information worth keeping.

What do you give up by leaving ROS 2?

You give up the packages, and for most products that is the whole bill. A camera pipeline that works, a lidar driver you did not read a protocol document to get, a navigation stack somebody else tuned over years, a tool that shows the robot's coordinate frames while it moves, and a recording format that lets you replay a customer's failure at your desk instead of flying to it. You give up the ability to search 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 it. You give up a hiring pool that arrives already fluent, and you take on the obligation to write the onboarding material yourself. Against that you get back 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.

When is ROS 2 the better choice?

ROS 2 is the better choice for most commercial robots, and the cases are worth 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 the machine is one of many talking to a server, the ecosystem was designed for that world and has lived in it for years. If integrators or customers will plug their own tooling into your robot, they will expect standard interfaces and will charge you for their absence. If you need to hire quickly, the pool that already speaks the vocabulary is far larger than for anything else. If a sensor you depend on has one maintained driver and it is a package, the decision was made at purchase. HORUS is not the answer in any of those cases, and choosing it there trades a mature ecosystem for plumbing your company would then own alone. Whether the ecosystem carries a product at all is settled, and settled in its favour.

Does replacing ROS 2 make a product cheaper to support?

No, and here is why: support cost is dominated by things the framework never touched. What actually generates support tickets is configuration drift between units, an update that half-applied, a sensor that degraded slowly, a start-up sequence that only fails when a network is slow, and a fault nobody can reproduce because the logs were turned down to make the machine feel smoother. Every one of those exists identically under any foundation, and a smaller foundation adds a category of its own: when something misbehaves deep in the layer, there is no forum thread, no vendor, and no stranger who hit it first, so the cost lands on your payroll at full price. Companies that moved to a narrow stack for support reasons usually discover their ticket volume unchanged and their escalation path shortened to one named engineer. The genuine support wins in robotics come from remote observability, disciplined versioning and updates that cannot half-apply. Those are worth funding first, and they are the same work regardless of what carries the messages.

Will an alternative middleware shorten the schedule?

Partly, but not the way you think. Removing serialisation between processes on one computer takes real work off a loaded machine, and when several programs exchange sensor data on a single board that is a genuine reduction rather than a trick, so a loop that was losing its rhythm can start holding it. What no transport does is create engineering time. The schedule is made of hardware revisions, calibration, safety paperwork, field updates and customer change requests, and a migration adds to that list rather than subtracting from it, because every week spent moving is a week not spent on what the customer bought. The narrow case where a change pays back within a schedule is specific: the product's differentiator is motion quality, the loop shares one computer with heavy work, and the symptom is visible to customers today. Test the theory before committing to it by quieting everything else and seeing whether the misbehaviour survives. If it survives with the machine otherwise idle, the cause is tuning, calibration or mechanics, and no foundation change touches those.

How do you decide which alternative to commit to?

Decide by naming the customer-visible symptom you are removing, and let the symptom pick the alternative, because each one points somewhere different. "We cannot get the packages we need" settles the question in favour of staying. "An auditor needs a supplier to call" means you are shopping for a support arrangement, not a transport, and buying a long-term supported build is the whole answer. "A certifier will read our documentation" means a commercial framework with paperwork included, and the software properties barely matter next to 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 price worth paying. "Motion degrades when the machine is fully loaded and cleans up when we quieten it" is the one symptom that genuinely implicates the layer underneath. If you cannot name any symptom, keep what you have and spend the quarter on start-up, configuration, observability and updates, because those will hurt first under every option on the list.

Decide by situation rather than by architecture preference:

• If you are pre-product-market-fit -> ROS 2 as it comes, because trying more things beats owning less code.
• If machines are in the field and an audit is coming -> ROS 2 with a support partner, because somebody external must 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 the application on a commodity machine -> a vendor platform, because the base is not your differentiator.
• 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.

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 customers notice when it slips, star HORUS on GitHub so it is in your list when you start building. Before any of that, settle whether open source is safe to ship, because that answer changes which rows are even eligible.