Blog Post

Standardized open source products are the key to unlocking the lock-in trap

Stay on Top of Enterprise Technology Trends

Get updates impacting your industry from our GigaOm Research Community
Join the Community!

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.

8 Responses to “Standardized open source products are the key to unlocking the lock-in trap”

  1. Talent App Store

    Great article Marten, especially the techniques for increasing agility. These are sound high level strategies.

    In our business domain (Talent Management SaaS) we strive for these same goals. We have found that a microservices approach maps onto these strategies very well.

    1) lowering the cost of experimentation

    Allow customers to try before they buy, and to install multiple different apps that address the same business need. Encourage apps to play nicely and to build in the data management smarts needed to support parallel running.

    2) splitting decisions into smaller decisions

    Make apps smaller – smaller apps by necessity need to work well with other apps, which means both producing strong APIs and consuming the APIs of other, popular apps.

    3) reducing organizational latency, i.e. reducing the time it takes to get a response or a decision

    Empower business people to install, parallel run and uninstall apps, without fear of destabilising a precarious, monolithic enterprise software stack. Make apps work within a customer-driven provisioning environment.

  2. martenmickos

    Pardon me if I wasn’t clear. I didn’t refer to open standards. I talked about widely accepted standards.

    As for the products you mention, Eucalyptus does not try to define a standard; it follows a de-facto standard.

    Yes, OpenStack is trying to define an open standard. I would say that they have not reached that goal yet.

    Google’s cloud APIs could become a widely accepted standard as their customer base grows. You are right that generally speaking Google is proprietary. I think however that it is fair to say that they have taken a more open attitude when it comes to their cloud services. The recent opensourcing of Kubernetes was a great step. Let’s hope they opensource more!


    • Cloud Insider

      OK, thanks for the clarification. Yes, agree that OpenStack has not reached that goal yet. And I doubt that they ever will, because fundamentally asking customers to run clouds (which is hard, and more expensive after you factor in all facilities, hardware and headcount costs) will never yield as much ROI for customers as public clouds. AWS owns over 83% of the cloud market. And then add in Azure and GCP, and you have probably 90%+ of the cloud market covered by vendors that are primarily closed source. I really think that customers don’t care so much about open-ness – else you would not have this scenario. The open source vendors still have not captured any meaningful market share. If open-ness were as important as the OpenStack vendors claim it is, then it would have had much more adoption.

      I just wish I could share some of the AWS adoption and revenue growth numbers. Even after it has become a massive business, that thing is still growing like there is no tomorrow. Every so often you hear enterprises now going all-in on AWS.

      At the end of the day customers want something that works and that they can rely on more than open-ness imo. Even after you get past that, I think it is more about the availability of similar alternatives. For example, if there are a few credible public clouds that appear to work, then customers would be comfortable enough moving to public clouds, vs having AWS as the only choice for public clouds. So I think that if Azure and GCE can get some meaningful adoption (by that I mean say 10% of AWS) then over the long term it helps all public clouds, including AWS.

      Good to know that you have not changed your stance, and gone over to the dark side (OpenStack) just yet, and are still espousing AWS :-).

  3. Cloud Insider

    OpenStack is more of an open standard than Eucalyptus. Appears that you are advocating OpenStack – did you switch camps? Also, GCP is proprietary – so how is Google open?

  4. zurlocker

    My guess is that many users of open source are unaware of what Marten Mickos has referred to as “design lock-in”. The more you customize, the more you are locked-in, regardless of whether something is proprietary or open source.

  5. Linux SQL and all the other products you mentioned have support costs and they just don’t work out of the box. This is one of the worst attempts at trying to explain the advantages of open source

    • martenmickos

      Thanks for your comment. I beg to disagree with your claim. Many open source (and other) products work out of the box. For instance, out of every thousand users of MySQL, only 1 or 2 will buy support. Most people use CentOS without support (I don’t even think there is support available for it). These products cover such a broad range of use cases that you will find examples both of fully supported and totally non-supported use.