The innovation S-curve: How technology matures, disrupts, and why your next platform decision matters more than you think

Every technology—from the steam engine to the smartphone—follows a predictable arc: slow start, explosive ascent, then a plateau as physics or economics set in. This arc is the innovation S-curve, and it's a lens for understanding why Broadcom bought VMware, why Kubernetes has defied all expectations, and why the jump from hypervisors to cloud-native platforms is the most consequential architectural decision a modern enterprise can make.

The 3 phases of the S-curve

The S-curve plots time or effort against performance or adoption, always producing the same shape.

Phase 1 - Ferment: Progress is agonisingly slow. Investment is high, output is low. Early electric vehicles existed but were expensive, clunky, and lacked range. The technology wasn't wrong, it just wasn't ready.

Phase 2 - Takeoff: Once fundamental hurdles are cleared, small improvements yield massive gains. Think smartphones between 2007 and 2015—extraordinary leaps every year, costs collapsing, an industry standard established.

Phase 3 - Maturity: Diminishing returns set in. The physical or economic ceiling is reached, and further investment yields progressively less. The curve flattens.

A line graph illustrating the Innovation S-Curve model across three consecutive, overlapping technology lifecycles plotted against Time on the x-axis and Performance & Revenue on the y-axis. The first curve (red) starts at a low black dot labeled 'Ferment: The Painful Beginning,' rises steeply through a 'Takeoff' phase, and peaks at a black dot labeled 'Maturity: The Plateau.' As the red curve begins to decline, a second curve (orange) emerges from its own 'Ferment' stage, experiences 'Takeoff,' and peaks at a higher 'Maturity' point. Finally, a third curve (green) repeats this identical lifecycle, starting during the orange curve's takeoff and peaking at the highest level of performance and revenue. Dashed lines connect the corresponding lifecycle stages (Ferment and Maturity) across all three curves to show how sequential disruptions occur.

The real power of the model: The jump between curves

The S-curve becomes most powerful when you recognise that true disruption happens when a new curve begins at the bottom while the old one sits at the top.

While film photography was at its peak, digital imaging was clunky and expensive, but its ceiling was far higher. It eventually surpassed the old curve, leaving established leaders like Kodak with almost no time to react. The collapse cascaded: Deluxe Entertainment processed film for most of Hollywood for decades, but when film ended, their reason to exist went with it, despite never competing with Kodak.

When incumbents respond, the instinct is equally treacherous: add the new capability on top of the old platform. Blockbuster matched Netflix on price and catalogue, but Netflix was winning because its entire stack was native to the new curve. Adding new capability on top of old infrastructure delays the reckoning without changing the outcome.

A case study: Hypervisors and containers

The virtual machine S-curve - Current status: Plateau

VMware's ferment through the early 2000s gave way to takeoff from 2005–2015, when virtualisation became the gold standard and directly gave rise to Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP). Today, the curve is flat. Improvements are incremental, and the fundamental overhead—every virtual machine (VM) carrying its own full operating system—is a physical constraint that cannot be engineered away.

The container S-curve - Current status: Rapid growth

Docker made containers accessible in 2013, but managing them at scale was chaotic. Kubernetes won the orchestration wars from 2016 onwards. The efficiency gains are real: a VM boots in minutes, a container boots in seconds. A server hosting dozens of VMs can host hundreds of containers.

Beyond efficiency: The shift to a universal control plane

The efficiency argument understates the disruption. Hypervisor-centric platforms are single-purpose control planes, orchestrating VMs through a proprietary API. Kubernetes is different in kind, with a flexible API by design. The same cluster can orchestrate containers natively, VMs via KubeVirt, and AI inference workloads via KServe or llm-d.

An organisation on the hypervisor S-curve is not merely running older infrastructure, it is operationally locked out of the tooling where the next wave of enterprise capability is being built.

Why Kubernetes hasn't levelled off: Network effects and the CNCF

Kubernetes benefits from 2 compounding forces. First, the stacked curve effect: every time a major Cloud Native Computing Foundation (CNCF) project—Prometheus, Cilium, Argo—matures, it adds a new burst of utility to the core platform. Second, network effects: the 2025 CNCF Annual Survey finds 82% of container users running Kubernetes in production, up from 66% 2 years prior. Because Kubernetes is the foundation of modern software, every vendor must build a Kubernetes-native integration—more vendors means more utility, which attracts more users, which attracts more vendors.

Engineering value from mature curves

Broadcom's $61 billion acquisition of VMware was not a bet on the future of virtualisation. It was a calculated harvesting strategy. This entails identifying a deeply embedded technology, bundling and simplifying it, cutting research and development (R&D), and raising prices, while counting on migration cost to exceed subscription cost for large enterprises. Broadcom ran this playbook before with Brocade, CA Technologies, and Symantec Enterprise.

The output of this for customers can often by price increases Along with forced bundling and slower innovation, as is the logical conclusion of S-curve management.

The lateral move trap

The instinctive response to a pricing shock is to find another solution which if we continue to follow to example outlined above is a hypervisor-centric platform. This is a lateral move within the same S-curve, not a jump to the next one. The vendor problem is solved, but the strategic problem is not. Worse, the migration consumes budget, organisational energy, and political capital that could have funded the actual jump, while the Kubernetes ecosystem continues to accelerate.

The question the pricing shock should prompt is not, "Which hypervisor do we move to?" it is "Should we still be on this S-curve at all?"

The silent migration signal you may have already missed

Linux won. Over 90% of public cloud infrastructure runs on it. Your developers may not have waited: a developer on your team launches Windows Subsystem for Linux (WSL), writes .NET Core code, builds a Linux container, and deploys to Kubernetes on Azure. Windows was on the laptop, but it didn't touch the workload.

In 2001, Steve Ballmer called Linux "a cancer." By the mid-2010s, Microsoft's most valuable software was at risk of irrelevance on a platform their customers had already chosen. They acted: Visual Studio Code (VS Code) went open source, .NET and SQL Server were ported to Linux, and Microsoft Office moved to the browser. What those decisions signal about the Windows Server S-curve, we'll leave that as an exercise for the reader.

The risks of jumping between curves

For many organisations, the transition has already begun—not as a deliberate decision, but as a series of pragmatic choices. When Kubernetes first reached takeoff, it had no native VM support—running both platforms in parallel was not a strategic misstep, it was the only architecture available. The risks that follow are not hypothetical, they are the current operating reality.

The operational valley of death: Running Kubernetes and traditional virtualization technologies in parallel creates double cognitive load. Worse, with Broadcom's bundle pricing, an organisation that migrates 40% of workloads may still pay for 100% of the bundle, this is called the dual-platform tax.

The identity crisis: In virtualization, IP address is identity. Containers are ephemeral, they die and restart with new IPs constantly. Many migrations stall because the firewall team, working in the language of the old S-curve, cannot keep pace with the DevOps team on the new one.

The skills gap: This is a mindset change as much as a technology change: pets versus cattle, GUI versus API, systems administrator versus platform engineer. Without a deliberate reskilling programme, experienced administrators can become—entirely unintentionally—a force of institutional resistance.

The modernisation trap: The jump is not binary. Containerising a monolith gains immediate platform benefits—consistent CI/CD, environment portability, rolling deployments—before a single line of application code changes. It is a valid intermediate position. The trap is mistaking it for the destination.

A true bridge with Red Hat OpenShift Virtualization

The engine running Red Hat OpenShift's VMs is KVM—the Linux kernel hypervisor that has been running enterprise workloads since 2007 and today sits underneath AWS Elastic Compute Cloud (EC2), Google Compute Engine, and most of what the world calls "the cloud." The execution engine is not new. What is new is the control plane built around it: OpenShift Virtualization presents VMs as Kubernetes-native resources, managed by the same API as containers, governed by the same security and lifecycle tooling.

Two broad paths have emerged. 

Path 1 - Kubernetes on top of the hypervisor (VMware Cloud Foundation with Tanzu and equivalents) adds container capabilities without re-platforming. The problem is consistent: the hypervisor remains the primary management plane, the seam between infrastructure and application teams persists, and the organisation stays on the old S-curve.

Path 2 - OpenShift Virtualization treats the VM as a Kubernetes custom resource definition (CRD): the same kubectl, the same GitOps pipelines, the same security model for containers and VMs alike. One control plane, one skillset, one observability stack. Kubernetes is application-aware: it can monitor whether the application inside a VM is actually responding, not just whether the host is up. Infrastructure is defined in version-controlled YAML, peer-reviewed like code, and automatically reconciled—auditable and tamper-resistant in a way that a vCenter database cannot be.

Making the strategic leap with Linux as the launchpad

Stepping back, this argument is not merely about resolving a platform consolidation problem, it's a strategic decision about which innovation ecosystem an organisation wants to be inside.

Moving to OpenShift Virtualization means:

• Exiting a harvested proprietary curve (Broadcom's VMware) where the vendor roadmap is optimised for profitability, not customer innovation.
• Entering a community-governed platform (CNCF/Linux) where the roadmap is driven by the engineering needs of millions of practitioners.
• Gaining access to the AI infrastructure curve as a native capability—not a bolt-on. Kubernetes is the ecosystem driving enterprise AI today, legacy workloads and AI inference run on the same platform, managed by the same control plane.
• Inheriting Linux's network effects—the same community-driven compounding that keeps Kubernetes climbing its S-curve applies at the OS layer. AI is being built on Linux: every GPU cluster, every training run, every inference endpoint runs on a Linux kernel. The depth of tooling, security practice, and operational knowledge accumulated by millions of practitioners isn't something a proprietary vendor can purchase or replicate.

The result is an enterprise that is not merely migrating away from one vendor, it's repositioning itself on the right S-curve at the right moment. The platform is already living in the world that AI is building, while its legacy workloads are carried forward intact.

The platform decision is a strategic decision

At this point the question is simple: which curve are you standing on?

OpenShift Virtualization doesn't force a choice between financial performance and operational continuity. The jump doesn't require rebuilding the estate at once, it requires moving onto the right platform and modernising from a position of strength.

Staying on the hypervisor curve—whatever platform it runs on—offers the comfort of familiarity. OpenShift offers something rarer: sovereignty over your own innovation cycle.

The S-curve doesn't care about vendor loyalty. It only cares about what comes next.