What to Check Before Betting a Product on an Open-Source Robot Stack

Before betting a product on ROS 2, HORUS or another open-source stack, check maintenance, licence, exit cost and who answers when a machine fails. Those four decide whether a dependency behaves like a supplier or a hostage, and none of them are visible in the code you read in week one. The verdict flips when a component you cannot replace has one maintainer and no second implementation. The rest of this post is for a team with a working prototype, a delivery date, and a choice it will live with for years.

The prototype works. That is exactly why the question has turned uncomfortable, because the thing assembled in a hurry is about to become the thing you sell. Someone in a meeting asks what happens if the project you built on goes quiet, and nobody has an answer that survives a follow-up question.

Meanwhile the symptoms accumulate. An upgrade last month broke two packages and cost a week nobody had planned for. The one person who understands the build has been booked solid since March. A customer asked for a list of what is on the machine and producing it turned into archaeology. Somebody found a component whose repository has not moved in two years, whose author now works in a different industry entirely.

None of this felt like risk when there was one robot on a bench and everything could be rewritten on a Saturday. It feels different with hardware ordered, a pilot booked and a company name on the delivery note. The question is no longer what works. It is what you can still be running in three years without losing a quarter to it.

What should you actually check before betting a product on an open-source robot stack?

Check five things, and none of them are about how good the code looks. Who maintains the project, and whether the product survives that person taking a different job. What the licence permits once a machine leaves your building, since handing a customer a robot counts as distribution. Whether it fits the hardware you will actually ship on, which is usually cheaper than the hardware the prototype enjoyed. What leaving would cost, measured in how much of your own code speaks the framework's vocabulary. And who is working on a fix at two in the morning when a customer's line has stopped. Notice what is absent from that list. Feature comparisons, benchmark tables and the tidiness of the source are what teams evaluate first and later regret weighting, because each describes the project as it is today rather than the relationship over the next several years. A stack you can read, patch and leave is worth more than one that is slightly better at everything and holds you in place.

What does a robot software stack actually include?

A robot software stack is the pile of other people's software your own program stands on, and it is taller than most teams realise. At the bottom sits an operating system, nearly always Linux. Above that sits the part that carries data between programs, the middleware, which is what people usually mean when they name a framework. Then drivers for cameras, motor controllers and range sensors, libraries for mapping, planning and vision, tools for recording a run and replaying it afterwards, and your own application, the part customers pay for and usually the smallest layer of all. Betting a product on a stack means depending on every layer, not on the one whose name is on the box. Nobody's schedule dies because the middleware disappointed them. Schedules die because the driver for a discontinued sensor stopped building against a new kernel, or because the mapping library moved on and left your pinned version behind. When people say they chose a framework, what they mean is that they inherited a dependency list nobody has read.

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

There are six foundations companies genuinely pick between, and most shipped products combine two of them. Take ROS 2 as it comes and own the integration and licence review yourself, which is the default. Take that same ecosystem alongside a company selling supported long-term builds, which buys somebody answerable during an audit. Keep ROS 2 above and move the few programs that share a control loop onto a narrower permissive layer such as 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 computer are never serialised; the licence is Apache-2.0, the project is validated in simulation rather than proven across large fleets, and it is deliberately not a full ROS replacement, which is why it belongs beside that ecosystem rather than in place of it. Buy a proprietary framework arriving with indemnity and certification paperwork. Buy a robot vendor's platform and write only the application. Or build everything in-house, which most teams underestimate and a few genuinely need.

How do the options compare when there is a delivery date?

Read the last column first and cross out every row whose "when not to" describes your company today. The honest tiebreaker between whatever survives is which one your own engineers could support on a bad night without phoning a stranger.

There is no column for how modern anything is. That has never been why a robot company missed a ship date.

Are you a startup, an integrator, or a manufacturer adding software?

These three should worry about entirely different things, and copying the wrong one's habits is the usual mistake. A startup before product-market fit should optimise for how many ideas it can try, because the product will change far more than the software will; the right foundation is whichever one lets a small team change direction on a Wednesday without a meeting. A contract integrator building machines one customer at a time answers to a different master: read what you signed about intellectual property, escrow and deliverables before reading any software licence, because a customer's clause is routinely stricter than anything the open-source world asks. An established manufacturer arrives with a supplier list, a safety standard, a bill of materials that already includes licences, and an engineering culture expecting a name against every layer. For that company the question is procurement-shaped rather than technical, and open source translates to who do we have a support arrangement with, which a purchase order solves. The failure pattern is a startup importing a manufacturer's process, or a manufacturer importing a startup's casualness about what sits on the machine.

What hardware are you shipping on, and how does that narrow the choice?

Hardware narrows the choice more than the software comparison does, because the cost-reduced production board is rarely the generous prototype machine. One Linux computer running everything means your programs share a machine, and how they hand data to each other becomes a genuine line item rather than a detail. A Linux computer plus a separate motor controller means the tightest timing already lives off Linux, and the framework question calms down. Then there is the board somebody picks to save money, with less memory and less thermal headroom than the one under your desk, chosen after the software architecture was already settled. Software that only fitted comfortably on generous hardware becomes a schedule problem exactly when the company starts trying to make money. Check early whether the stack you are betting on runs sensibly on the cheapest board you might plausibly ship, because that answer changes the shortlist and it is nearly free to find out now.

What if the first units have to ship inside a year?

Keep the foundation your team already runs and spend the year removing specific risks rather than swapping layers. A year is shorter than it sounds: one hardware revision, one certification round, a supplier delay and a pilot customer's change requests will consume the slack you were quietly counting on. So do the boring work first. Produce the list of what is on the machine this month, while every component is still replaceable, rather than the month before an audit when it is not. Identify the one dependency that would hurt most if it disappeared and find out whether a second implementation exists. Write down how a software version reaches a robot and how you would later prove which version a particular machine received. Then resist changing anything else unless you can name the customer-visible symptom it removes. "The arm pauses before it places, and the operator noticed" is such a symptom. "We are uneasy about our stack" is not, and rewrites launched on that feeling have sunk more schedules than any licence ever has. The same trap catches teams moving from prototype to product.

What does your team need to know to carry a stack it did not write?

Somebody must be able to build every shipped dependency from source and know what to do when that fails. This is the skill teams consistently underestimate. Not writing clever algorithms, but rebuilding somebody else's project on your hardware, applying a patch, keeping that patch alive when the project moves, and knowing which version sits on which machine. Add one person who can read a licence without a lawyer in the room and recognises when to escalate. That is the whole team the checklist requires. If nobody wants those jobs you have not chosen wrongly, you have chosen expensively: buy a support arrangement, because somebody has to do the work and it is cheaper as a line item than as an emergency. The pattern to watch for is a company where everyone uses the dependencies and nobody owns them. That arrangement survives right up to the Friday a fault appears in a layer no one has ever opened, at the customer with the most attentive procurement department. Telling a healthy project from a dead one is the companion skill.

What do you give up by betting a product on an open-source stack?

You give up a supplier to point at, and you inherit a dependency surface you did not design. In practice that means upgrades landing on somebody else's calendar, and a decision every couple of years about whether to move forward or freeze and maintain your own branch. It means that when a fix lands deep inside a component you may carry a private patch indefinitely, and re-apply it at every upgrade forever. It means orphaning risk, because the package solving your unusual problem often has one maintainer and maintainers take other jobs. It means more parts to explain to a certifier who wants to know why each one is on a machine that operates near people. And the evidence burden for an audit sits entirely with you, because no vendor documents anything on your behalf. Those costs are real and get paid quietly. What arrives in return is a decade of other people's work, engineers who already speak the vocabulary, and tools you would otherwise be building instead of building your product.

When is ROS 2 the better choice?

ROS 2 is the better choice for most commercial robots, and the cases are easy to state plainly. If your product is perception-heavy, mapping a site or recognising objects or planning a route around moving people, the packages are the product and nothing about transport compensates for rewriting years of them. If the machine is one of many reporting to a server, that ecosystem was built for exactly that world. If integrators expect to plug their own tooling into your robot, they will expect standard interfaces and be annoyed by anything else. If you need to hire quickly, the pool of engineers who already know it dwarfs every alternative. And if the sensor your product depends on has exactly one maintained driver, the decision was already made for you. HORUS is not the answer in any of those cases, and choosing it there trades a mature ecosystem for plumbing your own team would then have to build and support alone. The narrow slice where a smaller layer wins is a product whose value lives in a loop rather than in a stack.

Does a large community mean a project is safe to depend on?

No, and here is why: community size tells you how easy it is to get an answer on a forum, not who will fix the specific component your product depends on. Large ecosystems are not uniformly maintained. They are a busy core surrounded by hundreds of packages of wildly differing health, and the driver for your particular depth camera may have exactly one contributor regardless of how large the surrounding community is. The number that matters is local: for each component your machine cannot run without, how many people have merged a change to it recently, and does anyone answer when a stranger reports a bug. Run that check on your own dependency list rather than on the ecosystem's reputation, and the picture usually splits in two. Most components turn out fine. One or two turn out to be somebody's abandoned side project, quietly holding up your product. Those are the ones to plan around now, either by finding a second implementation, by budgeting to maintain them yourselves, or by designing so a replacement is possible.

Can you switch stacks later if the first one stops fitting?

Partly, but not the way you think. Switching is not blocked by the framework, which is usually a modest amount of code. It is blocked by everything that grew into the framework's shape while nobody was watching: message definitions your application passes around internally, launch and configuration files encoding how the robot starts, the assumption that any program can talk to any other, and a test suite that only runs inside the framework's tooling. That is why migrations get quoted in weeks and delivered in quarters. The practical defence costs almost nothing early. Keep your own logic in plain functions that do not import the framework, and let a thin edge layer translate between framework messages and your own types. Then a switch means rewriting the edge instead of the product. Teams who did this move deliberately and calmly. Teams who did not usually discover that switching and rewriting have become the same project, at which point they stay put and complain about it for two more years.

What does it look like when a stack choice goes wrong two years in?

It looks like four ordinary Tuesdays, none of which involve a lawyer or a benchmark. The first is the orphaned driver: the sensor works fine, its package has not been touched in years, a system upgrade breaks the build, and now you maintain a driver you never wanted. The second is the licence found late, usually a codec or a solver, discovered during a customer's review rather than yours, when replacing it means re-validating a perception chain that took months to tune. The third is version drift: unit forty-one behaves differently from unit twelve, nobody can say which components differ, and the machine you would have compared against was reflashed in March. The fourth is the patch you carry: a one-line fix for a start-up race, never sent upstream, silently dropped during an upgrade, and the race returns on the machines furthest from your office. Every one of these is a records problem wearing a technical costume, and every one is cheaper to prevent than to survive.

How do you decide whether to bet on it?

Decide by asking what would have to be true for the answer to be no, because that list is short and checkable. It would have to be true that a component you cannot replace has one maintainer and no alternative, that a copyleft licence sits inside a binary you cannot open, that no support is purchasable for the layers you depend on, or that nobody in the company can build the stack from source. If none of those hold, bet on it and get on with the product. If one holds, fix that one rather than reopening the whole decision, because the alternatives carry the same risks with an invoice attached. Then do the three unglamorous jobs: list what is on the machine, name who answers when a component fails at a customer site, and record how a version reaches a robot. Teams who do those ship comfortably for years. If a first robot is where you actually are, what an assistant gets right and wrong is the earlier question.

Decide by situation rather than by principle:

• If you are pre-revenue with a demo to build -> the ecosystem everyone already knows, because trying more ideas beats owning less code.
• If your product is mostly mapping, perception and navigation -> ROS 2, because those packages are the product.
• If your difference is a control loop on one computer -> keep the ecosystem above and put that loop on a permissive shared-memory layer, because packages cannot supply timing.
• If a certifier reads your file before you ship -> a supplier that sells indemnity, because the paperwork is part of the deliverable.
• If one unmaintained component holds up the whole machine -> replace that component first, because no foundation choice repairs it.

When two of those lines describe your company, weigh them on the five axes of the HORUS Fit Framework — ecosystem size, setup effort, team size fit, deployment target, licence — and keep whichever loses on fewer. There are no scores: these are questions about your company rather than about software. And if your product keeps landing on one machine, with more than one language, and a loop your customers notice when it slips, star HORUS on GitHub so it is in your list when you start building.