How to Tell a Healthy Open-Source Robotics Project From a Dead One

Judge an open-source robotics project by its maintenance habits, not its size: a newcomer like HORUS and a giant like ROS 2 face the same audit. Health shows in whether issues get answered, whether releases still happen, and whether more than one person can merge a fix. The verdict flips when you need only one small piece, because a frozen repository you can read end to end is safe enough. The rest of this post is for a team about to bet a product year on someone else's repository and wanting a defensible reason for the choice.

You found the repository three weeks ago and you still cannot tell what you are looking at. The README is confident. The last release was a while back, or maybe that is just how this maintainer numbers things. There are open issues from last year with no reply, and a pinned one promising a rewrite that has not arrived. Somebody on your team says the project is obviously abandoned. Somebody else points out that half your industry runs on packages whose last commit predates the pandemic, and nothing has caught fire yet.

Meanwhile the decision will not wait. Hardware is arriving, a demo is booked, and your design already assumes this library exists. If the project is alive, adopting it saves you a quarter of work you were dreading. If the project is dead, you are the maintainer now and nobody told you. The signals contradict each other too: thousands of stars and no answered questions, or a quiet repository whose author replies to strangers within a day. What you want is a test that survives contact with a real project, rather than a feeling you got from scrolling the commit graph on a Friday afternoon.

Should you build a product on this open-source project or walk away?

Build on the project when you can name the person who would merge your fix, and walk away when you cannot. That sounds glib, and it is the entire decision. What you buy from an open-source dependency is never the code sitting there today, because the code is already yours to copy. You buy repair: the reasonable expectation that when your robot meets a defect in the depth camera driver the week before a customer visit, something happens other than you rewriting a subsystem at midnight. So ask the question in that shape. If you filed a clear report with a reproduction this afternoon, who reads it? If you sent a small and obviously correct patch, who has the rights to merge, and have they merged anyone else's work lately? If both answers are nobody, the project is a snapshot rather than a dependency, and you should treat the code as something you now own outright. Plenty of good teams ship on snapshots deliberately. The expensive mistake is shipping on one while believing somebody else is on call.

What does a healthy open-source project actually look like?

A healthy project is one where a stranger's reasonable bug report changes something within a release or two. Health is not busyness. A repository with commits every day can be a project thrashing through a rewrite that will break your build twice a month, while a repository with a handful of commits a year can be finished work maintained by someone who still answers email. Four signals carry most of the weight. Someone responds to outside reports, even if the response is a polite no. Releases still come out and say what changed. More than one human has merge rights and has used them. And the project declines things, which sounds negative but means somebody is defending a scope rather than accepting whatever arrives. Notice that none of those are numbers on a badge. The reason this matters commercially rather than aesthetically is covered in the honest version of whether open-source robotics software is safe to ship, and the short answer is that ownership, not licence text, decides your exposure.

What are your actual options when a dependency looks half-alive?

You have five options, and only two of them involve the original project continuing. You can adopt as is and quietly accept that you are the maintainer. You can vendor a copy into your own tree so nothing changes under you. You can fork publicly and take on the role in the open. You can replace the dependency with something else. Or you can write the piece yourself, which is more common than people admit for small libraries. Replacement is where the real choosing happens, and the field is narrower than search results suggest: a large ecosystem such as ROS 2, where the package you doubt usually has competitors and a foundation maintaining the core; a focused newer project such as HORUS, which is real-time middleware where Rust, Python and C++ processes share the same shared-memory ring buffers so messages are not serialised between programs on one machine, released under Apache-2.0 with a smaller catalogue around it; the SDK your hardware vendor ships; or a supported commercial distribution. The wider field is laid out in the survey of ROS 2 alternatives.

Which kind of project should you trust with a shipping robot?

Trust the kind of project whose failure mode you could survive on a bad week, which is a different question from which project is best. Before reading a row, write down what happens to your robot if this dependency stops receiving fixes on the day your first units go out. If the answer is a shrug, almost anything works. If the answer is a recall, your options narrow sharply.

Two rows is a normal answer. Most shipped robots trust a big ecosystem for the outside of the machine and something small and owned for the part that must not be late. Read the last column first, because it is the one people skip and the one that later hurts. Notice also that the rows are not ranked by health. A single-maintainer package can be the safest thing in your stack when the scope is small enough that you could rewrite the whole file on a bad Tuesday, while a busy ecosystem can be the riskiest when you depend on the one corner of it nobody has touched in years.

What should a two-person team check before adopting a project?

A two-person team should check one thing: whether they could survive the project going quiet tomorrow. Everything else is decoration at your size. Practically, that means opening the source and reading it, not skimming the README. If the piece you depend on is a few thousand lines you could follow on a train journey, adopt it cheerfully, because the worst case is a weekend of study. If the piece is a sprawling system with generated code, custom build tooling and a plugin architecture, then adopting it means betting that its maintainers stay interested, and you should want evidence rather than optimism. The second check is dependency depth. A small library that pulls in a chain of other small libraries has multiplied your exposure, because any one of them can rot and you inherit all of them. The third is exit cost: how much of your own code would change if you swapped this out in a year? Keep the answer small by putting your own thin boundary in front of anything you are unsure about.

What if your robot depends on one vendor's driver package?

Vendor driver packages are the most common dead dependency in robotics, so plan for the package to stop rather than hoping it will not. The pattern repeats across the industry. A sensor maker ships a wrapper for the framework version that was current when the product launched, an engineer maintains the wrapper in gaps between other work, the product line moves on, and the wrapper freezes against an old distribution while your platform moves forward. Nothing was abandoned maliciously and nobody announced anything. The way out is structural. Underneath almost every framework wrapper there is a plain library or a documented protocol the vendor actually supports, because that is what their industrial customers use. Depend on that layer, write the thin translation yourself, and the wrapper becomes a convenience rather than a load-bearing wall. Then keep one recorded session from every sensor, so when you rewrite the translation you can check the new version against yesterday's data instead of guessing. This is also why teams end up outgrowing the first framework they chose without ever making a decision to leave.

What if you have to ship something in six months?

With a shipping date that close, prefer the boring answered project over the exciting quiet one, every time. A short calendar changes the arithmetic completely, because the cost of an abandoned dependency is rarely the rewrite itself. The cost is discovering the problem late, in the week when three other things are also broken, and having no idea whether to wait for upstream or start writing. Projects that answer strangers give you that information early and cheaply. So do your audit in the first fortnight, not the fifth month: file one real question against every dependency you plan to trust, and treat the response time as data. A project that answers within days is telling you something true about the year ahead. A project that never answers has also told you, and you can still adopt it, only now with your eyes open and a line in the plan for owning the code. Teams that skip this step are the ones described in why robotics projects stall after the prototype, where nothing dramatic broke and yet nothing shipped.

What if nobody on your team has maintained open-source code before?

Favour projects that have written down how contributions work, because that writing is the cheapest signal you can read without experience. A contributing guide, a template for reports, tagged releases with notes, and a visible history of outside patches getting merged together tell you that somebody has thought about strangers. Their absence does not condemn a project, but it does mean you will be learning two things at once. The second piece of advice is to make your first contribution tiny and early, before you depend on the project for anything. Fix a typo in the documentation, or a small defect you actually hit. You will learn more about the project's health in that one exchange than from a month of watching the commit graph: how long the wait is, whether review is friendly, whether a merge actually lands in a release. Doing that while nothing is at stake is a rehearsal. Doing it for the first time when your robot is broken and a customer is waiting is not.

What does a dying project look like before anyone admits it?

A dying project looks busy on the surface and stops answering underneath, and the sequence is remarkably consistent. First the maintainer stops replying to questions but keeps merging their own commits, so activity charts look fine. Then a large rewrite is announced, usually on a branch, usually with an ambitious scope, and normal fixes stop landing on the main line because they will be obsolete soon. Then outside patches begin to sit for months, and the people who sent them quietly maintain private forks instead. Then the release notes get thinner and eventually stop. Then documentation drifts out of date, and the community's real answers migrate to a chat channel where nothing is searchable. By the time the repository is formally archived, everyone who depended on it moved a year earlier, and the archive notice surprises only newcomers. What makes this hard to spot from outside is that each step is individually reasonable. The signal is not any single one of them, it is the direction: fewer conversations with strangers, month after month.

What do you give up by choosing the biggest project available?

You give up speed, control of your schedule, and any say in scope. Large projects are healthy in the way that large institutions are healthy: they will outlive their current staff, and they move at the pace of a committee. Your reasonable improvement can take several release cycles to arrive, and the feature you need may be declined on grounds that are correct for everyone except you. You inherit a support window and a platform pairing that were decided without you, which means your upgrade plans get written by someone else's calendar. You also inherit surface area, because a large ecosystem installs far more than you asked for, and every part of it is something a security team will eventually ask you about. None of this is an argument against picking the big one. For most robots the trade is obviously worth it, since what you receive is years of other people's careful work. But teams who choose the biggest option expecting to move quickly inside it are surprised, and the surprise usually arrives in month four.

When is ROS 2 the better choice?

ROS 2 is the better choice whenever the health audit itself is the deciding factor, and that happens more often than newcomers expect. Concretely: you need the project to outlast the people currently working on it, and a foundation with governance, a release calendar and multiple maintaining organisations is exactly that promise. You are hiring, and candidates already know the vocabulary and the tools. You need drivers for hardware from several vendors, and those vendors publish wrappers for one framework and no other. You need mapping, planning or arm motion that someone spent a decade getting right. You are reproducing published work that arrives as packages. Or your buyer's procurement process asks who maintains your stack, and a recognised answer shortens the conversation by months. In all of those cases HORUS is not the answer, and neither is a small library you found last week, because you would be trading the exact thing you came for. Pick the biggest healthy option when breadth and continuity are what you need, and spend your own scarce attention elsewhere.

Does a repository with no recent commits mean the project is dead?

No, and here is why. Software can be finished. A library that parses one message format, converts between two coordinate conventions, or speaks one motor protocol has a scope that can genuinely be completed, and after completion the honest commit rate is near zero. Punishing that project for silence pushes you towards a busier alternative that is still churning precisely because it has not settled. The test that separates finished from dead is not commit frequency, it is response to contact. Open the issue tracker and read the most recent exchanges rather than counting them. Are questions answered, even briefly? Are reported defects acknowledged, even when the answer is that they will not be fixed? Does the maintainer say no to features with a reason? A finished project answers and rarely commits. A dead project neither answers nor commits, and the giveaway is a tracker where the last several entries are strangers talking to themselves. Check whether the code still builds against a current platform, too, since that is what silence eventually costs you.

Is a company behind a project proof that the project will survive?

Partly, but not the way you think. Corporate backing buys you paid maintainers, predictable releases, documentation someone was assigned to write, and a security contact who answers. Those are real and worth a lot. What corporate backing does not buy is a guarantee of continuity, because company projects are cancelled by reorganisation more abruptly than community projects fade, and the cancellation is decided by people who have never heard of your robot. The useful question is not whether a company is involved but why. A project that is load-bearing inside the company's own product has a strong reason to keep existing. A project published as a hiring signal or a strategic gesture has a weak one. Check whether outside contributions are accepted at all, since a repository that only takes commits from employee accounts is a published mirror rather than a community, and a mirror is exactly what disappears when priorities change. Backing plus an active outside contributor base is the combination that survives; either one alone is thinner than the logo suggests.

How do you decide whether to adopt a project this week?

Decide with three probes, run this week, before your design hardens. Probe one: file a real question or a small patch against every dependency you plan to trust, and note who answers and how fast. Probe two: read the code you would depend on, and time how long it takes to understand the part you would have to fix. Probe three: try to build the current release against the platform your robot will actually run, not the one on your laptop, since dependency rot shows up as a build failure long before it shows up as a bug. Then write one sentence per dependency saying what you would do if it froze tomorrow, and give each sentence an owner's name. Anything without a plausible sentence is not a decision you have made, it is a risk you have accepted by accident. The point of the exercise is not to eliminate dead code from your stack. It is to know exactly which parts of your robot you quietly own.

Take the line that matches you:

• If you are two people with a shipping date -> the boring project that answers strangers, because surprise ownership is what kills small teams.
• If you depend on one vendor's wrapper -> the plain library underneath it, because wrappers freeze and protocols do not.
• If you need the stack to outlive its maintainers -> the large governed ecosystem, because continuity is what you came for.
• If the piece is small enough to read in an afternoon -> adopt or fork it without anxiety, because you can own it if you must.
• If nobody can say what happens when the project freezes -> answer that first, because the answer changes the design.

The HORUS Fit Framework is the checklist under those lines, and none of its five axes is a number: ecosystem size, setup effort, team size fit, deployment target, and licence. Score every candidate on all five, and the axis you cannot compromise on decides.

Health is a habit rather than a headline, and the audit above takes an afternoon rather than a quarter. If your robot's innermost loop turns out to be the part you want to own outright, with Rust, Python and C++ sharing the same ring buffers on one machine instead of serialising to each other, HORUS is open source under Apache-2.0. Star it so it is in your list when you start building.