On September 15, 2026, Fujitsu open-sourced its quantum application research software, the "Open Quantum Application Research Package (OpenQARP)." The initial release is v0.1.0, licensed under Apache License 2.0. It includes more than 70 composable components and more than 20 executable algorithms, totaling over 100 software components overall. Yet sheer numbers don't capture what this release actually means. OpenQARP isn't simply another tool for writing quantum circuits—its goal is to break apart the workflow connecting research questions to execution environments, and to make each stage swappable.
More Important Than 100-Plus Components: Three Interchangeable Layers
The public OpenQARP repository explains its design philosophy through three concepts: block, primitive, and engine. A block represents what a quantum circuit does. A primitive determines what is extracted from that circuit. An engine handles where and how that computation actually runs. Rather than stitching circuit, measurement, and execution into a single piece of code, this design lets researchers swap out only the layer they need.
For example, even with the same quantum circuit, computing the state vector exactly and estimating an expectation value from a finite number of measurements call for different outputs and different error characteristics. In OpenQARP, the circuit stays fixed as a block, while the primitive is swapped to select the desired output, and execution runs through an engine. By explicitly separating the research target from the computational method, the system makes it easier to identify exactly what needs to change when porting an algorithm to a different simulator or a future physical device.
The scope of what's included is broad. It covers VQE for finding ground states, its excited-state variants VQD and SSVQE, ADAPT-VQE for incrementally growing circuits, QAOA for combinatorial optimization, and QPE for quantum phase estimation. It also includes electronic structure mapping and configurable noise simulation, along with circuit partitioning and device-specific compilation. This is why Fujitsu describes OpenQARP not as a "gate library" but as an "application library"—the aim is to make entire research workflows the unit of reuse, not just low-level operations.
Fujitsu cites ADAPT-VQE in quantum chemistry as an example, reporting that Python code shrank from roughly 130 lines to fewer than 40—about a 70% reduction by line count. However, this is a single internal implementation example, not a measurement showing that development time or the learning curve shrinks by the same proportion. Execution speed and maintenance cost would need to be measured separately. What got shorter was the wiring code now handled by existing components. The work of verifying whether an algorithm is correct or meaningful for the target problem still remains.
Not Competing with CUDA-Q, But Layering Research Workflow on Top of It
OpenQARP can be installed on an ordinary PC via pip install openqarp. The distribution name is openqarp, but in Python it's imported as qarp. PyPI requires Python 3.11 or higher and distributes binaries for major CPUs on Windows, macOS, and Linux. This means researchers can experiment with the API and run small-scale computations locally, without connecting to Fujitsu's computing environment.
For GPU-based computation, however, NVIDIA CUDA-Q can be incorporated as the execution backend. CUDA-Q is a platform for running hybrid quantum-classical computation across GPUs and multiple quantum processing units, and OpenQARP builds problems, algorithms, circuits, and measurements on top of it. The two therefore don't compete for the same layer—OpenQARP's engine hands work off to CUDA-Q.
Comparisons with Qiskit and PennyLane deserve more careful reading. In a preprint submitted to arXiv, the OpenQARP development team compared operator processing, simulation, and compilation against OpenFermion, Qiskit/Aer, PennyLane/Lightning, Qulacs, qsim, and pytket. The authors report being one to two orders of magnitude faster in operator algebra, among the fastest for simulation, and comparable to mature compilers in two-qubit gate counts. The public repository states that each measurement comes with an independent correctness check.
Even so, these results alone don't establish overall superiority over existing quantum SDKs. What's being measured is performance under specific versions, inputs, workloads, and computing environments—separate from API stability or the number of supported physical devices. Documentation, external extensions, and maintenance staffing weren't compared on the same scale either. The paper is also a v1 preprint submitted on September 14, 2026, and has not been peer-reviewed. The authors' reproducible measurements are a starting point, but independent replication by outside teams under the same conditions is still needed.
The Aim: One API Spanning NISQ to Fault Tolerance
OpenQARP houses both variational methods designed for today's noisy intermediate-scale quantum computing and methods aimed at the fault-tolerant era. The former includes SSVQE and ADAPT-VQE; the latter includes QPE and QSVT. By placing currently usable features and future-oriented research targets within the same component model, the aim is to keep application-side experiments connected even as hardware generations change.
Execution environments also span this timeline. Beyond local PCs, building from source allows connection to CUDA-Q. Fujitsu also runs OpenQARP on a 40-qubit state-vector simulator using 1,024 units of the A64FX-equipped PRIMEHPC FX700.
However, appearing under the same API is not the same as being available at the same level of maturity. The 40-qubit state-vector computation is a simulation on a classical supercomputer—it does not demonstrate quantum advantage on physical hardware. Including QPE and QSVT does not mean industrial-scale problems can now be solved on fault-tolerant quantum computers. What OpenQARP shortens is the distance involved in assembling research code; it does not eliminate the physical distance measured in required qubit counts, error rates, and execution time.
Starting in February 2026, a beta version was provided to more than 80 organizations through joint research and the Quantum Simulator Challenge. This marks a shift from closed early access to a stage where anyone can obtain the code. However, it hasn't been disclosed how many of those 80 organizations continued using it, how many results passed external peer review, or how much outside developers have contributed to the code. The number of recipient organizations cannot be read as a measure of adoption or the size of a developer community.
The Distance Closed by This Release, and the Distance That Remains
Based on a review of the September 16, 2026 Fujitsu announcement, the public README, the v1 preprint, and PyPI, distribution availability and the developers' own evaluation can be tracked—but results demonstrating quantum advantage on physical hardware, independent benchmarks, or outside-developer adoption could not be confirmed. What was reviewed: the official announcement's public information and highlighted features, the README's design and Benchmarks section, the arXiv abstract and submission history, and PyPI's distribution information and metadata. This is not a determination that such evidence doesn't exist anywhere in the broader body of materials or external results.
The distance this release closes is concrete. The v0.1.0 source code, Apache 2.0 usage terms, distributions for major operating systems, executable notebooks, and a mechanism for reproducing benchmarks are now visible from outside. Researchers can test the API, examine computational results, and bring bugs or improvement proposals into the open. This marks a shift from beta access through joint research and the Quantum Simulator Challenge to a stage where public code and distributions are available to anyone.
The distance that remains is also measurable. The development status on PyPI is listed as Beta, and at release time the maintainer listing shows a single person. The public repository has only just launched, without the long track record needed to judge quality or the size of its user base. Policies on API backward compatibility, a track record of vulnerability response, and release management across multiple organizations all remain to be verified going forward.
Whether OpenQARP becomes a common building block for quantum application development won't be decided by the number of algorithms it includes. What matters is whether outside researchers can reproduce results with the same inputs, preserve numerical conventions when porting to a different engine, and migrate their research code to new versions that incorporate external contributions. If those conditions are met, researchers can spend less time rebuilding surrounding code for every experiment and direct more effort toward verifying whether an algorithm truly works for the target problem.