Focus
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 since the soſt ware they create is proprietary to their application and thus can’t be shared outside of their own organisation. Another point to consider is that
organisations that maintain open source soſt ware sometimes make unilateral changes to the licensing agreement for the soſt ware, potentially putting project costs and code integrity on a shiſt ing foundation.
2. Feature upgrades What happens when there is required functionality for your application that is not available from the open source soſt ware? 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 soſt ware that excludes future versions from the open source community. Once the internal team proceeds down
the path of using an orphaned branch of the soſt ware, a subject matter expert would have to assess how to pull in enhancements or fi xes from the open source community. T e integration will then be even more diffi cult, resulting in extended testing scenarios.
3. Security compliance Cybersecurity attacks and threats are growing by the day, and any soſt ware that has some level of network connectivity is at risk from unauthorised actors. One issue with open source is that the people writing the soſt ware can be unknown, and thus the open source projects and their contributors can’t be audited. T is makes open source soſt ware an easy target for hackers to build in undetected, compromisable access points, opening up widespread vulnerabilities from hundreds of deployed systems using the same soſt ware with the same access points. T is can result in costly re-coding eff orts – or
worse – breached systems. All this can be particularly disastrous if the systems operate in regulated, controlled or classifi ed environments. But, how does a user of an open source soſt ware typically fi nd out about security breaches – and how quickly can it be fi xed?
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 soſt ware would require two full-time support engineers, which would add approximately $400,000 per year to the project. T is calculation is based on research showing an average engineering salary of $150,000 per year plus average 35% benefi ts upliſt , or an hourly contract rate of $100 per 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 T e development team taking on open source soſt ware needs to have tough conversations upfront about what happens when something doesn’t work as expected. Open source soſt ware enables the team to track down precise bugs within the code. But then what do you do with that bug fi x? Depending on the open source soſt ware licensing terms, fi xes may need to be submitted back to the community. How does this fi x aff ect other functions of the soſt ware? Delayed fi xes 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 soſt ware, as discussed here.
The advantage of commercial software As we have already outlined, free open source soſt ware could have hidden costs that oſt en make it more costly than commercial soſt ware. Particularly when developing new products or services, there could be signifi cant consequences from missing functionality, leading to missed deadlines and delayed market entry. And this is where the big diff erence between commercially available soſt ware and open source soſt ware comes in. Commercial soſt ware 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 synchronised precisely to the project requirements. T e vendor manages future and backward compatibility to ease upgrades. Vendors control the code at all stages, so it is protected from backdoor entry points. T ey also 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 modifi cations that arise, and they 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-eff ective and time-saving aspects of using commercially- available soſt ware. T e decision to use open source soſt ware
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 here with some of the open source solutions that we have worked with and researched. When everything is at stake, using a commercial soſt ware package can off er stability, quality control and predictable costs.
www.electronicsworld.co.uk November 2025 11
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44
