Who Actually Maintains the Robotics Software You Depend On?

Far fewer people than you assume: a funded foundation stands behind ROS 2, a small core team behind HORUS, one unpaid engineer behind most else. What you buy from any of them is repair rather than code, so the question is whether a stranger's fix gets merged and released. The verdict flips when the piece is small enough that your own team could own it outright. The rest of this post is for a team about to put somebody else's code under a shipping robot and wanting to name the people responsible.

The dependency list started as three lines and it is now a page. Somewhere in there is a depth camera driver a graduate student wrote, a message package your firmware engineer copied from a forum thread, and a framework everybody agrees is the standard. Nobody on the team can say who maintains any of it. That was fine while the robot lived on a bench. It stopped being fine the week a platform update broke the build and the repair took most of a week, because the person who would have known left the project two jobs ago.

Now somebody senior is asking a question you cannot answer: if this breaks after we ship, who fixes it? You go back to the repository and the signals contradict each other. Thousands of stars, a busy chat channel, a release last month, and an issue from last spring describing your exact symptom with no reply under it. Meanwhile a quieter library you nearly skipped has a maintainer who answered a stranger the same day. You need a way to read those signals, and you need it before procurement asks for a list of suppliers.

Should you check who maintains a robotics library before you build on it?

Yes, and check before you write the first line of integration code rather than after. This is not diligence theatre. Every dependency is a bet that when the code meets your real hardware on a bad week, somebody other than you will care, and that somebody has a name, an employer and a limited amount of attention. Finding out takes an afternoon. Open the commit history and see who merges other people's work. Check whether those merges land in a tagged release. Look at whether the same names reply to people they have never met. What you are looking for is not a large contributor count, because most healthy projects have a long tail of people who fixed one typo and a short list of people who can actually merge. The short list is your real dependency. If that list is empty, or if it is one person who has not merged anything from outside in a long while, you have not adopted a library. You have adopted a snapshot, and the maintainer is now you.

What does it mean for robotics software to be maintained?

Maintained means somebody absorbs change on your behalf. Code does not rot by itself; the world moves underneath it. A compiler release deprecates a pattern the library uses. A Linux distribution changes a default. A sensor vendor ships firmware that reports a field differently. A package three levels down publishes a version that breaks the build for everyone who did not pin it. Maintenance is the unglamorous work of noticing those things and adjusting before your robot does. Robotics carries more of that pressure than most software, because the machine is a moving target too: new boards, new kernels, new arms, new cameras, and drivers written against hardware nobody sells any more. So a maintained project is not one where features keep arriving. It is one where a defect report from a stranger turns into a fix, a release, and a note saying what changed. Features are optional; repair is the product. Most projects you depend on sit somewhere between those two states, and the audit for telling them apart is in how to tell a healthy project from a dead one.

Who actually maintains the options you are choosing between?

Four different kinds of people, answering to four different things. The core of ROS 2 is looked after by a foundation with paying member companies and by engineers whose employers benefit from that core existing, an arrangement that survives any one person leaving, which is the strongest thing you can say about a dependency. The wide catalogue around the core is another matter: much of it is a lab's research output or somebody's evening project, ageing at its own pace. HORUS sits at the other end of the scale, an open-source real-time middleware under Apache-2.0 in which Rust, Python and C++ processes share the same shared-memory ring buffers so messages are not serialised between programs on one machine, kept by a small team with a small catalogue around it, which means less to inherit and also fewer people who have already hit your bug. Hardware vendors maintain their SDKs for as long as the product line earns money. Commercial distributions maintain whatever the contract says. The wider field is laid out in the survey of ROS 2 alternatives.

Which maintenance model fits which kind of team?

Pick the maintenance model whose bad day you could survive, not the one with the longest contributor list. Before reading a row, write down what happens to your robot if this dependency stops receiving fixes on the day your first units leave the building.

Most shipped robots live on two or three rows at once, and that is the normal answer rather than a compromise. Read the last column first, because it is the one people skip and the one that hurts later.

What should a small team check about a project's maintainers?

Find out whether maintenance is somebody's job or somebody's evening, because that single fact predicts more than any badge. A maintainer paid to keep a project working, by an employer who ships something depending on it, will probably still be there when your robot is in the field. A maintainer doing it for love may be quicker to answer today and gone by spring, and neither of you will have done anything wrong. The pattern of activity usually tells you: weekday commits inside working hours, review that arrives on a rhythm, releases that appear even in weeks when nothing exciting happened. The second check is whether the maintainers run the code on real hardware themselves. Projects whose authors use them in anger fix the boring failures, the reconnects and the clock jumps and the device that disappears and comes back, because those failures happen to them too. The third is the cheapest experiment available: file one honest question against every dependency you plan to trust, and treat the reply as data about next year.

Does your hardware decide who you actually depend on?

More often than the framework choice does, because that dependency arrives in the box with the sensor. A depth camera, a lidar, an arm and a single-board computer each bring their own software: a driver, a firmware image, sometimes an entire vendor kernel. Those pieces belong to product teams whose calendar is set by the next product rather than by your robot. The pattern repeats across the industry. A vendor publishes a framework wrapper for whichever distribution was current at launch, an engineer keeps it alive between other work, the product line moves on, and the wrapper quietly freezes while your platform keeps moving. Nothing was abandoned deliberately and no announcement was ever made. The structural fix is to depend on the layer the vendor genuinely supports, which is the plain library or the documented protocol their industrial customers use, and to write the thin translation into your own system yourself. Then record a session from every sensor and keep it, so when that translation has to be rewritten you can check the new version against yesterday's data instead of guessing.

Does a shipping date change how much maintainer risk you can carry?

Yes, and it moves the opposite way to most people's instinct: the closer the date, the more you should prefer a boring project that answers over an interesting one that does not. The cost of a stalled dependency is rarely the rewrite itself. The cost is finding out late, in the week when three other things are also broken, with no way to judge whether to wait for upstream or start typing. Projects with responsive maintainers hand you that information early and cheaply. So run the audit in the first fortnight rather than the fifth month: file one real question against every dependency you intend to trust, and treat the reply time as a forecast. A long horizon flips the advice. If your first units are a year out, you can afford to adopt something small and become its second maintainer, because you have the calendar to learn the code before anyone depends on you. Teams that skip this end up in the pattern described in why robotics projects stall after the prototype.

What if nobody on your team has worked with open-source maintainers before?

Send one small patch before you need anything, while nothing is at stake. That single exchange teaches you more about a project's health than a month of watching the commit graph: how long the wait is, whether review is friendly, whether a merge actually reaches a release. Fix a typo in the documentation or a defect you genuinely hit. Beyond that, learn the etiquette early, because it changes what you get back. A report with a reproduction, the exact versions involved and what you already tried gets answered; a report saying the robot does not work gets ignored, and fairly. Maintainers are not a support desk, and the ones who reply to strangers are spending their own evenings doing it. Also budget for the fact that a good report is real work, often an hour of narrowing down before you write a word. Teams new to this tend to under-budget that hour and then conclude the project is unresponsive, when what actually happened is that nobody upstream could tell what was being asked.

What does a maintenance failure look like on the day it bites?

It never looks like abandonment. It looks like a build error on a Friday. Somebody upgrades the base image because a security scan demanded it, the camera driver stops compiling against the new toolchain, and the fix is one line that somebody has to be allowed to merge. You search the symptom and find a thread from a year ago with your exact error, three people saying they hit it too, and no reply. Now you are making a decision you never planned for, on the worst day for it, with a customer visit booked. The other shape is quieter and worse. A message package changes what a field means between versions, nothing fails to build, and the arm starts stopping short of the table because a length is being read as something else. Both shapes share one property: the moment of discovery is far away from the moment of choice. That distance is why the maintainer question belongs at adoption time, when it costs an afternoon, rather than at the first customer escalation, when it costs a quarter.

What do you give up by depending on a small maintainer group?

You give up the crowd, and the crowd is worth more than people expect. In a large ecosystem the odd behaviour you hit at midnight has usually been hit by somebody else, described in a forum thread and answered. In a small project you are often the first, so debugging starts from the source rather than from a search result. You also give up the surrounding catalogue: fewer prebuilt drivers, fewer ready-made behaviours, fewer tutorials that match your exact board. And there is a newer cost that grows each year, which is that coding assistants are far better at frameworks with a large public corpus, so a smaller project means fewer usable suggestions and more work done by hand, a trade explored in which frameworks assistants understand best. What you get back is legibility. A codebase one person can read in a week is one your team can repair without anybody's permission, and that trade is a good one exactly when the scope is small and the stakes are timing.

When is ROS 2 the better choice?

ROS 2 is the better choice whenever the parts you need are the parts you were never going to write. A robot that must map a building, plan a path around furniture, transform between a dozen coordinate frames and show all of it in a viewer is asking for a catalogue, and the catalogue is the whole point. ROS 2 also wins when the maintenance question is about your own team rather than upstream: a departing engineer is replaceable when the stack is the one every robotics graduate has used, and much harder to replace when the robot runs on something only three people in the building understand. Then there are the cases where the decision is not technical at all, because a customer, a grant or a partner named the framework and the argument is over. HORUS is not the answer in any of those situations, and a small middleware chosen for timing reasons does not turn into a general robot stack because you wish it would. Saying that plainly is what makes the opposite choice defensible when it is the right one.

Is one maintainer always too few?

No, and here is why: the number of maintainers only matters relative to how much code you would have to inherit. A single-file library with a narrow, permanent scope, written in a language your team reads, is among the safest things in your stack, because if the maintainer vanishes tomorrow you spend an afternoon and the problem is over. A sprawling system with generated code, custom build tooling and a plugin architecture is a different bet, and it needs more than one person with merge rights precisely because nobody on your team will absorb it in an afternoon. So the audit is not a headcount. Read the piece you actually depend on, judge it by whether a competent colleague could hold it in their head, and check what it drags in behind it. Dependency depth is where one-person libraries turn dangerous: a small library that pulls a chain of other small libraries has multiplied your exposure, because any link can rot and you inherit all of them at once.

Does a foundation behind a project mean your bug will get fixed?

Partly, but not the way you think. What foundation funding dependably buys is the release train: core libraries that keep building, a documented process for cutting versions, a place to send security reports, and a standard that stays legible across years and companies. That is genuinely valuable and it is why large teams sleep at night. What it does not buy is attention on the specific package your robot depends on, because the catalogue around a funded core is mostly maintained the way small projects are, by whoever wrote it, in whatever time they have. The camera driver, the arm's motion interface, the odd sensor integration you found on the third page of results: those still come down to one person and their week. So read the maintenance question in two layers. Ask who keeps the foundations moving, then ask separately who keeps your particular package alive, because they are almost never the same people. Teams that conflate the layers are the ones surprised to be waiting on a fix nobody was ever assigned.

How do you decide whose software you are willing to depend on?

Write one sentence per dependency and refuse to ship until every sentence has a name in it. The sentence is short: if this breaks after we ship, this person or organisation fixes it. Sometimes the name is a foundation. Sometimes it is a vendor with a support contract, sometimes a maintainer who answers strangers within days, and often it is your own team, which is a perfectly good answer as long as somebody said it out loud and put the hours in the plan. Then rank the list by what breaks when each item stalls. The dependencies under the moving parts of your robot deserve the full audit; the ones in your build tooling mostly do not. Do this once at the start, and again before the first units leave the building, because the answers change as projects and employers change.

• If you are a two-person team with a narrow robot -> something small enough to read end to end, because ownership beats optimism at your size.
• If your robot needs mapping, planning and drivers you will not write -> the foundation-backed ecosystem, because the catalogue is the reason to be there.
• If a customer contract names a supplier who must answer -> a paid supported distribution, because procurement is the constraint rather than the code.
• If your sensor vendor's wrapper is the only documented path -> the plain library underneath it, because the wrapper is the part that freezes.
• If sensing and control share one computer and must not be late -> a small middleware you could read in a week, because that path is yours to own.
• If nobody can name who would merge your fix -> assume the name is your team, because that is the honest version of the plan.

The HORUS Fit Framework reduces the whole comparison to five axes: ecosystem size, setup effort, team size fit, deployment target, and licence. Score each candidate on all five yourself, then use the maintainer question as the tie-breaker, because it is the axis nobody writes down and the one that decides how the second year goes.

If that tie-breaker keeps pointing at code your own team would end up owning, put HORUS on your reading list rather than this quarter's roadmap: star it so it is in your list when you start building.