Vendor lock-in, part 1Proprietary and lock-in not necessarily synonymous

The first time you tried to connect one of your old Tinker Toys to a new plastic Lego block, you experienced vendor lock-in. Being locked in to one vendor's IT Tinker Toy can be disastrous if the vendor fails to deliver sound products and services. But is vendor lock-in always a bad thing? In this three-part interview, SearchEnterpriseLinux.com experts answer that question and many others. In part one, Sam Greenblatt, Ken Milberg, Matt O'Keefe and John Terpstra explain how lock-in works. In parts two and three, they discuss how lock-in can affect your company and offer tips for using open-source products.

When IT pros talk about vendor lock-in, what do they mean? From Wikipedia, the free encyclopedia, here is a definition of vendor lock-in: '... a situation in which a customer is dependent on a vendor for products and services and cannot move to another vendor without substantial costs. It is often used in the computer industry to denote the lack of compatibility between different systems which, intentionally or unintentionally, forces...

a customer to continue to use products and services from a particular vendor.' When IT pros talk about vendor lock-in, what do they mean? Vendor lock-in means that there exist particulars of a vendor's product that dictate how a customer may use the product and/or that constrain the ability of the customer to migrate to a platform of choice. How does open-source software fit into the vendor lock-in scenario? The concept of vendor lock-in is antiquated by the new paradigm that open-source works in. A product should be able to be extensible to any open-source model, and thus there is no concept of locking in a customer through functionality, but rather extending their capability through open innovation. Open innovation is when a commercial software package extends the model to include open-source. How do vendors lock in a customer? Examples include:

 

  • 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 so that it can be imported into another vendor's product.
  • A vendor who has a restrictive partnership agreement to implement (i.e. support) the product only on said partners' platforms or systems.
  • A vendor who 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 who places license restrictions on what OS platform data from the vendor's application may be placed on.
  • A vendor who demands contractual exclusivity from all competitors' products being on site.
  • A vendor who uses software or hardware locks to prevent the customer from changing the software, creating new data files [or] moving data files from one machine to another.
  • A vendor who charges a system upgrade or relocation fee when a hardware fails and new replacement hardware is installed. Instead of a fee, a vendor who demands to have control of application re-activation in any way is exerting a degree of vendor lock-in.
  • A vendor who does not supply source code for its applications. In this case, should the vendor go out of business the customer will be locked in and must find a new application vendor.
  • A vendor who provides source code but fails to provide any essential component or software needed to rebuild from that code a working binary application.

Customers should evaluate all business risks in the light of the degree to which the application software might jeopardize the business in the event of a fall-out of relationship with the vendor, or in the event that the vendor might go out of business or cease to support and/or develop the software. So, vendor lock-in and proprietary software are not synonymous?
Very few proprietary software products actually lock in the customer. There are generally several alternatives for each type of application, and the computing industry in the course of its history always tends more and more towards open standards. Open source is just part of that evolution. Nevertheless, it is up to customers to be careful to design the IT architectures so that they can have a choice among various vendors whenever possible.

So, vendor lock-in and proprietary software are not synonymous?
 

Sam Greenblatt is senior vice president and chief architect for Computer Associates' Linux Technology Group. Currently, he is involved with creating management solutions focusing on the next generation of servers and providers (Web services) and server consolidation.

Kenneth Milberg, president and Unix systems consultant at Unix Solutions, is an independent contractor who has been working with Unix systems for over 12 years.

Matt O'Keefe is chief technology officer and founder of Sistina Software, in Minneapolis, and an expert and educator in the fields of clustering technologies and storage infrastructures.

John H. Terpstra is co-founder of the Samba Team and a member of the Open Source Software Institute Advisory Board. He is also CEO and president of PrimaStasys Inc., a company that mentors information technology companies and facilitates profitable change in practices.

Does this mean I should never use a proprietary software vendor's products?
Absolutely not. Some of the best code is proprietary, both on the application side (IBM WebSphere and DB2, Oracle) the OS side (AIX, Solaris, etc.) and even the hardware side (p690 IBM Regatta platform). As great as open-source products are, they are not ready to replace enterprise-type products (that cost big money) by top vendors. Does this mean I should never use a proprietary software vendor's products?
No way! There are many ways in which vendor lock-in may be mitigated. Always, always consider all aspects of the vendor's solution, the negotiability of the vendor to help minimize customer exposure, etc. So, vendor lock-in and proprietary software are not synonymous?

Read part 2 of this series: "Vendor lock-in, part 2: Combating lock-in with open source"

Read part 3 of this series: "Vendor lock-in, part 3: Solid contract negotiation key to avoiding lock-in"

SearchEnterpriseLinux.com Ask the Experts

 

Best Web Links on decision criteria

SearchEnterpriseLinux.com news exclusive: "Red Hat's Tiemann: Architectural vision must be 20/20"

FEEDBACK: Have you experienced vendor lock-in? How did you break the chains?
Send your feedback to the SearchEnterpriseLinux.com news team.

Dig deeper on Introduction to Linux system administration

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchDataCenter

SearchServerVirtualization

SearchCloudComputing

SearchEnterpriseDesktop

Close