This blog is based on a white paper by Express Logic. Read the full version here.
Free is a good price, so the saying goes, so free, open source real time operating systems (RTOSs) might seem like a good deal. But they’re typically not worth the risks for developers of embedded and IoT devices such as home automation and wearable devices, medical instruments, and industrial control systems. Before you decide, make sure you understand the real costs and pitfalls of using an open source—rather than commercial—RTOS.
If the RTOS fails or behaves unexpectedly, your product can, too. Even if an RTOS malfunction might not lead to injury or death, it can lead to customer dissatisfaction, poor sales, and product recalls. A safety-certified RTOS offers confidence that it has been thoroughly reviewed, tested, and proven to perform as intended.
Open source software (OSS) is freely available, which means anyone can devise a means of subverting it. If it’s used in a successful commercial product, the motivation for hackers is heightened. OSS components might contain security vulnerabilities that could be exploited in any product in which they are used.
Some OSS RTOSs can be modified and “stewarded” by a commercial organization. This loss of independence creates concern in any environment that is not compatible with the stewarding organization. For example, ARM Mbed OS is available only for ARM processors, so its use is an effective lock-in for ARM. This limits options for future use on a different microprocessor.
The speed of RTOS services can impact your product’s performance and reliability. Size matters, too. Smaller code size enables the use of lower-cost microprocessors and less memory, and leaves more room for application code. The performance of any RTOS can be measured and quantified using the “Thread-Metric” benchmark suite (described here).
Lack of advanced features
OSS RTOSs perform basic RTOS services that enable an embedded or IoT device to function. Commercial RTOSs often provide additional value-added features to make applications operate faster, and make development and debugging easier. The result is a more efficient, higher-performance embedded/IoT product that gets to market faster and is more successful throughout its life cycle.
Commercial RTOSs often include middleware such as an embedded file system, TCP/IP networking stack, USB host/device support, graphics framework, and IoT cloud service interfaces. These middleware components might be available for use with an OSS RTOS, but are often not integrated or supported by a single organization. That “integration gap” must then be bridged by the product developer, adding project time, cost, and risk of error.
The OSS support community can be helpful—or not. A commercial RTOS includes reliable, responsive support for commercial products. Commercial RTOS providers also guarantee full backwards compatibility in the API, and the licensing terms are fixed in contract form that cannot be changed unilaterally—unlike OSS.
Three commonly encountered legal concerns related to the use of an OSS RTOS in a commercial product include:
- Use of “software of unknown pedigree” (SOUP), which can result in intellectual property rights infringement
- Requirement to disclose proprietary code that is combined with or linked to the OSS back to the open community
- Product liability where development best practices don't generally equate to "we used it because it was free"
Many of these pitfalls generate additional costs for in-house training, support, and integration. Other costs relate to legal concerns, including IPR infringement. These costs can be substantial, and ignoring them can be catastrophic for a commercial enterprise.
No commercial pressure to make open source better
Finally, the competitive pressure faced by commercial RTOS developers provides motivation to continue to invest in identifying and satisfying customer needs. This fundamental business dynamic operates to the benefit of RTOS users, guaranteeing them access to the best products from the best companies that have survived the longest.