While quantum hardware breakthroughs dominate headlines, a new arXiv preprint underscores a quieter but more immediate crisis: the fractured software stacks that prevent quantum processors from effectively teaming up with classical high-performance computing (HPC) systems. The paper, 'Quantum-HPC Software Stacks and the openQSE Reference Architecture: A Survey' (arXiv:2604.20912), authored by a collaborative team from national labs, universities, and industry including Oak Ridge, Lawrence Berkeley, and Intel, is not an experimental study with participant cohorts or benchmark runs. Instead, it offers a qualitative comparative survey of nine existing production QHPC deployments. As a preprint, it has not yet been peer-reviewed. Limitations include a relatively narrow sample of nine systems that may not represent all global efforts, and potential bias since several co-authors are directly involved in proposing the new openQSE architecture they advocate.

The survey maps common design patterns across deployment models, SDK support, runtime layers, resource managers, and readiness for fault-tolerant quantum computing (FTQC). It finds near-universal pain points: proprietary full-stack solutions with poor interoperability, inconsistent interconnect semantics between quantum and classical resources, and insufficient observability for hybrid workloads. These gaps matter because most near-term quantum applications rely on hybrid quantum-HPC workflows such as variational quantum eigensolvers (VQE) or quantum approximate optimization algorithms (QAOA) that offload heavy classical computation to supercomputers.

This work goes well beyond simply cataloging problems. It proposes the open Quantum Software Ecosystem (openQSE) reference architecture, which defines clean layer boundaries for runtime abstraction, resource scheduling, and execution. Crucially, openQSE is engineered to support both current noisy intermediate-scale quantum (NISQ) devices and future error-corrected FTQC systems without forcing changes to upper-layer application code. This forward compatibility is a smart recognition that quantum technology will evolve in stages rather than in one leap.

Our analysis reveals what the paper only hints at: this software fragmentation repeats a well-known pattern from classical computing history. Before the 1990s adoption of MPI (Message Passing Interface) and OpenMP, HPC was a Babel of vendor-specific libraries that slowed scientific progress. Quantum risks the same fate. What the preprint underplays is the economic incentive problem. Vendors like IBM (with Qiskit Runtime), NVIDIA (CUDA-Q), and Rigetti have clear commercial reasons to maintain walled gardens that lock customers into their hardware and cloud offerings. The survey also misses deeper connections to ongoing standardization efforts such as the Open Quantum Initiative and the European Union's Quantum Internet Alliance, which focus more on hardware and networking than the full software orchestration stack.

Synthesizing this preprint with NVIDIA's CUDA-Q documentation (which demonstrates tight GPU-quantum integration but remains proprietary) and the 2023 DOE ASCR report 'Quantum Computing for High-Performance Computing' (which called for greater middleware abstraction), a clearer picture emerges. True quantum utility for drug discovery, materials simulation, or optimization will require seamless, vendor-neutral orchestration at exascale levels. Without it, even a million-qubit processor will deliver limited impact because hybrid algorithms cannot efficiently schedule resources or debug across disparate systems.

The openQSE proposal therefore addresses a critical but under-covered practical barrier. It prioritizes deployment flexibility so national labs can run it on-prem while cloud providers adapt it for multi-tenant environments. Genuine progress will require more than a reference architecture, however. Governance questions around who maintains the standard, how quickly it evolves with hardware advances, and whether major vendors will actually implement the open interfaces remain unresolved. History suggests that only when dominant players see mutual benefit, or when government mandates interoperability (as with some HPC procurement rules), do such standards truly take hold.

In short, this survey illuminates that quantum's path to usefulness is as much about software engineering and open ecosystems as it is about reducing error rates. If openQSE or a successor gains traction, it could compress the timeline to practical quantum advantage by enabling a vibrant, interoperable developer community rather than isolated silos.