Tiemann: How Linux will Revolutionize the Embedded Market
May 22, 2002 — by LinuxDevices Staff — from the LinuxDevices Archive — 4 viewsIntroduction
If you haven't read The Innovator's Dilemma by Clayton Christensen, read it now (or at least the reviews). I liked the book so much I crafted many of my keynote and conference presentations around its findings, delivering speeches at… numerous conferences (public and private) around the world. In those speeches, I talked about how Linux and open source technologies were the perfect “disruptive technologies” that would revolutionize the embedded software market, destroying one status quo and replacing it with a newer, better status quo. Of course, it wasn't really possible to predict precisely what the newer one would be (and Christensen makes the points many times that it's folly to try to do so), but it was possible to predict that something was going to happen, and that was my point (and Christensen's).
I'm writing this op-ed because I think I now understand how this dynamic is playing out, and as predicted, it's not pretty. If Linux is truly going to revolutionize the embedded systems market, it's going to do so on its own terms, and the embedded systems market needs to adapt to those terms, not the other way around. I believe that the companies that can adapt in time will not only be spared the ravages of the revolution, but will emerge as the new leaders; and those that don't will, at best, become new chapters in a book by Christensen yet to be written. Let me explain.
The relationship (truly!) between enterprise and embedded Linux
12 years ago, when I first began selling GNU tools to software developers, I was quite amazed at how much more nimble, in general, were the embedded developers in comparison to those doing enterprise development. Many UNIX developers were wasting incredible amounts of time dealing with gratuitous platform issues, RAD tools that didn't work, vaporware that promised much and delivered nothing but headaches, etc. In contrast, I met many embedded developers who were working at break-neck speed on truly ground-breaking systems that would themselves become the key infrastructure of enterprise computing: Cisco routers, Nortel switches, EMC storage systems, etc.
Having spent the past 12 months reviewing the relative efficiencies and effectiveness of enterprise development tools and methodologies compared with those of embedded systems developers, it's becoming clear to me that the pendulum of relative advantage has swung far away from the embedded developers and toward those running Linux as an enterprise environment. And, like Christensen, I don't see that this has happened because the embedded developers or their management have suddenly lost their mettle. Instead, the effects of disruptive technologies have fundamentally changed the dynamics of software development, and have done so in a way that threatens virtually every company designing embedded systems today, with or without designs incorporating embedded Linux.
In the enterprise market, Linux is obsoleting billions of dollars of UNIX hardware and software and it is replacing or transforming innumerable companies who profited from the inefficiencies of the proprietary UNIX model with a new model offering unprecedented levels of price-performance and efficiencies in software development. Companies migrating from UNIX to Linux are seeing 20-fold improvements in operating metrics, in many cases saving tens of millions of dollars per quarter. One great example is Amazon.com — a company that previously never reported a profit in their operating history, yet reported profitability a year ahead of management's commitments after migrating from UNIX to Linux, and in so doing has proven wrong the nay-sayers who said Amazon.com would never report a profit. (Companies desperately seeking profits who build or deploy embedded technologies, take note!)
In the embedded space, there seem to be no such success stories, and I now think I know why. The companies who build embedded systems (like companies in Christensen's book that manufactured motorcycles, steel products, earth-movers, and the like) have created a model of manufacturing that's vulnerable to disruptive technologies. In the case of embedded systems, companies have created their own proprietary development models, and are thus threatened, rather than enabled, by the power of Linux. From what I can see, the biggest names in the embedded system development world are following the same course that the steel industry did in the 1970s: the maintenance of a “high ground” (perceived high margin business) that will ultimately (and possibly shortly) collapse right from under them. Jack Ganssle is right when he identifies a looming crisis; but the crisis is not because of open source, but because of historic behaviors that are not sustainable.
An evolving development paradigm
The modern (soon to be “archaic”) embedded development model is to select a microprocessor, design a hardware platform, and license an RTOS (not necessarily in that order) — then assemble or license additional software components, develop a proprietary “application”, and once debugged, sell the integrated widgetry to a buyer who supposedly wants the widget independent of any software or hardware componentry contained within the widget. Ever since this model was pioneered by James Ready and his VRTX RTOS, virtually the entire industry has inadvertently evolved to a point where licensors are treating 100% of the resulting development process as their proprietary value, rather than recognizing that 80% of what they do is actually quite common across the industry (or at least their slice of it). The result is that companies are paying the full proprietary cost of their development process while only 20% of their development process is truly value-add. The industry is therefore paying five times what it should for product development, and this 400% overage is causing an industry challenged by current economic conditions to slip from marginal profitability to substantial unprofitability. In this analysis, the fact that Linux can be licensed free of charge (thereby eliminating the entire cost of the proprietary RTOS) changes the equation almost not at all, yet companies are behaving as though it changes everything. This is where the industry is missing Christensen's entire message, and this is the point which, if missed, will be the point of no return for countless hundreds of companies.
The way in which Linux changes everything is not in the fact that it can replace a proprietary RTOS at the core of a proprietary embedded systems platform, but is instead the fact that it can replace an entire proprietary embedded platform completely. The proper adaptation to a true Linux-based platform can save companies the 80% of the development cost which is currently gratuitous, a factor far more significant than merely the cost of an RTOS. Unfortunately for the industry, most companies have changed suppliers (from proprietary RTOS vendors to Linux-as-an-RTOS vendors) without changing their production model or value web; and that is the classic trap detailed in Christensen's book. What is needed is to build an entirely new embedded development platform around Linux-as-a-platform, driving embedded requirements into the platform rather than taking people's adaptation of the Linux platform sold as an embedded-ready solution. If this suggestion seems counter-intuitive, look at the dozen plus case studies in Christensen's book, and see that any disruptive technology appears counter-intuitive to the status quo. That's the nature of disruptive technology.
Linux as a platform
With Linux, it is important to distinguish projects from platforms. Projects are organized around specific, though possibly far-reaching, technical goals (such as running on a laptop, in a cluster, in a router, on a mainframe, on a particular chip architecture, etc.). A platform, on the other hand, provides a common environment that can be widely deployed and serviced. Linux itself is a project (it moves forward largely for technical reasons), whereas commercial Linux distributions are platforms (which move forward more for commercial reasons). Regardless of how similar Linux-as-a-project and Linux-as-a-platform may be in terms of their code content, the difference is vitally important in terms of how they are developed and maintained and the ecosystem that ultimately forms around them.
Perhaps one of the most significant illustrations of this distinction can be found in the story of Midori Linux. Launched as a distribution from the company (Transmeta) that employs Linux creator Linus Torvalds, Midori Linux addressed numerous technical issues prevalent in the world of embedded systems, not the least of which was dealing with memory-constrained devices. While Midori developed a lot of great technologies as a project, these technologies migrated into the mainstream Linux project where they became standard components of the Linux platform. Had Midori Linux been mistaken for a platform itself, it could have fragmented the overall Linux market, but the fact that this did not happen shows that the folks who spawned Midori Linux knew what they were doing.
In the telecom segment, much is being made about Carrier Grade Linux. Again, this is a project, not a platform, although with careful work, the technologies being developed in this project will merge their way into mainstream Linux and will be supported as a platform consistent with other mainstream platforms. Indeed, Red Hat believes that the unification of carrier-grade and enterprise-class Linux technologies will yield dramatic advantages for the future integration of voice and data services, and we are excited to be active participants in the project.
It is from this perspective that one can see how absurd are the declarations of pseudo-platforms like KOSIX which (if they had any technical merit) are really better done as projects that can feed mainstream Linux development. Or how similarly absurd are the declarations of the TV Linux Alliance, which again seems to think that a platform can be created around a narrow, rather than a broad set of requirements. But the number of publicly announced “platforms” is dwarfed by the number of in-house de facto platforms, and it is the latter that we believe threatens the health of the industry the most. Indeed, natural forces put KOSIX out of its misery (and seems to be doing the same for other bogus “platforms”), but in-house “platforms” enjoy parochial protections that prevent the process of natural selection from taking its course. In such cases, these in-house “platforms” may live long enough to truly kill their host environment — not a good thing.
Getting onto the right path
How then do we get the industry on the right path? It's not as hard as one might think, and several companies are already taking the right steps.
- First and foremost, it is crucial to adopt Linux-as-a-Platform as widely as possible: as a server operating system (every embedded development company, hardware- or software-based, has web servers, file servers, print servers, etc), as a desktop operating system (many engineers call the machine on their desk with which they do their development a workstation), and as a prototyping and deployment platform for embedded software designs. According to two VDC surveys completed in May 2002, Red Hat Linux is the starting point for more than 40% of all embedded Linux projects, with the next closest commercial offering at about one-third that number. But that doesn't mean developers are building a platform: it only means they like our bits better than anybody else's.
- Second, recognize how the platform can be extended and supported in more diverse devices: different CPUs, different memory architectures, different operating environments, different developer communities, different user groups, etc. If the first step is done right, this second step will be radically different than the Linux-as-an-RTOS approach.
- Third, reengineer the business to deliver this platform to customers, with all the tools and support that one could expect from a platform provider, partnering if necessary to achieve this goal. Most enterprise deployments of Linux depend on 10-60 different ISVs (independent software vendors) and IHVs (independent hardware vendors) all working together, and there's no reason that PostPC devices cannot wrap together just as many components that work (in fact many do). What won't work, is trying to pretend that such integration is worth the cost of making it a pure “black box”. On the contrary, such integration should, as the industry evolves, be available just as one expects to install a new RPM on Red Hat Linux and see it work.
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.