This chapter is from the book
This chapter is from the book
This chapter is from the book
Deny Vendor Lock-in
In economics, vendor lock-in, also known as proprietary lock-in or more simply lock-in, is a situation in which a customer is dependent on a vendor for products and services and cannot move to another vendor without substantial costs, real and/or perceived. By the creation of these costs to the customer, lock-in favors the company (vendor) at the expense of the consumer. Lock-in costs create a barrier to entry in a market that, if great enough to result in an effective monopoly, might result in antitrust actions from the relevant authorities (the FTC in the United States).
Lock-in is often used in the computer industry to describe the effects of a lack of compatibility between different systems. Different companies or a single company might create different versions of the same system architecture that cannot interoperate. Manufacturers might design their products so that replacement parts or add-on enhancements must be purchased from the same manufacturer rather than from a third party (connector conspiracy). The purpose is to make it difficult for users to switch to competing systems. (Source: Wikipedia, the free encyclopedia.)
"Enraged" is probably the most appropriate description of CIO sentiments toward a certain ISV market leader’s attempts to limit choice through the practice of vendor lock-in. After a quick review of recent history, it’s not hard to conclude that a good deal of the intensity and momentum of the entire open source movement is a reactive backlash to the monopolistic and coercive methods of commercial software vendors.
Many ISVs, including Novell, work to ensure that customers return again and again for services and establish income flows through subscriptions and maintenance. But historically, others have consistently endeavored to limit choice to a single vendor with closed and proprietary solutions. As described in a recent eWeek article, "The economic value of ’open’ lies in the ability for users to walk away from onerous vendor pricing or licensing, the negotiating leverage they have, and the ability to avoid vendor-unique extensions."
The following list includes several of John Terpstra’s definitions of vendor lock-in. John has been part of the open source Samba project since its early days, and has methodically identified several restrictions that illustrate vendor lock-in scenarios:
Proprietary data storage formats that lack interoperability with other vendors’ software applications and/or that prevent the data from being exported from the vendor’s product to another vendor’s product
A vendor that has a restrictive partnership agreement to implement (that is, support) the product only on said partners’ platforms or systems
A vendor that requires customers to sign an agreement that mandates that support fees will continue to be paid even if use of that vendor’s product is discontinued within the contract period
A vendor that places license restrictions on what OS platform data from the vendor’s application may be placed
A vendor that demands contractual exclusivity, preventing all other competitors’ products from being onsite
A vendor that does not supply source code for its applications
A vendor that provides source code but fails to provide any essential component or software needed to rebuild a working binary application from that code
Open source provides fundamental freedom of choice. Sure, there are differences in distributions and features, but the fact that code is open and available means that in the majority of cases, good features and enhancements will eventually be merged with the mainstream code. Several elements of open source reduce the probability of vendor lock-in. These include open standards, application portability, and alternative selection:
Open standards—Support for open standards and being open standards-based can be two completely different things. Hundreds of examples exist in which a solution that accommodates a standard by conversion, tunneling, or mapping often breaks down when a new version arrives, or the "patch" must be flexed to conform to supposed standard requirements. Although standards themselves are sometimes fluid, there is more longevity, momentum, support, and compatibility when a solution is based on open standards. If an implemented solution is only open standards-compliant, any changes such as adding new components, upgrading applications, making new connections, and so on could require reimplementing the original solution at additional cost. If the support-solution doesn’t flex, you’re locked in.
Internet mail is a good example. Microsoft Outlook and Exchange, although compliant with mail standards such as POP and IMAP, are not based on them. Therefore, integrating other standards-based mail systems in the event of a merger or acquisition takes a lot of work. They don’t seamlessly interoperate, and the net result is usually a complete conversion of one system to another. If you convert to Exchange, you’ve solved the immediate problem, but it will resurface again at the next reorganization.
Open source solutions are, by and large, interoperable with little modification. It doesn’t matter if your email system is Sendmail or Postfix, one can be substituted for another. Any POP client works with both. There’s no pressure to get into a proprietary groove and stay with the commercially metered flow for everything to work together.
Portability—Open source means you’re not tied to a specific operating system or platform. The great majority of open source applications that have been written for Linux run on all distributions of Linux. They also run on most versions of Unix, including multiple versions of BSD. This extends to the majority of web applications and services as well. PHP, Perl, Python, Java, and the solutions that are built using them run virtually unchanged anywhere. There’s no requirement to develop to a specific platform and then port it to another platform while maintaining multiple versions of code.
The Unix/Linux architecture design provides for performance without intricate hooks or hardwiring between the operating system and the application. The thought of Internet Explorer or Exchange running on Linux seems odd, but it shouldn’t be.
Substitutes—In a free-market economy, the availability of substitutes is responsible for a number of market factors, including competitive pricing and an increase in features. Vendor lock-in is achieved when there are no practical substitutes and prices are at a premium. As a source of substitutes for a widening selection of mass-market software solutions, open source is helping release the stranglehold of monolithic, end-to-end solution providers.
At this point in time, almost every common software solution needed for a typical business is available as an open source solution. Operating system, file sharing, firewall, web server, database, office productivity applications—multiple versions are available for each of these with no interlocking dependencies.
Here are the top vendor lock-in dangers:
Price—Call it monopolistic pricing, call it extortion. If you don’t have choice, you’re stuck paying whatever the vendor demands. With a subscription fee schedule and no competition, you don’t necessarily get enhancements, but you keep paying.
Adequate technology—Why be saddled with "good enough" solutions when excellent options are available? If you’re on a train, you eat what’s in the dining car, sleep where they put you, and go where the train is going. If you drive, you have your choice of restaurants, hotels, and destinations. Windows is good enough, but you get viruses, blue screens, and you have to rebuild it periodically. A Windows file and print server will support 50–100 users, but Linux on the same hardware will support thousands. Windows supports clustering, but Linux supports it powerfully and elegantly. An "adequate technology" strategy works for some organizations, but most will suffer long-term disadvantages by being locked in to only what a vendor provides.
Flexibility—Most organizations are NOT single-vendor shops. They are a heterogeneous mix of dissimilar systems, and monolithic vendor solutions don’t "work and play well with others." Common administration, holistic and comprehensive management, and seamless interoperability are not priorities for a vendor bent on eliminating all competing options.
Lest you think it hypocritical to point out the blemishes of vendor lock-in in the face of Novell’s 20-plus years as an independent software vendor, we must look at the facts. Novell’s first product was an effort to get Unix, CPM, and DOS machines to work together seamlessly with the capability to share back and forth. If you look at Novell’s history, practically every product produced has had the stamp of interoperability—getting heterogeneous, disparate systems to work together. This includes NetWare with its many clients, eDirectory with its user authentication synchronization, ZENworks with cross-platform management, and now products such as SUSE Linux, Open Enterprise Server, and iFolder. In a way, Novell’s success is a result of providing interoperability and connection services between disparate systems. With a focus on open source and Linux, the tradition of managing flexibility and choice continues.