Quantum’s Next Bottleneck May Be the Person Maintaining the Code
A new survey reports concentrated maintenance in many sampled quantum-software repositories. It raises a human infrastructure question, not a verdict on every project.
A quantum computer can have a crowded laboratory behind it and a remarkably small team keeping part of its software alive.
A September research manuscript called Entangle looks at that less visible side of the field. In its sample, the authors classify 81.7% of repositories as having a bus factor of one: maintenance activity is concentrated in one key contributor under the study’s method.[1]
That does not mean 81.7% of quantum software is about to fail. It means the authors found a concentration worth examining. The difference matters to anyone tempted to turn a striking percentage into a verdict on an entire industry.
A picture of collaboration, not a census
The study builds a graph connecting repositories, contributors and organisations using a June 2026 GitHub snapshot. It covers more than 1,500 repositories, 27,000 contributors and 400 organisations, and identifies contributors who bridge organisational boundaries.[2]
The sample is constructed through searches and filtering. It is not a complete count of quantum developers, commercial teams or all the software used in operating machines. A repository is not the same thing as a product, and a contributor account is not a complete job description.[2]
The authors provide code for their collection and visualisation tools. That makes the method more open to inspection; it does not mean QubitWire has independently reproduced every classification or verified the current health of individual projects.[3][4]
Why maintenance is part of the hardware story
A working experiment needs more than a device. Someone has to keep the surrounding instructions understandable, fix failures, review changes and help new users reproduce an example. That is work even when it does not produce a new benchmark or a striking launch photograph.
A hypothetical lab can see the issue by asking a simple question: if the main maintainer of an important dependency were unavailable, who would know how to make a release? The answer might be reassuring. It might also reveal documentation, permissions or knowledge that need to be shared.
That is a better use of a maintenance metric than naming and shaming small projects. A research prototype can legitimately have a narrow team. A widely depended-on library presents a different responsibility. A percentage becomes useful only when connected to purpose, activity and actual dependence.
The less photogenic investment
Hardware photographs make quantum progress visible. Maintenance often remains visible mainly when something breaks. An editor looking only for dramatic equipment can miss the people who make separate pieces usable together.
The study suggests a practical line of questioning for organisations that rely on open tools: which dependencies matter, who reviews critical changes, where the release knowledge lives and whether another person can reproduce the workflow. These are editorial implications, not recommendations tested by the study.
Nor should a one-person concentration automatically be described as neglect. Public activity may not capture private support, funding arrangements or work done outside GitHub. The fair response is to inspect the context before drawing conclusions about any particular project.
The quantum race is often pictured as a competition to build a better machine. This research points toward another resource to watch: the people who keep the surrounding software usable. A -count milestone tells you little about who can ship the next software release.