---
robots: noindex, nofollow
---

# Decentralizing Bitcoin Core Development

**Subject: Toward Decentralizing Git Collaboration, not Privatizing Bitcoin Core**

In response to: https://groups.google.com/g/bitcoindev/c/43yjt8MXMvo

The concerns Bryan raised about coordination noise and GitHub's moderation limitations are real. We've seen how open platforms without clear boundaries invite persistent disruption — not just trolling, but sustained efforts to derail meaningful technical collaboration.

But rather than framing this as a call for *privatization*, I think it's more productive to view the problem through the lens of *decentralization*. Git is already a distributed protocol — we should be using it that way. We need infrastructure that supports secure, accountable collaboration without relying on centralized gatekeepers, corporate platforms, or closed offices.

### Git is Already Distributed — Let's Lean Into That

Git is a distributed version control system by design. In principle, any developer or group of developers can work together on their own forks, branches, or remotes — and coordinate externally from GitHub if necessary. What we often lack is robust and usable *infrastructure* for decentralized collaboration: systems that offer structure, provenance, access control, and cryptographic guarantees, without reverting to centralized or closed development.

### Open Source vs. Open Development

It’s also important to recognize that an open-source license alone is insufficient for true ***Open Development***. Sustainable open development depends not just on permissive licensing, but on values like transparent governance, verifiable contributions, and non-coercive collaboration. "Open Development" is a broader process that considers who can participate, how trust is earned, and what incentives shape behavior. These questions are especially vital in a high-stakes project such as Bitcoin Core.

I've written [an article on Open Development](https://www.blockchaincommons.com/articles/Open-Development/) that I invite you to read as a parallel stream to this discussion.

### Transparency Is Not a Given — It’s a Design Decision

One criticism that has surfaced around Open Development is the idea that Bitcoin Core developers have a "duty of transparency." But this expectation is rarely defined. Is it a duty to publish *code*, to explain *decisions*, to make *deliberations* public in real time — or something else entirely?

If transparency is important to Bitcoin’s social contract, then we should talk about what it actually entails, how it's balanced against resilience, and where it begins and ends. Developers already meet significant transparency obligations: reproducible builds, tagged releases, and open review processes. That’s not nothing.

But assuming an *unlimited* or *unspecified* duty to perform transparently — in every venue, at every stage — can easily become a vector for coercion or burnout. Like every part of this system, transparency needs intentional architecture, not moral ambiguity.

### A Proof-of-Concept: Open Integrity Project

I help maintain the [Open Integrity Project](https://github.com/OpenIntegrityProject/core), which explores how Git repositories can be used as cryptographic roots of trust. Our work includes:

* **Inception commits** to establish a verifiable origin.
* A signed `.allowed_commit_signers` policy to verify contributors.
* Future plans for branch distribution via **Bittorrent's DHT**, **FROST-based threshold signing**, decentralized governance, and other methods.

Open Integrity is *not a proposal for Bitcoin Core*. But it proves that decentralized coordination around open-source codebases can be more secure, intentional, and resilient — while remaining transparent and permissively licensed.

### Radicle and Other Directions

[Radicle](https://radicle.xyz) is another working example. It shows that peer-to-peer Git hosting and identity infrastructure are real and usable today. It may not fit every contributor, but it makes clear that **decentralization** — not privatization — is a viable and thoughtful alternative to GitHub’s constraints.

### Structuring for Sovereignty

Public dev spaces come with power dynamics — and attackers exploit them. We need tools and norms that protect developer autonomy without killing transparency. That’s not impossible. But we have to build for it, not assume it comes for free.

As I said, we shouldn't frame these transitions as “privatizing” development, but we should instead focus on how to **structure decentralized collaboration** more effectively — with clear boundaries, strong tooling, and healthy expectations. Still open, but designed to resist coercion and chaos.

Let’s explore optional decentralized spaces where trust is earned, review is rigorous, and participation remains open — but under conditions that developers can actually work within. No gates, just better scaffolding.

-- Christopher Allen, Blockchain Commons

P.S. For context: I've been working on secure software since the early '90s — contributing to projects like PGP, Digicash, SSLREF, TLS 1.0, and more recently the W3C DID 1.0 spec. I’ve participated in and helped shape multiple open-source and standards communities over the decades, including during my brief time at Blockstream and now with Blockchain Commons. My long view informs my belief that better tooling and clearer boundaries can preserve both openness and resilience.

Comments from Bryan:

“I think your draft could be improved by more directly calling out your link to https://www.blockchaincommons.com/articles/Open-Development/ or highlighting what the content has. Eg it's not just a link but rather it seems like readers should read it as an inline addition.”

“I think that even your Level 5 Cooperative can take so many forms, including user feedback submissions being private read only to members, for example. Right now the way GitHub works is that anyone on the Internet can post directly in a dev comment thread with only post facto moderation.”

“I like this part
" transparency is important to Bitcoin’s social contract, then we should talk about what it actually entails, how it's balanced against resilience, and where it begins and ends. Developers already meet significant transparency obligations: reproducible builds, tagged releases, and open review processes. That’s not nothing.

But assuming an unlimited or unspecified duty to perform transparency — in every venue, at every stage — easily becomes a vector for coercion or burnout. Like every part of this system, transparency needs intentional architecture, not moral ambiguity."