Skip to main content

How Lock-In Risk Evolves in A Cycle

Lock-In Risk Decreases With Bridges and Standards

Lock-In Risk seems to progress in cycles. As a piece of technology becomes more mature, there are more standards and bridges, and Lock-In Risk is lower. Once Lock-In Risk is low and a particular approach is proven a technology becomes a commodity. After that, there will be innovation upon this, giving rise to new opportunities for Lock-In Risk (see the diagram above). Here are some examples:

  • Processor Chips. By providing features (instructions) on their processors that other vendors didn't have, manufacturers made their processors more attractive to system integrators. However, since the instructions were different on different chips, this created Lock-In Risk for the integrators. Intel and Microsoft were able to use this fact to build a big ecosystem around Windows running on Intel chips (so called, WinTel). The Intel instruction set is nowadays a de-facto standard for PCs.

  • Browsers. In the late 1990s, faced with the emergence of the nascent World Wide Web, and the Netscape Navigator browser, Microsoft adopted a strategy known as Embrace and Extend. The idea of this was to subvert the HTML standard to their own ends by embracing the standard and creating their own browser Internet Explorer and then extending it with as much functionality as possible, which would then not work in Netscape Navigator. They then embarked on a campaign to try and get everyone to "upgrade" to Internet Explorer. In this way, they hoped to "own" the Internet, or at least, the software of the browser, which they saw as analogous to being the "operating system" of the Internet, and therefore a threat to their own operating system, Windows.

  • Mobile Operating Systems. We currently have just two main mobile ecosystems (although there used to be many more): Apple's iOS and Google's Android, which are both very different and complex ecosystems with large, complex boundaries. They are both innovating as fast as possible to keep users happy with their features. Tools like Xamarin exist which allow you to build applications sharing code over both platforms.

  • Cloud Computing. Amazon Web Services (AWS) are competing with Microsoft Azure and Google Cloud Platform over building tools for Platform as a Service (PaaS) (running software in the cloud). They are both racing to build new functionality, but it's hard to move from one vendor to another. Standards like Kubernetes attempt to address this.