The Linux Advantage: Locking Out the Lock-in Artists
Why move to Linux? It's free, of course, but as several commentators have pointed out, a purchase price of zero doesn't necessarily mean that Linux is without costs, including technical support and training. And those costs can be hefty. But there's more to the software cost picture - and when you fill in all the details, Linux starts looking very good indeed.
In this article, I will argue that Linux - and free software generally - provides the best defense against an odious but probably perfectly legal tactic, called technology lock-in, which the software industry routinely uses to coerce their customers into buying even more of the same firm's products. As you'll see, the downstream costs of technology lock-in can be devastating; but they are avoidable. By moving to Linux-based server infrastructures and free software applications, firms can guarantee they'll never again be victimized by technology lock-in, because (as I'll demonstrate) the General Public License (GPL) raises the costs of lock-in tactics to the point at which they're useless to even the most cynical vendors.
In my use of the term, which differs from that of many economists, a technology lock-in strategy is a conscious, deliberate and cynical design strategy in which certain technical features are incorporated within a product's design for no other genuine purpose than to coerce the firm's customers: specifically, to force customers to make huge collateral investments in additional products made by the same firm.
The classic technology lock-in case is IBM's use of CPU microcode against upstart competitor Gene Amdahl, who realized IBM's customers weren't very happy with IBM's mid-1960s processor offerings. A former product manager with IBM, Amdahl realized he could create much faster IBM-compatible processors if dispensed with microcode, a low-level (and inefficient) programming language that enabled IBM to specify a CPU's instruction set in software rather than hardware. Amdahl's processors were indeed much faster, but IBM dropped a bomb on the market by announcing that it would make continuous, unannounced and undocumented changes to its CPU microcode. The clear message from IBM to its customers? If you're running IBM's iron, you'd better not mess around with Amdahl's CPUs, which don't have programmable microcode. You might wind up with a bunch of equipment and software that won't work correctly, and what's more, we won't support it (Pfaffenberger 2000).
Isn't technology lock-in illegal? It's certainly predatory, but predatory marketing practices aren't necessarily illegal unless they're carried out by a firm possessing a monopoly in a given market. Even then, it's very difficult to prove that a given feature has been incorporated for no other genuine purpose than to coerce the firm's customers. IBM could argue that its motives for incorporating microcode into its products were perfectly innocent. Microcode was used, IBM spokesmen said, to ensure software compatibility across IBM's entire product line. And the truth is that the firm probably didn't fully grasp microcode's lock-in potential until Amdahl starting taking their market away with hard-wired CPUs. What started out as a rather kludgy and inefficient engineering solution suddenly became a potent weapon in IBM's campaign to safeguard its mainframe market monopoly. Even when the a feature's lock-in benefits are clearly foreseen, it's darned hard to prove to a jury that a lock-in feature was cynically designed for no other purpose than to coerce the firm's customers. The firm will talk about bringing all this great new technology to their customers - and then they put a few engineers on the stand, the jurors' eyes glaze over, and that's that.
What isn't debatable is the cost of technology lock-in to a firm's customers. A case in point: Bell Atlantic's mid-1980s purchase of AT&T's 5ESS switching systems (discussed in Shapiro and Varian 1999: 105-106). These were great switches, no doubt, but they came with an enormous hidden cost on top of their $3 billion price tag. Here's why. AT&T's 5ESS switches used a proprietary operating system that was available only from AT&T. As a result, AT&T was in a position to dictate the terms for subsequent modifications to Bell Atlantic's systems. For example, when Bell Atlantic wanted to implement toll-free 888 service, AT&T stiffed Bell Atlantic to the tune of $8 billion, more than twice the amount Bell Atlantic initially paid for the switches. Naturally, Bell Atlantic felt rather aggrieved about this situation, but they couldn't afford the massive capital investment that would be needed to switch to another vendor's technology. To put the point bluntly, they were had.
Business schools teach aspiring managers how to sniff out lock-in potential and avoid it at all costs. But sometimes it's difficult to detect a product's lock-in potential, and that's particularly true when you're talking about cutting-edge technology. Still, lock-in is something of a dangerous game to play, especially when it's as blatant as the strategy incorporated into AT&T's switches. That sort of behavior can get you sued - and that's just what happened to AT&T. In 1995, Bell Atlantic took AT&T to court, alleging that AT&T is a monopoly and its use of product lock-in amounted to an illegal predatory practice. Subsequently, the suit was settled out of court for an undisclosed sum.
Special Reports: DevOps
Have projects in development that need help? Have a great development operation in place that can ALWAYS be better? Regardless of where you are in your DevOps process, Linux Journal can help!
With deep focus on Collaborative Development, Continuous Testing and Release & Deployment, we offer here the DEFINITIVE DevOps for Dummies, a mobile Application Development Primer, advice & help from the experts, plus a host of other books, videos, podcasts and more. All free with a quick, one-time registration. Start browsing now...
- The Ubuntu Conspiracy
- Science on Android
- A First Look at IBM's New Linux Servers
- Disney's Linux Light Bulbs (Not a "Luxo Jr." Reboot)
- Vigilante Malware
- Bluetooth Hacks
- Vagrant Simplified
- Libreboot on an X60, Part I: the Setup
- System Status as SMS Text Messages
- October 2015 Issue of Linux Journal: Raspberry Pi