Source-linked AI summary
Open source software in quantum computing
Mark Fingerhuth, Tomáš Babej, Peter Wittek
TL;DR
Quantum computing needs accessible software spanning diverse paradigms and toolchain stages, while evidence about project quality and community practices remains fragmented. The paper surveys maintained open-source projects across these stages and evaluates their documentation, licensing, engineering practices, and project culture. It finds broad project diversity but limited external-developer participation and recurring shortcomings in documentation, governance, and software engineering.
Problem
Quantum computing lacks a consolidated assessment of its diverse open-source software projects and the practices needed to make them accessible, maintainable, and collaborative.
Method
The paper surveys maintained open-source projects across quantum-computing paradigms and toolchain stages, evaluating documentation, licensing, engineering practices, and community culture.
Results
The survey finds mesmerizing project diversity, but only a few projects attract external developers and many commercially backed frameworks have software-engineering shortcomings.
Takeaways & Limitations
The paper highlights best practices for building a more active quantum-software community with welcoming participation and well-documented, high-quality code.
Takeaways & Limitations
Most surveyed projects lack public governance structures and roadmaps, while documentation often fails to provide comprehensive user guidance and newcomer tutorials.
Abstract
from arXiv · showhide
Open source software is becoming crucial in the design and testing of quantum algorithms. Many of the tools are backed by major commercial vendors with the goal to make it easier to develop quantum software: this mirrors how well-funded open machine learning frameworks enabled the development of complex models and their execution on equally complex hardware. We review a wide range of open source software for quantum computing, covering all stages of the quantum toolchain from quantum hardware interfaces through quantum compilers to implementations of quantum algorithms, as well as all quantum computing paradigms, including quantum annealing, and discrete and continuous-variable gate-model quantum computing. The evaluation of each project covers characteristics such as documentation, licence, the choice of programming language, compliance with norms of software engineering, and the culture of the project. We find that while the diversity of projects is mesmerizing, only a few attract external developers and even many commercially backed frameworks have shortcomings in software engineering. Based on these observations, we highlight the best practices that could foster a more active community around quantum computing software that welcomes newcomers to the field, but also ensures high-quality, well-documented code.
INTRODUCTION
Open source software supports reproducibility, impact, community building, and skills development in quantum computing. This survey catalogs contemporary projects across the software stack to raise awareness, credit contributors, attract developers, and identify best practices.
- Motivations: Open source code improves reproducibility by reducing impediments caused by insufficiently detailed methods, data, and code.Sharing source code addresses a documented barrier to reproducing scientific results.
- Motivations: Commercial backing can help build quantum-computing communities by attracting developers who must overcome the field’s steep learning curve.The paper compares this ecosystem-building role with commercial support for large machine-learning frameworks.
- Motivations: Contributing to open source can provide credit, new skills, and perceived pathways to better career prospects.The paper identifies learning new skills as an important contribution motive.
- Survey aims: The survey reviews contemporary, maintained quantum-computing projects across software-stack categories and highlights practices associated with successful projects.It excludes projects that are no longer actively developed and maintains an accompanying website for updates.
- Motivations: Quantum open source includes a broad range of tools, libraries, and programming languages.This diversity motivates the survey’s effort to raise awareness and give contributors credit.
SOFTWARE PROJECTS IN QUANTUM COMPUTING
Quantum software spans multiple computing paradigms and workflow stages, from problem formulation and algorithm selection to compilation, execution, and simulation. Gate-model and annealing workflows differ in how problems are represented and mapped to hardware.
- Computing paradigms: The survey distinguishes discrete-variable gate models, continuous-variable gate models, quantum annealing, and application-specific quantum simulators.Quantum simulators are excluded because their application-specific nature limits generality.
- Gate-model workflow: Gate-model workflows define a problem, select an algorithm, express it as a circuit, compile it, and execute or simulate it.Compilation maps an abstract circuit to the gate set supported by a processor or simulator.
- Abstraction levels: Quantum software projects differ in abstraction level: some require manual circuit construction, while others generate circuits from higher-level problem specifications.The paper illustrates the latter with graph and starting-point inputs for the Traveling Salesman Problem.
- Quantum annealing workflow: Quantum annealing workflows encode a problem as an Ising-type Hamiltonian, embed it into the hardware graph, and sample low-energy states.A quantum annealer or classical solver can perform the final sampling step.
- Software landscape: Open source software covers all paradigms and stages of expressing quantum algorithms, using varied languages and vocabularies.Some projects also define domain-specific programming languages.
PROJECTS CONSIDERED
The survey selects and characterizes quantum software projects using explicit maturity, licensing, activity, and community criteria. It covers simulators, compilers, full-stack libraries, and projects spanning the quantum-algorithm workflow.
- Selection criteria: Projects had to satisfy selection criteria covering open-source licensing, maturity, activity, outside interest, and community status.The selection process is summarized in a decision tree.
- Selection criteria: Eligible projects used an OSI-approved licence, which grants rights to use, modify, and share the software.The study considered licences approved by the Open Source Initiative rather than merely publicly available source code.
- Selection criteria: Active projects generally required at least 100 repository commits and at least 20 commits in the past year, with an exemption for projects younger than one year.The thresholds operationalize project maturity and maintainer activity.
- Project characterization: The project overview records taglines, programming languages, licences, supported operating systems, and workflow-aligned features.The feature overview treats quantum annealing with reassigned workflow columns and includes postprocessing as an additional feature.
- Project categories: The review includes simulators, quantum compilers, and full-stack libraries such as ProjectQ, XACC, and Qubiter.Full-stack libraries expose multiple parts of the quantum-computing software stack under open-source licences.
EVALUATION
The evaluation assesses quantum-computing projects through open-source best practices, combining static source analysis, repository metadata, documentation analysis, and community-support measures. Results include documentation scores, code-readability indicators, and responsiveness to user and developer contributions.
- The evaluation combines static source analysis, repository metadata, and in-depth documentation analysis with qualitative and quantitative results.The study organizes evaluation around best practices in open-source software development.
- Documentation: README files serve as the initial user contact and should explain a project’s mission, capabilities, setup, requirements, examples, licence, and maintainers.The README is described as a hub linking users to more detailed documentation.
- Documentation: Documentation distinguishes newcomer-oriented tutorials from concise per-feature references intended for experienced users.The two forms address different levels of familiarity with the project.
- Documentation: Documentation is evaluated across source code, README files, changelogs, user documentation, and tutorials using scores from 1 to 5.The scoring rubric is provided in the Supporting Information.
- Community support: Project support is assessed through user and developer discussion channels, issue tracking, pull requests, and response attention.An issue or pull request is considered ignored when no core contributor responds within 30 days; attention rate is 1 − I.
- Code quality: Code readability is assessed through naming, comments, docstrings, consistency, and cyclomatic complexity, with lower complexity considered better.Cyclomatic complexity is extracted only for Python projects because the metric is readily obtained there.
DISCUSSION
The discussion interprets evaluation results through user, developer, and community experience, while also considering governance and open standards as important to quantum-computing community growth.
- The discussion uses user, developer, and community experience to identify best practices and gaps in open-source quantum-computing software.It additionally addresses governance structure and open standards as factors important to community growth.
User experience
Quantum software projects generally provide strong README files but often lack comprehensive user documentation, tutorials, release information, and dedicated user discussion channels. Community responsiveness varies, while licensing choices are predominantly permissive.
- Documentation: Most projects scored maximum points for README files, but user documentation often covered only a small share of project functionality.This makes project capabilities harder to understand quickly for both new and experienced users.
- Documentation: Most quantum software projects lacked detailed code tutorials, although several larger projects offered extensive, illustrated guidance for different user levels.Smaller projects tended to perform worse because tutorials require substantial time and labor.
- Community responsiveness: Only 15 of 26 reviewed projects had an average issue response time below one week, with responsiveness varying substantially across projects.Quirk’s core contributors responded in less than a day on average, while ProjectQ, Quantum++, and Qubiter showed strong attention rates despite limited resources.
- Community support: The majority of projects lacked user-centric discussion channels beyond issue and pull-request responses, which the survey identifies as a major field shortcoming.Qiskit, dimod, and pyQuil were examples of projects offering forums or Slack-based support.
- Licensing: 65 % of projects used the permissive Apache-2.0 licence, while only two projects used the copyleft GPL-3.0 licence.Apache-2.0, BSD-3-Clause, and MIT licences allow derived software works to become proprietary.
Developer and community experience
The survey finds generally reasonable code readability and widespread automated testing, but weaker documentation, governance, contribution processes, and standardization. Public development practices remain inconsistent, especially around roadmaps and developer participation.
- Development process: Most projects lacked roadmaps, while Qiskit Terra was an exception with a roadmap on its wiki.The survey associates roadmaps with greater openness and potential developer engagement, particularly for smaller projects.
- Code quality: Sixteen projects achieved full scores for source-code documentation, and several combined high documentation quality with low code complexity.Highlighted projects included Strawberry Fields, Qiskit Terra, Cirq, PyQuil, OpenFermion, FermiLib, and dimod.
- Testing: 23 of 26 projects employed automated test suites, with median code coverage of 87% despite wide variation across projects.Average coverage was 75%, with a standard deviation of 29%.
- Developer experience: Developer-centric discussion channels and high-level architecture documentation were commonly missing, limiting direct community participation and project orientation.Code review often remained available through pull requests, including for external contributions.
- Contribution process: Only Strawberry Fields and the three Qiskit projects received maximum community-profile scores for clear contribution guidelines and templates.These projects provided templates for user questions, issues, and pull requests.
- Governance: Projects generally lacked formal public governance structures, with many design decisions made offline, including in commercially backed projects.The survey argues that opening decision processes could strengthen community ownership and encourage contributions.
- Standards: Open standardization was neglected: ProjectQ supported IBM processors, while XACC supported IBM, Rigetti, and D-Wave QPUs.The survey identifies standardization as an increasingly important gap for interoperability across quantum hardware.
CONCLUSIONS
The survey maps a difficult-to-navigate quantum-computing software landscape and finds that open-source availability lowers the barrier to learning and using quantum computing. It also identifies persistent shortcomings in documentation, governance, responsiveness, standardization, and long-term maintenance.
- Scope and purpose: The survey began as a curated list and developed into an evaluation intended to help newcomers and experienced developers navigate quantum-computing software.It aims to give credit to pioneers and support the growing quantum-computing community.
- Impact: Open-source projects make understanding, creating, and executing mathematical models on specialized quantum hardware easier.The paper relates this development to the role of open-source frameworks in machine learning.
- Shortcomings: Most projects had inadequate documentation, internal decision processes, slow responses to issues and pull requests, and competing software platforms.The paper reports these shortcomings even among projects with commercial support.
- Standards and governance: The paper identifies missing open standards as a source of maintenance and development overhead for both users and developers.It also calls for more open decision-making to broaden community participation.
- Sustainability: Automated extraction of evaluation criteria and a live website were created to keep the survey useful as software projects evolve.The website updates results as new software releases appear.
SUPPORTING INFORMATION
The supporting information includes a rubric for evaluating code documentation.
- Code documentation: Table V presents the evaluation rubric used for code documentation.The rubric is referenced as the basis for documentation scoring.