Short answer: ROS — the Robot Operating System — is not an operating system in the Windows or Linux sense. It is an open-source set of middleware, communication tools and libraries that robot builders use to assemble their software, stewarded by the Open Source Robotics Foundation. Whether a robot "runs ROS" matters less than three buyer questions: who can maintain this software in five years, what interfaces are open to you, and how long the vendor will support the version you are buying.
From ROS 1 to ROS 2: what actually changed
ROS 1 grew out of research labs: excellent tooling, a huge package ecosystem, and design assumptions from its academic origins — a single master node, no built-in security model, and no real-time guarantees. ROS 2 was the ground-up rebuild for products: it replaced the master with a standard industrial middleware layer (DDS), added security, quality-of-service settings for unreliable networks, and support for running on the embedded and real-time systems commercial robots use. The practical marker for buyers: the last ROS 1 release line, Noetic, reached end of life in May 2025, so a new product shipping on ROS 1 today is shipping on an unmaintained base unless the vendor maintains it privately.
What "ROS-based" on a datasheet does and does not tell you
Vendors use the label loosely, and buyers should unpack it. At one end, a product may be built natively on ROS 2: its components are ROS nodes, its interfaces are the standard messages, and your engineers can inspect and extend real parts of the system. At the other end, "ROS compatible" may mean only a bridge — a gateway that republishes a closed product's data in ROS formats for your convenience. Both can be legitimate engineering; they are not the same purchase. The bridge product gives you data access but no maintainability of the underlying behaviour, and the internals remain as closed as any proprietary stack. Ask which of the two you are being offered, which ROS distribution and version it tracks, and who rebases it when the next long-term-support release arrives. The answers predict your year-five options better than the label does.
The case for proprietary stacks
Plenty of excellent robots expose no ROS at all. A vendor's own stack can be more polished, more deterministic and better integrated with its controller and safety system than a general ecosystem, and one throat to choke has real value when a line stops. The risks are symmetrical: your maintenance talent pool is the vendor, your integration surface is what the vendor chooses to document, and your negotiating position at upgrade time is weak. Neither architecture is automatically better. The question is which risks your organisation is set up to carry — which is why the software section of the directory is worth reading alongside any maker's claims: the suppliers there sell the layers around the arm as much as the arm itself.
Maintenance and the talent market
Software outlives hardware programmes. A robot bought this year will need updates, security patches, replacement computers and small behaviour changes for a decade. If its stack is ROS-based, the engineers who understand its foundations work in a large open market, documentation is public, and a second supplier can realistically take over support. If it is proprietary, support quality is a vendor-continuity question: ask what happens to your fleet if the vendor is acquired, pivots or exits the product line. There is no wrong answer — there is only the answer you failed to ask about.
The software questions for the contract
Put these in writing before signing. Which exact software versions ship, and what is the update policy — frequency, cost, and whether updates are ever forced? What interfaces are documented and licensed for your own integration: APIs, data export, log access? What is the stated support horizon for this version, and what notice period applies at end of support? If the vendor holds source code you depend on, is there an escrow or continuity arrangement? And who owns the data the robot generates — the raw material of every future improvement, as our guide to open-source robotics software discusses from the ecosystem side.
Frequently asked questions
Is ROS free?
ROS is open-source software released under permissive licences, so there is no licence fee for ROS itself. The costs sit where they always sit: integration, product engineering, testing and support — whether you pay your own team, an integrator, or a vendor of a supported distribution.
Does a robot that uses ROS work automatically with other ROS robots?
No. ROS standardises how software components communicate, not what a finished product exposes. Two ROS-based robots from different makers may share foundations and still present completely different interfaces to the buyer. Ask what is documented and supported at the product level.
Should I prefer ROS 2 over ROS 1 in a new purchase?
For a new product, yes as a default: ROS 1's final release reached end of life in May 2025. A vendor shipping ROS 1 today should be able to explain its private maintenance plan for that base. What matters most is the vendor's stated support horizon for the exact version you receive.
What is the Open Source Robotics Foundation?
The non-profit steward of the ROS project and related open-source robotics software such as the Gazebo simulator. It maintains the core projects and infrastructure; commercial support for them comes from companies in the ecosystem, not from the foundation itself.