Open source solutions are easy to download and use. In most cases, they are “free.” Then again, there are different definitions of free.
Free as in speech: Open source technology is not under the restrictions of proprietary licensing that would prevent a developer from modifying it as they wanted.
Free as in beer: Open source technology doesn’t cost you any money up front, but you might pay for it in training hours or support needs.
Free as in puppy: Taking on an open source solution for long-term use is a responsibility. It may require nurturing a community around that solution so it continues to develop, or help in building a new solution if a previous one becomes unsupported and obsolete.
Again, open source may be easy to download and use, but it is not as easy to download and use it successfully. Making a business case for it can involve costly licensing compliance and security certification, copyrights, and export control, especially when dealing with the safety-critical standards of aerospace and the medical market. It can require stakeholders to be pushed, sometimes unwillingly, toward new ideas, all the while maintaining a reputation as a trusted and secure solution provider.
The software engineers at DornerWorks have been working with open source tools and embedded Linux environments for years. In fact, they contribute regularly to the open source community through development on Xen Project hypervisors like Virtuosity®, the seL4 microkernel, and other applications. But even the experts still ask questions, and before undertaking a truly open source project, such as something licensed under the GNU Public License (GPL), and using other open source tools to do it, here are a few that are well worth asking.
Many open source projects are driven by larger commercial interests. As such, the solution may specifically address a hardware profile that is not readily available.
The Virtuosity® hypervisor, based on open source Xen, for example, was ported to both ARM and x86 targets, supporting both Xilinx’s Zynq UltraScale+ and NXP’s i.MX 8 architecture. These are powerful processors, and while the software running on them may be “free,” the hardware is not. Implementing these processors on a fleet of MPSoC or SOM devices will require substantial financial resources.
Open source hardware design, at least, does have a community of supporters. The field is a little younger than the software side—its origins date back to the late 90s—but it is no less important to those interested in building stronger businesses with open source tools. Xilinx offers such resources in the form of 32-bit microcontroller-grade Cortex-M1 and M3 cores available for Xilinx’s Spartan, Artix, and Zynq chips. As an Alliance Program Premier Partner, DornerWorks can even show you how to make the most of these designs in a fully functional product.
When building an operating system, specialized Linux builds using Yocto Project or Buildroot hold value in their customizability, but wrangling the complexities of these tools requires engineering hours and expertise some small businesses may not have. The same goes for implementing extreme security with the seL4 microkernel. There is great potential for value but if you plan to learn how to implement it yourself, it will take some time.
Like building a new house, developing a product or business with open source technology affords greater customization.
On the flip side, there’s also greater risk.
Open source can provide the raw materials for your project, but companies that build their own solutions are also on the hook for anything that goes wrong. With all eggs in one basket, the results can be disastrous if a specialized tool doesn’t work anymore.
That’s also why building a supportive community needs to be part of the blueprint, Key partnerships with other organizations involved in open source development, combined with a culture of mentorship, can build resilience and mitigate the risk of obsolescence.
There are costs inherent in adopting any new technology. Moving an entire business, or even just a single segment, from a proprietary system to a Linux-based solution will require time and training to ensure legacy applications and data are transferred securely and kept intact.
The U.S. government has been very interested in open source technology since even before reporting a yearly expenditure of $6 billion on software licenses and maintenance. Finding duplicate licenses and negotiating volume pricing has helped save millions each year, and a commitment to open source will likely save more, though not without thousands of hours of migration work.
Still, it seems worth it. As well, the Federal Source Code policy now dictates that government agencies must release at least 20 percent of their internally developed code to the public domain.
A number of open source licensing options are explained in this post, but understanding what they are meant for can take much less time than actually managing them on a project. Once the top-level licensing is squared away, developers need to map out module-level licensing requirements, and there may be many, even in a single piece of software. New versions and releases need to be cataloged and licensed appropriately, as well.
This is going to take some time. Whether that’s your own time, or the time of someone you pay to manage the responsibility for you, maintaining licensing compliance is a critical step. Getting it right will help you grow your business but getting it wrong could be costly. According to a report by Industry Week, the average cost of licensing non-compliance is about $20,000. That cost increases quite a bit when dealing with products that have already launched or if court costs are incurred.
The earlier in the development stage licensing policy violations are identified, the less they will likely cost.
Downloading the source code is a big step. Making sure the right hardware is available is just as important. Following that, a developer will need to learn how to use the software, install it, configure it, import data from the legacy system, and customize the setup to work well with other existing applications.
All of this is important to building an effective system, but it also takes time and could lead to temporary setbacks in meeting productivity goals.
Once the system is in place, it’s time to get others to use it.
As individuals are onboarded to the organization, or new features are added to the project, the team will undoubtedly need some time getting familiar with the software. Developing experts who can mentor others on how to best use the tools available can accelerate this stage and prepare teams to make more of a business case for their open source solution, otherwise help needs to be found externally.
Where not available from colleagues or free forums, software support can often be found in the form of paid subscriptions. Update rollouts may also be available for free, though it takes some footwork to learn if and when they’ve been committed to a particular project.
Any updates made by the organization need to be maintained by the organization, though. To use the home-building metaphor once more, those pipes aren’t going to plumb themselves.
Open source tools are built and maintained by developers who see the value in keeping them available to all. Likewise, organizations that borrow code from these projects might think about contributing their own additions back to the source, or elsewhere contributing to the community.
A long-time supporter of open source technology, particularly embedded Xen, DornerWorks has made a number of contributions back to the same code base from which it has borrowed. Projects like the mathematically secure seL4 microkernel, maintained by Data 61, the KISS FFT library, created by Mark Borgerding, and the Xen Zynq Distribution, now Virtuosity, are all examples of existing open source projects that have been augmented and improved upon by DornerWorks engineers.
“Membership” in the open source community requires accountability in return for freedom, collaboration, and shared responsibility. It’s been modeled in other fields to great success, from agriculture to education. And, as a meritocracy, open source allows the best solutions to rise to the top by way of participation and trust.
If you are considering using open source technology or your next project, you should weigh the costs involved. DornerWorks can help you do that and lay out a plan to meet your product goals. Contact us today to schedule a free brainstorming session and start off on the right path to success.
