OpenDDS for C++ publish-subscribe applications

OpenDDS targets publish-subscribe and distributed-cache applications

OpenDDS addresses applications whose participants need to publish typed data and consume it without directly connecting every writer to every reader. It implements the Object Management Group Data Distribution Service for Real-time Systems specification, identified by the README as version 1.4, and also references related specifications. The intended audience is therefore not limited to message-broker users. The project is aimed at distributed-systems developers working with typed interfaces, discovery, quality-of-service behavior, real-time data exchange, or interoperable DDS peers.

The implementation is primarily C++, but Java applications can use OpenDDS through Java bindings provided through JNI. That makes it relevant to mixed-language services, although the README does not describe the Java setup commands, supported JDK versions, or binding limitations in the text available here. A team should therefore treat Java support as a documented capability to verify against the relevant Developer’s Guide, not as evidence that every C++ feature has identical Java exposure.

The release information also places OpenDDS within a standards and platform ecosystem rather than presenting it as an application-specific library. OpenDDS supports DDS Security and XTypes, while its RTPS work follows the DDS-RTPS Specification version 2.3. Those specifications matter when separate implementations must exchange data. They also make configuration more involved than using a general-purpose queue or socket library.

ACE, TAO, IDL, and the DCPS Information Repository form the core stack

OpenDDS is built on the ACE abstraction layer for platform portability. It uses TAO capabilities for IDL compilation and interaction with the DCPS Information Repository. The README requires TAO and states that ACE is included with TAO. This is not an incidental build detail. IDL compilation affects how application type definitions become usable interfaces, while repository interaction affects how OpenDDS systems coordinate through the DCPS architecture.

The repository includes several build-system entry points, including `CMakeLists.txt`, `configure`, `configure.cmd`, MPC files, and a `Dockerfile`. Perl is used by the configure script, automated tests, examples, and generation of Makefiles or Visual Studio project files. Windows documentation recommends Strawberry Perl. This gives developers more than one build route in the tree, but it also means the selected workflow determines which dependencies and generated files are required.

The `Dockerfile` shows a concrete Linux-oriented build sequence. It starts from `ubuntu:jammy`, installs build dependencies, copies the source into `/opt/OpenDDS`, runs `./configure --prefix=/usr/local --security ${ACE_CONFIG_OPTION}`, compiles and installs the project, loads `setenv.sh`, copies MPC, and sets environment variables for ACE, TAO, DDS, and MPC. Because this is the repository’s container build definition, it documents a repeatable build image, but the README excerpt does not provide a complete command for building or launching that image.

OpenDDS transport choices span network and shared-memory paths

The listed transport protocols are TCP/IP, UDP/IP, IP multicast, RTPS over UDP/IP using either unicast or multicast, and shared memory. This selection is one of OpenDDS’s clearest engineering distinctions. A deployment can use a conventional network transport, multicast for local distribution, an RTPS configuration associated with interoperability, or shared memory when processes need a lower-latency local path. The README does not say that every application should use every transport, nor does it provide a universal performance comparison.

RTPS features are based on DDS-RTPS Specification version 2.3, and the repository includes `docs/design/RTPS` for further technical detail. The RTPS transport is therefore not merely an alternate socket option. It is tied to an interoperability specification and has its own design documentation. Teams selecting it should read that document and the Developer’s Guide rather than infer interoperability from the presence of a transport name.

The transport list also illustrates a configuration trade-off. Shared memory can fit tightly coupled participants on one machine, while TCP/IP, UDP/IP, multicast, and RTPS address processes distributed across networks. The project documentation does not establish a single default topology for production systems. Network interfaces, discovery configuration, operating-system support, and the quality-of-service requirements of the application all need to be considered in the actual deployment design.

Building OpenDDS requires a documented dependency setup

The README points developers to the OpenDDS Developer’s Guide for detailed dependency and platform information. It also states that the `configure` script downloads TAO when that script is used, so a separate TAO download is not required in that path. The required dependencies include ACE/TAO and Perl. The repository’s `Dockerfile` gives a concrete configuration fragment for enabling security support:

ARG ACE_CONFIG_OPTION="--doc-group"
RUN cd /opt/OpenDDS && \
    ./configure --prefix=/usr/local --security ${ACE_CONFIG_OPTION} && \
    ./tools/scripts/show_build_config.pl && \
    make && \
    make install

The script prints the selected build configuration before compilation, which is useful because ACE/TAO and OpenDDS have many configuration choices. The same file then sets these environment locations after installation:

ENV ACE_ROOT=/usr/local/share/ace \
    TAO_ROOT=/usr/local/share/tao \
    DDS_ROOT=/usr/local/share/dds \
    MPC_ROOT=/usr/local/share/MPC

These are build-image settings, not a claim that every installation must use those paths. The README does not provide a single command for a first C++ publisher or subscriber in the visible text. For a first real use, the appropriate next step is the Developer’s Guide’s platform quick start, where the generated IDL, MPC or CMake build files, runtime configuration, and publisher/subscriber example can be followed as one procedure.

DDS Security and XTypes expand capability while increasing configuration work

OpenDDS states that it supports the DDS Security and XTypes specifications. These features address two different concerns. DDS Security is relevant when applications need specification-defined protection mechanisms. XTypes is relevant when type representation and type-consistency behavior need more than a basic IDL mapping. The README confirms support but does not enumerate certificates, keys, permissions, type filters, or deployment settings, so those details must come from the specification documentation and OpenDDS Developer’s Guide.

The Dockerfile’s `--security` option shows that security support is considered during configuration. Enabling that option is not the same as explaining how a running system establishes trust or assigns permissions. The visible documentation does not provide a complete security configuration example, nor does it state whether every supported transport has identical security behavior. A security review should therefore start with the OpenDDS security documentation and the application’s trust boundaries rather than treating the build option as a complete deployment procedure.

XTypes has a similar qualification. The project supports it, but the README does not state which XTypes features are enabled by default or how compatibility is handled across mixed-version peers. Applications that depend on advanced type behavior should check the Developer’s Guide and `docs` directory for the relevant version. This is especially important for systems where publisher and subscriber versions may differ.

OpenDDS has a broad platform matrix, but not an unlimited one

The README lists tested operating systems and toolchains. For the Linux family, it names Ubuntu 22.04 LTS and 24.04 LTS on x86_64, plus a limited Ubuntu 14.04 GCC 4.6 compatibility build. For Windows, it lists Windows Server 2022 and Windows 2025, both 64-bit. It also lists macOS 14. Embedded and mobile entries include LynxOS-178 with the OpenDDS Safety Profile, VxWorks 6.9, 7, and 21.03, Linux on Raspberry Pi, and Android using several named NDK versions.

The distinction between tested platforms and additional use matters. The README says OpenDDS is also used on other platforms and compilers, but directs specific platform and configuration questions to GitHub Discussions, issues, or the support page. It also says that VxWorks builds received basic system and performance tests, not the entire regression test suite. That is a narrower validation statement than saying the platform has the same coverage as the principal Linux and Windows configurations.

The correct adoption check is therefore concrete: compare the deployment operating system, processor architecture, compiler, NDK or embedded toolchain, and required OpenDDS configuration with the documented lists. A platform not named in the README may still be possible, but the project text does not provide enough detail to call it supported. The linked Developer’s Guide and support resources are the appropriate places to resolve that gap.

OpenDDS maintenance, licensing, and support have specific boundaries

The repository is not archived, and the last push was on 2026-10-08. The recent release list includes v3.34.0 on 2026-05-21, v3.33.0 on 2025-08-01, and v3.32.0 on 2025-05-06. Those dates indicate recent release activity, but they do not by themselves define the cost of upgrading an application. OpenDDS is a C++ system with generated code, IDL compilation, transport configuration, security options, and platform-dependent dependencies, so migration should account for build and deployment compatibility as well as source changes.

The project identifies its primary development work as being done by Object Computing, Incorporated, in St. Louis and Phoenix. The README describes the release terms as generous and similar to ACE, TAO, and MPC, but it directs readers to the repository’s `LICENSE` file for details. The repository metadata classifies the license as other, custom terms that GitHub cannot classify. No legal conclusion should be drawn from the short README description. Teams need to read `LICENSE` and assess the actual terms for their intended distribution and use.

Commercial support is documented through the OpenDDS support page, and questions are directed to GitHub Discussions. Bug reports are expected to include a minimum working example with IDL, source, configuration, an MPC file, a `run_test.pl` launcher, and a `README.rst`. This contribution format gives maintainers a reproducible case, but it also shows that diagnosing issues can require a complete IDL and build package rather than a short configuration snippet.

Editorial conclusion

OpenDDS is appropriate for teams already building standards-based distributed real-time systems in C++, especially when interoperability, DDS Security, XTypes, RTPS, or a documented selection of transports matters. It is a poor fit for a small application that needs a lightweight message bus or for a team unwilling to manage IDL compilation and the ACE/TAO dependency chain. Before adoption, verify the target operating system and compiler combination against the supported list, inspect the LICENSE file, and reproduce the relevant quick start because the README links to platform-specific procedures rather than presenting one universal installation command.

Frequently asked questions

Official sources

1. Issues
2. OpenDDS/OpenDDS on GitHub
3. Project website
4. README
5. Releases