Open Source vs Commercial Robotics Platforms: How to Decide

Build on open source, and pay for a commercial robotics platform only where money buys an obligation you cannot staff yourself. Open stacks such as ROS 2 and HORUS give you source you can read and no per-robot fee; a paid platform sells a contract and somebody to call at midnight. That flips when you ship into a regulated setting or cannot physically reach the fleet. The rest of this post is for a team that must make this call this quarter and then justify it to whoever signs the cheques.

The argument arrives dressed as a technical question and is really a question about who gets blamed. Somebody on the team says the sensible thing: everything we need is free, the source is right there, and no vendor can raise a price on us halfway through a product cycle. Somebody else says the other sensible thing: when a machine stops moving in a customer's building on a Friday night, a mailing list is not a plan.

Meanwhile the evidence piles up on both sides. A library you depend on was last touched by one person a year and a half ago, and the issue you filed has no reply. A demo unit at a trade show behaved differently from the one on your bench and nobody can explain the difference. Procurement at your first serious customer has sent a questionnaire asking who supports your software and what happens if they stop. Your lawyer has developed opinions about a licence file nobody on the engineering side has read.

Underneath all of it sits the question people avoid saying out loud, because saying it means somebody has to own the answer: when this goes wrong in the field, who exactly is on the hook?

Should you build your robot on open source or pay for a commercial platform?

Build on open source, and treat every paid platform as the purchase of one specific obligation rather than the purchase of software. The question sounds like it is about code quality. It is almost never about code quality, because the open stacks in robotics are the same stacks the commercial vendors build on top of.

What differs is who is contractually required to care. A free project is maintained by people who have made you no promise, however good they are. A paid platform puts a named party on the end of a phone line and writes down what they owe you. That is worth real money exactly where being stuck is expensive, and almost nothing everywhere else.

Most teams that regret this decision bought the wrong side of it. They paid for an obligation when what they lacked was two weeks to read the source of something free, or they stayed free to save cash when the real constraint was that nobody could be woken at two in the morning. Decide which shortage you have before deciding which cheque to write.

What does a commercial robotics platform actually sell you?

It sells insurance, integration and paperwork, in that order, and only occasionally better software. The pitch is usually framed around features, but the features are the least durable part of the offer, because a free project will have most of them within a couple of releases.

What survives the comparison is narrower and more useful. A response commitment with a name attached. Security patches that arrive without you tracking them. Prebuilt integration with the arm, the base or the sensor you bought, already tested on the combination you own. Compliance documents you can hand to a customer's auditor without writing them yourself. Sometimes indemnity, which matters to a lawyer even when it never gets used.

This is worth spelling out because teams routinely pay for the wrong item on that list. Paying for integration you could do in a week is expensive. Paying for compliance paperwork that would cost your team a quarter to assemble is cheap. What a company is really buying when it pays for a framework is rarely the code, and treating the invoice as a code purchase leads to buying too much of it.

What are the real options once you stop treating this as two camps?

There are about seven, and the useful ones sit between the extremes rather than at them. At the free end: a large open ecosystem, ROS 2, which brings drivers, visualisation, recording and a hiring pool; a focused open middleware such as HORUS, which moves messages between Rust, Python and C++ processes through shared memory on one machine under Apache-2.0 and leaves the rest of the robot to you; and small single-maintainer projects that do one thing well and have no succession plan.

At the paid end: a supported distribution of an open stack, where the code is the same but somebody answers the phone; a full commercial platform with its own tooling and its own way of thinking; the vendor SDK bundled with your hardware, which is commercial software you accepted without a procurement process; and your own internal stack, the most expensive platform of all because you are both the vendor and the only customer.

Almost nobody ships one of these alone. The usual arrangement is an open ecosystem carrying perception and drivers, plus one paid relationship covering the part the company cannot afford to own.

How do these options compare when you put them side by side?

The comparison turns on what each option assumes you already know and what it expects you to own forever. Read the last two columns first, because the mistake teams make is picking a row whose exit condition already describes their situation.

No row wins. The right row is the one whose final column does not describe you.

Does the answer change for a three-person team compared with a forty-person one?

Yes, and it changes in the direction most people expect but for a reason most people miss. A three-person team should lean open, not because paid software is bad but because a support contract does not reduce the number of things three people have to understand. It only changes who they ask. The bottleneck at that size is attention, and attention is not for sale.

A forty-person company has the opposite problem. It can afford to own a dependency, but it cannot afford ambiguity about who owns it, and free software has a way of belonging to whoever touched it last. That is when a paid relationship starts paying for itself, not because the vendor is smarter but because the obligation is written down and survives the person who leaves.

There is a middle size where this decision goes wrong quietly. Around ten to fifteen people, teams often have enough engineers to fix anything and no explicit owner for anything, so problems bounce between people for days. That symptom is not a licensing problem, and buying a platform will not cure it.

Does the hardware you already bought settle this for you?

Often, yes, and teams usually discover this after the decision rather than before. If your arm, base or humanoid arrived with an SDK, you have already accepted a commercial dependency, whether or not anybody signed a purchase order for software. The vendor's assumptions about how your software is organised are now inside your architecture.

Hardware settles it a second way through drivers. If the sensor you standardised on has a maintained driver for one ecosystem and a half-finished community port for everything else, then choosing anything else means adopting driver maintenance as an unpaid ongoing job that no customer will ever see or pay for.

And hardware settles it a third way through what the machine can hurt. A tabletop arm in a lab and a two-hundred-kilogram machine moving near people are the same software question with completely different consequences for being wrong, and the second one is where certification support, incident response and written obligations stop being overhead. Ask what the machine can do at its worst before you ask what the software costs at its best.

How much does your shipping date change the answer?

A date inside one quarter pushes hard towards whatever your team already knows, open or paid, and away from anything new. Under deadline pressure the important variable is not which option is better in the abstract. It is how many unfamiliar failure modes you can afford to meet for the first time between now and the demo.

Deadlines also distort the decision in a predictable direction. A commercial platform looks fast because the sales engineer makes it look fast, and the first week genuinely is fast. The cost arrives later, when your behaviour does not fit the vendor's model of a robot and you need a change that only they can make, on their schedule rather than yours.

Long runways invert this. With a year, reading the source of a free stack is a genuine investment, because the understanding compounds across every future problem and nobody can invoice you for it. The rule of thumb: short calendars favour familiarity and written obligations, long calendars favour source you can read. Neither favours adopting something new the month before a demo.

What if nobody on the team has shipped a commercial robot before?

Then buy the paperwork and keep the code open, because the part a first-time team underestimates is never the software. It is the security questionnaire, the safety file, the patching policy, the incident process and the customer who wants to know what happens if your supplier disappears.

A team shipping its first commercial machine tends to prepare for technical risk it can imagine and gets ambushed by process risk it cannot. Weeks disappear into a document nobody scoped. Meanwhile, the actual software questions are the ones a first-time team should keep close, because being able to read the source is the only way to build the judgement that later tells a real problem from a self-inflicted one.

The specific trap to avoid is buying a platform because it feels safer. Safety in this business comes from testing, limits and process, not from an invoice. Whether an open stack is safe to ship commercially is a question about your obligations and your evidence, and a paid licence answers only part of it.

What does the wrong choice look like a year later?

It looks like waiting, and the flavour of waiting tells you which mistake you made. On the too-paid side, the standup fills with things that are blocked on the vendor. A behaviour the product needs cannot be expressed in their model. A bug is confirmed and scheduled for a release two quarters out. Someone has written a wrapper around the platform to work around it, and now you maintain both.

On the too-free side, the waiting has no address. A dependency broke after an update and the fix is somewhere in a codebase nobody has read. The person who understood the tricky part has left. A customer asks a question about supply chain and the honest answer takes a week to assemble. Every incident starts from scratch because nothing was ever written down.

Both failures feel like bad luck from the inside and look predictable from the outside. The tell is where the hours go: blocked on someone else, or lost inside something nobody owns. Name which one you have before you change anything, because the remedies are opposites.

What do you give up by choosing open source?

You give up the right to escalate, and that turns out to be the whole of it. When something breaks, your options narrow to reading the code, working around the problem, or maintaining a patch. All three are survivable and none of them are on the roadmap you presented last month.

You also give up a certain kind of answer to customers. Procurement questionnaires ask who supports the software, and the honest reply for an open stack is that your own team does. That answer is acceptable, common and entirely defensible, but somebody has to be prepared to give it in a room full of people who buy software rather than build it.

The third thing you give up is scheduled attention. Free maintainers fix what interests them, in the order that interests them, and your production incident is not automatically at the front. The mitigation is not to buy something. It is to make sure at least one person on the team has read the source of everything on the path between a sensor and a motor, before you depend on it in the field.

When is ROS 2 the better choice?

ROS 2 is the better choice for most robots, and specifically when the hard part is perception, navigation, integration or being maintainable by a team whose members change over time. If your machine has to map a building it has never seen, plan around a person, recognise objects and report to a fleet manager, ROS 2 is not a compromise. It is years of work you get to skip, available at no cost, with commercial support purchasable separately if a customer demands it.

ROS 2 also wins on the arguments that actually decide products. You can hire people who already know it. Hardware vendors ship drivers for it. You can record a failure in the field and replay it at a desk on Monday. Contractors, students and collaborators arrive fluent.

HORUS is not the answer in those cases. A shared-memory middleware carries messages between processes on one machine and brings you no mapper, no planner, no fleet interface and no driver for the lidar that arrives next week. If those are your hard problems, choosing something smaller means writing all of it yourself.

Is commercial software safer to ship than open source?

No, and here is why. Safety in a shipped robot comes from what the machine physically cannot do, from the tests that prove it, and from the process that catches the case nobody imagined. None of those three arrive with a licence key. A paid platform can help you produce the evidence, and on a certification path that help is genuinely valuable, but the evidence is still yours to produce.

The stronger claim hidden inside the question is that closed code has been reviewed more carefully. Sometimes true, often not, and unverifiable either way from outside. What is verifiable is whether the code on the path between a sensor and a motor can be read by the people responsible for the machine's behaviour. When a robot does something unexplained in front of a customer, the team that can read every layer gets to an answer, and the team that cannot files a ticket and waits.

Licence choice is a separate question with real consequences, and what a licence actually permits you to sell deserves a proper reading before adoption rather than during an acquisition.

Does paying a vendor remove the risk of being stranded?

Partly, but not the way you think. A contract genuinely removes some risk: response times, patches, a named escalation path and, if you negotiated well, source escrow if the company folds. Those are real and worth paying for when a stalled fleet costs more than the invoice.

What a contract does not remove is the dependency itself. Vendors get acquired, change pricing, deprecate the product line you standardised on, or decide your segment is no longer strategic. Then you migrate under time pressure, with a fleet already in the field, which is the most expensive kind of migration there is. Open dependencies fail differently: they go quiet rather than disappearing, and a stack you can still compile buys you the time to plan an exit properly.

So the honest framing is not stranded versus safe. It is which failure you would rather manage. The practical hedge costs nothing today: keep your own control logic, safety limits and task behaviour in plain libraries that any substrate can call, so that changing the layer underneath becomes rewiring rather than rewriting.

How should a team settle this within a week?

Write down the one thing that would hurt most if it failed at a customer site, then ask which option puts a name against it. That single question resolves more arguments than a feature comparison, because it converts a philosophical debate into an ownership question with a finite answer.

Then run a three-day test rather than a three-month evaluation. Take the ugliest part of your robot, build it on the hardware you actually intend to ship, in the language your team actually writes, on each finalist. Do not compare feature lists. Watch four things: how long a new engineer takes to reproduce it from a clean checkout, whether you can replay yesterday's failure at your desk, what happens when one process is killed, and how fast a real question gets a real answer from whoever is meant to answer it.

That last one is the whole decision in miniature. Ask a hard question of the vendor's support channel and the same question of the open project's issue tracker on the same afternoon, then compare what came back.

• If you are three people with a demo next month -> open source, because a contract does not reduce how much you have to understand.
• If you ship into a regulated or audited setting -> a commercial platform or supported distribution, because somebody else's paperwork is cheaper than your own.
• If your fleet is somewhere you cannot drive to -> a paid support relationship, because response time becomes a contractual promise rather than a hope.
• If the timing of the motion is what customers pay for -> an open middleware alongside the ecosystem, because that layer is your product and you should own it.
• If your hardware vendor's SDK already does the job -> stay on it, because a port buys nothing a customer can see.
• If the real problem is that nobody owns your dependencies -> fix ownership first, because no licence cures that.

The HORUS Fit Framework reduces the whole comparison to five axes: ecosystem size, setup effort, team size fit, deployment target, and licence. Score every finalist on all five and pick the one that is not weak on the axis your company cannot afford to be weak on.

If that axis keeps turning out to be timing on a single machine, put HORUS on your reading list rather than this quarter's roadmap: star it so it is in your list when you start building.