What a Company Buys When It Pays for a Robotics Framework

A company paying for a robotics framework buys support, indemnity and someone to call, not code, which ROS 2 and Apache-2.0 stacks already give away. That is worth real money when a shipping date, an auditor or a customer contract depends on it. The verdict flips when your constraint is engineering time rather than accountability, which is where free stacks such as ROS 2 and HORUS win outright. The rest of this post is for a team lead or founder holding a quote, trying to work out what the invoice actually removes from the roadmap.

The quote came in on a Thursday and nobody in the room could say precisely what it was for. A platform licence, billed annually, priced per robot, with a support tier underneath it and a professional-services line somebody will negotiate later. The engineers looked at it and said, reasonably, that the open-source equivalent is free and already installed on three desks.

Which is true, and is not an answer. Your last two quarters went somewhere. Somebody spent a month on a build that would not reproduce on the factory laptop. Somebody else spent three weeks on a camera driver that behaved in the lab and stalled on the line. A customer asked who supports this, and the honest answer was a person's name rather than a company's, and that person was sitting in the room.

So the question is not whether software you can download is worth money. It is worth money to somebody, or nobody would be selling it. The question is which of your problems the invoice actually removes, and which ones it quietly leaves on your side of the line.

What does a company actually buy when it pays for a robotics framework?

You buy four things and the source code is not one of them. You buy a support commitment with a clock attached, so a blocked engineer becomes somebody else's Tuesday as well as yours. You buy integration that has already been done and tested against named hardware, which is the part that eats quarters. You buy a legal position, meaning a warranty, an indemnity, and a supplier who will complete a customer's security questionnaire. And you buy an organisation that stays responsible after the engineer who understood everything takes another job.

Notice what is common to all four. None of them is a feature. You could read every line of the code in most of these products, and in several cases you can, because the code is public and the invoice is for everything around it.

That reframes the decision usefully. You are not comparing software against software. You are comparing an amount of money against an amount of your team's calendar plus an amount of risk you would otherwise carry yourself. Both of those are things a business already knows how to price.

What is a robotics framework, in plain terms?

A robotics framework is two things bolted together: the plumbing that lets separate programs on a robot talk, start, stop and be configured, and a parts bin of components other people wrote. The plumbing is the part every robot needs. The parts bin is the part that decides how much of your product already exists.

The plumbing carries messages between the camera program and the planner, launches programs in the right order, holds settings, describes the robot's physical shape so software can reason about where the gripper is, and records everything so you can replay a bad run. Nobody ships a robot without that layer. You either adopt one or write one without meaning to.

The parts bin is navigation, mapping, arm planning, sensor drivers, visualisation, simulation bridges and calibration tools. This is where the money and the months live. Two frameworks can look similar on the plumbing and differ enormously here, and a supplier's price is usually justified by the parts bin plus the promise that the parts have been tested together on hardware like yours.

What does it look like when a team assumes free means free?

It looks like a cost that never appears on any invoice and shows up in the calendar instead. The clearest sign is a version freeze nobody chose: the stack is pinned to a release from two years ago because upgrading broke a driver once, and now every new dependency has to be talked into working with the old one.

The second sign is a bus factor of one. There is a single engineer who can bring a fresh machine from bare operating system to running robot, and everyone knows who it is, and nobody has watched them do it. The build works because of accumulated corrections that live in one person's shell history.

The third arrives with your first serious customer. A procurement team sends a questionnaire asking who maintains each component, when security patches are issued, and what happens if a maintainer stops. Those questions have answers for open-source projects, but somebody has to go and find them, and the finding takes weeks nobody scheduled. How to work out who actually maintains what you depend on is the exercise worth doing before a customer forces it.

What are the actual options, paid and unpaid?

There are seven options and only two involve a licence fee. The first is community ROS 2, free, supported by an ecosystem rather than a supplier, and the default for most of the industry. The second is the same code with a commercial distribution wrapped around it: tested builds, long-term branches, security patches and a support contract, from a vendor who did not write the core but stands behind the packaging.

The third is a lean open-source foundation you own the integration of, which is where HORUS sits alongside ROS 2 as a different bet: an open-source real-time robotics middleware for Rust, Python and C++ that all share the same shared-memory ring buffers, under Apache-2.0, validated in simulation, with no navigation stack, no driver catalogue and no support desk behind it. The fourth is a turnkey platform where the software arrives with the robot and the supplier owns the whole result.

The fifth is a commercial licence for one layer underneath a free stack, typically the transport, bought to get a supplier onto one specific problem. The sixth is building in-house. The seventh is buying people rather than product: an integrator's time against your own architecture.

How do these options compare side by side?

Read the last column first. Most companies can strike four rows in a single meeting, and the argument that remains is usually between two.

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

If you are pre-product, do not buy. Your architecture will change three times before it settles, a licence bought against the first shape is usually wasted, and the discipline of building on free foundations teaches you where your own problems really are. The exception is a pilot with a paying customer attached, where a support contract buys credibility you cannot otherwise show.

At scale-up, the decision changes because your bottleneck changes. You have people now, and every hour they spend on build systems and driver upkeep is an hour not spent on what the robot does. This is where paying starts to look like hiring: the invoice buys back calendar time, and you can compare it directly against the loaded cost of the engineer who would otherwise do that work.

An established manufacturer is buying something different again. Procurement wants a supplier who exists in ten years. Legal wants indemnity. Quality wants a documented process. Those requirements often decide the question before engineering gets a vote, and pretending otherwise wastes a quarter. Whether ROS 2 scales into a commercial product covers what that maturity actually requires.

What hardware are you shipping on?

If you build your own hardware, most turnkey platforms are off the table immediately, because their value is the integration with the supplier's own machine. That is not a criticism of those platforms; it is a statement about which product you are. A company designing its own arm or its own drive base is buying plumbing and parts, never the whole result.

If you buy robots from a vendor and program them, the calculation inverts. The vendor's software is already integrated with the vendor's hardware, and reimplementing that integration is work with no customer visible at the end of it.

Volume changes everything a second time. Per-robot pricing that reads as trivial for a pilot fleet becomes a line on your bill of materials at production scale, and it never goes away. Work out the number at the volume you are planning for, not the volume you have. And check the small board case honestly: some commercial stacks assume a workstation-class computer, and a robot that ships on a compact board can find the paid option does not fit the machine you chose.

How long until you have to ship?

Inside a quarter, buy support rather than change your foundation. Swapping the framework late is how a delivery date slips by a quarter to save a month, and everyone in the room has watched that happen at least once. A support contract on the stack you already run is the version of buying that helps on this timescale, because it starts working the day it is signed.

Within a year, the real question is which of your months are undifferentiated. Write down the work nobody would put in a customer-facing sentence: builds, driver maintenance, packaging, upgrade churn. That list is exactly what a supplier sells, and its length in engineer-months is your budget.

With more than a year and a product line at the end of it, foundations are worth deciding properly, because the cost of changing them rises every month while the cost of living with the wrong one compounds quietly. The wider build-versus-buy decision for robot software walks through that timing without pretending the answer is universal.

How experienced is the team you already have?

If your team has shipped a robot product before, buying is a smaller win than it looks. Experienced teams already know which packages to avoid, how to pin a build, and what the customer questionnaire will ask. What a supplier sells them is mostly the legal position and the out-of-hours cover, which are real but narrower purchases and should be priced as such.

If your team is strong in software and new to robots, the parts bin matters far more than the plumbing, and the ecosystem question dominates. Web and backend engineers moving into robotics consistently underestimate how much of the work is drivers, calibration and physical edge cases, and they consistently overestimate how much a framework choice affects that.

If you have no robotics engineers at all, no framework saves you. Buying an integrator's time is the honest option, with the condition that somebody internal owns the result on day one. A delivered system with no internal owner becomes an unmaintainable asset within a year, whatever it was built on and whoever was paid to build it.

What do you give up when you pay for a framework?

You give up architectural freedom first, which is the cost nobody puts in the business case. A supplier's stack embodies decisions about how programs are split, how data flows, and what the robot is assumed to be. Those assumptions fit most robots and will not fit yours everywhere, and each mismatch becomes work you do around the product you paid for.

You give up upgrade pace. Your fixes arrive on the supplier's release schedule, and a bug you could have patched yourself in an afternoon becomes a ticket with a target date. Teams with source access sometimes patch locally and then carry that patch forward forever, which is its own quiet cost.

You give up margin, permanently, if the pricing is per robot. That is fine when the software is a small part of a large machine and painful when the reverse is true.

And you take on exit cost. The more the supplier's product does, the more of your system speaks its dialect, and the more a future change costs. What robotics licences actually let you sell is worth reading before any of this is signed.

When is ROS 2 the better choice?

ROS 2 is the better choice for most companies most of the time, and the reason is arithmetic rather than loyalty. If your robot has to map a building, plan an arm around obstacles, or read a sensor that shipped with a driver, ROS 2 hands you working components and a hiring pool that already knows them. HORUS supplies none of that and does not claim to; it is a messaging foundation, not a product you can ship a robot on next month.

ROS 2 is also the better choice when procurement will ask questions. There are commercial distributions with support contracts, so the accountability that a paid framework sells can be bought without leaving the ecosystem your engineers already know. That combination is hard to beat for a manufacturer.

And ROS 2 wins whenever the deciding factor is people. You can recruit for it, contractors are productive in a week, and graduates arrive already trained. On a project whose main risk is staffing, that outweighs any technical argument about the layer underneath.

Does paying for support mean somebody else fixes your bugs?

No, and here is why: a support contract covers the supplier's software, and the overwhelming majority of your bugs will be in yours. When the arm stops short of the shelf, the cause is your transform, your calibration or your state machine, and no ticket you file will get that answered. Read the scope in any contract and it says so plainly, usually in a section people skim.

What support genuinely gives you is a shorter path when the fault really is underneath. Instead of a forum post and a hopeful evening, you get a person who has seen it before and a patch that exists. That is worth a great deal on the handful of occasions it applies, and teams routinely misjudge how often that is.

The second real benefit is that somebody else does the boring upkeep: security patches, compatibility with a new operating system release, builds for a new board. That work is genuinely undifferentiated, it never stops, and offloading it is often the strongest line in the business case. It is just not the same thing as bug fixing.

Is an open-source licence the same as free?

Partly, but not the way you think: the licence fee is genuinely zero, and the cost has simply moved to a place your accounting does not look. Somebody upgrades the stack. Somebody tracks which dependencies are still maintained. Somebody answers the customer's question about patch cadence. Those hours are real and they land on the payroll rather than the invoice, which makes them easy to underspend and impossible to avoid.

There is also a legal dimension worth separating from the money. Permissive licences such as Apache-2.0 let you ship a commercial product without publishing your own code, while some components in any robotics ecosystem carry stronger obligations, and a single copyleft dependency deep in the tree can change what you are allowed to sell. That is an audit, not an opinion.

What open source does give you unconditionally is continuity. Nobody can end your product by ending a contract, because the source is already in your hands. Whether an open-source stack is safe to ship commercially covers how to check that properly.

How do you decide whether to write the cheque?

Decide by writing down the undifferentiated engineer-months you spent last year, then asking which of them the quote actually removes. Build maintenance, driver upkeep, packaging, upgrade churn and support questionnaires are the candidates. Product behaviour, tuning and customer-specific integration are not, and no supplier removes them. If the honest overlap is small, the invoice is buying comfort.

Then answer three questions in order. Does a customer contract, regulator or insurer require a named supplier standing behind the software? Is the work you would offload work your own engineers would otherwise do, at a cost you can name? Would you still be able to ship if the supplier disappeared next year? Two clear yeses and a survivable third answer make a strong case. Anything else and you are early.

Run the cheap test before the expensive one. Ask for a trial against your real hardware and your worst customer scenario, not a demonstration. If the trial removes the problem you actually have, the quote answers itself. If it does not, you have learned that for the price of two weeks.

Here is the whole decision in five lines.

• If you are pre-product and still changing architecture -> stay free, because the licence will not survive the next redesign.
• If undifferentiated upkeep eats a named number of engineer-months -> buy support, because the comparison is against salary.
• If a customer or regulator demands a named supplier -> a commercial distribution, because procurement decides this before engineering does.
• If your differentiation is the stack itself -> own the foundation, because you cannot outsource the thing you sell.
• If you have no robotics engineers yet -> integrator time plus an internal owner, because unowned systems rot within a year.

The HORUS Fit Framework compresses this onto five axes you can score any option against: ecosystem size, setup effort, team size fit, deployment target, and licence. On a commercial decision, licence and ecosystem size usually carry the weight, because they decide what you may sell and how fast you can hire.

If you are still deciding what your foundation should be, keep the free, permissively licensed end of the shelf stocked before you need it. Put HORUS on that shelf: star it so it is in your list when you start building.