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?

We have learned the value of open source software over the years, as well as the level of attention needed to maintain the codebase.. In addition, we have engagements with projects that have used open source in the past and then later moved  over to a commercially available version. From these engagements and their reported findings, it's clear that some open source is pretty straight-forward to adopt and incorporate, while some is not so clear and requires more work and support. This post is an attempt to provide insight with regard to the risk and support needed, based on our experience and industry vision on certain open source solutions. 

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^TM) 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 potential limitations (if any) inherent in open source software could lead to 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, some open source licenses (such as copyleft) 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. One issue with open source is that the people writing the software can be 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. How does an open source software user typically find out about security breaches – and how quickly is it fixed? 

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? Depending on the open source software licensing terms, fixes may need to be submitted back to the community. 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 could have hidden costs that often make it more costly than commercial software. Particularly when developing new products or services, there could be significant consequences from missing functionality, leading to missed deadlines at the go-to-market stage. 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. In the course of our experience, RTI has come across many of the items listed above with some of the open source solutions that we have worked with and researched. Given RTI’s commitment to the users of our software, we anticipate and plan for these risks so that we can provide the best, most reliable software for our users. 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 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.