10 Steps To Overcome Your Fear Of Using Open Source Software
By Shahid Shah, president & CEO, Netspective Communications
Follow me on Twitter @ShahidNShah
The entire Internet runs on open source software (OSS) and, if we used it more in medical devices, it would lead to reduced costs and increase the quality of devices. If you ask some regulatory affairs folks in medical device companies, they think OSS is too “dangerous” for use in safety critical systems. The most common excuse given by engineers is that the regulatory compliance folks will not allow OSS or that the FDA will disapprove. There is plenty of evidence to the contrary, however, because the FDA hasn’t really rejected devices due solely to the use of OSS. The lack of OSS use in medical devices and healthcare IT circles in most cases likely stems from a lack of experience with OSS at the senior executive and regulatory compliance ranks within companies. This is a summary of a quick 10 step process that R&D groups can use to properly experiment with and include OSS in safety-critical systems.
1. Understand open source licensing, remove the fear of intellectual property (IP) loss.
One common fear is that using open source will “leak” your own IP or cause IP loss. However, open source licenses allow for inclusion of open software in your device(s) without harming your own IP rights or proprietary claims. There’s no need to fear that if you include open source you’ll accidentally relinquish proprietary IP. If you’re not sure which licenses to use, start with the Apache Software License (ASL), Mozilla Public License (MPL), or LGPL, all of which are friendly enough to use in commercial software.
2. Understand where code is coming from and what test harnesses are included.
If you use the right license (e.g. ASL, MPL, LGPL), there’s no fear of IP loss but, if you use the wrong license or library linking methodology, you could accidentally end up getting into trouble. That’s why you need to keep track of precisely where you’re getting the OSS code from. Also, try and focus on incorporating OSS that already contains good test harnesses so you can prove to yourself, your QA teams, and your regulatory teams that the software works for its intended uses.
3. Connect with the developers of the OSS you’re using.
If you’re going to rely on some OSS, get in touch with the developers of those projects. Most OSS developers are quite community-oriented and usually helpful. In case your senior executives, regulatory, or QA folks have questions, you’ll be able to answer them easily if you’re in touch with the original developers. Also, if you need changes, some developers will likely be available for hire for making changes or helping with validation.
4. Monitor the revision control system of the open source project.
My general recommendation is that you not download binaries for OSS projects. Instead, connect directly to the Subversion, Git, CVS, Mercurial, or other revision control system (RCS) the OSS project developers are using. You should get used to various RCS systems and not just the one you’re using in your own shop. It’s much easier to know precisely what lines of code, modules, etc. are changing when you’re directly connected to the RCS.
5. Create your own binaries so that your team trusts the builds.
As soon as you’re connected to the revision control system of the OSS project, build your own binaries using the existing make or build scripts. If there are no make or build scripts, you should not use the OSS (if you have other choices), or you can create your own.
6. Create a process to securely sign the binaries.
When you create your own binaries, you’ll want to make sure you digitally sign the binaries and ensure that your devices / gateways have firmware or other software that verifies the binaries.
7. Create your own deployment packages.
If you’re running on Windows, you’ll want to create *.msi packages. If you are on RedHat, you’ll want to create RPMs and, if you are are on Debian / Ubuntu, you’ll want to create *.deb packages, etc. You will want to have a proper package management approach that your QA and regulatory folks have confidence in and easily understand.
8. Create a process to test the binaries using code coverage tools.
This step could be done before or after step 6, but you’ll want to be sure you run the test harnesses with code coverage turned on. That way, you’ll know what test coverage you can achieve in the various OSS packages you build. Try not to go to your regulatory folks and say “we can trust OSS package X” without some sort of real evidence — test harnesses and code coverage tools are good starts.
9. Keep an eye on changes coming in from the source and retest regularly.
Figure out how you’ll ensure that packages stay up to date and will be regularly tested (with code coverage). You might want to read an RSS feed, get regular e-mail notifications from forums, etc. Each time the code changes, you probably don’t want to upgrade immediately. Rather, you’ll want to stay abreast of the updates.
10. Review your process with the compliance officers and get their buy in.
Share your process with your QA and regulatory folks early and often — they’ll have more confidence in your process when the process is documented, scripted, and easy to understand and follow.
If you do things “properly” and follow a good, solid OSS integration process, then business executives, technical executives, engineers, and especially compliance officers can (hopefully) be convinced that the code can be trusted. The more proprietary software we create in medical devices, the less interoperable they will be, so it’s time we get our design team folks on the OSS bandwagon.
Shahid Shah is an open source advocate, chairman of the OSEHRA Strategic Advisory Board, and an award-winning medical device hardware / software design coach with 25 years of technology strategy and engineering experience. You can reach him via Twitter or email.