Everyone wants to avoid lock-in, but given the impossibility of avoidance, the key is to manage it.
Image: iStockphoto/Iaremenko
It's the "year of our lordt 2019 and people [are] still worried about lock-in," grumps Ben Black, eye roll in full effect. His cynicism is warranted. While vendors continue to position their offerings as all about reducing lock-in, and CIOs continue to declare in analyst surveys that avoiding lock-in remains a top concern, the reality, as Gregor Hohpe points out, is that we can "get locked up into avoiding [lock-in]," and positioning open source as a panacea for lock-in "turn[s] out to be not entirely true."
Same as it ever was
Back in 2000 I worked for an open source embedded Linux vendor, Lineo. We talked about using Linux to avoid vendor lock-in. A few years later, I was at a different open source vendor (Alfresco), still talking about open source as a tonic for lock-in. For nearly 20 years I worked for open source and proprietary companies, but lock-in was never far from the conversation, no matter the vendor.
Nor was I alone. Open source vendors talked up open source as The Answer to lock-in, but pretty much every vendor touted some aspect of their strategy as anti-lock-in, too…
...even as they locked-in customers.
SEE: How to choose and manage great tech partners (ZDNet special report) | Download the report as a PDF (TechRepublic)
The problem with the whole lock-in discussion is that everything creates lock-in. This is true whether you're a consumer opting to use Android over an iPhone, but it's particularly true for enterprises. Within the enterprise, the mere use of a technology—no matter its origin, license, or delivery model—results in lock-in. Why? Because...friction. Or, as Dave McCrory put it, "Every choice has resistance once you've started down a specific path."
Yes, even for open source. While Lucene and Hadoop creator Doug Cutting (correctly) notes that open source introduces a very different form of lock-in than vendor lock-in. "Sure, using an open-source API makes it difficult to switch to a different API, but it doesn't necessarily commit you to a commercial relationship," what he doesn't address is all the other forms of lock-in that remain (product, version, platform, architecture, etc.). As Patrick Angeles calls out, even enterprises that decided to write their own software (from scratch or using open source code) discover they're still locked in: "That team [that wrote the software] turns over, you're now locked in to an unsupported product."
In sum, there's no way out of lock-in. The key is to manage switching costs.
The price of lock-in
Richard Seroter captured this view a few years back, and his reasoning rings true today. "There are many reasons to embrace lock-in, including when that technology adds significant value and keeps you focused on the right activities," he said. But when a vendor stops innovating, or it's difficult to source talent for a given technology choice, he reasoned, it's time to pay the switching costs. There are ways, however, to ensure those switching costs remain reasonable all along, including the embrace of microservices, the avoidance of technologies that don't expose APIs, and more.
SEE: Vendor relationship management checklist (TechRepublic Premium)
One of the key things to avoid, Seroter implies and Massimo Re Ferré has hammered home, meta-management layers that claim to overlay multiple platforms (thereby unlocking you from those underlying platforms) simply end up (surprise!) locking you into the management layer. It's trading one form of lock-in for another, while eliminating much of the value of those underlying platforms. Perhaps worse, Re Ferré has suggested, that idea of innovative, multi-platform management is "just a unicorn thing," not a real-world thing.
Of course, as much as lock-in is a technology thing, it's more a matter of culture, as Expedia's Subbu Allamaraju has described:
During the last fifteen years, most enterprises reacted to lock-in concerns by over-investing in abstractions, whether it be programming frameworks, parsers, databases, communication protocols, application servers, cloud providers, you name it. At the end of it all, what's left was past regrets and large difficult to change monoliths. Those abstractions, in effect, did nothing other than contributing to a culture of change resistance.
Instead of heading down those false paths, he urged, enterprises should "embrace[] techniques like service orientation, asynchronous and decoupled communication patterns, micro-architectures, experimentation, failing fast, tolerance for mistakes, chaos engineering, constant feedback and continuous learning." In this way, whether using open source or proprietary code, on-premises software or cloud services, a company can maintain its independence and agility. That's not to say lock-in will disappear, but rather that it will be manageable.
Open Source Weekly Newsletter
You don't want to miss our tips, tutorials, and commentary on the Linux OS and open source applications. Delivered Tuesdays
Sign up today Sign up today
0 Comments