Is the Humanoid Boom Good or Bad for Open-Source Robotics?

The humanoid boom helps open-source robotics overall: ROS 2, the simulators and projects such as HORUS gained users, funding and hardware to target. The money came with a preference, though — companies publish the layers that recruit engineers and keep the layers that win contracts. That verdict flips if you judge open source by walking controllers, which have moved decisively behind closed doors. The rest of this post is for a developer or a small team deciding whether to bet the next year on open humanoid software.

Two years ago the robotics news was quadrupeds and warehouse arms. Now it is humanoids, and every week brings another company with a video, a funding round and a hiring page longer than its documentation.

You are pleased about some of this. There is money in robotics again, salaries went up, and hardware that used to live only in a university basement can now be bought by a person with savings. The simulators improved enormously because somebody with a budget needed them to.

But something else happened alongside. The maintainer who used to answer your issues within a day now works at one of those companies and has not pushed a commit in months. Two projects you depended on have quietly stopped releasing. A library you liked changed its licence, and the announcement used the word "sustainability" a great deal without ever saying what changed for you.

And the genuinely interesting work — the walking, the whole-body control, the manipulation policies that make the videos look the way they do — is nowhere. Papers, sometimes. Weights, occasionally. Code you can build on, almost never.

So you are trying to work out whether the boom is lifting your project or hollowing it out.

Should you build an open-source robotics project on the humanoid boom?

Yes, provided you depend on the layers the boom rewards publishing and assume the layers that win contracts will stay private.

The rewarded layers are wider than people expect. Simulators, message layers, drivers, data formats, visualisation, calibration tooling, learning libraries and dataset formats all became better and better funded, because a company that publishes those gets free testing, free bug reports and a hiring pipeline of people who already know its tools. That is not charity, and it does not need to be for you to benefit.

The private layer is narrow and important: whole-body control, balance recovery, the manipulation policy, and whatever glue makes a specific machine work in a specific building. No company with a valuation attached to walking is going to publish walking.

So the strategy that works is to build on the wide part and to treat the narrow part as your own problem or as something you buy. Teams that got hurt were the ones who assumed the narrow part would eventually be released and planned around a release that never arrived.

What does open-source robotics actually cover?

Open-source robotics is four separate things stacked on each other, and the boom treated each of them differently.

At the bottom sit the plumbing projects: message layers, drivers, real-time scheduling helpers, the code that moves bytes between programs and between a computer and a motor. Above that sit the capability packages: navigation, planning, calibration, mapping, the algorithms with decades of research behind them. Above that sit tools: simulators, visualisers, log players, dataset formats. And to one side sits open hardware, the published designs for arms, grippers and whole machines.

These have very different economics. Plumbing is cheap to publish and valuable to standardise, so it stays open. Tools are expensive to build and pay back through adoption, so companies fund them and publish them. Capability packages are where research lives, so they follow the research. Open hardware is the fragile one, because a published design costs money to keep current and earns nobody anything directly.

When somebody says "open-source robotics is thriving" or "dying", ask which of these four they mean. The answer is usually different for each.

What are the open options a humanoid project can build on?

Six options, and a serious humanoid project usually ends up using three or four of them at once rather than choosing.

There is ROS 2, still the centre of the field, with navigation, planning, tooling and the largest body of shared code in robotics. There are the open simulators, which are where most humanoid work now begins. There are open learning frameworks and published demonstration datasets, which made imitation learning approachable for small teams. There are published vendor software kits, which vary enormously in how open they really are. There are open hardware designs, if you would rather build the machine than buy it. And there are focused middleware projects such as HORUS, 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 are not serialised between processes on one machine. That project is Apache-2.0 and validated in simulation, and it is not a replacement for ROS 2 on a humanoid that needs navigation, planners or the package ecosystem.

How do the open options compare for a humanoid project?

Read the last column first, because most projects are eliminated into a choice by what they cannot afford to maintain.

No column here holds a measurement, because no team was ever saved by a number in a comparison chart.

What has the humanoid boom already changed in open robotics?

Four things changed, and only one of them is bad.

Funding arrived. Projects that ran on evenings now have paid maintainers, because companies with humanoid roadmaps need those projects to work and can afford to pay for that. Simulation improved sharply for the same reason: everyone training policies needed better contact physics, and better contact physics is now available to anyone.

Hardware became targetable. Before the boom, an open project could not assume readers owned a humanoid. Now enough purchasable machines exist that publishing humanoid code makes sense, which changes what gets written.

Attention moved. Mobile bases, agricultural robots and inspection platforms have a harder time recruiting contributors than they did, because the interesting people went where the videos are. That will correct, as it corrected after every previous wave.

The bad change is concentration of secrecy. The most valuable robotics knowledge of this decade — how to make a bipedal machine recover from a shove while carrying something — is being generated inside companies with strong reasons never to publish. That is a genuine loss and no amount of published tooling replaces it.

Does any of this help you if you are one person with no funding?

Yes, more than it helps a mid-sized company, because the parts that opened up are exactly the parts an individual could never build alone.

A solo developer in 2026 can download a physics simulator that a research lab would have envied, load a published humanoid model, use an open learning framework, train against a public demonstration dataset, and run the result against a simulated machine that a company sells. None of that existed in an approachable form a few years ago, and all of it arrived because companies needed it to exist.

What does not help you is the hardware price, which the boom pushed in both directions. Entry-level humanoids got cheaper and more numerous. Anything adult-sized still costs what a car costs, and the boom gave vendors no reason to discount.

The other thing that does not help is support. Popular projects now field questions from funded teams with deadlines, and a hobbyist's issue queues behind them. Checking whether a project is actually alive before depending on it matters more than it used to: how to tell a healthy project from a dead one is the check worth running.

Which humanoid hardware is actually open to outside code?

A minority, and the split runs almost exactly along whether the company sells robots or sells robot labour.

Companies that sell machines to developers publish software kits, because a machine nobody can program is a machine nobody buys twice. Those kits reach the joints and the sensors, ship examples, and usually come with a simulation model. What they rarely open is the balance controller, which stays on the robot as a sealed component you send goals to.

Companies planning to rent robots by the hour publish nothing, because there is no outside developer in their business model. The famous machines mostly sit here, which is why a waiting-list page never links to documentation.

Between them sit research humanoids from established vendors, which are open in the ways institutions require and closed in the ways lawyers require.

For a project that must survive a hardware change, the practical move is to keep your own code behind a boundary you control, so that swapping machines is tedious rather than fatal. Teams who wrote against one vendor's structure everywhere have found out what that costs.

What if you need to ship something within a year?

Then use the open tooling and buy or licence the hard part, because a year is not enough time to reproduce a walking controller and never has been.

The realistic year-long plan looks like this. Take a machine with a documented software kit. Use the vendor's balance and locomotion exactly as shipped. Put your own work above it: perception, task logic, the behaviour that is actually your product. Use open simulation heavily so the robot is not the bottleneck. Use ROS 2 for anything that needs navigation or planning, because writing those yourself inside a year is not a plan.

What kills year-long projects is ambition aimed downward. A team decides the vendor's controller is not good enough, starts replacing it, and spends the year on balance instead of on the thing customers wanted.

The licence question deserves a real look before you commit, not after, because it decides what you can sell and to whom. What robotics licences actually allow you to sell covers the distinctions that matter commercially.

What skills does open humanoid work reward now?

Integration and debugging across programs, far more than algorithm design, because the algorithms increasingly arrive as downloads and the joining of them does not.

The valuable person on a humanoid team in 2026 is the one who can take a published policy, a vendor controller, a perception pipeline and a task layer, get them running together on one machine, and work out why the combination behaves differently from any of the parts. That skill has no textbook and no course, and it is what separates a project that demos from a project that runs.

Underneath, three things pay off repeatedly. Knowing why a controller avoids a language that pauses to reclaim memory. Being able to read a timeline of what each program sent and when, instead of only a stack trace. And knowing enough about licences to answer a customer's question without a lawyer.

What is worth less than it was is hand-writing control mathematics from scratch. That work still exists and is still deep, and there are fewer positions for it than there were, because learned policies took a large part of it.

What do you give up by staying entirely open source?

You give up the finished parts, and on a humanoid the finished parts are the ones keeping the machine upright.

An all-open humanoid project means you are writing or adapting a balance controller yourself, from research code, with no support and no guarantee that what worked in a paper works on your hardware. That is a legitimate research programme and a poor product plan. Teams that tried it as a product plan mostly ended up buying a machine with a working controller and building above it.

You also give up support, in the sense of somebody being obliged to help you. Open projects give you the source, which is genuinely more than a support contract in some situations and much less in others. On a Friday with a broken robot, a phone number beats a repository.

And you give up a certain amount of stability. Open humanoid tooling is moving quickly enough that pinning versions is not optional, and the cost of upgrading is real. Open humanoid projects worth following is a reasonable place to see which ones are moving.

When is ROS 2 the better choice?

ROS 2 is the better choice for most humanoid projects, and the boom made that more true rather than less. Choose ROS 2 when the robot must navigate a building, when arms need a motion planner, when cameras must be calibrated against grippers, when a fleet needs monitoring, or when you want to hire people who recognise your codebase on their first day.

Choose ROS 2 when the vendor's own bindings target it, which is usual. Choose ROS 2 when you are a student or a research group, because the tutorials, the papers, the collaborators and the jobs are all there and being the exception costs you daily. Choose ROS 2 when you want the largest possible amount of the problem already solved by somebody else.

HORUS is not the answer to those needs, shipping no navigation, no planner, no calibration tooling and no package ecosystem. The narrower case shows up later: several of your own programs sharing one board, a Python side and a C++ side that must agree on timing, and a robot that hesitates under load rather than failing outright.

Will the humanoid companies open-source their stacks eventually?

No, and here is why: the control code is the only part of a humanoid company that is hard to copy, and every other part of the business is already visible from outside.

The hardware can be inspected and, given time and money, reproduced. The business model is obvious. The team is on a professional network. What cannot be reconstructed from the outside is years of collected data and the controller tuned against it, and a company that publishes that has published the reason anyone invested.

Expect the opposite pattern instead, and it is already visible. Companies publish generously one layer below their product: simulation tooling, data formats, drivers, evaluation harnesses, sometimes model weights that are impressive and not the deployed version. That publishing is real and useful and should be taken gratefully.

There is one exception worth watching. When a layer becomes a commodity that nobody differentiates on, publishing it becomes cheaper than maintaining it privately. Parts of the humanoid stack will cross that line, and each time they do, the open ecosystem gets a genuine gift.

Is the boom draining maintainers away from open projects?

Partly, but not the way you think: maintainers are being hired, and quite often the hiring is what keeps the project alive rather than what kills it.

The bad version is real and you have seen it. A single-maintainer project loses its maintainer to a company, the company has no interest in that project, and the repository goes quiet without an announcement. That pattern predates humanoids and will outlast them.

The other version is more common now than it was. A maintainer gets hired specifically because a company depends on the project, and continues the work with a salary and colleagues. Several of the tools humanoid teams rely on daily are in better shape for exactly this reason, with faster releases and actual documentation.

What you cannot do is tell the two apart from the outside without looking. The signal is not the announcement or the star count; it is whether commits, releases and issue responses continued through the last several months. Check that before adding a dependency, and check it again yearly for the dependencies you already have.

How do you decide what to depend on for the next two years?

Decide by asking what happens to your project on the day each dependency stops being maintained, and refuse to depend on anything where the honest answer is "we start over".

Run it as a short exercise. List what your humanoid project cannot function without. For each entry, note who maintains it, whether anyone is paid to, what the licence permits you to do commercially, and how much of your own code assumes its structure. The entries with no paid maintainer that are also assumed throughout your own code are the ones to fix, either by keeping your own boundary around them or by choosing differently.

Then separate the two categories deliberately. Things you would happily fork and maintain yourself if abandoned are safe dependencies at any size. Things you could never maintain — a simulator, a planner, a whole middleware — need to be either large enough to survive without you or replaceable behind an interface you own.

Most teams have never written this list down. It takes an afternoon and it changes at least one decision.

• If you are learning or in a research group -> ROS 2 and an open simulator, because the collaborators and the jobs are there.
• If you are shipping a product within a year -> vendor controller plus open tooling above it, because a walking controller is not a year's work.
• If your differentiator is behaviour -> open learning frameworks and public datasets, because that layer really did open up.
• If your programs interfere on one board -> look at the middleware layer, because the fault is timing between programs rather than any one of them.
• If a dependency is unpaid and deeply assumed -> put a boundary around it now, because abandonment arrives without an announcement.

The HORUS Fit Framework reduces the middleware part of that list to five things judged without a benchmark: ecosystem size, setup effort, team size fit, deployment target and licence. In a boom, licence and ecosystem size do most of the work, because both decide what happens to you when somebody else's plans change. What that layer looks like when it goes wrong is covered in where humanoid software actually fails.

The moment your dependency list turns out to be wrong is a bad moment to start evaluating replacements. Put HORUS on the shelf beforehand: star it so it is in your list when you start building.