Linux has been a mainstream embedded operating system for many years. And yet, the licensing and development model of open-source software is still little understood. Let me explain. I’ll start with that that word “free,” which has two meanings—free as in “you’re free to use it,” and free as in “nothing to pay.” Linux is free in both senses, so it’s a win-win. The software engineers are happy because they get access to a large body of robust, mature source code, and the product managers are happy because there are no license fees to pay. But, of the two meanings, the first is the more important. Let’s be clear: Do not choose Linux just because it’ll save license fees. Choose it because it’s the best solution for your project.

Next, let’s consider the term “Linux.” Strictly speaking, Linux is the kernel of an OS, the source code of which can be obtained from www.kernel.org. More generally though, Linux is a common shorthand for all the open-source components needed to create a working system based on a Linux kernel. That includes the toolchain, the bootloader, the system libraries, the command shell, the system services (also known as daemons), the end-user applications, and so on.

So, where does all this free software come from? Open source is an ecosystem, with various players fulfilling different roles. Each has their part to play, each has different motivations and revenue streams.

First is the open-source community, composed of a loose alliance of developers from many different backgrounds, but with a common motivation to write software and share it with others. Why do they do it? Partly because software engineers like writing software and partly because open-source projects generate a sense of camaraderie, in which you get recognition for the contributions you make. Some work purely for the buzz of doing so, but usually the core team on a big project is funded by not-for profit organizations, such as the Linux Foundation, or by companies with a commercial interest in the technology, like Google, Red Hat, IBM, or Oracle.

You would think that putting thousands of highly individualistic programmers together would result in chaos. But that doesn’t happen because open-software projects, the successful ones, at least, are highly organized. Each project is managed by one or more maintainers, who control who has commit access to the source-code repository and which changes will make it into the final product.

The most obvious example is the Linux kernel, lead by Linus Torvalds, and assisted by a large band of sub-system maintainers for each critical part of the kernel. Most other project maintainers keep a low profile and aren’t known outside the project’s circle of developers. Nevertheless, they control some of the key components on which we depend, including GCC, OpenSSL, Apache, and GDB. Contributors to open-source projects are a self-selected group of highly-motivated, highly talented software engineers.

The next important group of players are the vendors of the system on ICs at the heart of most embedded systems. In each case, the vendor must demonstrate that Linux runs on the platform. Consequentially, they all employ large teams of Linux kernel engineers, toolchain specialists, and graphics library developers to ensure that Linux and Android work well on their platform.

For large or specialized products you may be designing a board around an SoC. For small to medium product volumes, it’s cost effective to use a single-board computer (SBC) or system-on-module (SoM) rather than taking an SoC and designing from the ground up.

This brings me to the third group. Once again, they often have to show that they have support for Linux/Android to sell products. They take the kernel for the SoC vendor, add support for the features they’ve added to the board, and supply it with a Linux OS. They typically use Yocto Project to generate the full operating system, but Debian Linux is also popular. They’re often a weak link in the chain, since many of them are are small companies without the resources to give full support to the OS they distribute.

A fourth group are the companies that provide commercial support for embedded Linux. They can provide off-the shelf solutions for a range of hardware from SoM and SBC vendors, and can create custom Linux builds. Examples include Mentor Graphics, Wind River, Timesys, Sysgo, and MontaVista. They may bundle in proprietary components for a license fee.

Fifth, you must have noticed that there are cheap, widely available boards, such as the Raspberry Pi, which are well supported by the community. Several are available in “industrial grade” versions that have higher spec components and can endure wider temperature ranges than the consumer versions. In addition to the Raspberry Pi, boards hail from Beagleboard.org (based on TI Sitara and OMAP3 processors), Minnowboard.org (Intel Atom E38xx), and www.wandboard.org (using the NXP iMX6). All of these, except the Raspberry Pi, are open source hardware, meaning that the schematics and board layout files are freely available (in both senses of the word), letting you customize the board to your needs. The information for the Raspberry Pi is also available, but the SoC is not, unfortunately.

Open source has always been about giving you choice, and now you have many. Which you choose depends on the in-house skill level and the time you want to devote to it. There may not be anything free lunches, but there is the freedom to choose the best solution for you.

Chris Simmonds is a freelance consultant and trainer who has been using Linux in embedded systems for over 15 years. He is the author of the book Mastering Embedded Linux Programming, and is a frequent presenter at open-source and embedded conferences. You can see some of his work on the Inner Penguin blog.