Why I Joined the Unitary Foundation And What I'm Planning to Do

Every quantum hardware vendor I've talked to says the same thing: they can realistically support one, maybe two digital routes to market.

Not because they lack ambition, but because each integration — whether it's their own vertically integrated application, Amazon Braket, Azure Quantum, OVHcloud, or an aggregator like QBraid — is a bespoke engineering effort. These companies are busy making qubits, and qubits are extraordinarily hard to make. Maintaining parallel integration stacks is a distraction they can't afford, and it limits their market exposure at exactly the stage when they most need feedback from users.

On the other side of the table, cloud providers face the mirror image of the same problem. At Amazon, I watched the Braket team integrate vendor devices one at a time through custom engineering. Each vendor arrives with its own proprietary stack layered on top of the control plane, creating a different integration challenge every time. With over 100 quantum hardware vendors now in the marketplace — a figure that grew more than 40% in under a year, per Bob Sutor's analysis — no single cloud provider can sustain the investment to integrate them all.

ISVs face the same challenge at a smaller scale, with fewer resources. The result is an M × N complexity problem that taxes the entire ecosystem.

I joined the Unitary Foundation as a Fellow because I believe it's time to fix this. Specifically: it's time to begin a concerted, community-driven effort to define the first open standards for the quantum technology stack — starting with the integration layer.

The Quantum Device Integration Layer

I'm calling it the Quantum Device Integration Layer (QDIL).

The scope is deliberately narrow. QDIL covers the set of actions a piece of classical infrastructure needs to carry out on a quantum device: discover its capabilities, initiate a session, pass a task, receive results, close the session. There are ancillary management tasks — checking queue depth, tracking task status — but the core is a small, well-defined set of verbs and responses.

The design philosophy draws from HTTP. When HTTP first emerged, it seemed almost comically narrow compared to the enterprise client-server protocols it would eventually displace. It supported only GET and POST, with an extensible header set and complete agnosticism toward the application layer above it. That simplicity is precisely why it became ubiquitous. QDIL follows the same logic: the spec does not prescribe whether the payload is QASM, QIR, QUA or some future intermediate representation. It only requires that the task describe how the payload is delivered, along with appropriate metadata — submitting entity, security context, and other extensible fields.

The goal is a spec and reference implementation that serve the community across the full lifecycle — from an experimental qubit in a university lab to a production cloud service. A team building a novel device should be able to grab a GitHub repo and build their experimental, alpha, beta, and production access around the same spec.

Why Now

Standards efforts have a lousy track record. The Unix wars are a reminder that "open" has often been used as a competitive weapon. But several factors make this moment different.

The community is receptive. The Quantum Device Management Interface (QDMI), developed out of work at TU Munich and LRZ, rapidly became a de facto standard after distilling lessons from deploying AQT and IQM devices on-premise. LRZ announced they would require QDMI support from any future hardware purchases. Vendors accepted this without pushback. U.S. entities including DOE National Labs are now considering QDMI seriously. QDMI addresses management and access in on-premise contexts and doesn't fully solve the access-layer problem across cloud and other loosely-coupled use cases QDIL targets — but the community's response is a strong signal that the appetite is there.

The hardware explosion itself creates urgency. We're past the point where bespoke integration scales. The problem demands a shared solution, and everyone involved knows it.

And there is a deeper reason this matters right now.

The Case for Openness

A story from the dawn of information technology, in the late 1940s. Two projects were trying to build the first universal electronic computer in the U.S. ENIAC — built at Penn by Mauchly and Eckert — was the product of scientists who immediately began pursuing IP claims against anyone they believed was infringing on their patents on universal computation. John von Neumann, leading the parallel effort at Princeton's Institute for Advanced Study, took the opposite approach: he published the IAS architecture in a white paper and handed copies to anyone who asked. Within a few years, some 50 clones of the IAS machine had been built around the world — in Ukraine, Israel, and elsewhere — with names like MANIAC and JOHNNIAC as tributes. Today, every computer and phone on the planet runs a von Neumann architecture. The ENIAC architecture, and the company that tried to commercialize it, are footnotes.

Linux and the broader open-source movement arrived roughly 50 years too late in classical computing. We'd already spent five decades building proprietary moats, weaponizing standards, and constructing monopolies that limited not only how much value the IT industry created, but who got to participate in it.

Quantum doesn't have to repeat that pattern. Today's quantum devices are experimental. There are no production workloads. No enterprise is deriving economic value from a quantum computer. The public sector, academic research, and the open-source community hold disproportionate influence over this stage of the industry. That is an asset.

By the time a quantum product or service exists that companies will pay real money for, I want open standards deeply embedded in it — so that everyone gets a fair shot at creating and capturing that value. Premature commercialization of an immature technology is a higher-risk path than openness, for the commercializing entity and for the rest of us.

We have a window. It won't stay open forever.

What Happens Next

There are a number of projects and communities already working on related challenges — QDMI, QIR Alliance, OpenQASM, Oqtopus, and others. This effort is meant to complement them, not compete. I'm strengthening my existing ties with these projects to work toward a shared goal.

My immediate plan: canvas those communities, get alignment on a collaborative process, and turn a series of conversations into an in-person workshop at the Unitary Foundation's conference in September in Toronto.

I want hardware vendors, cloud providers, ISV engineers, national lab staff, and open-source maintainers at that table. If you build, operate, or integrate quantum devices — or if you're building the software that talks to them — this is your problem too, and I'd like your input.

Reach out in the comments, via this newsletter, or directly: sebastian@unitary.foundation