DevQ: An Open-Source Quantum Runtime That Makes the Quantum Execution Layer Transparent and Reproducible

The "Black Box" Dilemma of Quantum Computing

Quantum computing carries transformative expectations, but a problem rarely discussed openly is this: mainstream commercial quantum runtimes are essentially opaque black boxes. A quantum runtime refers to the entire software execution layer between when a user submits a quantum circuit and when measurement results are returned—it encompasses critical steps such as quantum circuit compilation and optimization (converting abstract gate operations into hardware-supported native gate sets), qubit mapping (assigning logical qubits to physical qubits), circuit scheduling (determining task execution priority and timing), and the application of error mitigation strategies. In IBM's Qiskit Runtime or Google's Cirq execution environment, these steps are typically completed automatically as part of a cloud service, and users can only configure them through limited parameter interfaces.

You submit a quantum circuit, receive results, and everything in between—which physical qubits were selected for execution, why those particular qubits, what error trade-offs were made, how tasks were scheduled—all happens inside a closed system that cannot be inspected or modified.

Recently, a developer shared his open-source project DevQ on Reddit, built precisely to address this pain point. In his words: "For a field that's supposed to be scientific, this opacity has always felt backwards to me." The core of science lies in reproducibility and verifiability, and when critical decisions are hidden behind API boundaries, is an experimental result a reliable conclusion or merely an unreproducible anecdote?

DevQ's Core Philosophy: Runtime Decisions Fully Open to Developers

DevQ is an open-source quantum execution layer licensed under Apache-2.0, designed with the goal of complete "openness." The author specifically emphasizes that this "openness" is not the kind where "the client SDK is on GitHub, but the real core logic runs server-side"—it's thorough transparency: you can read exactly which source code chose your qubits, replace it with your own strategy, and fully reproduce a run using a random seed.

The project is built on a simple yet powerful principle: Any decision made by the runtime should never be hidden from you. This statement is implemented at every level of the architecture design.

Inspectability: Real-Time Exposure of Runtime Internal State

DevQ provides an interactive shell that exposes the runtime's internal state in real time—including which qubits are currently in use, error map conditions, and process status.

Error maps here refer to topological maps of current error rates for each qubit and quantum gate in the quantum processor. Since qubit performance drifts over time—affected by temperature fluctuations, cosmic rays, crosstalk, and other factors—error maps need to be updated through periodic calibration. This data includes single-qubit gate error rates, two-qubit gate error rates, readout error rates, and qubit connectivity topology. On commercial platforms, while some calibration data is provided to users through APIs, the specific logic of how the runtime uses this data to make routing and allocation decisions remains closed. DevQ opens this layer completely, with no information hidden behind an impassable API boundary.

For quantum computing researchers, this transparency means they can finally understand and trust the execution logic at every step.

Extensible Plugin-Based Architecture

DevQ designs routers, allocators, schedulers, providers, and frontends as fully pluggable components.

The technical nature of the qubit allocation problem is worth understanding in depth: on real quantum hardware, not all physical qubits are of equal quality. Each qubit has different T1 (energy relaxation time) and T2 (decoherence time) values, and the error rates of two-qubit gates (such as CNOT gates) between different qubit pairs vary significantly. Therefore, the decision of "which physical qubits to use to execute your circuit" has a decisive impact on the quality of the final results. Commercial platforms typically perform this allocation automatically based on real-time calibration data, but users cannot know the specific basis for the allocation or verify whether the optimal solution was chosen. DevQ's plugin-based allocator is designed to give researchers complete control over this process.

Users can bring their own implementations, and these custom components are treated as "first-class citizens," enjoying equal status with built-in components. This plugin-based design allows researchers to replace the strategy at any quantum execution stage for specific experimental needs.

Reproducibility: Seeded Runs Ensure Verifiable Results

Through seeded runs and recorded decisions, DevQ ensures that "a result is a result" rather than an unrepeatable coincidence.

The irreproducibility of quantum computing actually comes from two fundamentally different levels: first, the inherent probabilistic nature of quantum measurement—this is a physical reality determined by the Born rule and cannot in principle be eliminated; second, classical randomness introduced in runtime decisions, such as randomly selecting qubit mapping schemes or randomizing circuit compilation paths to achieve noise symmetrization. Seeded runs target the second level—by fixing the pseudorandom number generator's seed, all classical-level decisions can be precisely reproduced under identical conditions. This way, when researchers observe anomalous results, they can clearly distinguish whether they originate from statistical fluctuations of quantum noise or from the runtime making different classical decisions.

Given the inherent noise and randomness of quantum systems, reproducibility has always been a critical threshold for verifying the credibility of quantum computing results. DevQ systematically solves the reproducibility problem at the classical decision layer through its architecture.

Why Apache-2.0 License

The project's adoption of the permissive Apache-2.0 license is not accidental. The author's rationale: to allow both researchers and enterprises to build their own products and research on top of it without friction.

The Apache-2.0 license allows users to freely use, modify, and distribute code (including for commercial purposes) without requiring derivative works to be open-sourced. It also includes explicit patent grant clauses that protect users from patent litigation by contributors. In the quantum computing field, this is particularly important because many quantum algorithms and compilation optimization techniques involve numerous patents. Compared to copyleft licenses like GPL, Apache-2.0 does not require derivative works to also be open-sourced, significantly reducing legal concerns for enterprises integrating it into commercial products. Notably, IBM's Qiskit also uses the Apache-2.0 license, which has become the de facto standard in the quantum computing open-source ecosystem.

This choice reflects the author's clear-eyed understanding of the project's positioning: he wants DevQ to become open infrastructure for the quantum execution layer, not an isolated academic project. A permissive license is the practical path to attracting ecosystem participants.

Project Status: An Honest Early-Stage Open-Source Project

It's worth acknowledging that the author is very candid about the project's current state. DevQ is currently a single-author project developed with personal resources, still in its early stages. There is a command marked as WIP (Work In Progress) in the project, as well as a known large-device bug, and the author chose to track these issues publicly rather than hide them.

What's even more commendable is that the project's complete Git history has been public from day one. This thorough transparency is consistent with the project's core philosophy that "nothing should be hidden"—not only should quantum runtime decisions be transparent, but the development process itself should be transparent too.

The Significance and Challenges of an Open Quantum Computing Ecosystem

DevQ's emergence touches on a deep contradiction in the current quantum computing commercialization process: scientific research demands transparency and reproducibility, while commercialization tends toward closure and protection.

The major quantum cloud service providers currently include IBM Quantum (based on superconducting qubits, with Eagle processors exceeding 127 qubits), Google Quantum AI (also superconducting, known for the Sycamore processor), Amazon Braket (an aggregation platform accessing multiple hardware vendors including IonQ and Rigetti), and IonQ (using trapped-ion technology), among others. While these platforms provide user-friendly SDKs and cloud interfaces, their core runtime logic—particularly advanced compiler passes for circuit optimization, dynamic qubit routing algorithms, and adaptive error mitigation strategies based on real-time noise data—is typically closed-source proprietary information. This opacity is especially problematic as quantum computing enters the "practical quantum advantage" exploration phase, because researchers need precise control and understanding of every experimental variable to make reliable scientific claims about computational results.

As a single-maintainer early-stage project, DevQ faces realistic challenges: whether it can attract enough contributors to form a community, whether its reliability can be validated on real quantum hardware, and whether it can keep pace with the rapid feature iterations of commercial quantum runtimes. The author explicitly states that precisely because the project is still early, "thoughtful opinions can genuinely shape its direction," and he looks forward to community contributions of code or issue submissions.

For developers and researchers focused on quantum computing infrastructure, DevQ offers a direction worth watching: in a field dominated by large corporations, is there still a truly open, inspectable, and reproducible path for quantum computing technology? The project repository is at github.com/DevUs-org/DevQ.

Note: This article is based on the project author's original post on Reddit and represents a single-source piece of information. The project's actual maturity and usability should be independently evaluated and verified by readers.