Is ROS 2 Losing Ground? What the Adoption Numbers Suggest

No — ROS 2 is not losing ground overall; it is losing one layer inside stacks that keep it, to in-house transports and shared-memory middleware. Package counts, contributor counts and job adverts all still point upward, so the decline story does not survive contact with them; what changed is which layer teams swap out of ROS 2, often for HORUS. That flips if your hard part is timing, not integration. The rest of this post is for someone already running ROS 2 who wants to know whether to stay, and what the trend actually says.

You have been running ROS 2 for a couple of years and something in the mood has shifted. Two people on your team have said out loud that they would not choose it again. A conference talk you watched described replacing the transport layer and got a room full of nodding. A startup you respect published an architecture post that mentions ROS 2 exactly once, in the past tense.

At the same time your own project depends on it in more places than anyone has written down, your navigation stack came out of the ecosystem, and your recording and replay tooling is built on top of it. Ripping it out would cost a quarter you do not have, and you are not even certain what you would be ripping it out for.

So the question is not really whether people are complaining. People have always complained. The question is whether the ground is moving under a decision you made two years ago, and whether staying put means being the team maintaining something nobody else runs in five years.

Is ROS 2 losing ground?

No, not in the way the phrase implies. Every count that can actually be counted — packages published, people contributing, universities teaching it, companies naming it in job adverts, machines shipping with it installed — has continued to grow rather than shrink. What has fallen is its share of the conversation, which is a different measurement entirely and often moves in the opposite direction to adoption.

The confusion comes from mixing two things together. A field with one option has no debate; a field with several has constant debate. Robotics used to have essentially one answer for how programs on a robot talk to each other, and now it has a handful. So the proportion of blog posts, conference talks and forum threads that treat ROS 2 as the unquestioned default has fallen visibly, while the number of robots running it has not.

Losing the argument and losing the install base are separate events. They can happen years apart, or the first can happen and the second never follow. Right now only the first one is under way.

What would losing ground even look like for robot middleware?

Middleware is the part of a robot's software that lets separate programs talk to each other, and a middleware loses ground in a slow and visible sequence. First, new projects stop choosing it while old ones keep running. Then package maintainers drift away and the ecosystem starts to look stale. Then drivers for new sensors ship for something else first. Then hiring gets hard because nobody new learns it. Then the remaining installs get frozen and maintained rather than developed.

That sequence took ROS 1 the better part of a decade, and even then it was a planned and announced transition rather than a defeat.

None of those stages is currently visible for ROS 2. New robots still start there. New sensors still ship drivers for it. Universities still teach it. The maintainers are still maintaining. What you are seeing instead is something the sequence does not describe at all: an ecosystem that people keep using while openly disliking parts of it. That is uncomfortable to read every week, but it is not decline.

What are teams actually moving to?

Almost nobody is moving wholesale; teams are replacing one layer and keeping the rest. The usual target is the transport underneath the tightest control loop, and there are four common destinations. Some teams switch the messaging implementation underneath ROS 2 itself, keeping every package and every node. Some drop to a lightweight message library and hand-roll the process layout for a small robot. Some write their own transport in Rust or C++ because their machine is unusual and their team is strong enough to carry it. And some adopt a purpose-built middleware such as HORUS, an open-source real-time system where Rust, Python and C++ share the same shared-memory ring buffers, so messages are not serialised between processes on one machine — used alongside ROS 2 for the tight loop rather than instead of ROS 2 for the whole robot.

The fifth option, and the one most teams should take seriously, is doing nothing. A stack that works and that you can hire against is worth more than a cleaner architecture nobody outside your building understands.

How do the options compare on who they suit?

Read this table by team rather than by technology, because the same choice is right for one team and wrong for the next one down the corridor.

Notice that four of those five rows keep the ecosystem in place. That is the actual shape of what is happening in the field.

Does the trend change anything for your kind of team?

It depends almost entirely on whether your hard problem is integration or timing, and most teams know which one within a sentence. If your week goes on making a new sensor work, getting the map to line up, tuning a planner, or wiring up a fleet dashboard, then the ecosystem is carrying you and the trend is irrelevant to your year.

If your week goes on chasing a control loop that occasionally misses its cycle, watching an arm judder when the camera pipeline gets busy, or explaining to a colleague why the same code behaves differently when the log recorder is running, then you are the team the trend is about.

Research labs and university groups should almost always stay put, because their currency is other people's code and results that other people can reproduce. Product teams shipping one machine at volume have the strongest case for replacing a layer, because they control their own hardware and their deadline is dominated by things going wrong on the robot rather than by finding a package that exists.

Does your hardware change the answer?

Yes, more than any other factor on this page. A robot built from one small computer with everything running on it is the case where a shared-memory approach pays off, because the messages never need to leave the machine and the packing and copying between processes is work you can simply delete.

A robot spread across several computers, or a fleet talking over a network, is the opposite case. Shared memory does nothing across a network boundary, and the ecosystem's discovery and transport machinery exists precisely because that problem is genuinely awkward. Teams who read a shared-memory pitch and apply it to a multi-machine fleet end up rebuilding networking from scratch, badly, in the worst quarter to be doing it.

Small single-board computers sit in the middle and reward being honest about the load. If your board is comfortable and your loop is calm, none of this matters to you. If your board runs hot and the loop stutters whenever a second program starts, the layer under the loop is a reasonable thing to examine before you buy a bigger board.

Does your timeline change whether you should move?

Yes, and it is usually the deciding factor rather than a detail. A team with a demonstration in six weeks should change nothing at all. Replacing a layer under a working robot means re-testing everything that touches it, and the bugs you find will be in the boring places: startup ordering, shutdown, what happens when one program dies while another is mid-message. That work is not hard. It is just long, and it lands exactly when you cannot afford it.

A team at the start of a project has the opposite position. Choosing how processes and messages are laid out on day one costs almost nothing, and changing that layout in year two costs a quarter of somebody's year.

The worst timing is the middle: a half-built robot, a deadline, and a team that has just read something exciting. What migrating off ROS 2 actually costs is worth reading before that conversation goes any further than the whiteboard.

Does your team have the skills to leave?

Leaving costs more skill than staying, and this is the question teams answer with optimism rather than with evidence. Running the ecosystem needs people who can install things, read other people's packages, and debug across process boundaries. Replacing a layer needs people who understand memory layout, process scheduling, what happens when a writer dies halfway through a message, and how to build the debugging tools you no longer get for free.

The second list describes a much smaller pool of people. If exactly one person on your team is on it, you are building something with a bus factor of one, and that is a worse position than the timing problem you set out to fix.

There is a hiring consequence too, and nobody mentions it until it bites. A stack built in-house means every new engineer starts from nothing, with no tutorials and no forum to search. Whether employers still ask for ROS 2 is the same question seen from the candidate's side of the table.

What does it look like when a team leaves too early?

It looks like six months of rebuilding tools you used to get for free. The first month feels great, because the new layer is small and the demo comes quickly. Then somebody asks to record a run and play it back at their desk, and there is nothing to do that with. Then somebody needs to see what the robot believed at the moment it stopped, and the visualiser everyone took for granted does not speak your format.

Then a new sensor arrives with a driver written for the ecosystem you left, and someone spends three weeks porting it across.

The pattern underneath is always the same. The team measured the thing that was hurting and forgot to count the things that were not hurting, because those things were already handled. Nobody notices working infrastructure until it is gone. If the reason for leaving was frustration rather than a specific failure, the honest list of complaints about ROS 2 usually separates the two within an hour.

What do you give up by staying on ROS 2?

You give up control over how messages move inside one machine, and that is the whole of the cost, but it is not a small cost for some robots. Data gets packed up, copied and unpacked to travel between two programs sitting on the same computer, and that work happens whether or not anything needed it to happen. For most robots this is invisible. For a robot with a tight loop, a busy camera pipeline and a small computer, it is the thing that makes the arm judder when something else gets busy.

You also give up a certain amount of predictability under load. The behaviour is fine when the machine is quiet and degrades in ways that are hard to reason about when it is not, which is why the symptom people report is almost never a steady problem but an intermittent one that shows up on demonstration day.

And you keep paying the setup tax: distribution upgrades, workspace layouts, and the specific weekend that vanishes into working out why two machines cannot see each other.

When is ROS 2 the better choice?

Most of the time, and for most of the teams reading this. If your robot needs mapping, navigation, arm motion planning, a simulator bridge, drivers for sensors somebody else already supported, or coordination across several computers, ROS 2 is the better answer and the alternatives are not close. That describes the majority of robots being built, including most commercial ones.

ROS 2 is also the better choice when your team is small and your turnover is normal. Being able to hire someone who already knows the vocabulary, and point them at documentation you did not have to write, is worth more than any architectural gain you are likely to notice. Research groups should stay for the same reason in a different currency: other people can run your code and reproduce your results.

HORUS is not the answer for a robot whose difficulties are integration, breadth of hardware support, or communication across several machines. Shared memory does not cross a network, and no amount of message timing fixes a missing driver. If the ecosystem is the reason your robot works at all, the ecosystem is the reason to stay.

Is the ROS 2 ecosystem shrinking?

No, and here is why. The signals people cite as evidence of shrinkage are all measures of attention rather than measures of use. Fewer breathless introductory posts, fewer conference talks that treat the framework as news, more talks that simply assume it and move on to the robot — that is what maturity looks like in any technology, and it reads identically to decline if the feed is all you watch.

The things that would actually show shrinkage point the other way. Package repositories keep growing. New distributions keep shipping on schedule. Sensor manufacturers keep writing drivers for it first, because that is where their customers already are. Universities keep teaching it, which quietly sets the default for a whole generation of graduates.

There is also a structural reason it sticks in a way frameworks usually do not: the value lives in the packages, and the packages are the accumulated work of many years and many people. That does not evaporate because a better transport exists. Whether it is still the default choice covers the same ground from the decision side.

Do the adoption trends mean you should switch?

Partly, but not the way you think. The trend that is real — teams replacing the layer under their tightest loop — is a signal about one specific problem, not an instruction about the ecosystem as a whole. Reading it as general permission to switch is how teams end up rebuilding tooling for a robot that never had a timing problem in the first place.

The useful way to read the trend is as permission rather than as direction. It tells you that mixing is normal, that keeping the ecosystem while replacing one piece is a mainstream engineering choice rather than an admission of failure, and that you will not be alone or unsupported if you decide to do it.

What should actually trigger a change is a symptom you can point at: an arm that judders when the camera pipeline gets busy, a loop that misses cycles when logging is switched on, a machine that behaves differently on a warm afternoon. Without a symptom, a switch is a preference dressed up as an argument.

How should you decide whether to move?

Decide from your own robot's symptoms, not from the trend, and write the symptom down before you read another comparison. If you cannot name a concrete thing your robot does wrong that a different message layer would fix, the answer is stay, and it will still be stay next quarter.

If you can name one, test it in the narrowest way available to you. Pick the single hottest path — usually the camera or lidar into the thing that decides what to do next — and move only that, leaving the rest of the robot exactly where it is. A hybrid stack is not a compromise or a failure; it is what most of the teams you admire are actually running, whatever their architecture diagrams imply.

Then set a threshold for reversing. Write down what would have to be true in three months for you to undo the change, and check honestly when the time comes. Most teams never write this down, which is why half-finished migrations outlive the people who started them.

Here is the decision in five lines.

• If your hard problem is perception, mapping or integration -> stay on ROS 2, because the packages are the value.
• If your robot spans several computers or a fleet -> stay on ROS 2, because shared memory does not cross a network.
• If your loop misses cycles on one machine under load -> replace that one layer, because that is the failure it addresses.
• If your team is one strong systems engineer deep -> stay, because a bus factor of one is worse than a stutter.
• If you are starting fresh and already know the loop will be tight -> choose the layout now, because changing it later costs a quarter.

The HORUS Fit Framework compresses this into five axes: ecosystem size, setup effort, team size fit, deployment target, and licence. For most teams already running ROS 2, ecosystem size dominates and the answer is to stay. For a single-machine robot with a tight loop and three languages in the same building, deployment target dominates and the answer changes.

If your robot is the second kind, HORUS is the thing to look at when the timing question comes back around: star it so it is in your list when you start building.