Open Source vs. Proprietary: an Embedded Hardware Point of View

It is one of the common questions of the embedded world: “Open source or proprietary software; which is inherently better for my application?”

Fewer things ignite passion in software geeks more than the debate of open source versus proprietary code. The dispute is somewhat equivalent to the hardware debate on which type of capacitor is ideal for audio circuits. While a majority of the world just wants something that works regardless of software licensing provisions, the distinction between “open source” and “proprietary” gets a lot of philosophical discussion in many areas of technology.

In the context of going to market with an embedded system, which model is better, proprietary or open source? Sometimes you don’t have a choice.

Source Code 101

Source code has a lot to do with the concerns that businesses have in terms of control of their destiny and potential future costs. What is source code, anyway? Source code is human-readable (mostly) instructions to tell a processor what to do. A computer cannot do anything with source code. It must be compiled or interpreted into binary object code, something a computer understands. If you have the source code, you can modify it, recompile it, and produce a modified application that meets your specific needs. Looking at the source code also lets you do an independent review to ensure there are no bugs or hidden backdoors. Operating systems can also be open source and therefore transparent, but work at a deeper level on the processor to provide interrupt handling, peripheral management, and more.

Operating Systems and Compilers, Anyone?

With open source, you are not beholden to another party to keep your product working (whether it be open source operating system, program, or software development tool.) You can work on it yourself, if necessary. Proprietary-based systems, if they are not home-grown by you (thus belonging to you), are open to the possibility of getting “orphaned” if the proprietary software is abandoned. For example, an operating system (OS) might be purchased from and maintained by another company to run on your end product, but what happens if that company gets bought by your competitor? Updates to include new technology or bug fixes would be abandoned on their schedule. Worse yet, you might be ordered to cease and desist using the software immediately, if you are not specifically protected against this kind of activity through an existing contract.

On the other hand, if you go with an open source compiler or operating system, you need to know what you are doing; open source is rarely turn-key in the embedded world. You also need to have reasonable expectations of what the open source maintenance community can do with respect to your need-for-speed in going to market, since open source may adopt a specific technology at a comparatively glacial pace. You can always roll up your sleeves and create and contribute to the open source community for what you need, but even then the acceptance into the formal repository (e.g., the maintained Linux “tree” for a specific embedded processor) may not proceed as you would like. If you do not contribute your changes back to the community, which is entirely legal, no one will help you maintain it but you, no matter how good you think it is (this is known as “forking” the code.)

It would be remiss not to include a mention about open source hardware (OSHW). OSHW is similarly “open,” especially if source files for the schematics are provided, but the openness may stop at the doorstep of the SoC, processor, or a support chip on the board. OSHW can also be supported by proprietary development tools, as well, depending upon the processor. Nevertheless, “open source” as a concept has broadened to the world at large, infiltrating all areas of design, not just electronics. “Openness” generally refers to publically sharing information so that others can reproduce the design (whether physical products, software, education, or ideas) and get the same results. Indeed, an open source movement is afoot, and most would say it was inspired by Linux, which got its start in late 1991.

Pros, Cons, and Misconceptions

Both open source and proprietary software have equal shares of misconception. Further complicating matters for open source is the vast number of licenses that can confuse even the savviest technologist. For the purpose of this article, we will use the open source definition as provided by the Open Source Initiative, which states, “Open source software is software that can be freely used, changed, and shared (in modified or unmodified form) by anyone. Open source software is made by many people, and distributed under licenses that comply with the Open Source Definition.”

Some of the most popular open source licenses include the Creative Commons, Apache License, BSD, GNU General Public License (GPL), MIT License, and the Mozilla Public License. For a complete listing, you can head over here. Open source licensing varies, but a typical license ensures that if you build or expand on an open source project, you are given attribution and those who build upon your work must also release their code under the same license. This prevents someone else from unfairly profiting on your hard work, or at the very least, making it much harder to do so.

Open source software is fundamentally about sharing and gaining wisdom from the crowd. Many larger, non-corporately backed open source projects rely on a small army of volunteers to develop, debug, and document source code. Some projects gather a significantly large enough community where developers can receive some modest amount of funding via donations solicited from end users. The collaborative nature of open source projects between the user community and developers can become quite a remarkable resource to entice new users and coders alike. Recognition for participating in an open source project is another alluring appeal for independent developers. Some people contribute in order to learn from others, but you need a humble attitude and thick skin if you are in any kind of learning mode, since open source is open in every way. Your code will get picked apart, criticized, and praised (sometimes by the same person.) Contributed code in an open source community that gets into the maintained version is the best code, because the coder’s technique is there for all to see and comment on.

In contrast, with proprietary software, the proprietor retains significantly more in legal rights by enforcing copyright restrictions on their code. Typically, proprietary software is “closed source” with no access to the source code even when the application is purchased. The complete list of limitations is typically in an “End User License Agreement” (EULA) or some other legally binding fine print. These agreements describe what the user of the software can and cannot do with the application. This tends to involve restrictions on modification, sharing, redistribution, and reverse engineering of the application. At the end of the day, proprietary software is about protecting Intellectual Property (IP). For example, if you have invented an algorithm that is so unique and game changing (e.g. compression or search algorithms) that it becomes a “secret sauce” to your product (a.k.a. “trade secret”), then proprietary licensing is perhaps a wise move. On the other hand, if your software is a “one-of-many” solution, then open sourcing your code might give you greater adoption, or at least goodwill.

It is important to note that “open source” does not necessarily mean cost-free, and “proprietary” does not necessarily mean that it costs money to use. Nor is it true that open source is only for amateur projects while “professional” products are all proprietary. However, should you select a proprietary platform, be sure to understand the licensing fee structure, if one exists, so that you aren’t shocked with a bill when you are ready to go into production. Otherwise known as “royalties,” the fees associated with acquiring a license allow the developers to dedicate their time to refining and debugging their application-specific code. From a developer perspective, this means that proprietary OEM support should be prompt and the support will ideally be there for a long time (in some cases, a maintenance and support agreement must be paid on an annual basis.)

Since commercial and industrial embedded systems tend to have lifespans that last many years, if not decades, the longevity of reach-back support can be crucial. Support for open source software might in some cases be more unreliable in comparison to proprietary. Should a key developer decide to quit working on a project and no one steps up to take on the job, an application can grow stale quickly, no longer supporting technology upgrades like USB 3.1, for example. But at least you have access to the source code and can make changes if you have enough expertise, time, or money to hire someone to do it for you. With proprietary code, there is no legal basis to access source code or make changes without the originator’s consent.

Just to make matters even more complex, it is also possible to have software that contains a mix of both proprietary and open source code. For example, Apple’s OS X operating system builds upon the open UNIX operating system. However, the windowing system that drives the OS X GUI is not open source. There are many embedded systems that have open source operating systems with custom adjustments. Google’s Android operating system source code is taken and customized by carriers to install on their authorized phones, which is legal but is not necessarily supported or maintained by Google. (This “customization” also generally results in “bloatware”- unnecessary applications that cannot be deleted that drain the battery and use up memory.)

Bits Meet the Metal: Open Source & Proprietary in the Embedded World

Historically the embedded electronics world has been dominated by proprietary software, including things like the Integrated Development Environment (IDE), Real-Time Operating Systems (RTOS), and firmware libraries. Platforms such as Arduino are attempting to change that, but many “professional” platforms remain locked behind proprietary license agreements. It’s not just open source communities that are pushing for change, the U.S Department of Defense and NASA are also pushing for open software architectures to enable collaboration, data sharing and prevent “vendor lock,” where a project grows but is locked in to one vendor, thus reducing total life cycle and increasing future development costs.

Some established embedded-platform OEM companies are beginning to respond to developers' desire for more open source solutions. Others are at least rethinking the licensing fees in hopes of attracting, or at least not losing, developers for their platforms as open source slowly pervades the embedded ecosystem. From IDE (a development tool) perspective, the open source Arduino IDE is rather spartan when compared to other platform IDEs such as Texas Instrument’s Code Composer Studio, which includes many significant professional development features such as power consumption monitoring. TI is also supporting an open source product called Energia as an alternative, for various TI microcontroller products. STMicroelectronics’ STM32 Open Development Environment (STM32ODE) is another example of a company that is adapting to the changing licensing landscape. The STM32 Open Development Environment includes their OSHW Nucleo boards (see below). In the end game, TI and STM are chip makers focused on providing cutting-edge integrated chips, but they are astute in understanding that silicon is not the whole embedded picture. In one way or another, software touches all electronics; even IC designers use software tools like Synopsis, Mentor Graphics, and Cadence, to name a few) to design IC layouts.

Open Source: Not Just for Software Anymore

Hardware is also undergoing an “open source” revolution. The discussion surrounding hardware is perhaps unsurprisingly more complicated. Software source code is granted copyright protection as soon as it’s written down. Furthermore, nothing “tangible” comes from source code. In the hardware world, that isn’t true. CAD design files or 3D printer STL files eventually get turned into a physical product. Does copyright apply to the design files only, or does it also cover the eventual tangible product? Even if conventional wisdom holds that copyright doesn’t apply to hardware, these are uncharted waters that haven’t been tested in the courts yet. There are specialized open source hardware licenses, with two of the most popular being the CERN Open Hardware License and the TAPR Open Hardware License.

Bottom Line

With respect to the embedded development world, the choice of using open source or proprietary software is often driven by the hardware selection. If a microcontroller or FPGA that meets project specifications only comes from a vendor that has locked their code behind a proprietary license, then you really have little choice but to accept it. You might try to negotiate additional data rights, but not without adding significant cost to your budget. With that said, as hardware becomes more commoditized and multiple vendors offer similarly capable hardware solutions, the more software licensing may affect the balance of overall offerings and create differentiation. Therefore, it’s reasonable to assume that as products become more commoditized, more vendors will offer choices on the software side of things. The licensing structure of the IDE, (RT)OS and libraries may be enough to sway developers to pick one platform over another. There is no doubt that the business model for open source licensing and products is establishing itself in the mainstream, especially as open source gains momentum with a growing community, contributors, and as the finer points are settled in court and establish precedence.

---

Michael Parks, P.E. is the owner of Green Shoe Garage, a custom electronics design studio and technology consultancy located in Southern Maryland. He produces the S.T.E.A.M. Power Podcast to help raise public awareness of technical and scientific matters. Michael is also a licensed Professional Engineer in the state of Maryland and holds a Master’s degree in systems engineering from Johns Hopkins University.

Lynnette Reese is a member of the technical staff at Mouser and holds a B.S. in Electrical Engineering from Louisiana State University. Prior to Mouser, she completed a combined 15 years in technical marketing in embedded hardware and software with Texas Instruments, Freescale, and Cypress Semiconductor. She started her career as an applications engineer at Johnson Controls.