Open Source Software (OSS) is an attractive alternative to proprietary software platforms. There’s a lot to love about OSS. Lower cost is a primary decision driver for many companies. Others want to enjoy the freedom and flexibility to modify the software to their particular application requirements. Some companies don’t want to be at the mercy of the direction—or lack of direction—of proprietary software roadmaps.
There’s also a lot to fret over with OSS. With so much open source development taking place, OSS is a moving target. This is particularly true when working with modules. One of the key benefits of using modules is that you can bring technology into an application without having to become an expert in that technology. Gumstix, for example, allows you to build customized modules by dragging blocks of functionality into a project. The customize part is that you choose the functionality you want. The fabric of interfaces connecting your chosen technologies is handled for you. In addition, the firmware you need to manage peripherals is prepared for you for your chosen operating system.
All good so far. What gets challenging is when the open source software you’ve chosen evolves. Updates to an operating system, for example, can subtly change how a device operates. Thus, testing is required to assure your device will continue to operate as expected. Some companies avoid this issue by locking in the version of software they use. Devices that work will continue to work.
Except—and this is a big exception—security messes all of this up. You can have a perfect design, but when a new security vulnerability is discovered, your perfect system needs an update. You now have a choice:
Be an ostrich: You can pretend that security doesn’t matter to your application. Good luck with that. As we see more and more often in the news, hackers are using the vulnerabilities of IoT devices to create havoc, everything from taking over IoT devices to using IoT devices to hack into the network. If your IoT product isn’t secure, companies are starting to get savvy to this and will purchase from someone else (i.e., a competitor) who is actually concerned with security.
Make the changes yourself: You can download the software image used in your modules. This becomes your master image. To adapt to security changes, you then carry over the changes you want in later versions of the open source software. But not having to manage software was one of the reasons for buying a module in the first place. Not an ideal choice.
Take advantage of test automation: The company that makes your modules is keeping up with all the important OSS updates. Gumstix, for example, is always moving to the next version of the Linux kernel. Builds are made using the Yocto environment, and patches are kept up-to-date for everything in the build environment. There’s still the testing aspect to consider, however. After all, you need assurance that the new code will perform as expected.
That’s where automated testing comes in. Gumstix has instituted several layers of automated testing. At the highest level, your customized boards are individually tested before being shipped out. At lower levels, Gumstix is working towards a continuous test automation environment. By running its entire line of production boards through repeated rounds of testing, OSS is tested again and again.
One advantage of continuous test automation is that the software used on your modules is being tested in a diverse multitude of applications. Specifically, every time Gumstix ships a custom board, this provides another data point that the system is stable and reliable under a completely different set of operating conditions.
OSS is a moving target that can be hard to manage on your own. Or, with the right partner, it can be seamless to manage. The choice is yours.
Take a look at some Gumstix customer success stories or contact Gumstix today to learn more about their products, design tools, and services. Or try out Upverter, their customized module design tool, for yourself.