Repository control confers no power over bitcoin

Control of Bitcoin's reference software repository confers no power over Bitcoin, because the rules are set by the clients users are already running rather than by commits to any repository.

For (strongest version as argued): The distinction is not a technicality, it is the whole design. Users can run any software they like, from any repository, and nobody is forced to upgrade — so a maintainer's commit changes what is offered, never what is enforced. When the reference repository changed hands, the position taken was that ownership amounted to a janitorial role: the rules are determined by running clients, and a maintainer who merged a rule change the economy declined to run would have published a change to nothing. Influence over the technical community, where it exists, comes from reputation rather than from write access, and reputation is not transferable by handing over a repository. Treating maintainership as authority is a misconception that has persisted for years precisely because it looks like authority from outside.

Against (strongest version as argued): "Users can run anything" describes a right, not a practice. Nearly everyone runs the reference client, few audit it, and the cost of maintaining a divergent client is high enough that the option is theoretical for almost all of the economy — which makes the maintainer's agenda the default outcome in every case where users do not actively revolt. Setting the release schedule, deciding what is reviewed, and deciding what is never merged are real forms of power even if none of them is enforcement. The opposing case was made publicly at the time: that the reference developers were bitcoin's single biggest risk, because inaction absent a perfect solution is itself a decision, and a group able to decline indefinitely does not need formal authority to determine outcomes.

Nuance: Both sides are describing different mechanisms and are largely compatible. Maintainers cannot impose a consensus rule — that is settled, and the record supports it. But agenda control, review capacity and default-client inertia shape which changes ever reach the point of being accepted or rejected. The honest formulation is that repository control is not sovereignty but is not nothing either: it is the power to set the menu, not to choose the meal. Note also that the historical episode is asymmetric evidence — it shows the rejection path working, which tells us less about changes nobody contested.

Sourcing: one owner-research file, at medium confidence because that source states both the position and its strongest contemporaneous rebuttal rather than only one side. It is not a primary source, so INGEST_PLAYBOOK.md caps the status at CONTESTED, and it stops at February 2016 — the UASF episode, which is the sharpest available test of who actually decides, falls outside it entirely.

Common misstatements: "The Core developers control Bitcoin" (they cannot make anyone run anything; what they control is the default and the agenda). "The maintainer is just a janitor, so maintainership doesn't matter" (the janitorial framing was an argument in a live dispute, not a neutral description, and it understates agenda-setting). "Anyone can just run a different client" (true as a right; rare as a practice, and the gap between the two is the actual subject of this dispute).