Skip to the main content.

Did you know?

 

RTI is the world’s largest DDS supplier and Connext is the most trusted software framework for critical systems.

Success-Plan-Services-DSSuccess-Plan Services

Our Professional Services and Customer Success teams bring extensive experience to train, problem-solve, mentor, and accelerate customer success.

Learn more

Developers

From downloads to Hello World, we've got you covered. Find all of the tutorials, documentation, peer conversations and inspiration you need to get started using Connext today.

Try the Connectivity Selection Tool ⇢

Resources

RTI provides a broad range of technical and high-level resources designed to assist in understanding industry applications, the RTI Connext product line and its underlying data-centric technology.

Company

RTI is the infrastructure software company for smart-world systems. The company’s RTI Connext product is the world's leading software framework for intelligent distributed systems.

Contact Us

News & Events
Cooperation

5 min read

The True Cost of Open Source in Mission-Critical Applications

The True Cost of Open Source in Mission-Critical Applications

Open source software has become prevalent in many applications today. According to a recent study by Synopsys, 96 percent of the total code bases reviewed contained some open source code, which included advanced applications such as sophisticated robotics, smart grid, defense infrastructure, unmanned vehicles, transportation, and more. 

The popularity of open source software can of course be chalked up to several factors. For example, users can download and start using the software in just a few minutes. And there is a lot of code that’s available, developed from a large community of developers, enthusiasts and experts who collaborate on projects. Yet the main reason for choosing open source usually comes down to the perception of cost – the idea that free really does mean free. But does it?

Unfortunately, the true cost of using open source is often misunderstood, because the wide-ranging implications of that choice are not always immediately obvious. A big part of decoding the real cost equation is the fact that open source software has well-documented risks that directly affect the bottom line, including lack of dedicated support, fragmentation and compatibility issues, licensing concerns, and developer resource expenses. This blog post examines the hidden costs of open source software for mission-critical systems. While this information applies to all open source programs, it is oriented to those who are considering software based on the Data Distribution Service (DDS) standard.

Top 5 Costs of Choosing Open Source Software

Choosing open source software software may seem to start out free – open-source software is typically available without licensing fees. But as a project evolves, the limitations inherent in open source software can rapidly generate situations that hamper productivity and lead to expensive rework. In the end, developers of mission-critical applications may find that choosing open source software over commercially-available options actually ends up costing much more than robust, commercially-available solutions – especially when safety assurance and compliance are required to go to market.

Let’s take a look at some of the reasons that drive up the cost of using open source software.  

1. Upfront Legal Costs

While it’s typically free to download the code itself, there are legal costs associated with license evaluation and usage. On top of that, many open source licenses require you to contribute any changes you make back to the originating open source community. For some project teams, this can be a non-starter as the software they are creating is proprietary to their application and thus cannot be shared outside of their own organization. Another point to consider is that open source software-maintaining organizations sometimes make unilateral changes to the licensing agreement for open source software, potentially putting project costs and code integrity on a shaky and/or shifting foundation.

2. Feature Upgrades

What happens when there is required functionality for your application that is not available from the open source software? Your internal team could add the feature directly in order to meet the project timeline, but then the feature typically must be submitted back to the open source community under the open source license agreement….again. And if the feature is not submitted back, the project would work on an “orphaned” branch of software which excludes future versions from the open source community. Once the internal team proceeds down the path of using an orphaned branch of the software, a subject matter expert would have to assess how to pull in enhancements or fixes from the open source community. The resulting integration will then be even more difficult, resulting in extended testing scenarios.

3. Security Compliance

Cybersecurity attacks and threats are growing by the day, and any software that has some level of network connectivity is at risk from unauthorized actors. The biggest issue with open source here is that the people writing the software are unknown and thus the open source projects and their contributors cannot be audited. This makes open source software an easy target for hackers to build in undetected, compromisable access points, opening up widespread vulnerabilities from hundreds of deployed systems using the same software with the same access points. This can result in costly re-coding efforts or worse, breached systems – and this can be particularly disastrous if these systems operate in regulated, controlled, or classified environments. Particularly chilling is the fact that open source software users are typically not made aware of specific breaches or weaknesses unless and until the wider community becomes aware and creates a fix for it.

4. Support and Talent Retention

Open source of course lacks support, which can be devastating at certain junctures of project development. It can be expensive to either dedicate internal resources to support the team or outsource the support to a third-party company (Support-as-a-Service). On average, a mid-sized distributed application based on open source DDS software would require two full-time support engineers, which would add approximately $400,000 per year to the project – this calculation is based on research showing an average engineering salary of $150,000/year plus average 35% benefits uplift; or an hourly contract rate of $100/hour. In addition, bringing support in-house poses attrition risks, plus the workload and opportunity cost of the designated developer’s time. Care must be taken so that the support engineers chosen for this task are retained for the life of the project. Otherwise, project teams can face steep training costs and expensive delays to get the new expert(s) up to task. 

5. Software Life Cycle Management

The development team taking on open source software needs to have tough conversations upfront about what happens when something doesn’t work as expected. Open source software enables the team to track down precise bugs within the code. But then what do you do with that bug fix? Most open source communities require that the fix be submitted back to the open source repository. When does this get committed back? How does this fix affect other functions of the software? Delayed fixes can upset tight development schedules, so it pays to plan for disrupted usage when it comes to open source. For example, once a successful research project moves into a commercially deployable stage, the next phase of work will introduce many of the direct or hidden costs of open source software as discussed above.

The Commercial Software Advantage

As we have outlined above, “free” open source software has hidden costs that often make it more costly than commercial software. Particularly when developing new products or services, the consequences of missing functionality and missed deadlines at the go-to-market stage can be nothing short of catastrophic. And this is where the big difference between commercially-available software and open source software comes in. Commercial software users enjoy the following advantages throughout the life of their project: 

  • New features and upgrades are directly managed by the vendor, who can provide a roadmap and timeline that is synchronized precisely to project requirements. The vendor manages future and backward compatibility, to ease upgrades.
  • Vendors control the code at all stages, so it is protected from backdoor entry points.
  • Vendors maintain rigorous quality processes, including cybersecurity assessments that can be audited to ensure compliance.
  • Support is either included in the upfront purchase or is a small fraction of the upfront costs, with a predictable, planned-for budget line item.  
  • Vendors are responsible for tracking, testing, and validating updated code as well as any other modifications that arise.
  • Vendors provide documentation along with example use cases.
  • Project teams can rely on the vendor’s deep bench of experts who can help resolve critical issues on short notice, which reduces project risk, and can be one of the most cost-effective and time-saving aspects of using commercially-available software.

Summary

The decision to use open source software needs to be carefully weighed against potential costs and risks down the road. When everything is at stake, using a commercial software package such as RTI Connext, the most widely used implementation of the well-established DDS standard, can offer stability, quality control, and predictable costs.  

Please contact RTI to discuss whether commercial or open source software is right for your mission-critical project. We also invite you to evaluate our software for free; download your free trial of Connext today.

 

 

About the author:

Bert Farabaugh Preferred_2018Bert Farabaugh is the Director of Field Application Engineering  at RTI. During his 21-year tenure with RTI, Bert has developed extensive expertise in real-time applications and distributed systems architecture design. Prior to his current role, he also spent 12 years developing robotic systems with various key defense contractors. Bert holds a B.S. in Electrical Engineering from The University of Pittsburgh.