Open-source software is either viewed as a cheap, fast alternative to quick functionality integrated into an embedded system or viewed as the devil that will trip you up and cause problems to the unsuspecting development team. The use of open-source software has many advantages along with many disadvantages. For those interested in successfully using open-source software in their project, here are five steps to successfully integrating open-source in your embedded application.

Step #1 – Identify Your Needs and Research Available Open-Source Options

Every embedded application has different requirements, depending on factors like target industry, system functionality, hardware capabilities, and required levels of stability and reliability. Your system requirements will help dictate which open-source projects fit your application well. Once you understand these requirements, you can start researching open-source software that might meet your needs.

When you first identify open-source solutions, starting with a wide net is not a bad idea. Most open-source solutions probably won’t fit your requirements and needs, but in the first step, we want to understand your requirements and needs and then identify potential options. I often create a list of solutions with links to their GitHub and website. If a solution appears to be way off, I’ll still document that it exists but add a note that it doesn’t appear to be a good fit. Solutions that look like they may be a fit, but I’m not sure about them; I’ll leave them on the list for further analysis later.

Step #2 – Evaluate License and Compliance Requirements

For a commercial product, one of the biggest issues you will encounter with open-source software is licensing and compliance requirements. Many different types of open-source licenses exist. The details of each are well beyond the scope of this article; however, evaluating if a solutions license fits your company’s needs is critical. If you select a solution with the wrong license, you may be forced to release your source code! Therefore, having a lawyer specializing in open-source licenses review your list of prospective solutions is always a good idea. You may find solutions to drop off your prospect list based on the license.

In addition to licensing needs, you also need to consider the compliance requirements for your system and whether the open-source software meets those requirements. For example, if you are working on a medical device, you may find that there are requirements for the robustness of your file storage system. Does using spiffs, eefs, or LittleFS fit your compliance needs if that is the case? Maybe they all do, or perhaps none of them do. Your compliance needs may force you in one direction or the other, though.

Step #3 – Suitability Assessment and Testing

It’s important to recognize that all open-source software is not created equally. It’s also not necessarily designed with your needs in mind! Open-source software often starts as a pet project of some developer who has a need. Their needs may or may not align with yours. Under the worst circumstances, they might appear to align, and only when you get into the details do you discover the ugly truth that they don’t. As a project gains steam, it’s not uncommon for multiple stakeholders to begin maintaining the project, all with their vision of where the software should go.

You should not assume that an open-source solution will meet your needs, even if it is provided by your silicon vendor already integrated into their toolchain. You should assess whether the software meets your licensing, performance, code size, integration, and maintenance needs. I would also recommend that you take the time to run the solution and test it. Throw some curve balls and corner cases and see how it behaves. You may discover quickly that a solution isn’t right for you.

There are many assessments and tests that you can run on a potential open-source solution. You should also use a tool like pmccabe to measure the cyclomatic complexity of the code. Complexity measurements can help you understand the likelihood of bugs hiding in the code base. I recall one time when I was excited to use an open-source file system solution that had been used on several NASA missions. I assumed the code was of the highest quality but decided to check anyway. I discovered the code was far more complex and likely to have bugs than expected. After some testing, it was found that better open-source solutions were available.

Step #4 – Integration and Customization

Once you’ve selected an open-source solution, the real work begins. You must integrate it into your code base. In many cases, I’ll see teams add the solution and start making direct calls to its APIs. That is a mistake. When you use a third-party solution, even open source, it’s a good idea to hide it from your application through your API or wrapper functions. The reason is that you may discover that you need to change solutions. If you tightly couple your application code to the solution, you’ll have to go back and change all that code! If you abstract the code through an interface, you must update the functions the interface calls, and you’re back in business very quickly.

Another key to successfully integrating open-source software is developing unit tests for the necessary functionality. A big open-source project like an RTOS or file system may change over time. You don’t want there to be a change to something you use that then breaks your application code. Whenever you integrate software into your code, you should write unit tests to ensure it does what you expect. You don’t need to write unit tests for the entire solution; just write unit tests for the pieces you use. Doing so will ensure you don’t get bitten by a nasty bug later.

Step #5 – Maintaining the Solution

Luckily, your selected open-source software is now integrated into your application and working successfully. Unfortunately, that isn’t the end of the story. You now must maintain that open-source solution in your code. The solution may change with time to add new features, fix bugs, or even patch security vulnerabilities! To ensure that your code continues to meet your customers’ needs and operate as expected, you’ll need to maintain it throughout the lifetime of your product.

Conclusions

Open-source software can be advantageous to embedded software teams or a major stumbling block. This post has looked at the five steps for integrating open-source software into an embedded application. You’ve seen the importance of examining licensing and compliance requirements. We’ve also discussed how important it is to assess software quality and develop unit tests. Perhaps the most important integration tip is to decouple the solution from your application code through an API.

Adhering to these steps should help you increase the chances of successfully integrating open-source software into your embedded system. Good luck!