How are commercial/proprietary ROS 2 components typically distributed?

Projects
1

I’d like to understand the common deployment patterns for commercial ROS 2 software.

My background is in mobile/on-device AI. In the mobile ecosystem, binary distribution has fairly clear boundaries: an SDK vendor might provide an AAR for Android or an XCFramework for iOS, while keeping the underlying implementation proprietary.

As we move into robotics, the boundaries seem less standardized.

For example, consider an optimized AI inference runtime targeting Jetson or another Linux-based robotics platform. The core runtime is proprietary, but customers need to integrate it into an existing ROS 2 system.

One possible architecture is:

Proprietary inference runtime
        |
        +-- C/C++ API
        |
        +-- ROS 2 adapter
                |
                +-- node
                +-- launch files
                +-- configuration

The actual distribution could then happen through Debian packages, containers, prebuilt binaries, or potentially ROS packages themselves.

I’m curious how companies shipping production robotics systems approach this in practice.

Do you generally treat ROS 2 as the distribution boundary itself, or as an integration layer on top of independently packaged software?

And has the ROS ecosystem developed any common best practices around binary-only commercial components, versioning, dependency management, and deployment?

I’m particularly interested in experiences from people who have shipped ROS 2 software to customer robots rather than only deploying software internally.

2

Transitive, the open-source platform for building full-stack robotics capabilities we’ve built, is one such distribution channel. Each capability contains one or more of:

  • a robot component (which is often a ROS node)
  • a cloud component, and
  • one or more web components.

While all our existing capabilities combine all three, you could use it to distribute a robot-only capability as well. Capabilities are npm packages, i.e., tar-balls with dependencies and (pre/post-)install script(s), so they can carry any payload, including pre-compiled binaries.

If you want to explore this, I recommend you first try it out as a user on our hosted offering (accounts are free and several capabilities are, too), and then read these sections: