|[Home] [Credit Search] [Category Browser] [Staff Roll Call]||The LINUX.COM Article Archive|
|Originally Published: Thursday, 24 February 2000||Author: Mike Corns|
|Published to: corp_features/General||Page: 1/1 - [Std View]|
Stormy Weather Ahead for Proprietary Software
A recent email on the Linux corporate site suggested that the absence of rececnt Microsoft references to Linux might indicate that they are considering leaving the lower-end to Linux. Instead, the real reason for minimizing Linux and Open Source is that they represent a storm of fundamental challenges for traditional software vendors. A storm that sweeps in a new focus on qualitative superiority and sweeps out the old model of closed proprietary technology.
To date, vendor's margins have largely been produced by revenue generated selling packaged products and expanding their market share while simultaneously minimizing development, service, general overhead and distribution costs over that same period. Pretty much a traditional manufacturing strategy. This approach often produces a decline, or at least fluctuations, in product quality and cohesiveness. Most vendors you ask will insist that this is not the case and they'll show all sorts of numbers indicating the size of their R&D investment. If you could get full disclosure of how the R&D dollars are accounted for you would find that proportional investment in the maintenance and development of specific EXISTING products typically declines, or fluctuates independently of customer needs, even when "R&D" dollar expenditures are growing over all. Linux challenges this model by modifying the software manufacturing emphasis from its current focus on marketing, sales and proprietary uniqueness to quality superiority.
In any manufacturing company, including software, one of the typical targets of expense control are the development and maintenance areas or the "shop floor". Big software firms do make tremendous R&D investments. However, these investments tend to gravitate towards substantial "new revenue" opportunities rather than reinvesting heavily in incrementally improving the technical quality of existing products. This natural tendency is magnified when market dominance is substantial and competitive pressures to dramatically improve existing software are lessened.
Additionally, the focus of traditional vendors has been to create functional, proprietary extensions, supposedly qualitative - which I think is often a dubious claim, in order to differentiate their products from their competitors. This practice creates high "switching costs", intentionally or unintentionally, that impede a customers ability to jump ship once they've embraced a particular product. In short, if industrial-age companies used the current information-age manufacturing model, two competing companies producing, let's say, nuts & bolts (fasteners) would compete by using different threading standards rather than higher quality metals or machining precision.
At one time this was the practice, fortunately, it is no longer the usual situation in the industrial world - and so fixing a leaky pipe is no big deal. Unfortunately, it is the case in the high-tech software and hardware world. We accept inter vendor incompatibility and rapid obsolescence as the price of "innovation". In reality, it is often high-tech companies "churning' the market to generate new revenue with mildly functionally different or improved technologies. These technologies create upgrade requirements, impede customer switching because of a proliferation of proprietary extensions and deteriorate the cost effectiveness of end user solutions by making solution architectures and human skills rapidly obsolete.
Fixing a "leaky pipe" can be ridiculously expensive in the "high-tech" business. First we discover that the guy who sold us the pipe no longer makes a replacement - he's got a newer and better trademark-protected pipe system - and that the replacement pipe is priced differently. Then we discover that the pipe no longer will fit with our existing plumbing and that we will need to strangely splice the replacement into place or replace the whole system. We say, to heck with that, and we call "pipe" vendor B. He says not only do we need to replace the "pipe" but now the contents flowing through the pipes need to change and two of our pumping stations need to go as well. We go back to A and discover on further examination that similar problems will occur using A's replacement system, so we make our own patch, whose continual leaking and clogging, makes our tenants unhappy and leaves them wondering why we are such bozo's. We go to the big boss and say we need to kick in a few million bucks more to fix the pipes - which we renovated just a few years back. Resulting in the big boss saying why didn't we anticipate A's changes to pipe standards or use B's approach since it's so much cheaper and better. We explain that A's pipes were brand new just three years ago and were "state of the art" innovations at the time (which forced us to throw out the preexisting pipe system which was only 8 years old then) and B didn't exist. We didn't know A was going to obsolete their own standard or that B and A wouldn't cooperate to produce some standards that allowed us to combine both pipe systems or incrementally improve our own plumbing without having to forge and manufacture our own custom fittings....and so on. This may be a great source of work for the plumbers but, not so good for tenants living with leaking pipes or the manager footing the bill. All the while, the pipe vendors exclaim that this is just the price of "innovation", which we certainly wouldn't want to impede, as we write them checks.
Open Source challenges this archaic situation. Not so much because it's free but, because of the potential for creating de facto, OPEN standards for core technology, like OS's, DBMS's, development tools and other central technologies which many of the biggest high-tech software company's revenues depend on today. Technologies were minor functional differences are less valuable then rock solid reliability and coherent evolution. If this happens, then most software companies essentially have to rework their culture from one focused on proprietary differentiation to one of qualitative differentiation. Quality differentiation will require a rebalancing of internal resources and corporate culture. The heavy focus on sales, marketing and "innovation" will change to one that favors large, high quality "shop floors" where continuous incremental improvement is the norm. The American automotive industry was presented with a similar challenge in the late 70's and early 80's by inexpensive, high quality Japanese vehicles.
This manufacturing paradigm shift, if it occurs, will give a software technology like Linux a substantial INITIAL advantage over technology being supported by pre-Open Source software manufacturing models. Architecturally Linux has an open loosely connected structure. This facilitates incremental, safe improvements of subsystems. The distributed nature of the resource community that services Linux has forced standards adoption. Linux improvements tend toward making incremental quality upgrades of existing tools since there is no market imperative driving Linux to favor "big bang" technology releases in order to garner the market's attention. The net effect is that Linux has become very stable and very standardized despite the absence of any single corporate or government entity mandating these characteristics.
If I was Microsoft, I'd consider becoming the world's preeminent support and value added supplier of a Linux distribution rather than trying to bury it. I suspect their culture leaves them as unable to do this, for now, as IBM's was unable to recognize the potential revenue power of the personal computer. IBM missed that boat, in part, because PC's appeared to threaten their big-iron hardware pricing and manufacturing models and because, initially, it just didn't seem to be "serious" technology. I think the parallels with the Linux and Open Source movements are striking.
If I'm a vendor, particularly one with an increasingly tenuous hold on proprietary, building block technologies, I would be working very hard to minimize the importance of Linux and Open Source. Or I'd jump in with both feet. Whether everything stays "free" is unimportant and I suspect unlikely, however, it's all going to become MUCH less expensive, quality focused, evolutionary and standards driven if Open Source continues to be successful. That, to me, is the really exciting aspect of what the Linux community represents for software developers and consumers.