Open source software is everywhere and has the potential to help businesses accelerate development and improve software quality. Achieving these results can be challenging if care is not taken.
By Jacob Beningo – 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.
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
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. more>