Untold Stories of Intellectual Property: platform lock-in

Showing posts with label platform lock-in. Show all posts

Sunday, August 16, 2026

Why Are Quantum SDKs Free? The Platform, Standards, and Quantum-Compute Competition Behind the Code

The platform, standards, and quantum-compute competition behind free code

When I first learned to work with quantum computing in code during graduate school, one of the tools I used most often was IBM's Qiskit. I would build quantum circuits, implement algorithms, and then examine the results on simulators or actual quantum hardware. At the time, I saw Qiskit primarily for what it plainly was: an excellent tool for learning and research. Looking at the industry again years later, however, a different question came into view. In a field that requires extraordinary levels of research and development investment, why do companies make core development tools available for free?

It would be too simple to reduce the answer to vendor lock-in. It would be equally incomplete to describe free quantum SDKs solely as an open-source contribution to research and education. Free SDKs do, in fact, facilitate education, dissemination of research, external contributions, and technical validation. At the same time, they can expand developer adoption, make particular programming paths familiar, and help cultivate future demand for scarce computing resources. Those are different propositions. Saying that a company intended those market effects requires evidence of intent; observing that such effects may arise from the structure of the market does not.

The Code May Be Free; the Compute Is Scarce

Qiskit is an open-source SDK distributed under the Apache License 2.0.^[1] But a free SDK is not the same thing as unlimited free access to a quantum computer. As of August 16, 2026, IBM Quantum's Open Plan provides up to 10 minutes of QPU usage on a rolling 28-day basis.^[2] Amazon Braket generally charges for on-demand QPU access through a combination of per-task and per-shot fees, while dedicated reservations are offered on a time-based basis.^[3]

The economics become clearer once those layers are separated. Software and documentation do not ordinarily incur proportional marginal cost each time another developer downloads or uses them. A QPU is different. It is a physical resource with substantial construction and operating costs and finite availability. That makes it economically plausible to lower the barrier at the software layer while charging for scarce execution resources and higher-value services. Nor do all providers offer hardware access on the same terms. Cirq is an open-source framework, but access to Google's quantum processors requires a separate approval process.^[4] Free software and access to quantum hardware are distinct questions from the outset.

Several Distinct Layers Sit Beneath the Label “SDK”

One of the easiest mistakes in discussing quantum SDKs is to collapse the entire software stack into a single category. An SDK, an intermediate representation (IR), a compiler or transpiler, a runtime, QaaS, and a QPU do not perform the same function. A development framework expresses circuits and algorithms. An IR provides a representation used to carry a program through stages of compilation. Compilers and transpilers perform gate decomposition, placement, routing, and optimization. Runtimes and cloud services handle job submission, queuing, execution, and result management. The QPU ultimately performs the physical computation.

For the same reason, it is imprecise to say that an SDK directly “controls” a QPU. In a cloud environment, developers generally interact with circuits, execution options, and job-submission interfaces. Device calibration, physical control, resource allocation, and substantial portions of execution policy remain with the provider. The strategic importance of the SDK therefore does not arise because it owns or physically controls the QPU. It arises because the SDK helps mediate the path by which a developer's algorithm reaches the underlying computing resource.

Lock-In Is More Often Accumulated Than Announced

The fact that Qiskit is open source and the proposition that IBM released Qiskit for the purpose of creating lock-in are entirely different claims. The latter requires independent evidence. Research dissemination, community growth, external contributions, and technical validation are themselves sufficient reasons for maintaining an open-source project.

Open source, however, does not eliminate switching costs. Developers become familiar with a framework's object model, libraries, APIs, and compilation workflow. Organizations build codebases, tests, automation, authentication systems, experiment records, security reviews, and operating procedures around those tools. Optimizations tied to a particular QPU's gate set and connectivity, as well as runtime policies, queues, reservations, pricing, support, and service-level commitments, can add further friction. In practice, switching costs tend to arise not from a single restrictive license, but from the accumulated weight of technical, operational, and contractual assets. That concentration is not necessarily undesirable. A customer may accept greater dependence on a platform in exchange for better performance, productivity, reliability, or support.

An Intermediate Representation Is Not Middleware

Portability analysis also requires careful terminology. OpenQASM and QIR concern, in different ways, how quantum programs are represented between stages of a toolchain. pytket, by contrast, is better understood as a compiler and toolkit layer that uses a common Backend abstraction to interact with devices and simulators from multiple providers. The OpenQASM 3 specification expressly identifies an intermediate-representation role between higher-level compilers and quantum hardware as one of its principal objectives.^[5] QIR is an LLVM-based quantum intermediate representation, and generic QIR may need to be transformed into a form that satisfies the requirements of a particular target or capability profile.^[6] pytket provides compilation functionality and a Backend abstraction that connects software to devices and simulators across providers.^[7]

An IR and middleware are therefore not synonyms. An IR is a representation in which a program is expressed. A compiler or middleware layer is software that reads, transforms, and connects such representations to an execution environment. Conflating those concepts can lead to another mistaken inference: that the existence of an open IR necessarily makes movement between platforms frictionless.

Code portability does not guarantee performance portability. Rewriting source code for another framework, translating a program into another IR without losing information, and successfully executing the program on a different QPU are separate questions. Whether accuracy, circuit depth, cost, and latency remain comparable is yet another question of performance portability. Operational portability also matters: authentication, monitoring, experiment metadata, security processes, and regulatory controls may all have to move with the workload. An open IR can improve representational portability without solving every other layer of portability.

Open Source Does Not Necessarily Mean an Open Platform

The Apache License 2.0 used by Qiskit broadly permits modification, redistribution, and commercial use, and includes a patent license from contributors within the scope defined by the license. It also contains a patent-termination provision that applies to specified patent litigation involving the Work or a Contribution.^[8]

What an open-source license opens, however, is primarily the code and the associated legal permissions. It does not automatically open access to physical QPUs, calibration data, low-level controls, execution priority, managed runtimes, enterprise support, or service-level commitments. Open source and commercialization are therefore not opposing strategies. The more useful question is which layers are open and which remain under the provider's control.

In Standards Work, Status Matters More Than the Project Number

Standards discussions are particularly time-sensitive. A Project Authorization Request (PAR) authorizes a standards-development project; it is not itself a published IEEE standard. As of August 16, 2026, IEEE project pages list P7130, Quantum Technologies Definitions, and P3329, Quantum Computing Energy Efficiency, as Active PARs.^[9]^[10] P3980, approved on March 26, 2026, is also listed as an Active PAR and addresses general application guidance for hybrid quantum-classical computing technology.^[11]

IEEE Standards Board action records, however, show that the PAR for P3155 was withdrawn in June 2023, P3120 in June 2025, and P3185 in September 2025.^[12] Some individual project pages may continue to display an Active PAR label after a withdrawal action appears in the Board's records. That is precisely why a project page should not be treated as the sole source of truth for current status; the most recent Standards Board action should also be checked.

The movement itself is instructive. It suggests that the standards architecture for quantum computing remains unsettled. For policymakers and companies, the important question is not simply whether a component is open source. More practical questions are whether code and data can move, whether results can be reproduced across QPUs, how far IRs and APIs are interoperable, and whether experimental assets and operational processes remain recoverable when a contractual relationship ends.

What a Free SDK Expands Is the Future Path

When I first used Qiskit, I was simply grateful that such a capable tool was available at no cost. Looking at the same kind of tool today, I pay more attention to what accumulates on top of it. Developers learn the tool, write code, and build tests and experimental procedures. Organizations begin to treat particular APIs and execution environments as part of their operating infrastructure. From a provider's perspective, more developers become familiar with programming paths that lead into the provider's own ecosystem or an affiliated one.

None of that, standing alone, proves an intentional lock-in strategy. It does, however, support a more modest and more defensible conclusion: free SDKs can lower the barriers to research and education while also shaping future compute demand and platform adoption. Looking only at qubit counts and error rates misses that layer of competition. At a time when no one can say with confidence which hardware architecture will ultimately prevail, the languages, SDKs, IRs, compilers, and runtimes around which developers build code and habits may themselves become strategically significant.

The future competition among quantum platforms will not take place only inside hardware laboratories. The SDK a developer installs today—and the code, tests, and operating practices built on top of it—are already part of that competition.

Primary Sources and Verification Materials

Verification date: August 16, 2026. Service terms and standards-project status may change after this date.