Here are five best practices for utilizing open source software successfully.
Best Practice #1 – Use an abstraction layer to remove dependencies
One of the common issues with code bases I review is that developers tightly couple their application code with the software libraries they use. For example, if a developer is using FreeRTOS, their application code makes calls specific to the FreeRTOS APIs in such a way that if a developer ever decided to change their RTOS, they’d have to rewrite a lot of code to replace all those RTOS calls. You might decide that changing libraries is rare, but you’d be surprised how often teams start down a path with one OS, library or component only to have to go back and rewrite code when they decide they need to make a change.
The first thing teams should do when they select an open source component, and even commercial components, is to create an abstraction layer to interact with that component. Using RTOS as an example, a team would use an OS abstraction layer, OSAL, that would allow them to write their application code with OS independent APIs. If the OS changes, the application doesn’t care, because it’s accessing an abstraction layer and the software change can take minutes rather than days.
Best Practice #2 – Leverage integrated software when possible
Most open source software is written in its own sandbox without much thought given to other components with which it may need to interact. Components are often written with different coding standards, styles, degrees of testing, and so on. When you start to pull together multiple open source components that were not designed to work with each other, it can result in long debugging sessions, headaches, and missed deadlines. Whenever possible, select components that have already been integrated and tested together.
A good example is using Amazon FreeRTOS for connecting to AWS. FreeRTOS is already integrated and tested with the additional connectivity libraries required to connect to the cloud, so do not select some other library unless it has also been tested and integrated. Another example is the code generator tools many microcontroller manufacturers produce. These tools often already integrate driver software components, an RTOS, a file system, USB, and several other components. They are already proven to work together, so if they can be leveraged it will save time and money.
Best Practice #3 – Perform a software audit and quality analysis
There is a lot of great open source software and a lot of not so great software. Before a developer decides to use an open source component in their project, they need to make sure they take the time to perform their due diligence on the software or hire someone to do it for them. This involves taking the time to audit the component and perform a quality analysis. Quality is often in the eye of the beholder.
At a minimum, when starting out with an open source component, the source code should be reviewed for:
- Complexity using cyclomatic complexity measurements
- Functionally to ensure it meets the businesses needs and objectives
- Adherence to best practices and coding standards (based on needs)
- Ability to handle errors
This will, at least, help developers understand what they are working with, and the potential issues and pitfalls.
Best Practice #4 – Have the license reviewed by an attorney
Open source software licensing can be difficult to navigate. There are a dozen or so different licensing schemes, which place different requirements on the user. In some cases, the developer can use the open source software as they see fit. In others, the software can be used but any other software must also be open sourced. This means that it may require releasing a product’s secret sauce, which could damage their competitive market advantage.
While these licenses have become more comprehensible in recent years, product developers are running a business and it is imperative to enlist an attorney to review the software license, ensuring everything is above board. Yes, there is an added expense, but it is part of the cost of doing business and could save money in the long run in the event of a mistake.
Best Practice #5 – Select software from an active community
It is always tempting to do a quick web search or to peruse github to find a software component that solves the problem. When selecting an open source component, it is so important to ensure that the component has an active community.
For example, developers who use FreeRTOS know they can go on a forum, ask questions, and will usually get a quick response. New versions are periodically released, and the software is always being improved with new features being added. Selecting a component with an inactive community can result in a developer being on their own, forced to figure out problems themselves or, worse, having to maintain the component.
Properly leveraging open source software can dramatically benefit the development team using it. However, in order to be successful, developers need to make sure they select their open source components wisely. This includes abstracting out the component to ensure their application remains flexible and maintainable. It also requires careful review the open source software, assuming it’s not Linux, to ensure quality and general requirements are met before committing to the component.
Following these best practices can help a team avoid a quagmire that results in product delays, a poorly architected solution, quality issues and many other issues that often come up during product development.
Jacob Beningo is an embedded software consultant who currently works with clients in more than a dozen countries to dramatically transform their businesses by improving product quality, cost and time to market. He has published more than 200 articles on embedded software development techniques, is a sought-after speaker and technical trainer and holds three degrees, including a Master of Engineering from the University of Michigan. Feel free to contact him at firstname.lastname@example.org, at his website www.beningo.com, and sign-up for his monthly Embedded Bytes Newsletter.