Open source software is everywhere and has the potential to help businesses accelerate development and improve their software quality. Achieving these results though can be challenging if care is not taken. Here are five best practices for utilizing open source software that will help leverage open source software successfully.
Best Practice #1 – Use an abstraction layer to remove dependencies
One of the common issues I often see with code bases I review is that developers tightly couple their application code with the software libraries that they use. For example, if a developer is using FreeRTOS, their application code makes calls specific to the FreeRTOS API’s in such a way that if a developer ever decided to change their RTOS, they’d have to rewrite a lot of their code to replace all those RTOS calls. Now you might decide that changing libraries is rare, but you’d be surprised how often I see teams start down a path with one OS, library or component only to have to go back and rewrite their code when they decide they need to make a change.
The first thing that 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 an 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 API’s. 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 very own sandbox without much thought given to other components that it may need to interact with. 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 few good examples include 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 that 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 out there 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 that 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, that is, the readers definition of quality code may be very different from my definition.
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
- Testability
This will at least help a developer understand what they are working with along with the potential issues and pitfalls.
Best Practice #4 – Have the license reviewed by an attorney
Open source software licensing can be a difficult area to navigate. There are a dozen or so different licensing schemes which place different requirements on the user. In some cases, the developer can just 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 products secret sauce which could damage their competitive advantage in a market. While these licenses have become more human readable in recent years, product developers are running a business and it is imperative that they have an attorney review the software license to ensure that everything is above board. Yes, no one wants to spend the money, but it is a cost of business and can potentially save much more money in the long run if a mistake is made.
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 that they can go on a forum and ask questions and that they will usually get a response quickly. 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!
Conclusions
Properly leveraging open source software can dramatically benefit the development team using it. However, in order to be success, developers need to make sure that they select their open source components wisely. This includes abstracting out the component to ensure their application remains flexible and maintainable. It also requires that a developer carefully review the open source software, assuming its not Linux, to ensure that 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.
