When it comes to software and cloud services, the concept of lock-in has a heightened meaning. Vendor lock-in exists in all industries, but no where does it take you more by surprise than in software and cloud services. Much like when selecting a house renovation contractor, there's a hidden penalty you pay both operationally and financially.
Over the past 15 years, I’ve served as CEO at several software companies, including MySQL and Eucalyptus Systems, where I am today. During this time, I have seen organizations large and small battle with lock-in. The cure they found was open source reference implementations of a widely accepted standard.
What to a customer first looked like an exciting new piece of software — easy to try, no strings attached — soon infests the organization and isn't quite as easy to remove. That's the definition of lock-in: A decision that later proves costly or impossible to get out of. It's ironic that the ease of adoption of open source can lead exactly to this situation.
To understand lock-in, there are three main things to know:
- Lock-in happens with your own designs as much as it happens with vendor-provided offerings
- Buyers may publicly decry lock-in, but like complaints about death and taxes, few can avoid it
- Agility is the opposite of lock-in
The first point is about the nature of lock-in. Vendor lock-in is just one form. But, if you customize the software you use or if you produce your own "glue code" to integrate disparate pieces of your infrastructure, you are locking yourself into an architecture of your own making. Because of the ongoing efforts required to maintain these systems, this will be costlier than any other form of lock-in.
There is a way to minimize both types of lock-in. Just think of how you avoid each type on its own. You avoid vendor lock-in by using open source software. You avoid design lock-in by using standard software components with industry-proven interfaces.
By using industry-standard open source software products, you reduce your lock-in down to an absolute minimum. You can always choose to self-support. You don't require an ongoing financial relationship with a vendor to continue to use the software. And because you chose a product and not a project, you also avoided ending up with design lock-in.
This is what Google and other leading vendors are doing, and it explains the enormous popularity of Linux, JBoss, SQLite, MySQL and other open source products (as opposed to projects). You know that you are not dependent on just one vendor, and you know that you don't have to customize the product for your own needs. The product works as expected out of the box.
The second point about lock-in is that risk-averse decision-makers actually don't mind it. If you have staffed your organization with leaders who are there to protect an existing business or safeguard some company asset, you can bet that they will always recommend sticking to those expensive commercial licenses. Publicly they may complain about lock-in, but in practice they will ignore the cost savings and enormous scalability benefits of modern open source software. They have a vested interest in status quo, and because the annual increase in software costs doesn't upset the CFO too much, no change in course will be taken.
The third point is that while maintaining the status quo is rational, it's also locking you out of further innovation and potential competitive advantage. By locking into the status quo, you are shutting the door to new experimentation and learning. There is little incentive for your team to try new technologies since you've effectively communicated an unwillingness to try new things. What seemed like a good risk mitigation strategy now leaves you blind to improvements. You've inadvertently institutionalized resistance to change.
The only way out of this predicament is to consider the opposite of lock-in: agility.
Agility is the ability to make changes (useful ones, we hope!) without much pre-planning and without rocking the boat. Agility is the ability to go from idea to experimentation very quickly, and to go from experimentation to actual deployment equally quickly.
You can increase agility in your organization by
- lowering the cost of experimentation
- reducing lock-in of all types
- splitting decisions into smaller decisions
- reducing organizational latency, i.e. reducing the time it takes to get a response or a decision
Consider a private cloud infrastructure that allows for quick and inexpensive experimentation. Use standard open source products to avoid lock-in of all types. Divide projects into smaller interoperable parts, and delegate decision-making to the project managers. Measure managers by how quickly they make decisions and how they enable their teams to experiment and innovate.
With the above list, it becomes clear that lock-in is actually one of several opposites of agility, not the only one. You won't become agile just by removing lock-in. But by not removing lock-in, you most certainly will not be agile.
Choose open source products that follow an established standard. Do not customize. Maintain your freedom, and strive for agility. That's true avoidance of lock-in. It leads to innovation and competitive advantage.
Mårten Mickos is CEO of Eucalyptus Systems, provider of an AWS-compatible private cloud software platform. Previously, he was CEO of MySQL AB.
Photo courtesy of Shutterstock user Sergey Nivens.
Related research and analysis from Gigaom Research:
Subscriber content. Sign up for a free trial.
