Is ROS 2 Free? What It Actually Costs You

ROS 2 costs no money, but it charges you in engineer weeks, which is why teams weigh it against lighter middleware and writing their own. That bill is mostly setup, network debugging and distro upgrades, and it is usually smaller than rebuilding the packages you would otherwise write yourself. The verdict flips when your product's difference is a control loop on one computer, where HORUS costs less to carry. The rest of this post is for a small team pricing a first robot programme and trying to work out where the months actually go.

Somebody in the meeting says the software is free, and the sentence lands as though it settles the budget. It settles one line of it. Then the quarter starts.

The first fortnight goes on a laptop that cannot see the robot's topics, and nobody can say why, because everything looks configured. A week goes on a colleague who upgraded their operating system and now builds nothing. Four days go on a camera driver written for a distribution you are not running. A demo works in the lab and stops working in the customer's warehouse, and the fix turns out to involve the Wi-Fi rather than the robot at all.

None of this appears on an invoice. It appears as the feature that slipped, the hire you made a quarter earlier than planned, and the engineer who is now the only person alive who understands your build. At review time the honest summary is that the software cost nothing and the schedule cost a quarter, and nobody wrote that possibility down before it happened.

Should you treat ROS 2 as free when you plan a budget?

No — treat ROS 2 as free of money and expensive in calendar time, and plan the second number rather than celebrating the first. The licence genuinely costs nothing. You can download everything, ship it inside a product, keep your own application code private, and sell the machine without paying anybody a fee or a royalty. That part is real, and it is not a trick. What you agree to instead is ownership. Nobody is contractually obliged to make your build work, to keep a driver alive, to answer at midnight when a fleet stops, or to guarantee that next year's release behaves like this year's. Those obligations do not vanish because the software is free; they move onto your payroll. The useful way to price this is to ask what a capable engineer's first month would go on under each option you are weighing. The answer is never zero anywhere, which is why the comparison is worth making rather than assuming.

What are you actually paying for when software is free?

You are paying for the work that a price tag would otherwise have hidden. Commercial software bundles several things into one number: the code, salaried time keeping it current, documentation, a support channel, and a promise about how long the thing keeps working. Free software hands you the code and unbundles the rest. Every unbundled item still has to happen; the question is only who does it. Integration is the biggest line, because the packages you assemble were written by different people for different robots and were never tested together on yours. Learning is the second, and it is not one curve but four — a build system, a message model, a networking layer, a release cycle. Maintenance is the quiet one, arriving as upgrades you did not choose. Hiring is the line nobody counts, because a stack your team already knows is cheaper than an unfamiliar one even when both are downloadable. None of this argues against free software. It is the actual budget.

What are your real options for the plumbing under a robot?

You have about five, and only two are widely used. ROS 2 is the default: a large open-source ecosystem with drivers, navigation, visualisation and a hiring pool, released under permissive terms and carrying the integration and upgrade work that any large shared codebase brings. Writing your own is the opposite trade — no ecosystem, total control, and a maintenance bill that arrives every year forever. A general-purpose message broker of the sort used in industrial and connected-device systems moves data between machines cheaply but knows nothing about robots and leaves the robot-shaped parts to you. A hardware vendor's own toolkit is often the fastest route for a single arm or a single base, at the price of being tied to that vendor's plans. And there are lighter robotics middlewares, of which HORUS is one: an open-source real-time robotics middleware for Rust, Python and C++ where the three languages share the same shared-memory ring buffers, so messages between processes on one computer are never serialised. Apache-2.0, like ROS 2, so licence terms are not where those two differ.

How do the options compare on what they cost a team?

They compare mostly on what you would end up building yourself, which is why the last column is the one to read first. Ruling an option out is quicker than ranking the survivors.

Are you a solo builder, a startup, or a research lab?

The same software costs three different amounts depending on who carries it. A solo builder pays almost entirely in evenings, and evenings are the scarcest thing in that situation, so the deciding question is how many disappear before anything moves. A startup pays in runway and in opportunity cost: every week on plumbing is a week not spent on what customers are paying for, and the trap is that plumbing feels like progress because it produces visible commits. A research lab runs a different economy again, since students arrive and leave, so the real cost is handover, and tutorials plus a hiring pool are worth more than a leaner stack that nobody else has seen. A company with a fleet already running has paid most of the setup cost once and would pay it again to switch, which is why incumbency wins so many of these arguments correctly. Work out which of those four economies you are in before comparing anything, because the cheapest option in one of them is the most expensive in another.

Does the computer on the robot change the bill?

Yes, and it changes the bill more than any other single factor. A robot with one capable computer and a handful of processes is the cheap case for every option, including the heavy ones, because nothing crosses a network and most of the difficulty never shows up. A robot with several computers on board — a compute module for perception, a controller for the joints, a small board reading sensors — pays for the wiring between them in configuration, in clocks that disagree, and in faults that only appear when all three are running at once. A robot with parts on the far side of Wi-Fi pays the most, because a wireless link turns a message system into a distributed-systems problem, and that is where teams lose the weeks nobody budgeted. Small single-board computers add their own line: less memory and slower storage make heavy stacks awkward to build, so engineers start trimming, and trimming is unpaid work. Count your computers and your network hops before anything else, and read why ROS 2 breaks on ordinary Wi-Fi before you plan around one.

What if you need something working in a month?

Then buy the ecosystem rather than the architecture, because a month is not enough time to build plumbing and a robot at the same time. Over four weeks, the option with existing drivers for your exact sensors wins almost regardless of its other properties, since writing a driver for an unfamiliar camera eats a fortnight and teaches you nothing you set out to learn. Take the tutorial path exactly as written, on the operating system version it names, on hardware somebody else has already used successfully. Resist every improvement that occurs to you along the way. The costs that make people angry — upgrades, network debugging, integration across suppliers — mostly arrive after the first month, which is precisely why a demo is weak evidence about a product. The mistake is treating a month that went well as a forecast for the year. If that month is a prototype for something you intend to sell, write down every workaround you used while you still remember it, because that list is the real estimate for what comes next.

How much does your team need to know before the cost drops?

One person needs to be genuinely comfortable on Linux, and everything gets cheaper from there. The skills that shrink the bill are unglamorous: reading a build error, understanding what a process is and how two of them share data, knowing where a machine's clock comes from, and separating a networking problem from a code problem in under an hour. Teams without those skills pay more not because they are less capable, but because every problem costs a day of classification before anybody can begin solving it. C++ matters less than folklore suggests, and Python-only teams get further than expected, right up to the point where timing starts to decide behaviour. What predicts a cheap first year is whether somebody has shipped anything that ran unattended for weeks, because that person recognises these failure modes on sight. If nobody has, budget for that learning openly instead of discovering it as slippage, and see how long it really takes to learn ROS 2.

Which of these costs come back every year?

Three of them repeat, and they are the ones that surprise teams who priced adoption as a one-off purchase of effort. The first is the distribution cycle: the release you built on eventually stops receiving fixes, and moving to the next one is a project with testing attached rather than an afternoon of upgrades. The second is dependency drift, where the operating system, the compiler, a camera vendor's driver and a handful of libraries each move on their own schedule, and one morning your build fails on a machine nobody touched. The third is staff turnover, because the person who understood the build always leaves eventually, and the cost of that departure is proportional to how much of the setup lived in their head rather than in a script. The defence against all three is identical and boring: put the entire environment into something reproducible early, so that a new machine, a new hire and a new release each cost hours rather than weeks. What happens when a distro reaches end of life is the detailed version of the first one.

What do you give up by taking the free option?

You give up somebody to hold responsible, and that trade deserves stating plainly rather than pretending it does not exist. There is no warranty, no promise of a fix, no release you can name in a contract, and no supplier who priced your downtime into a support agreement. When a fleet stops on a Saturday afternoon, the people who can help are your own, plus whoever happens to be reading a forum thread. You also give up a kind of planning, because an open ecosystem changes on its own timetable and features you depend on can be deprecated by people who owe you nothing. In exchange you get the source, the right to fix anything tonight without waiting in a vendor's queue, freedom from per-machine fees that grow as you succeed, and access to people who already know the thing you build on. Most robotics companies end up buying support for the narrow parts that would stop a customer's line and carrying the rest themselves.

When is ROS 2 the better choice?

ROS 2 is the better choice for most robots, and nothing in the cost argument changes that. If your machine has to perceive and navigate — build a map, avoid people, plan a path, recognise objects — then the packages are the product, and no amount of saved plumbing time repays writing those from scratch. If you intend to hire, the pool of people who already know this stack is larger than for every alternative combined, and onboarding time is a cost like any other. If your customers or integrators expect standard interfaces so they can attach their own tooling, an unfamiliar stack turns into a sales objection you have to answer in every meeting. If the sensor your product depends on has exactly one maintained driver, the decision was made before you arrived. HORUS is not the answer in any of those cases, and choosing it there trades a mature ecosystem for plumbing your own team must then build and support alone. The engineer weeks are real, but they buy something, and for most teams what they buy is worth more than the weeks.

Does paying for a supported platform remove the cost?

No, and here is why: a support contract moves part of the bill and renames the rest. What money buys is a named person to call, releases somebody else tested, and maintenance of the components that supplier ships. That is worth a great deal when a stopped production line costs more per day than the contract costs per year. What money does not buy is integration, the largest line in the estimate. Your sensors, your arm, your customer's network and your own application still have to work together, and no supplier can do that without knowing your machine. Contracts add costs of their own too: procurement time, a version cadence you no longer control, and dependence on a company that may reprice or be acquired. The honest framing is that a paid platform converts unpredictable engineer weeks into a predictable invoice plus fewer engineer weeks. For a team with a customer waiting and nobody to spare, that is often the right trade. For a team whose only scarce resource is cash, it usually is not.

Is the real cost of ROS 2 just the learning curve?

Partly, but not the way you think. The learning curve is real and steep, and also finite: people get through it, the tutorials exist, and a team is quicker in its second quarter than its first. The cost that never decays is the one attached to your particular combination of hardware, network and application, because that combination is unique and nobody has debugged it before you. Six months in, a team knows the framework well and still loses days to a sensor that drops out under load, a message that arrives late only while the arm is moving, and a build that works on exactly one laptop. Those are not knowledge problems. They are the price of assembling parts that were never tested together, and experience makes them quicker to diagnose without making them stop. Budget for the curve once and for integration every year. Teams who budget only for the first are the ones who end up feeling deceived. The honest list of complaints is mostly this second category wearing the first one's clothes.

How do you decide whether the cost is worth paying?

Decide by naming your product's difference, because that determines which costs buy you something and which ones you simply pay. Write down the one thing your robot does that a competitor's does not. If the answer involves perceiving, mapping, planning or fitting into somebody else's fleet software, the ecosystem is the point, and the engineer weeks are an entry fee against a far larger saving. If the answer is a loop on one machine — an arm that stops before it hits the table, a balance controller, a machine whose value is that it does not stutter — then most of the ecosystem is weight you carry without ever using. Then check three facts: how many computers your robot has, whether any message crosses Wi-Fi, and whether anybody on the team has run a system unattended for weeks. Those answers move the estimate further than the framework choice does. Whether you need ROS 2 at all is the same question for people who have not started yet.

Decide by situation rather than by principle:

• If you are a solo builder with evenings only -> a vendor toolkit or a single program, because plumbing is what eats evenings.
• If you are a startup whose product is perception -> ROS 2, because the packages are what customers are buying.
• If you are a startup whose product is one control loop -> a lighter middleware, because you would carry an ecosystem you never open.
• If you are a lab handing work to new students yearly -> ROS 2, because tutorials and a hiring pool outvalue a leaner stack.
• If nobody can state your product's difference -> answer that first, because every option looks reasonable until somebody does.

When two of those lines apply at once, weigh the candidates 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. Those are questions about your company rather than scores about software. And if your bill keeps landing in the control loop rather than the package list, star HORUS on GitHub so it is in your list when you start building.