Today, a growing number of companies vie for the attention of embedded systems developers seeking to build and deploy on Linux. Which are going to grow, thrive, and eventually lead the industry? Which technologies, licensing practices, business models and market forces will determine the leaders?

The use of Linux as an embedded systems platform represents a major change in the technologies and economies of building embedded applications. The power of Linux as an operating system, and the new types of business models for licensing, represent a marked change from “business as usual” practices that have dominated embedded design for the last 20 years.

Even with the short history of the open source approach, there is more than enough evidence to demonstrate the superiority and survivability of a royalty-free business model. Proprietary, closed source technology and binary product royalties have always been an encumbrance on embedded developers, slowing down business operations, lengthening design and development cycles, and delaying the availability of leading edge technology. Open source approaches enable rapid decision making, more effective engineering, rapid availability of leading technology, and encourage a tighter vendor-customer relationship after the initial product sale.

This article reviews the strengths of the Linux open source, royalty-free business model, and why it is the most appropriate model for the future of embedded systems design and deployment.

Linux for embedded systems

The embedded market is highly fragmented, and is exploding with new designs with no legacy software. Linux will sweep through the embedded systems markets, and this rush has already begun. The reasons are many:

• Reliability — Linux is an extremely robust and comprehensive operating system. Linux provides extremely high technology value to embedded systems designers.

• 32-bit CPU support — Linux provides tremendous technology and quality advantages over traditional embedded operating systems, by making use of all the features of modern 32 bit microprocessors. Such processors are becoming extremely common in embedded designs as costs continue to fall and computing power requirements continue to rise.

• Open source — Linux frees embedded system designers from the tyranny of proprietary operating systems. The visibility of source code increases the efficiency of design engineers. It increases their ability to create optimal designs. It increases their productivity when faced with easily resolvable (with source) system defects outside of normal business hours. It frees developers to choose the best and most capable operating system technology and service provider available. Most significantly, it eliminates the risk that OS technologies on which developers base their product designs, training and R&D infrastructures will suddenly be discontinued when one OS company swallows up another! Another advantage of Linux is that the need for source code escrow contracts is eliminated, reducing purchasing time and cost.

• Innovation — Linux is a hotbed of innovation. New software technology of all types is being developed on and within Linux first and foremost, for all the reasons herein, and is immediately available to all.

• Talent pool — There is a rapidly increasing pool of Linux trained talent available worldwide, far greater than is available for proprietary technologies.

• Cost — Linux carries no royalties, reducing cost of goods sold and bolstering margins. R&D departments can make the decision to deploy Linux without lengthy production department involvement, greatly reducing the time to close on operating system selection and project initiation.

The Open Source snowball

Linux itself is GNU Public Licensed (GPL) source code. GPL software ensures that the value added by one engineer is available without encumbrances to the inheritor of the code. The only costs to bear are the direct engineering costs of using, designing with, or modifying the resulting software, greatly reducing the “cost of ownership”.

It is the nature of open source to snowball, to grow in mass and momentum with use. Because Linux is open source, over time, new capabilities are created for it (in it or running on top of it) using open source (GPL) licensing. This inevitable process is a function of Linux itself, and its continued development and usage by and for engineers. This snowball effect lies at the heart of the open source “movement”.

The transitory nature of proprietary add-ons

Notwithstanding the open source essence of Linux, it is also possible to add proprietary components to the overall operating system (provided they are not statically linked to the kernel). For example, I/O drivers, graphics capabilities, specialized browsers, and unique utilities might be offered on a licensed, royalty-based, basis as options to be used along with open source Linux components.

Such components may be successful during the period in which they are the only solutions available. However, assuming the need they satisfy is substantial, the tremendous power of the open source phenomenon is eventually (often quickly) brought to bear on the requirement. As a result, an individual, a loosely formed group (an “open source project”), or a company develops a robust open source solution — generally superior to its proprietary predecessor.

At this point, the proprietary add-on tends to fast-forward to its “end of life” phase. Users who have made a substantial investment in the proprietary technology are stuck with using it until they can afford to migrate to the newer open source solution. The open source solution quickly moves ahead of the proprietary technology in capability and robustness, for all the reasons cited by Eric S. Raymond in his open source manifesto, “The Cathedral and the Bazaar”.

Traditional software business models

In the traditional embedded system development model, there were two choices: build, or buy. That is, expend internal resources to develop the required operating system software, or license a ready-made embedded operating system and pay the provider the required fees. Either way, there is a cost to the customer.

Traditionally, the “build” scenario means hiring a team of experts to address all the technology and software development requirements. The breadth and depth of that team depends on many factors, including the nature and complexity of the required technologies and software, the project's time-to-market requirements, and the willingness of management to expose the program to risk. Similarly, in the “buy” scenario, when a proprietary operating system is acquired from a vendor, these same types of costs must be absorbed by the vendor — and so they are funded by a combination of purchase price, support fees, royalties, and professional services.

A third way: joint ownership

With Linux, however, there is a third alternative to “build” or “buy” — “partner”. With “build”, the customer invests in doing everything. With “buy”, the customer purchases the required components and support from a vendor. With “partner”, the customer and an outside provider work together as a team. The provider manages Linux as a platform, including sourcing, integrating, and testing Linux technology, extending it to meet current and future embedded application needs, adapting it to meet unique customer requirements, and supporting the technology as problems arise.

This teamwork strategy works extremely well with Linux, because there is no one company that actually “owns” Linux, due to the nature of the GPL software license. Since both the customer and the outside provider own Linux equally, they can jointly share in the efforts and rewards of a successful Linux based embedded project.

What business model supports this kind of partnership? Clearly it is not one of proprietary product licensing, since that puts the customer in a subservient position.

Monetizing value

Yet, the customer seeks something of clear value from the provider — expertise, know-how, customization, adaptation, support, etc. Obviously, customers are willing to provide profitable remuneration in return for value received. Therein lies the opportunity for a successful embedded Linux business model.

Rather than adding proprietary components in order to create a license/royalty income model, which is subject to obsolescence and also puts the customer at a disadvantage, a more long-lasting and equitable embedded Linux business model — and one consistent with the shared ownership philosophy of GPL — is this simple value proposition: the customer pays for value received.

Typically, that value will include packaged software distributions, development tools, engineering services, training, and technical support. It is completely practical for these financial transactions to occur without a royalty based relationship, and without the artificial injection of proprietary intellectual property.

Mitigating risk

Some have questioned the viability of a royalty-free embedded Linux business model. Even were this model to prove non-viable, wherein lies the risk to the customer?

If a supplier provides excellent product and service, but falters for financial reasons, one of two causes exist: customers are finding a superior open source value with another vendor; or customers no longer need an open source provider and are able to achieve their product development goals by some other means. In either of these cases, it is the customer who comes out ahead.

This raises the question: Who really benefits most from embedded Linux solutions encumbered by royalties and proprietary content — the customer, or the vendor?

---

About the author — Kevin Morgan is Vice President of Engineering of MontaVista Software. Kevin has 20 years of experience developing embedded and real-time computer systems for Hewlett-Packard Co. A computer industry driver since 1980, Kevin was a member of the HP 1000 computer software design team. Kevin's expertise is operating systems research and development. While at Hewlett-Packard he worked as engineer, project manager and section manager across five operating systems. Most recently serving as HP-UX Operating System Laboratory Manager, Kevin was responsible for overall HP-UX release planning, execution and delivery for Hewlett-Packard server computers.

---

Do you have a question or comment on this article? Talkback here!

 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.