When building any software system, choosing between fully custom “Roll Your Own” (RYO), open source software (OSS) and closed source (Commercial) software is a challenging decision. While there are many factors to consider in designing distributed network applications, this article will focus on those relating to the communications framework that forms the nervous system of many complex, real-time applications. The assumption is that you’ll use RYO software for your custom application features and leverage existing components where possible.
The Object Management Group (OMG®) Data Distribution Service (DDS™) standard is an "open standard." The standard is publicly available and provides a normative reference to help guarantee consistency, portability and interoperability. An open standard is not the same as software that is "open source." OSS is computer software made available with its source code. OSS may be shared, modified and distributed, under some open source license. DDS is an open standard and has both Commercial and OSS implementations available. For example, OpenDDS is an OSS implementation managed by OCI (Object Computing Inc.). There are many commercial distributions available as well, the most deployed in mission critical systems being RTI Connext.
So, what factors should you consider when deciding between an OSS versus a Commercial DDS solution?
First, it is important to examine the DDS features you need. If you aren't certain of what you will need, a complete implementation is more likely to meet your needs over time. Here are some of the standard OMG DDS capabilities that Connext supports which are not commonly found in OSS DDS distributions:
Additionally, here are some of the enhanced (non-standard) capabilities that Connext supports which are not commonly found in OSS DDS:
When considering solutions, it's important to determine what support outside the DDS core you may need. Do you need to interface with web pages? Do you want to persist data in the event of power-down? Some of the key services not available with OSS DDS include:
What development tools are available for the DDS implementation you are considering? Often DDS is used in large inter-connected systems that can be quite complex. Having the right tools available to debug these systems is crucial. Connext has a complete set of tools designed to meet the needs of real customers over 20 years, including:
OSS DDS distributions do not directly include any security support. That is, most do not support the DDS Security standard and also do not have any TLS or DTLS transports available. Connext supports the DDS Security standard and also has a Secure WAN transport that includes TLS and DTLS support.
Robustness is perhaps the most important factor when determining if a particular OSS DDS implementation is a good choice. The best way for software to prove itself is in actual customer applications. How many real-world, deployed systems are using the DDS implementation you are considering? Connext has been field-tested, proven and used by more than 2,000 different projects in over 1 million devices today. Some of these complex, mission-critical applications, that leverage Connext today, include:
Connext has proven itself repeatedly in mission-critical, real-world applications. This includes extensive automated testing, rigorous training and reviews, and extensive issue tracking and management. In addition, the RTI Testing Lab is one of the industry’s largest, most complete lab facilities, able to test over 3,000 endpoints and over 100 different targets, validating Connext on:
A very important question to ask yourself is: What is the quality of the DDS implementation that you are entrusting your products to?
There are a few other items to consider. Commercial software typically has a published release cadence along with a tiered support and extended support period. This helps you manage your schedules and release milestones. A stable release cadence is also part of a Vulnerabilities Mitigation strategy. A software product with a definitive release date can have a well-planned strategy for handling the inevitable Vulnerability patch(es) needed. OSS often uses a chaotic release strategy which causes duplicate testing and impacts product schedules.
Some OSS DDS implementations are available as a free download, appearing initially to cost less than a Commercial DDS. However, over time, the costs of using OSS DDS can increase. While OSS DDS is supported by an open source community without license, support or runtime fees, you must rely on community support or pay another company for support. As a result, OSS DDS will likely cost more in the long run due to missing features, the extra developers that are needed, increased development time and additional support costs. How much of staff’s time will go towards your product deliverables vs. community participation? What is the value of avoiding a bug because you’re using stable, battle-tested, well-crafted software? How important is fast, reliable support? Weigh the cost of a Commercial DDS license versus the loaded cost of an engineer per year. Is it worth it to “save” the money up front?
How quickly do you need to get your product to market? If the DDS implementation you want to use is less complete – does not have the tools, documentation, support or services you need, or just does not work as expected – how is that going to affect your schedules? How important is getting your product out on time with all the envisioned functionality?
Generally speaking, Commercial DDS implementations are more full-featured and more robust than OSS versions. This is because they have a larger number of engineers dedicated full-time to development and testing. For instance, Connext Professional has over 50 engineers working full time on development. This does not include the 25 full-time support engineers, or the services, training and field application engineers.
It is critical to understand what support is available to you in case you run into problems. OSS DDS usually has support available through online user groups or third parties for a fee. However, you’ll want to determine if the support engineers are dedicated to just this implementation or if they support multiple products. Also, do they have an escalation policy if you run into critical problems? Will the only fix require a migration to a different fork?
RTI understands that connectivity software is a mission-critical part of your application and treats customer support seriously. Our support engineers are exceptionally qualified: They are experts at designing, debugging and implementing distributed real-time and embedded systems. With global support centers, RTI support engineers can be reached almost 24/7. In addition, RTI support engineers are co-located with, and have direct access to, development engineering resources. It is imperative to have the development engineers help out when a critical issue has stalled your project’s progress.
RTI has examples available online for many Connext features. There are also user group articles, instructional videos, blogs, Case + Code walkthroughs, online training and over 2,000 pages of documentation. With the rollout of the Connext AI Chatbot in April of 2025, trained specifically on Connext, you’ll join 3,000+ users getting not only great answers with clickable references but even unique, validated sample code or QoS snippets, anytime.
It is important that you completely understand your requirements and what features and services you need before selecting which DDS implementation to use. The following are some of the key questions to help define your requirements:
If you have a complex product with time-to-market concerns that needs to be rock solid, well supported, with the features you need now and in the future, then RTI Connext is the right choice.
Learn more:
The True Cost of Open Source in Mission-Critical Applications
About the authors:
Andy Krassowski is a Senior Field Application Engineer for Real-Time Innovations, supporting customers in the eastern US area. Andy has been in the real-time software industry for over 40 years working in engineering and sales roles. Andy holds a Bachelor of Science degree in electrical engineering from Worcester Polytechnic Institute, and a Master of Science degree in computer science from the Rensselaer Polytechnic Institute.