Article: The Great Open Source Debate of ESC West 2000
Sep 26, 2000 — by Rick Lehrbaum — from the LinuxDevices Archive — viewsOnce again, the Embedded Systems Conference opened with a debate (and discussion) about open source. Here's a report from . . . “The Great Open Source Debate of ESC West 2000”.
The Teams
Let's meet the contestants. See if you can figure out who was on the “pro-open” side, and who was on the “pro-proprietary side” . . . . . .
- Michael Tiemann — Chief Technology Officer, Red Hat Software
Bill Gatliff — freelance embedded developer
John Fogelin — VP Technology, Wind River Systems
Steven Stolper — System Software Manager, Silicon Spice Inc.
Vereen then introduced Michael Barr, Editor-in-Chief of Embedded Systems Programming, who was to serve in the role of moderator for the debate. Barr stated the rules (no hitting, no spitting, no biting, etc.), and rang the starting bell to begin the first round — the opening statements . . .
Tiemann
I think we need to change the nature of the debate. “Open vs. proprietary software” is great for a discussion over a few beers, but we don't have enough beer here. Being in the technology industries, we have seen the profound changes that technical and architectural innovation enable. We aren't making just incremental changes, but fundamental and revolutionary changes. Open source is intrinsic to the success of the Internet. Open source has fueled an unheralded process of collaborative innovation. Open source has enabled free and extremely rapid dissemination of innovations. No technology propagates as quickly as open source technology.
Understanding the evolution vs. revolution possibilities of open source is extremely important. At Red Hat we've been looking at how you effectively put the Internet into Internet Appliances — it's going to be difficult to sell Internet Appliances that don't contain “true” Internet technologies, which requires open source technologies. For security, availability, scalability, maintainability, etc. This is needed if you're going to put millions of devices out there. The real debate is evolution vs. revolution, how to turn disruptive technologies into technical revolutions — and open source is unmatched in its ability to accomplish that.
Fogelin
Wind River is not “against” open source, per se . . . I agree that the embedded industry is undergoing a massive discontinuity — but not due to operating systems — rather, due to the Internet. There have been other revolutionary technologies in the past. Microkernels, Integrated Development Environments, Java, . . . The industry needs to grapple with both the opportunities and challenges that the open source movement now brings. It's not just black and white — there are many shades of gray to concepts like “free”, “Linux”, and “collaboration”. So I hope to clarify some of the vocabulary.
Another issue is to define the fundamental needs in the industry. We have seen increasing pressure on vendors of embedded operating systems to provide solution-level products that hit the ground running. Never before have we seen such time-to-market pressures, as well as pressures for new technologies. How does open source answer these sorts of questions? How do we engage this practice to meet the industry's needs — both from a market standpoint, and from a technical standpoint?
First of all, open source can be good. Wind River has supported open source over the years, including contributing to the GDB and GCC. We've certainly seen open source be successful in some instances — Apache, Linux, GDB/GCC — are all good examples.
Also, one of the benefits of the open source movement is in keeping proprietary systems vendors honest. You see a lot of pressure to innovate and differentiate in order to compete with what's available from the open source community. But it's also not a panacea.
There's a fundamental challenge in provisioning ourselves with the necessary technology to get the job done. And that provisioning comes with a set of choices. Do you want to own the technology? Do you want someone else to provide support for that technology? What types of business models are you willing to engage in?
The embedded industry is a highly fragmented market, with lots of different processors and other factors. What is the common goal here? Can open source manage a highly fragmented industry? I think there's a real question as to open source can find a home here in the embedded market, because of the lack of commonality and therefore the lack of common goals for the open source community to rally around.
Another issue is licensing. Open source doesn't equate with free (of cost). Proprietary vs. open is not a business model question, per se. Also, from the development perspective, there is the question of licensing — there's GPL, BSD, etc. licensing — and that's a question we need to talk about. I think there are some real issues regarding what type of licensing you want to use.
A key question is whether or not aspects of the intellectual property can be better supported by a vendor standing behind it, or by a community standing behind it. Actually, that question has been in the embedded market from day one. There are countless examples of people building their own solution — what you'd call in-house proprietary. And at the other end of the spectrum you have community ownership. In what kinds of situations will the community-based system work? What can be supported by that process, and what can't be supported by that process?
The embedded market is inherently fragmented, and therefore does not lend itself to being supported by a community-based open source development process. One way or another, in the embedded market, you really must invest in unique technology, because the needs are truly individualized. Innovation really does cost money. And it either costs money for people to do it themselves, or it costs money for vendors to develop it for them.
So the open source question is a complicated one.
Gatliff
I am an independent developer who specializes in solving difficult problems using open source technologies and techniques. You've heard it said many times that proprietary closed source tools vendors are the only places you can go to find somebody to take care of you. But most of the companies making these statements have their selfish interests at heart. They'll take your money and provide the services, but eventually they decide that continuing to support your version of their closed source product is no longer profitable, so they stop supporting it. At that point, you have little recourse other than to throw more money at the vendor. If that doesn't sound like extortion to you, it certainly does to me!
The reason that “natural selection” doesn't apply in the embedded systems world is that embedded systems are so different from each other. As a result, the only person who can decide what's right for my system is me. The so-called “heavy lifting” that commercial tool vendors provide with their “shrink wrapped” software is simply a mirage. You can't predict which vendor will buy another, and what products will become obsolete.
And don't be fooled into thinking you've protected yourself from this situation by getting the source code to a proprietary embedded operating system, because every development environment is generally the sum of many components. So having the source code to only a portion of those tools is a fools paradise. When the day arrives one or more of your required components or tools falls victim to circumstances — and in my ten years of professional experience, it's always a case of when, not if — you'll be left without any protection and without any recourse. Maybe that day will come for you tomorrow, or next week, or five years from now, but it will eventually come. And in my experience, it always comes sooner rather than later!
I have the source code to every single tool that I use on this CD (holds up a GNU/Linux CD)! I'm not talking about just the source code to my embedded application — I'm talking about the compiler, linker, debugger — even the host and target operating systems. I'll always have this.
What about the application source code, is that open source? That depends on the customer. So I ask you to carefully consider the question, “Who is taking care of whom?” GNU takes care of me by empowering me to take care of myself. In the juvenile justice system, this concept is called “tough love”. In embedded systems, this concept is called “free software”.
Stolper
Tells story about a three legged chicken . . . This guy in a sports car finds a chicken running along side his car. He goes faster, and the chicken runs faster. Then he notices that the chicken has three legs. He speeds up even more, and no matter how fast he goes the chicken stays with him. Suddenly, the chicken zooms ahead of him and then abruptly turns off the road into an alley. So the guy stops and walks into the alley and there he finds a farmer leaning against his truck. He asks the farmer, “Have you seen a three legged chicken?” The farmer says “Yep, I raise three legged chickens.” “Why?” the man asks. “Well,” says the farmer, “a lot of people want a drumstick for Dad, a drumstick for Mom, and a drumstick for Junior — so that's why I raise three legged chickens.” “That's a great idea. By the way, how do they taste?” asks the man. “I don't know, I've never been able to catch one!” replies the farmer.
The moral of this story, according to Stolper, is that chickens are for eating. If you can't sell the chickens, it won't be long before you won't be producing any chickens, innovative or otherwise. (Presumably there's some advice of significance here, for open source companies such as Red Hat.)
I'm what's called an open source pragmatist. My motto is “Use the best, lose the rest.” I have no malice towards open source. If you're going to use open source, you have to keep your eyes open. There are some successes, but there are also some miserable failures.
Some successes . . .
- Using open source to jump start your proprietary system. You can get the project going by incorporating a piece of open source, and then remove it later and substitute a proprietary component prior to completing the product and beginning to sell it.
- Giving away software, to sell hardware.
- Giving away software, and selling services for porting and customizing.
- Giving away software to compliment another product, or to help others to incorporate your proprietary software into their application.
- Giving away a modified operating system that works with your proprietary product (which you are selling).Some failures . . .
- Giving away your core competency, intellectual property, or differentiating technology. Differentiation pays the rent!
- Using an open standard to beat down a smaller company who has superior technology. That's not good for innovation!
The Rebuttals and Audience Questions/Comments
In this section, we'll highlight some of the key points made by the four panelists, and also include a few questions and comments from members of the audience . . .Tiemann: Gave an example of a performance problem that Linus felt he couldn't solve, and a programmer in Turkey took it on and solved it. “Never underestimate the intellectual capability of the entire world!” The key is to think of it as “How can I best take advantage of the competency of tens of thousands of competent programmers?” rather than “How can I protect my individual core competency?”.
Foglin: Having access to source seems like such a great opportunity, but in reality programs are enormously complex and may consist of millions of lines of code written by many authors. Source does provide an opportunity to isolate and diagnose problems, but not to be fully self-supported. Source availability can help, but it's not a panacea. For example, networking problems can be extremely tricky to debug. Proprietary suppliers, like Wind River, do provide source code to customers for these same reasons.
Stolper: One problem with open source, is what happens when the programmer graduates from college? (laughter)
Gatlin: It's true, having source doesn't automatically equate with self sufficiency, but on the other hand NOT having source code definitely denies self sufficiency.
Stolper: If you try to be self sufficient, you end up in the operating system business instead of in the the application development business where you belong.
Foglin: Those companies who do the best job getting customers to “hit the ground running” are going to be able to generate the most revenue and will be able to use it to provide the best support.
Tiemann: The problem is, Wind River knows their software better than anyone else (because it's proprietary), so they have an unfair competitive advantage. With open source, you are in a community free from vendor domination.
Stolper: Cost minimization is the real goal. Whatever costs less is what I'd do, whether it's supporting myself or outsourcing that support. Whichever costs less.
Gatlin: Why must Wind River keep its source closed? Wouldn't it be better to open it up?
Foglin: When you're doing something unique, you might not have an available community to support you.
Tiemann: Many major companies are innovating and giving the innovations away. For example peer-to-peer communications technologies. They're seeding the technology pool, but they're not losing their edge. [The disadvantage of giving away technology] is a moot point, because proprietary companies spend 90% of their time duplicating each other's technologies anyway. Open source companies get to use each other's technologies and therefore, instead of reinventing the wheel, can use their resources to do new innovative things. The key question you need to answer is: “What is the best platform to take advantage of these innovations?
Foglin: Open source leads to innovations only if there is sufficient community. A world where innovation depends on charity is not one conducive to a successful business model.
Stolper: Why should I build a product if what I build will become free? I won't incorporate open source if I can't sell the product I create for a fee.
Audience question: I'm amazed by the lack of discussion of quality assurance. Coding standards, design standards, quality standards. The idea of every application developer modifying the operating system scares the hell out of me. If I use open source, how can I possibly get my system approved by regulatory authorities?
Tiemann: The Free Software Foundation has published software development standards. Whether the software is proprietary or open doesn't automatically imply that the programmers do or don't follow coding standards. For example, at Cygnus, we developed a comprehensive automated test suite for eCos (an open source OS).
Foglin: If you look at the source of Linux, you'll see a big mixture of coding standards. Wind River has strict coding standards.
Tiemann: I can't speak for VxWorks, but in nearly every operating system, there are many licensed components produced by many different companies and individuals. In other words, proprietary operating systems are the same mixture of software as open source.
Audience comment: Open source works for commodity products. But when the goal is niche-oriented and very unique, proprietary software seems to be the better approach.
Foglin: Open source works best when there is a common goal. But whether that translates into innovation is a question. Also, dependence on “charitable acts” is a great concern, from a business perspective.
Audience comment: I am building equipment for utilities companies. We need twenty years of maintenance and support. How can this be assured, except with open source? We want to be able to pay anybody to support our needs, for twenty years. Open source enables that.
Foglin: Wind River has very long support contracts. Which community is better able to support you, Wind River or the open source community? In twenty years, is Wind River going to be around, or is Linux?
Concluding Statements
Gatlin: Let's look at the auto industry. Cars used to be serviceable by anyone. Back then, there were lots of corner garages with good prices and convenient service. Today's electronic engine controllers are closed source systems which drive business to dealerships who have what amounts to a monopoly. Corner garages are relegated to changing oil and tires. The proprietary approach is a big advantages to the dealerships, who can charge $75 per hour for servicing your car just because they have access to proprietary information. The result: customers and consumers lose.Foglin: But in fact, the quality of cars has gone up. The systems run in an increasingly reliable way. So the key question is quality. You couldn't build a reliable car without controlling the quality of the development process. (Implication: “In other words, a proprietary OS vendor like Wind River has better quality control in its software development process than the open source community process has.”)
Stolper: Be an open source pragmatist. Use the best, lose the rest. Don't leap on every fashion. Just because it's free, doesn't mean it's good. The cost of it actually working is what matters most. Chickens are for eating.
Foglin: Open source provides an opportunity to connect and collaborate, but it's not a panacea. Wholesale reinvention of software development methods is an overreaction. By the same token, burying your head in the sand and ignoring the potential benefits of open source is also a mistake.
Gatlin: Speaking of hiding things, if you have to hide your source code to stay in business, you shouldn't be in business.
Tiemann: Innovate by being better, rather than just different. Don't discount your “disruptive chickens” before they're hatched. Disruptive technology doesn't always have to be better immediately. The real question is “What's the best horizon?”, not just “What's the best today?”
And the Winner is . . . ?
Who do you think won this debate? Personally, I'd rate both sides at about a “B”. Both made some good points, and both missed some good ones, too. Specifically, in my opinion . . .- On the quality issue — I think the concern raised by Fogelin about how the quality of open source software is assured is an important one, and needs a better answer. One point often made is that the open source approach actually exposes the source code to a huge amount of peer review, which is seldom the case with proprietary operating systems. However, testing is still important, and I think the commercial Linux vendors ought to contribute a significant amount of formalized, structured testing to the open source community. Perhaps a shared test lab to which they all contribute as sponsors.
- On the issue of sole-source vs. multi-source — I think one of the strongest points in favor of Linux is that it represents the first truly multi-sourced embedded operating system. You can choose among half a dozen suppliers who cater to the needs of embedded system developers, or hire a consultant to create what you need, or do it yourself. No matter which path you take, you are generally free to move to a different solution down the road if you need to or want to. Certainly, there will be some effort to do so, but it remains the same technology. Try that with VxWorks or pSOS. With a proprietary RTOS, you pick a path and the longer you stay on that path, the more costly it is to change to another alternative. Interestingly, LynuxWorks and QNX are now offering what they consider proprietary “Linux-like” (from an API/ABI perspective) alternatives to open source Linux, which seek to capitalize on the POSIX and other standards supported by Linux. Should that approach begin to succeed, Wind River may find itself increasingly isolated by its nonconformity to the increasingly popular “Linux-like” standards.
- On the business model issue — the open source advocates allowed themselves to be portrayed as utopian socialists, rather than pragmatic capitalists. The debate on business issues was a “shutout”, with the pro-proprietary panelists leaving the open source advocates looking somewhat weak. In my opinion, we pay for value received. There's no reason why the customer won't pay the same fair price for either license fees or for services rendered. The difference between open source software and proprietary software, in this respect, may be whether the payments are license royalties or whether they are fees for support or annual subscriptions. Nobody says open source software has to be “free as in beer”. It's “free as in speech”. Well, to be precise, you can't require a royalty for reproduction of GPL software — but you can certainly charge for tools and support. And if you provide a useful service, the customer should be just as willing to make payments to an open source provider as to a proprietary provider. As a matter of fact, the customer should be willing to pay slightly MORE to an open source provider than to a proprietary software vendor, because they gain freedom from future extortion! They get not just the software, but an insurance policy that protects their interests in the future.
Who do you think won the debate? Let us what you think!
Talkback:
Do you have questions or comments on this story? 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. - Giving away your core competency, intellectual property, or differentiating technology. Differentiation pays the rent!