Members of the open source movement contend that they have found a better way of writing and distributing software. Because the cost of software has increased as a fraction of total development cost, the movement is appealing to embedded developers. However, I question whether we are going to see much more from this movement than the limited benefits already seen.

Over the years, the free software movement has shifted from a set of principles based on building software independent of a commercial community-the original GNU (“GNU's Not Unix”) approach-to building software that could blend with commercially supported offerings. Most recently, the movement has shifted again-from an engineering philosophy to a business model (climaxing in several well-publicized stock market IPOs)-and this has transformed open source from a guiding principle into a marketing policy.

While the open source movement, in its many guises, has undoubtedly made valuable contributions to the engineering community, I contend that in its present form and direction it has little more to offer either as a business model or as a software construction model. I further contend that open source offers little that has not appeared before.

Nothing new
The three basic tenets¹ of the open source movement are that software be made available in source code form, legally modifiable for any purpose, and redistributable. Individually these tenets have been part of the commercial software landscape. For example, the RTOS market is supplied by several vendors who choose to supply the source code of their product, albeit to paying customers. Modifications of that software are allowed and sometimes necessary to make the RTOS suitable for a specific application. However, a buyer is not typically allowed to give away or sell the resulting code as a new RTOS.

Free redistribution is where members of the open source community believe that they are doing something radical. This is also where they try to turn business madness (giving one's product away) into a business model. But is this really all that new? Let's look at it from a business perspective. Consider that there are some customers who are prepared to pay a reasonable amount for your software and that there are other potential customers who are not willing to pay the price. Some products benefit greatly from the network effect,² which says that the more popular the product, the greater the value of any individual item. This is true for telephones, since it means that I can call a greater number of people on the phone that I purchased, and it is true for operating systems, since their popularity dictates the number of applications, and the amount of expertise, that are available.

It is the network effect that makes it sometimes worthwhile for a business to give its product away for free to everyone, or at least to those who would not otherwise purchase it. (Even hardware costs can be subsidised, as is currently done in the cellular phone and satellite television markets.) Many companies have taken advantage of this in the shareware marketplace. It has also worked to commercial software developers' advantage, in a more subtle way, as the result of software piracy. In a sense, free redistribution and unlitigated piracy are one and the same business model. (It's interesting to think about how these models are already competing in the operating system market for PCs.)

Follow the money
Even if the open source model cannot introduce anything new, perhaps it will still be a success. Maybe the combination of the three properties described above will work more than any one or two of them individually.

Success, of course, can be defined in more than one way. Success can be defined as “makes money,” but I would prefer to define success in this arena as “results in a better product, or better value, to the user.” By the first definition, a number of Linux companies have succeeded in making large amounts of money from their IPOs. After the fashion of a host of other dot-com start-ups, they have managed to trade potential for cash. Like many of the dot-com companies, some will fail to live up to their potential. However, with a bit of luck these companies will contribute a bunch of free software to the community before they go bankrupt.³

Unfortunately, I am not sure that even this benefit will accrue to the programming community. It is significant that the major open source companies are all leveraging already existing open source products, which were originally written with no commercial motivation. I contend that these companies will fail to ever truly innovate. Innovation requires a level of risk, and the returns will never justify the risk when the playing field has been levelled by an open source philosophy. Even the most successful open source products that already exist tend to be imitations of successful commercial products.

In this way open source companies are dodging the two most expensive parts of a product's life. The definition of requirements that is necessary to define a new market is often the part that requires the most vision and innovation. The second, and financially larger, cost is marketing. Today, demand for Linux would be minimal had commercial Unix not already established the definition of a good operating system and market awareness of the problems Unix can solve. Marketing costs are often 10 times development costs, sometimes more.

Open source companies claim that they are putting back into the community by releasing their improvements as open source. Cygnus was, at one point, doing 50% of all new development on the GNU compiler toolchain.⁴ They should be applauded for this, certainly, but the statistic overlooks the fact that they were not contributing 50% of the effort of defining the C language, nor of marketing its benefit. When the open source community is asked to produce products including the costs of definition and of marketing, I believe that the model will fall asunder.

In “Giving It Away,” Red Hat's Robert Young considers how they've succeeded at selling their brand of Linux, when the customer can get the same software for free elsewhere.⁵ He compares this to Evian selling bottled water. Brand recognition counts for more than what the product contains (some bottled waters have even been found to be of lower quality than the local tap water). This model will thrive in the pure commodity market, but the engineering community is faced with challenges that will only be solved with real research and development effort. Young's model will not solve those problems, just repackage the solutions that already exist.

Not only are these new, well-funded companies unlikely to innovate themselves, their commercial interests may stifle some efforts coming from academia or elsewhere. Consider if I were to independently write a cross compiler and release it as open source. A few years ago, if its quality were superior to anything else available for free, the free software community would embrace this new product and it would thrive. Now, following a spate of multi-million dollar IPOs I would face competition from companies with endless financial resources, who already had large investments in the established open source cross compiler GCC. Similarly, internal innovations will be unlikely since they could immediately be improved upon by competitors, once the source had been released. David has grown up and become Goliath.

Commercial pursuits
The IPO market is probably not the best place to look for typical performance of open source companies, since it is so speculative in nature. Let us look instead at some of the established companies that have made a business decision to release their flagship product with an open source license. Netscape (released their browser Mozilla), Zinc (open sourced their graphics toolkit), and Inprise (released the Interbase database as an open source product) all spring to mind. Netscape and Zinc were bought by other companies within months of the open source releases, and Inprise narrowly escaped being taken over by Corel. I am not suggesting that releasing their software as open source caused a collapse, but would rather suggest that the open source release was a last gasp attempt to save a threatened product or company.

Other companies have provided open source releases of products that were not so close to their core business, to encourage the sales of their core products or services. For those companies, the open source package is often loss leader, and in many cases releasing the source itself does not really benefit the community because the product is so inextricably linked to other products from that same company. In the case of AOL, they released one version of their Instant Messaging (IM) client as open source, but then discovered that this provided Microsoft, Yahoo!, and others with a competitive advantage. They immediately released another incompatible (closed source) version. Any developer who was depending on support for the open source version was left high and dry. According to the open source philosophy, it should be straightforward for the user community of that software to support it themselves. In this case, however, the source was useless unless it was compatible with AOL's closed-source server software. Software from commercial organizations will always get caught up in these battles, leaving third-party developers as incidental victims.

At the Spring 2000 Embedded Systems Conference in Chicago, a panel discussion on open source seemed to revolve around one question: “How do we make money from open source?” Making money was neither the primary objective of those who started the open source movement nor of those who made the most important contributions. So this is a bit like asking: “How do we make money out of poetry?” True, some people do make money from poetry but if everyone involved starts to focus solely on what makes money, we are not likely to see much new, innovative poetry (though there would be an incredible number of publishers selling “Best Loved Verses” compendiums).

Encouraging embedded engineers to release code as open source rarely has benefit unless the hardware design is also included. There is no evidence that this is happening and it is unlikely to start. The chances of me being able to use an open source alarm system as a starting point for the commercial alarm system that I wish to develop are slim. When it comes to end-user applications with narrow markets, competition dictates that releasing designs becomes commercially foolhardy. So the only software that the OS community is likely to receive is the material like operating systems and compilers which are not application-specific. This means that the opportunities for embedded engineers to share the majority of the code they write will always be very limited.

Embedded Linux
The greatest desire for third-party software within the embedded community is for an operating system. Linux vendors and a number of market commentators are trying to convince us that embedded Linux will become the preferred choice.⁶ The fact that it is not a real time operating system can be overcome in a number of ways. One technique involves running Linux, including multiple processes, as a low-priority task within a more conventional RTOS.⁷ Another is to embed the RTOS in Linux as a device driver, since device drivers can handle interrupts and generally have better real-time properties than Linux processes.

What is the motivation for these architectures? The phrase “easy portability of application software and programming skills from desktop Linux” gets tossed around a lot. The last time I heard similar logic was in the early stages of Windows CE marketing. It was as bogus then as it is now. Desktop-style applications can only be used in a tiny minority of embedded designs; admittedly, this refers to large volume applications like set-top boxes. Sharing a skill set is bogus too. The vast majority of embedded software developers have never written a single program to the Unix API (nor the Win32 API, I might add) and asking them to learn one of these monsters in order to use an RTOS embedded within it is putting a huge onus on the engineer. Will programmers experienced in Linux on desktop machines now be able to turn their hand to embedded systems programming? This would assume that, apart from the knowledge of a particular API, there are no skills necessary in the embedded domain that are not already known to desktop programmers. This is simply not the case, and to suggest otherwise is an insult to the engineers who've spent years honing their skills as embedded and real-time specialists.

In the proposed real-time Linux environment, the developer will also need to learn how to communicate between Linux processes and RTOS tasks, as well as knowing both inter-process and inter-task communications mechanisms. The developer will also have to handle trade offs between putting certain application functionality into a Linux process where it may have soft real-time targets, and putting it in a hard real-time task. In short the architecture has taken a solution (an RTOS) and divided it into two problems (a soft real time system, and an integrated RTOS).

The real motivation behind these real-time Linux architectures is to allow open source vendors to play catch-up with more established RTOS vendors. QNX, Wind River Systems, and others already offer any functionality (such as file systems and networking) that the embedded community may want to borrow from Linux. These products, written from the ground up for embedded systems, are free from a legacy of design decisions influenced by the server and desktop world. A number of smaller vendors have gathered under the banner of embedded Linux in the hope of upsetting the applecart for these larger vendors, and benefit to the tune of a few apples themselves.

Unfortunately for these cidermakers, the strength of open source will always lie in its disruptive influences-it will never create new markets, just scare the big cats in already established markets. In the desktop OS market there was an undeniable monopoly, but the RTOS market is much more diversified and there is not the same dire need to shake up a single player with 95% of the market. The very fact that the RTOS market is reasonably fair and open means that open source software will not have the same appeal that it had when competing with Microsoft.

Moral high ground
The open source community claims to have the moral high ground over commercial developers. Bertrand Meyers disputes this and argues that much of the high-minded attitude is misplaced.⁸ I tend to agree. Saying that you are writing software for the good of the world, and for no personal gain, becomes harder to swallow once you've become known throughout the engineering world as a multi-millionaire. Those who've made big money from the efforts of the open source developers will be compromised by their new-found responsibilities as owners of major corporations. And those who did not make money out of the recent spate of public offerings will be less likely to offer large chunks of their programming time for free next time around.

While some may try to convince us that open source vendors are the wave of the future, I think we will look back on this idea as a quaint notion that happened to provide the embedded community with a good cross compiler. I doubt this new way of doing business will profit any of us in the long run.

References
1. “Licensing Models of Open Source Computing” available at www.eg3.com/open/license.htm.

Back

2. Shapiro, Carl and Hal R. Varian. Information Rules: A Strategic Guide to the Network Economy. Harvard Business School Press.

Back

3. “Can Linux Billionaires Carry the Free Software Torch” by Andrew Leonard available at www.salon.com/tech/feature/1999/12/23/linux_ipos/.

Back

4. “Future of Cygnus Solutions: An Entrepreneur's Account,” by Michael Tiemann, included in Open Sources: Voices from the Open Source Revolution, edited by Chris DiBona, O'Reilly and Associates, 1999.

Back

5. “Giving It Away: How Red Hat Software Stumbled Across a New Economic Model and Helped Improve an Industry” by Robert Young, included in Open Sources: Voices from the Open Source Revolution.

Back

6. Crenshaw, Jack, “And Another Thing…” Embedded Systems Programming, March 2000, p. 15.

Back

7. Epplin, Jerry, “Linux as an Embedded Operating System,” Embedded Systems Programming, October 1997, p. 96. This article is available online at www.embedded.com/97/fe39710.htm.

Back

8. Meyers, Bertrand, “The Ethics of Free Software,” Software Developer, March 2000, p. 59. This article is available online at www.sdmagazine.com/features/2000/03/f4.shtml.

Back

Niall Murphy has been writing software for user interfaces and medical systems for ten years. He is the author of Front Panel: Designing Software for Embedded User Interfaces. Murphy’s training and consulting business is based in Galway, Ireland. He welcomes feedback and can be reached at .