Pith. sign in

REVIEW 3 major objections 5 minor 69 references

Navigating the Socio-Technical Complexity Challenge in Quantum Software Ecosystems

T0 review · 3 major / 5 minor · reviewed 2026-08-02 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read Quantum software environments can be navigated by identifying the technologies that act as 'gravity wells' — Kubernetes and Slurm today — and judging them against four socio-technical goals that preserve flexibility and room to experiment.

desk verdict A clearly written design-science framework for socio-technical friction in QC software ecosystems; the authors admit the graph construction is analyst-dependent, so the empirical demonstration is illustrative, not validated. read the letter →

arxiv 2607.15135 v1 pith:UT56MVVO submitted 2026-07-16 cs.SE

Ronja Heikkinen , Santiago Núñez-Corrales , Vlad Stirbu This is my paper
classification cs.SE
keywords quantumcomputingsoftwareecosystemssocio-technicalsystemsgravitywellsorchestrationKubernetesSlurmenvironmentchoice
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper argues that choosing a quantum computing environment is less about picking the best tool than about aligning choices across a fragmented stack, and that the main sources of friction can be located structurally. It introduces 'gravity wells' — densely connected technologies that pull surrounding choices toward them — and four socio-technical desiderata to judge whether that pull helps or hurts. Applying the framework to three hybrid quantum-classical execution scenarios, it identifies Kubernetes' API server and kubelet and the Slurm scheduler as the current gravity wells. The claim is that using the framework lets practitioners see architectural risk and evolutionary constraints that a feature-by-feature comparison misses, and so make more deliberate, reversible environment choices.

What carries the argument

The analytical engine is the gravity well: a highly connected partition of the ecosystem graph, characterized by three properties — workflow specialization, technology entrenchment, and ecosystem convergence pressure. Its impact is judged against four socio-technical desiderata: operational and governance transparency, knowledge and skill portability, avoiding irreversible choices and constraints, and preserving productive failure and allowing experimentation for evolution. The framework works in three phases: draw the environment graph, identify dense nodes as gravity wells, then evaluate those wells against the desiderata.

What would settle it

Reconstruct the three execution-path graphs using a transparent, rule-based edge-extraction procedure — e.g., define an edge wherever one component passes data, control, or scheduling authority to another — then compute node centrality. If Kubernetes' api-server/kubelet and Slurm are not the highest-centrality nodes, the framework's headline finding fails. Equivalently, a practitioner study showing that teams using the framework make no fewer irreversible choices than teams using feature checklists would undercut the practical claim.

Watch

Extended reading notes

Core claim

The central claim is that an ecosystem of quantum software tools can be represented as a graph, and that the most highly connected regions of that graph — gravity wells — determine which workflow paths remain practically available. In the three scenarios examined, the Kubernetes api-server/kubelet pairing and Slurm emerge as the structural gravity wells. Evaluating these wells against the four socio-technical desiderata shows that the Kubernetes cluster is a relatively open, composable gravity well, whereas Slurm is a more constraining one: it concentrates workflow specialization around its scheduling semantics and offers fewer escape routes. The authors argue that this analysis supports del

Load-bearing premise

The claim rests on the assumption that a technology ecosystem can be faithfully represented as a graph whose edges are drawn from an analyst's reading of the cases; if that graph is subjective or incomplete, the identification of Kubernetes and Slurm as gravity wells does not follow.

Editorial extensions

If this is right

  • Friction in quantum software environments can be traced to a small number of structural choke points rather than to defects in individual tools.
  • Choosing Kubernetes-based orchestration preserves more architectural flexibility than routing through Slurm, because its gravity well is open and composable.
  • The same technology can be productive or obstructive depending on an organization's readiness level; the evaluation is inherently context-dependent.
  • Environment selection becomes a phased analysis — graph, gravity wells, desiderata — rather than a combinatorial guessing game.
  • Avoiding irreversible choices, such as vendor-specific specification or human-capital lock-in, becomes an explicit design goal rather than an afterthought.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If the graph construction were made reproducible — for example, by deriving edges systematically from documented architectures — the gravity-well analysis could be automated and applied at a much larger scale; the paper leaves this as future work.
  • The gravity-well lens likely transfers to other emerging software ecosystems, such as classical HPC, AI toolchains, or serverless platforms, where adoption concentrates around a few hubs.
  • A testable extension: teams that explicitly evaluate gravity wells before committing to an environment should show lower switching costs and more evolvable stacks than teams that decide by feature checklists.
  • The framework implies a predictive claim: as quantum hardware matures, the Slurm well's constraints will bind more tightly, pushing integration toward Kubernetes-style extensible control planes.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. The paper proposes a framework for evaluating quantum computing environments through a socio-technical lens. It introduces two central constructs: gravity wells—defined as highly connected partitions of a technology graph—with three properties (workflow specialization, technology entrenchment, ecosystem convergence pressure), and four socio-technical desiderata (transparency, skill portability, avoiding irreversible constraints, preserving experimentation). The framework is developed using Design Science Research methodology and demonstrated on three case studies (Qubernetes, a Kubernetes-orchestrated hybrid circuit-cutting workflow, and an HPC execution model). The demonstration identifies the Kubernetes api-server/kubelet pair and Slurm as gravity wells and evaluates them against the desiderata in Table II. The paper claims that the framework supports practitioners in making context-aware environment choices that preserve architectural flexibility and guide the field's evolution.

Significance. If the framework's claims are substantiated, it would provide a useful analytical complement to feature-by-feature tool comparisons by surfacing structural forces—centrality, entrenchment, and convergence—that shape the viability of quantum software environments. The paper is well-grounded in established socio-technical theory (Gasser, Star & Ruhleder, Orlikowski) and the DSR process is clearly described. The authors' explicit acknowledgment of subjectivity and the threats-to-validity section are honest and welcome. However, the empirical basis is thin: three illustrative cases, one of which is the authors' own platform (Qubernetes, ref [64]), and the core gravity-well identification is not reproducible from the manuscript. The conceptual vocabulary may be valuable for structured reflection, but the prescriptive power claimed in the abstract is not yet established by the evidence presented.

major comments (3)
  1. [Section V.B and Fig. 5] The gravity-well identification procedure is underspecified. The paper defines gravity wells as 'highly connected partition[s] of the QC environment graph' (Sec. IV.B), but it does not define what constitutes a node, what constitutes an edge, or how edges are extracted from the case materials. The graph in Fig. 5 is presented as the merged result of three 'extracted' execution paths, yet the extraction relies on the analyst's qualitative judgment. The paper itself concedes in Sec. VI.B that graph construction 'relies on the analyst's familiarity with the cases.' Because the subsequent desiderata evaluation (Table II) and the prescriptive guidance depend entirely on which nodes are identified as gravity wells, this is a load-bearing methodological gap. The authors should provide an explicit extraction protocol (node/edge taxonomy, inclusion rules, traceability to the case descriptions) an
  2. [Section VI.C and Abstract] The paper honestly states that 'the framework was not subjected to systematic empirical evaluation' and that the assessment is 'inherently subjective and potentially difficult to reproduce.' Yet the abstract claims the framework 'supports practitioners in making deliberate, context-aware environment choices' and the conclusion says it 'guides the evaluation of technological environments.' These claims are stronger than the evidence supports. The demonstration is illustrative, not confirmatory. To align the claims with the evidence, either temper the wording to describe the framework as a structured reflection tool whose empirical validity remains to be tested, or provide additional validation—for example, inter-rater agreement on gravity-well identification, an expert survey, or a counterfactual case analysis. Without such validation, the central contribution is a plausible but unverifie
  3. [Table II and Section VI.B] The desiderata evaluation is entirely qualitative and provides no guidance for weighting or resolving conflicts among the four desiderata. For instance, Slurm scores well on operational transparency but weakly on skill portability and avoiding irreversible constraints; the table does not indicate how a practitioner should decide which desideratum prevails in a given context. The authors note in Sec. VI.B that 'the framework does not yet provide guidance on how to weight competing desiderata,' but this is a substantive limitation for a framework whose stated purpose is to inform environment choices. Even a simple ordering rule or a discussion of trade-off strategies would make the framework more actionable. As it stands, two analysts could reasonably reach opposite recommendations from the same evidence, reducing the framework's practical value.
minor comments (5)
  1. [Fig. 2] Typo: 'Technology Entrentchment' should be 'Technology Entrenchment'.
  2. [Table I] Typo: 'Realiability' should be 'Reliability'.
  3. [Section IV.B] The text refers to 'the MAY A principle from design theory' in reference [57]. This should read 'MAYA principle' (Most Advanced, Yet Acceptable).
  4. [Section V.A.3 and Section VII] The HPC case is described generically, but Section VII refers to 'Qubernetes, CERN, and HPC.' The hybrid circuit-cutting case appears to be CERN-related, but the paper should explicitly name the institution in Section V.A.2 to match the conclusions.
  5. [Section IV.A] The evaluation criteria are synthesized from [6], [15], [46] and the first author's prior work [47], and one of the three demonstration cases is the authors' own Qubernetes platform [64]. This is not disqualifying, but it should be explicitly acknowledged as a potential source of bias in the threats-to-validity section, alongside the other subjectivity concerns.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the framework is a qualitative conceptual lens; its conclusions are not forced by definition or by fitted inputs.

full rationale

The paper proposes a qualitative Design Science Research framework (gravity wells, their properties, and socio-technical desiderata) and demonstrates it on three execution scenarios. It contains no equations, no fitted parameters, and no statistical prediction that is later read back as a result. The identification of api-server/kubelet and Slurm as gravity wells is an analyst-constructed graph observation, and the paper explicitly concedes this: 'The construction of the technological graph currently relies on the analyst's familiarity with the cases' (Sec. VI.B) and the framework 'was not subjected to systematic empirical evaluation' (Sec. VI.C). Those are threats to reproducibility and external validity, not circularity: the gravity-well identification is not asserted to follow from a formal derivation in which the graph or centrality was defined in terms of the conclusion. Self-citations exist — [47] (first author) is 'used as a starting point' for the evaluation criteria and [64] (co-author) supplies the Qubernetes case — but the criteria are synthesized primarily from external works [6], [15], [46], and Qubernetes is one illustrative scenario rather than the evidence forcing the framework's conclusions. No definitional equivalence, fitted-input-as-prediction, uniqueness/ansatz imported from self-citation, or renaming-with-claimed-derivation was found. Score 0.

Assumptions & free parameters 0 free parameters · 6 assumptions · 2 invented entities

No numeric parameters are fitted; the framework is conceptual. The load-bearing assumptions are the validity of the three-layer stack, the sufficiency of the synthesized evaluation criteria, the graph-density-to-gravity mapping, the representativeness of the three cases, and the socio-technical premise that friction is persistent and technology/social practice are entangled.

assumptions (6)
  • domain assumption Technology and social practices are constitutively entangled; friction between systems and work is a persistent condition, not a residual to be eliminated.
    Section II.D invokes Gasser, Star & Ruhleder, and Orlikowski as the foundation for treating environment choice as an act of alignment.
  • domain assumption The quantum software stack can be validly decomposed into three layers (applications, QSDKs, infrastructure), and the most consistent gaps appear at layer interfaces.
    Section II.A and Fig. 1, based on [6] and [7]; the framework's mapping and gravity-well analysis depend on this decomposition.
  • domain assumption The evaluation criteria synthesized from [6], [15], and [46] are comprehensive enough to assess quantum computing environments.
    Section IV.A uses these three works as the complete source for the technology evaluation criteria from which gravity-well properties are derived.
  • ad hoc to paper A technology ecosystem can be represented as a graph with nodes as tools/offerings and edges as technical/organizational relationships, and highly connected partitions exert 'pull' on surrounding choices.
    Sections IV.A-IV.B and Fig. 5; this graph-density-to-gravity mapping is the central modeling device but is asserted, not derived or empirically validated.
  • domain assumption The three selected cases (Qubernetes, Kubernetes-Argo circuit-cutting, HPC/Slurm) are representative of current QC-HPC integration approaches.
    Section V.A states that the cases were chosen to evaluate diversity, but no selection protocol is given; authors later acknowledge limited generalizability in Section VI.B.
  • domain assumption Readiness-level frameworks (TRL, QTRL, QORL, QCRL, etc.) provide a valid maturity mapping for the quantum stack.
    Section IV.C and Fig. 3 use these frameworks to argue that gravity wells can be beneficial or obstructive depending on organizational readiness.
invented entities (2)
  • Gravity well and its three properties (workflow specialization, technology entrenchment, ecosystem convergence pressure)
    purpose: Analytical construct to denote highly connected partitions of the technology ecosystem that exert growing pull on surrounding environment choices.
    Defined qualitatively in Section IV.B; no falsifiable operationalization, thresholds, or measurement procedure; identification depends on analyst judgment.
  • Socio-technical desiderata (transparency; skill portability; avoiding irreversible constraints; preserving experimentation)
    purpose: Normative criteria to evaluate whether a gravity well is beneficial or obstructive in context.
    Introduced in Section IV.C as goal-oriented criteria; not empirically derived or measured, and no weighting guidance is provided (conceded in Section VI.B).

how reviews work

0 comments
Cite this review

Pith. "Pith review of Navigating the Socio-Technical Complexity Challenge in Quantum Software Ecosystems." pith.science (2026). https://pith.science/paper/UT56MVVO

@misc{pith2026260715135,
  author       = {Pith},
  title        = {Pith review of: Navigating the Socio-Technical Complexity Challenge in Quantum Software Ecosystems},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/UT56MVVO}},
  note         = {Machine review of arXiv:2607.15135}
}
read the original abstract

Quantum computing environments are composed of heterogeneous layers spanning hardware, software development kits, and applications. Practitioners curating these environments face a fragmented and rapidly evolving landscape with few principled guides for navigation. This paper presents a framework for evaluating quantum computing environment choices through a socio-technical lens, developed using Design Science Research methodology. Drawing on the quantum software engineering literature as well as organizational and socio-technical research, the framework introduces three analytical constructs: gravity wells and their properties, which characterize how certain technologies and structural conditions exert increasing pull on surrounding environment choices, and socio-technical desiderata, which articulate the normative goals against which those pulls can be evaluated. The framework supports practitioners in making deliberate, context-aware environment choices that preserve architectural flexibility and support the evolutionary development of the field. Demonstration and evaluation of the framework is conducted through exemplary cases. The contribution advances both the theory of quantum ecosystems and the practical guidance available to organizations and practitioners navigating the current, evolving field of quantum computing.

Figures

Figures reproduced from arXiv: 2607.15135 by the authors.

Figure 1
Figure 1. The three layers of the quantum software stack, based on [6], [7] [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Associations between the gravity well properties, the technology [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Alignment of readiness levels along different dimensions: general TRL, outcomes corresponding to quantum TRL (QTRL) [58], activities corresponding [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: Explained relationships between the framework’s core concepts: technological choices, technological ecosystems, evaluation criteria for technology, [PITH_FULL_IMAGE:figures/full_fig_p008_4.png]
Figure 5
Figure 5. Figure 5: Applying the framework in the selected scenarios. Workloads remain the centerpiece to be realized by hybrid infrastructure. Identified gravity wells [PITH_FULL_IMAGE:figures/full_fig_p008_5.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

69 extracted references · 6 linked inside Pith

  1. [64]

    Qubernetes: Towards a unified cloud-native execution platform for hybrid classic- quantum computing,

    V . Stirbu, O. Kinanen, M. Haghparast, and T. Mikkonen, “Qubernetes: Towards a unified cloud-native execution platform for hybrid classic- quantum computing,”Information and Software Technology, vol. 175, p. 107529, 2024

    2024

  2. [1]

    In- tegrating quantum computing resources into scientific hpc ecosystems,

    T. Beck, A. Baroni, R. Bennink, G. Buchs, E. A. C. P ´erez, M. Eisenbach, R. F. da Silva, M. G. Meena, K. Gottiparthi, P. Groszkowskiet al., “In- tegrating quantum computing resources into scientific hpc ecosystems,” Future Generation Computer Systems, vol. 161, pp. 11–25, 2024

    2024

  3. [2]

    Accel- erating hpc with quantum computing: It is a software challenge too,

    M. Schulz, M. Ruefenacht, D. Kranzlm ¨uller, and L. B. Schulz, “Accel- erating hpc with quantum computing: It is a software challenge too,” Computing in Science & Engineering, vol. 24, no. 4, pp. 60–64, 2023

    2023

  4. [3]

    Running kubernetes workloads on hpc,

    A. Chazapis, F. Nikolaidis, M. Marazakis, and A. Bilas, “Running kubernetes workloads on hpc,” inInternational Conference on High Performance Computing. Springer, 2023, pp. 181–192

    2023

  5. [4]

    intertwin: Advancing scientific digital twins through ai, federated computing and data,

    A. Manzi, R. Bardaji, I. Rodero, G. Molt ´o, S. Fiore, I. Campos, D. Elia, F. Sarandrea, A. P. Millar, D. Spigaet al., “intertwin: Advancing scientific digital twins through ai, federated computing and data,”Future Generation Computer Systems, p. 108312, 2025

    2025

  6. [5]

    Towards quantum-algorithms-as-a-service,

    M. De Stefano, D. Di Nucci, F. Palomba, D. Taibi, and A. De Lucia, “Towards quantum-algorithms-as-a-service,” inProceedings of the 1st International Workshop on Quantum Programming for Software Engi- neering, 2022, pp. 7–10

    2022

  7. [6]

    Quantum software components and platforms: Overview and quality assessment,

    M. A. Serrano, J. A. Cruz-Lemus, R. Perez-Castillo, and M. Piattini, “Quantum software components and platforms: Overview and quality assessment,”ACM Computing Surveys, vol. 55, no. 8, pp. 1–31, 2022

    2022

  8. [7]

    Towards european standards for quantum technologies,

    O. van Deventer, N. Spethmann, M. Loeffler, M. Amoretti, R. van den Brink, N. Bruno, P. Comi, N. Farrugia, M. Gramegna, A. Jenet, B. Kassenberg, W. Kozlowski, T. L ¨anger, T. Lindstrom, V . Martin, N. Neumann, H. Papadopoulos, S. Pascazio, M. Peev, R. Pitwon, M. A. Rol, P. Traina, P. Venderbosch, and F. K. Wilhelm-Mauch, “Towards european standards for qu...

    2022

Show all 69 references
  1. [8]

    Kubernetes distributions for the edge: serverless performance evaluation,

    V . Kjorveziroski and S. Filiposka, “Kubernetes distributions for the edge: serverless performance evaluation,”The Journal of Supercomputing, vol. 78, no. 11, pp. 13 728–13 755, 2022

    2022

  2. [9]

    Moirai: Optimizing quantum serverless function orchestration via device allocation and circuit deployment,

    T. Li and Z. Zhao, “Moirai: Optimizing quantum serverless function orchestration via device allocation and circuit deployment,” in2024 IEEE International Conference on Web Services (ICWS). IEEE, 2024, pp. 707–717

    2024

  3. [10]

    Software architecture challenges in inte- grating hybrid classical-quantum systems,

    V . Stirbu and T. Mikkonen, “Software architecture challenges in inte- grating hybrid classical-quantum systems,” in2023 IEEE International Conference on Quantum Computing and Engineering (QCE), vol. 2. IEEE, 2023, pp. 203–204

    2023

  4. [11]

    Qdmi-quantum device management interface: Hardware-software interface for the munich quantum software stack,

    R. Wille, L. Schmid, Y . Stade, J. Echavarria, M. Schulz, L. Schulz, and L. Burgholzer, “Qdmi-quantum device management interface: Hardware-software interface for the munich quantum software stack,” in2024 IEEE International Conference on Quantum Computing and Engineering (QCE...

    2024

  5. [12]

    A survey on available tools and technologies enabling quantum computing,

    P. Singh, R. Dasgupta, A. Singh, H. Pandey, V . Hassija, V . Chamola, and B. Sikdar, “A survey on available tools and technologies enabling quantum computing,”IEEE access, vol. 12, pp. 57 974–57 991, 2024

    2024

  6. [13]

    Quantumpath: A quantum software development platform,

    J. L. Hevia, G. Peterssen, and M. Piattini, “Quantumpath: A quantum software development platform,”Software: Practice and Experience, vol. 52, no. 6, pp. 1517–1530, 2022

    2022

  7. [14]

    Toward a quantum- science gateway: A hybrid reference architecture facilitating quantum computing capabilities for cloud utilization,

    A. C. Marosi, A. Farkas, T. M ´aray, and R. Lovas, “Toward a quantum- science gateway: A hybrid reference architecture facilitating quantum computing capabilities for cloud utilization,”IEEE access, vol. 11, pp. 143 913–143 924, 2023

    2023

  8. [15]

    Quantum software engineering: Roadmap and chal- lenges ahead,

    J. M. Murillo, J. Garcia-Alonso, E. Moguel, J. Barzen, F. Leymann, S. Ali, T. Yue, P. Arcaini, R. P ´erez-Castillo, I. Garc ´ıa-Rodr´ıguez de Guzm´anet al., “Quantum software engineering: Roadmap and chal- lenges ahead,”ACM Transactions on Software Engineering and Method- olog...

    2025

  9. [16]

    Quantum software engineering challenges from developers’ perspective: Mapping research challenges to the proposed workflow model,

    M. Haghparast, T. Mikkonen, J. K. Nurminen, and V . Stirbu, “Quantum software engineering challenges from developers’ perspective: Mapping research challenges to the proposed workflow model,” in2023 IEEE International Conference on Quantum Computing and Engineering (QCE), vol....

    2023

  10. [17]

    On the definition of quantum programming modules,

    P. S ´anchez and D. Alonso, “On the definition of quantum programming modules,”Applied Sciences, vol. 11, no. 13, p. 5843, 2021

    2021

  11. [18]

    Programming languages and compiler design for realistic quantum hardware,

    F. T. Chong, D. Franklin, and M. Martonosi, “Programming languages and compiler design for realistic quantum hardware,”Nature, vol. 549, no. 7671, pp. 180–187, 2017

    2017

  12. [19]

    Engineering software systems for quantum computing as a service: A mapping study,

    A. Ahmad, M. Waseem, P. Liang, M. Fehmideh, A. A. Khan, D. G. Reichelt, and T. Mikkonen, “Engineering software systems for quantum computing as a service: A mapping study,”arXiv preprint arXiv:2303.14713, 2023

    2023 arXiv

  13. [20]

    Qfaas: A serverless function- as-a-service framework for quantum computing,

    H. T. Nguyen, M. Usman, and R. Buyya, “Qfaas: A serverless function- as-a-service framework for quantum computing,”Future Generation Computer Systems, vol. 154, pp. 281–300, 2024

    2024

  14. [21]

    The cloudveneto’s container-as-a-service ecosystem,

    F. Fanzago, D. Lupu, D. Marcato, M. Sgaravatto, S. Traldi, A. Troja, M. Verlato, and L. Zangrando, “The cloudveneto’s container-as-a-service ecosystem,” inEPJ Web of Conferences, vol. 337. EDP Sciences, 2025, p. 01250

    2025

  15. [22]

    Unlocking the compute continuum: scaling out from cloud to hpc and htc resources,

    D. Ciangottini, D. Spiga, A. S. Memon, A. Manzi, A. Filipcic, A. Troja, F. Fanzago, G. Bianchini, M. Sgaravatto, T. Pricaet al., “Unlocking the compute continuum: scaling out from cloud to hpc and htc resources,” inEPJ Web of Conferences, vol. 337. EDP Sciences, 2025, p. 01296

    2025

  16. [23]

    An empirical investigation on the challenges in scientific workflow systems development,

    K. Alam, B. Roy, C. K. Roy, and K. Mittal, “An empirical investigation on the challenges in scientific workflow systems development,”Empir- ical Software Engineering, vol. 30, no. 5, p. 151, 2025

    2025

  17. [24]

    Kubernetes-orchestrated hybrid quantum–classical workflows,

    M. Tejedor, M. Grossi, C. T ¨uys¨uz, R. Rocha, and S. Vallecorsa, “Kubernetes-orchestrated hybrid quantum–classical workflows,” 2026. [Online]. Available: https://arxiv.org/abs/2603.24206

    2026

  18. [25]

    Reference architecture of a quantum-centric supercomputer,

    S. Seelam, J. M. Chow, A. C ´orcoles, S. Sheldon, T. Mittal, A. Kandala, S. Dague, I. Hincks, H. Horii, B. Johnson, M. Le, H. Jamjoom, and J. M. Gambetta, “Reference architecture of a quantum-centric supercomputer,”

  19. [26]

    Qonductor: A cloud orchestrator for quantum computing,

    E. Giortamis, F. Romao, N. Tornow, D. Lugovoy, and P. Bhatotia, “Qonductor: A cloud orchestrator for quantum computing,” in Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis, ser. SC ’25. New York, NY , USA: Associatio...

    2025

  20. [27]

    A kubernetes’ bridge’operator between cloud and external resources,

    B. Lublinsky, E. Jennings, and V . Spi ˇsakov´a, “A kubernetes’ bridge’operator between cloud and external resources,”arXiv preprint arXiv:2207.02531, 2022

    2022 arXiv

  21. [28]

    Platform architecture for tight coupling of high-performance computing with quantum processors,

    S. A. Caldwell, M. Khazraee, E. Agostini, T. Lassiter, C. Simpson, O. Kahalon, M. Kanuri, J.-S. Kim, S. Stanwyck, M. Li, J. Olle, C. Chamberland, B. Howe, B. Schmitt, J. G. Lietz, A. McCaskey, J. Ye, A. Li, A. B. Magann, C. I. Ostrove, K. Rudinger, R. Blume-Kohout, K. Young, N...

    2025

  22. [29]

    Ephemeral kubernetes: dynamically deleting and recreating clusters using warewulf,

    J. Decker and J. Kunkel, “Ephemeral kubernetes: dynamically deleting and recreating clusters using warewulf,”The Journal of Supercomputing, vol. 81, no. 16, pp. 1–28, 2025

    2025

  23. [30]

    A fine-grained gpu sharing and job scheduling for deep learning jobs on the cloud,

    W.-C. Chung, J.-S. Tong, and Z.-H. Chen, “A fine-grained gpu sharing and job scheduling for deep learning jobs on the cloud,”The Journal of Supercomputing, vol. 81, no. 2, p. 361, 2025

    2025

  24. [31]

    Gpu-based embedded edge server configuration and offloading for a neural network service,

    J. Kim, S. Ullah, and D.-H. Kim, “Gpu-based embedded edge server configuration and offloading for a neural network service,”The Journal of Supercomputing, vol. 77, no. 8, pp. 8593–8621, 2021

    2021

  25. [32]

    Easyscale: Elastic training with consistent accuracy and improved utilization on gpus,

    M. Li, W. Xiao, H. Yang, B. Sun, H. Zhao, S. Ren, Z. Luan, X. Jia, Y . Liu, Y . Liet al., “Easyscale: Elastic training with consistent accuracy and improved utilization on gpus,” inProceedings of the International Conference for High Performance Computing, Networking, Storage ...

    2023

  26. [33]

    A systematic review and classification of hpc-related emerging computing technologies,

    E. Arianyan, N. Gholipour, D. Maleki, N. Ghorbani, A. Sepahvand, and P. Goudarzi, “A systematic review and classification of hpc-related emerging computing technologies,”Electronics, vol. 14, no. 12, p. 2476, 2025

    2025

  27. [34]

    State of the art in parallel and distributed systems: Emerging trends and challenges,

    F. Dai, M. A. Hossain, and Y . Wang, “State of the art in parallel and distributed systems: Emerging trends and challenges,”Electronics, vol. 14, no. 4, p. 677, 2025

    2025

  28. [35]

    Con- tainers as the quantum leap in software development,

    I. Ahmad, T. Autto, T. Das, J. H ¨am¨al¨ainen, P. Jalonen, V . J ¨arvinen, H. Kallio, T. Kankainen, T. Kolehmainen, P. Kontioet al., “Con- tainers as the quantum leap in software development,”arXiv preprint arXiv:2501.07204, 2025

    2025 arXiv

  29. [36]

    2025, last updated 18-Dec-2025

    Market Growth Reports, “Container orchestration market size, share, growth, and industry analysis, by type (platform, services), by application (telecommunications and it, bfsi, government and public sector, healthcare, retail and consumer goods, manufacturing, others), region...

  30. [37]

    The integration of computing and routine work,

    L. Gasser, “The integration of computing and routine work,”ACM Transactions on Information Systems (TOIS), vol. 4, no. 3, pp. 205– 225, 1986

    1986

  31. [38]

    Steps towards an ecology of infrastructure: Complex problems in design and access for large-scale collaborative systems,

    S. L. Star and K. Ruhleder, “Steps towards an ecology of infrastructure: Complex problems in design and access for large-scale collaborative systems,” inProceedings of the 1994 ACM Conference on Computer Supported Cooperative Work, ser. CSCW ’94. Chapel Hill, NC, USA: ACM, 199...

    1994

  32. [39]

    Sociomaterial practices: Exploring technology at work,

    W. J. Orlikowski, “Sociomaterial practices: Exploring technology at work,”Organization Studies, vol. 28, no. 9, pp. 1435–1448, 2007

    2007

  33. [40]

    Perceived usefulness, perceived ease of use, and user acceptance of information technology,

    F. D. Davis, “Perceived usefulness, perceived ease of use, and user acceptance of information technology,”MIS Quarterly, vol. 13, no. 3, pp. 319–340, 1989

    1989

  34. [41]

    User acceptance of computer technology: A comparison of two theoretical models,

    F. D. Davis, R. P. Bagozzi, and P. R. Warshaw, “User acceptance of computer technology: A comparison of two theoretical models,” Management Science, vol. 35, no. 8, pp. 982–1003, 1989

    1989

  35. [42]

    User acceptance of information technology: Toward a unified view,

    V . Venkatesh, M. G. Morris, G. B. Davis, and F. D. Davis, “User acceptance of information technology: Toward a unified view,”MIS Quarterly, vol. 27, no. 3, pp. 425–478, 2003

    2003

  36. [43]

    Consumer acceptance and use of information technology: Extending the unified theory of acceptance and use of technology,

    V . Venkatesh, J. Y . L. Thong, and X. Xu, “Consumer acceptance and use of information technology: Extending the unified theory of acceptance and use of technology,”MIS Quarterly, vol. 36, no. 1, pp. 157–178, 2012

    2012

  37. [44]

    Dealing with complexity in design science research: a methodology using design echelons,

    T. Tuunanen, R. Winter, and J. v. Brocke, “Dealing with complexity in design science research: a methodology using design echelons,”MIS quarterly, vol. 48, no. 2, pp. 427–458, 2024

    2024

  38. [45]

    A design science research methodology for information systems research,

    K. Peffers, T. Tuunanen, M. A. Rothenberger, and S. Chatterjee, “A design science research methodology for information systems research,” Journal of management information systems, vol. 24, no. 3, pp. 45–77, 2007

    2007

  39. [46]

    An exploratory study on the usage of quantum programming languages,

    F. Ferreira and J. Campos, “An exploratory study on the usage of quantum programming languages,”Science of Computer Programming, vol. 240, p. 103217, 2025

    2025

  40. [47]

    Towards understanding the developer experience in quantum software development,

    R. Heikkinen, M. Haghparast, and T. Mikkonen, “Towards understanding the developer experience in quantum software development,” inInterna- tional Conference on Product-Focused Software Process Improvement. Springer, 2025, pp. 533–542

    2025

  41. [48]

    How to get started in quantum computing,

    D. Matthews, “How to get started in quantum computing,”Nature, vol. 591, no. 7848, pp. 166–167, 2021

    2021

  42. [49]

    On the impact of quantum computing technol- ogy on future developments in high-performance scientific computing,

    M. M ¨oller and C. Vuik, “On the impact of quantum computing technol- ogy on future developments in high-performance scientific computing,” Ethics and information technology, vol. 19, no. 4, pp. 253–269, 2017

    2017

  43. [50]

    Serverless high-performance comput- ing over cloud,

    D. Petrosyan and H. Astsatryan, “Serverless high-performance comput- ing over cloud,”Cybernetics and Information Technologies, vol. 22, no. 3, pp. 82–92, 2022

    2022

  44. [51]

    Software architecture for quantum computing systems—a systematic review,

    A. A. Khan, A. Ahmad, M. Waseem, P. Liang, M. Fahmideh, T. Mikko- nen, and P. Abrahamsson, “Software architecture for quantum computing systems—a systematic review,”Journal of Systems and Software, vol. 201, p. 111682, 2023

    2023

  45. [52]

    Scheduling ml and hpc jobs with shoc platform over kubernetes,

    D. Petrosyan, “Scheduling ml and hpc jobs with shoc platform over kubernetes,”Physics of Particles and Nuclei, vol. 56, no. 6, pp. 1581– 1585, 2025

    2025

  46. [53]

    Orchestration of materials science workflows for heterogeneous re- sources at large scale,

    N. Zhou, G. Scorzelli, J. Luettgau, R. R. Kancharla, J. J. Kane, R. Wheeler, B. P. Croom, P. Newell, V . Pascucci, and M. Taufer, “Orchestration of materials science workflows for heterogeneous re- sources at large scale,”The International Journal of High Performance Computing...

    2023

  47. [54]

    Advancing quantum software engineering: A vision of hybrid full-stack iterative model,

    A. Khan, D. Taibi, C. M. Perrault, and M. A. Akbar, “Advancing quantum software engineering: A vision of hybrid full-stack iterative model,” inProceedings of the 40th ACM/SIGAPP Symposium on Applied Computing, 2025, pp. 1444–1448

    2025

  48. [55]

    Quantum computing challenges in the software industry. a fuzzy ahp-based approach,

    U. Awan, L. Hannola, A. Tandon, R. K. Goyal, and A. Dhir, “Quantum computing challenges in the software industry. a fuzzy ahp-based approach,”Information and software technology, vol. 147, p. 106896, 2022

    2022

  49. [56]

    Skills required for quantum computing: A comprehensive review of recent studies,

    R. Ju ´arez-Ram´ırez, S. Jimenez, C. X. Navarro, C. Guerra-Garc ´ıa, H. G. Perez-Gonzalez, C. Fernandez-y Fernandez, J. Ortiz-Hern ´andez, and K. Cancino, “Skills required for quantum computing: A comprehensive review of recent studies,”Programming and Computer Software, vol. ...

    2024

  50. [57]

    ‘most advanced, yet acceptable’: Typicality and novelty as joint predictors of aesthetic preference in industrial design,

    P. Hekkert, D. Snelders, and P. C. Van Wieringen, “‘most advanced, yet acceptable’: Typicality and novelty as joint predictors of aesthetic preference in industrial design,”British journal of Psychology, vol. 94, no. 1, pp. 111–124, 2003

    2003

  51. [58]

    Building a quantum-ready ecosystem,

    A. Purohit, M. Kaur, Z. C. Seskir, M. T. Posner, and A. Venegas-Gomez, “Building a quantum-ready ecosystem,”IET Quantum Communication, vol. 5, no. 1, pp. 1–18, 2024

    2024

  52. [59]

    Quantum organisational readiness levels,

    M. Teitsma, I. Ahmed, and J. van Velzen, “Quantum organisational readiness levels,” 2025

    2025

  53. [60]

    User needs over time: The market and technology maturity model (mtmm),

    J. Silberer, S. Astfalk, P. Planing, and P. M ¨uller, “User needs over time: The market and technology maturity model (mtmm),”Journal of Innovation and Entrepreneurship, vol. 12, no. 1, p. 39, 2023

    2023

  54. [61]

    Quantum utility – definition and assessment of a practical quantum advantage,

    N. Herrmann, D. Arya, M. W. Doherty, A. Mingare, J. C. Pillay, F. Preis, and S. Prestel, “Quantum utility – definition and assessment of a practical quantum advantage,” in2023 IEEE International Conference on Quantum Software (QSW). IEEE, 2023, pp. 162–174

    2023

  55. [62]

    Quantum economic advantage,

    F. Bova, A. Goldfarb, and R. G. Melko, “Quantum economic advantage,” Management Science, vol. 69, no. 2, pp. 1116–1126, 2023

    2023

  56. [63]

    A generalized technology readiness level scale for mea- suring technology maturity: Development and pilot validation study,

    M. S. Townes, “A generalized technology readiness level scale for mea- suring technology maturity: Development and pilot validation study,” Journal of Research Management and Administration, vol. 5, no. 1, p. 2026011801, 2026

    2026

  57. [65]

    Three ways to share a qpu: Scheduling strategies for hybrid quantum-hpc applications,

    M. Cipollini, S. Rizzo, S. Iserte, P. Viviani, G. Vitali, M. Barbieri, G. Bettonte, E. Boella, F. Ganz, R. Roccoet al., “Three ways to share a qpu: Scheduling strategies for hybrid quantum-hpc applications,”arXiv preprint arXiv:2604.14955, 2026

    2026 arXiv

  58. [66]

    Qurator: Scheduling hybrid quantum-classical workflows across heterogeneous cloud providers,

    S. Pehlivanoglu, U. de Muelenaere, P. Kogge, and A. Sabry, “Qurator: Scheduling hybrid quantum-classical workflows across heterogeneous cloud providers,”arXiv preprint arXiv:2604.05505, 2026

    2026 arXiv

  59. [67]

    Qmio: A tightly integrated hybrid hpcqc system,

    J. Cacheiro, ´Alvaro C S ´anchez, R. Rundle, G. B. Long, G. Dold, J. Friel, and A. G ´omez, “Qmio: A tightly integrated hybrid hpcqc system,” 2025. [Online]. Available: https://arxiv.org/abs/2505.19267

    2025 arXiv

  60. [68]

    Wohlin, P

    C. Wohlin, P. Runeson, M. H ¨ost, M. C. Ohlsson, B. Regnell, A. Wessl´en et al.,Experimentation in software engineering. Springer, 2012, vol. 236

    2012

  61. [2026]

    Available: https://arxiv.org/abs/2603.10970

    [Online]. Available: https://arxiv.org/abs/2603.10970

Pith tools

Reviewed August 2, 2026 · model on record in the stance chip above.