To read original PDF of the print article, click here.
Internet Appliance Design
Open Source Point/Counterpoint:
Read the Counterpoint to this article Open Source is Already Delivering by Bill Gatliff
According to the popular wisdom of the moment, open source software is the way of the future. But can the purveyors of free software really innovate?
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.
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,2 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
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.3
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.4 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.5 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.
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.
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
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.
2. Shapiro, Carl and Hal R. Varian. Information Rules: A Strategic Guide to the Network Economy. Harvard Business School Press.
3. “Can Linux Billionaires Carry the Free Software Torch” by Andrew Leonard available at www.salon.com/tech/feature/1999/12/23/linux_ipos/.
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.
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.
6. Crenshaw, Jack, “And Another Thing…” Embedded Systems Programming, March 2000, p. 15.
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.
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.
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 .