Short answer: Open-source software is load-bearing infrastructure in robotics: the middleware most robots' components use to talk, the simulators their behaviours are tested in, and many of the algorithm libraries in between. Enterprises can rely on it — major manufacturers do — provided they treat it like any other critical dependency: check the licence, the project's health and who answers when something breaks. What open source does not provide by itself is a support contract.
Three layers of the open stack
Middleware. ROS and ROS 2 are the connective tissue: messaging, hardware abstraction, and the tooling around them, stewarded by the Open Source Robotics Foundation. Simulation. Physics engines and simulators — MuJoCo, open-sourced by Google DeepMind in 2022, and Gazebo from the Open Robotics ecosystem — let teams test behaviour and generate training data before hardware is involved; our guide to robot simulation and digital twins covers how that testing is used. Algorithm libraries. Motion planning, perception and control components that vendors assemble into products. A commercial robot typically mixes all three layers with proprietary code of its own — which is why the buyer questions in our ROS guide for buyers focus on interfaces and support rather than ideology.
What the licences mean commercially
The core robotics stack is dominated by permissive licences — Apache 2.0 and BSD variants — which allow commercial products to be built on the code, including in closed products, subject to notice requirements. Some components elsewhere in the ecosystem carry copyleft licences that impose conditions on distributed derivatives. The operational rule is boring and essential: inventory the licences of what you ship, component by component, the same way you inventory bought-in parts. This is a summary of the landscape, not legal advice; product counsel should review the actual bill of materials.
Community support vs supported distributions
When a community project breaks at 2 a.m., the community owes you nothing — that is the deal, and it is priced into the zero licence fee. Enterprises close the gap three ways: in-house expertise (the stack is open, so your engineers can read and patch it), support contracts with companies that package and maintain distributions of the open stack, or buying finished products whose vendor carries the dependency. The software suppliers in the directory include firms selling exactly those supported layers. What you cannot sensibly do is depend on the software while budgeting nothing for any of the three.
Where open source stops: certification and accountability
Two needs sit outside what a community provides, and enterprises must source them elsewhere. The first is certification: where a robot operates under machinery-safety or sector regulation, the evidence trail for the software in the safety path has to satisfy assessors, and "the community tested it" is not evidence. Vendors of supported distributions earn their fee partly by maintaining exactly this documentation for their builds. The second is accountability: a licence disclaims warranty by design, so when a component matters commercially, someone — your firm or a paid supporter — must own its behaviour contractually. Neither point argues against open source; both define the layer an enterprise still has to buy or build around it.
Adoption due diligence
Before building on an open-source project, check: the licence of the core and of its dependencies; release cadence and whether security fixes are back-ported; maintainer diversity — a project carried by one employer is a continuity risk; the upgrade path between major versions; and how the project handles vulnerability disclosure. Healthy signals are public roadmaps, multiple institutional contributors and long-term-support releases. Apply the same scepticism you would to a small proprietary vendor, because the failure mode — abandonment — is the same; the difference is that with open code, your exit is a fork rather than a dead end.
One operational habit separates enterprises that rely on open source successfully from those that merely use it: version discipline. Pin the versions you ship, track the project's security announcements as you would a supplier's product-change notices, and rehearse the upgrade to the next long-term-support release before you need it. The dependency is free; managing it like a dependency is the cost of admission.
Frequently asked questions
Can companies legally build commercial products on open-source robot software?
Yes — that is the normal case. The core stack (ROS 2, Gazebo, MuJoCo) uses permissive licences that allow commercial use, including inside closed products, subject to their notice terms. Some peripheral components carry copyleft conditions, so the licence inventory has to be done component by component.
Who fixes a bug in open-source software our product depends on?
One of three parties: your own engineers (the source is open to them), the community if it accepts the fix upstream, or a support vendor you pay. What does not exist is an obligation on the project's volunteers — plan accordingly.
Is open-source robotics software less reliable than commercial software?
Not categorically. Widely deployed open components are tested across far more environments than most proprietary equivalents, and their defects are public. Reliability in your product still depends on your integration, testing and version discipline — the licence model changes who supports the code, not whether it needs engineering.
What should due diligence on an open-source project check?
Licence and dependency licences, release and security-fix cadence, maintainer diversity, long-term-support options, and the project's governance. A project with several institutional maintainers and an LTS line is a different dependency from one person's repository, however good the code.