Fig 1.
Visualization of a typical quantum algorithm workflow on a gate-model quantum computer.
First, the problem is defined at a high-level and based on the nature of the problem a suitable quantum algorithm is chosen. Next, the quantum algorithm is expressed as a quantum circuit which in turn needs to be compiled to a specific quantum gate set. Finally, the quantum circuit is either executed on a quantum processor or simulated with a quantum computer simulator.
Fig 2.
Visualization of a typical quantum algorithm workflow on a quantum annealer.
First, the problem is defined at a high-level and is then encoded into an Ising-type Hamiltonian which can be visualized as a graph. Next, via minor graph embedding the problem Hamiltonian needs to be embedded into the quantum hardware graph. Finally, either a quantum annealer or a classical solver is used to sample low-energy states corresponding to (near-)optimal solutions to the original problem.
Fig 3.
Flow diagram with selection criteria.
Decision tree used to select quantum open source software projects for consideration in this study. The acronym PR stands for pull request which is a form of code contribution on software hosting websites.
Table 1.
Overview of all projects considered in this review.
The table shows the tagline (description), the programming language(s) used, the licence and the supported operating systems (OS) for each project.
Table 2.
Feature overview of selected projects.
Overview of the projects and how their features align with the typical quantum algorithms workflow shown in Figs 1 and 2. Note, that the workflow is different in the quantum annealing paradigm as indicated by the reassigned column headings. Postprocessing is an additional feature used in quantum annealing to improve solution quality [18]. Data obtained in August 2018.
Fig 4.
Heatmap of documentation analysis results.
The heatmap shows the evaluation results for source code documentation, README files, changelogs, user documentation and tutorials on a scale from 1 (bad) to 5 (good). The evaluation rubrik used for scoring can be found in S1 Table. Data was obtained in August 2018.
Table 3.
Evaluation results for the community analysis.
For each project, we indicate if a public development roadmap exists and if the software is published in form of releases. Additionally, we report the GitHub community profile score, the total number of contributors, the type of user- and developer-centric discussion channel and the type of public code review process—specifically if it applies to internal (I) and/or external (E) contributors. Data obtained in August 2018.
Table 4.
Evaluation results for the static analysis of each project and its source code.
We report the version control and issue tracking systems as well as the total number, attention rate and average response time for all open and closed issues and pull requests (PRs). Next, we analyze the existence of a test suite and report the resulting code coverage for most projects. Code complexity is only reported for projects written in Python since other languages do not allow for fast retrieval of this metric. Data obtained in August 2018.