Are Open Source and Innovation Compatible? (Point)



To read original PDF of the print article, click here.

Internet Appliance Design

Open Source Point/Counterpoint:

Are Open Source and Innovation Compatible?

Niall Murphy

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.

Nothing new
The three basic tenets1 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,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
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.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.

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.6 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.7 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.8 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 .

Know Your Rights

One of the more confusing aspects of the open source phenomenon is the proliferation of different source code licensing schemes. If you are considering using software developed by others within your products, you'll probably want to have an intellectual property lawyer read the individual license agreements in detail and summarize your rights. However, this quick guide to the licensing terminology should be enough to get you started.

Proprietary Software
In the most traditional licensing model for commercial software, no customer is allowed to examine the source code for the product. The one exception to this is a customer willing to pay an additional, often exorbitant, source code license fee. But even if you do buy the source code for such a product, you cannot publish that code or otherwise cause it to fall into the possession of anyone outside the licensed group. And your rights to modify the source code may be restricted.

Shareware
With shareware, the traditional model is somewhat reversed. The software is distributed for free, and may even be passed on to others. Users of the shareware product are honor-bound to pay the developer's registration fee, whatever it may be. A variant on this licensing scheme, termed crippleware, will not function fully until the registration fee is paid. Freeware is shareware with no registration fee. The source code is typically not included with any of these.

Free Software
Free software, on the other hand, is all about access to the source code. The free software movement (www.fsf.org) is as much a political organization as anything else. Under the free software licensing model, it is your right to use the software, modify it, and redistribute it in any way you like. It's even okay for you to charge for your distribution. However, these broad rights are conditioned upon your commitment to provide similar access to your modifications and to never narrow the licensing rights as a condition of distribution.Proponents of free software generally believe that all information, especially source code, has a right to be free. Therefore, they mean free software in the “free speech” sense, not as in “free lunch.” They advocate attachment of a copyleft, which says that “anyone who redistributes the software, with or without changes, must pass along the freedom to further copy and change it.”

Public Domain Software
Public domain software is just as free as free software, but less restrictive. It can be used, modified, or redistributed in any way. However, you are free to make changes to the software and keep those changes proprietary. You can even choose to charge for the original code or a derivative, without providing access to the source code at all. In that way, anyone can make use of public domain software in any way, without consulting a lawyer beforehand.Unless otherwise indicated, all of the source code published in ESP is placed into the public domain by its author(s). In other words, while copying the text of the article is a copyright infringement, using the source code in your work is perfectly legal.

GNU General Public License (GPL)
Since 1984, the goal of the GNU project has been to develop a complete UNIX environment that is licensed as free software. Although some of the code involved is public domain, the vast majority is licensed under GPL (www.fsf.org/copyleft/gpl.html). GPL is a specific implementation of copyleft. This is analogous to copyright law, in which there is a general right that is implemented in various ways in different contracts and print and electronic publications.

GPL prohibits proprietary patents related to modifications of the software, prohibits royalties, and requires that the same terms be attached when redistributing the software or a derivative of it. Of course, anyone can create software and then license it under these same terms. Use of the GPL language is not restricted to GNU-related projects. (Their copyleft is not copyrighted.)

The popular GNU compiler and associated tools are licensed under GPL. This means that anyone making a new and improved GNU compiler must give their new source code back to the community. However, it is important to note that this does not mean that software built with the compiler must also become free. It is legal to use a free software tool to produce proprietary software.

GNU Lesser General Public License (LGPL)
The LGPL (www.fsf.org/copyleft/lesser.html) is used to license free software so that it can be incorporated into both free software and proprietary software. In other words, it is a weaker sibling of GPL. The rules are basically the same, with one major exception: the requirement that you open up the source code to your own extensions to the software is removed. So while LGPL components remain free software, they can be included within a larger proprietary software package.

The real downside of the GPL, particularly for embedded developers, is that it's designed to discourage the creation of proprietary software and to encourage free software. If you wanted to build your firmware around a GPL package or library, you'd be forced to give away the source code to your firmware. But this is not a problem with an LGPL package, like the GNU C library, which can be legally included as part of proprietary software.

Open Source
Unfortunately, this is where things get confusing. Although we've framed our debate with those words, there is no clear definition for “open source software” and no standard license. Many companies are using the term open source these days, but in far different ways. And while the idea is similar to that of free software (you can generally still use, modify, and redistribute the software), there is far less emphasis on the right of the source code to be free. While not as true with respect to Linux, many open source companies seem to be unwilling to give up central control of their software. (Free software has no owner.) What's important about open source software, particularly for embedded developers, is that its licensing terms are more like LGPL than GPL. In other words, you are typically free to add your own proprietary software to the open source code and produce a proprietary result. The free software movement doesn't much like this, but is otherwise more in alignment with the newer open source movement than in opposition to it.

Community Source
Sun Microsystems' community source licensing program (www.sun.com/981208/scsl/principles.html) was launched to give Sun and its customers the simultaneous advantages of both free and proprietary software. Users of the software have full access to Sun's source code and can do their research and development work before paying licensing fees. They can even modify the code for any purpose. However, users are asked to register at the time of code download and are ultimately required to negotiate licensing terms with Sun prior to launching any commercial product based on that code.

Sun felt this licensing model was a better alternative than making its formerly proprietary software into free software. By keeping licensing fees in the equation, Sun hopes to reap some benefits from all this giving away of its most valuable code. (To date they have made the source code for Solaris, StarOffice, and many Java technologies available on their Web site.) By retaining their role as a central authority on the software and a provider of compatibility testing, they hope to reduce chaos and source code fragmentation in the market.

-Michael Barr

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.