Bitcoin is often discussed as pure code and consensus. Less visible — at least to those not deep in the weeds — is the living network of people writing that code, reviewing it, and debating its future.
My goal with Orange Dev Network is to make that human layer more transparent and easier to understand: who is contributing, how influence flows, and what’s actually happening in the quiet corners of development.
It currently tracks 7,367 contributors across GitHub, Delving Bitcoin, and the mailing list. Here’s what stands out early:
- 1,142 people contributing code and core PRs
- 4,951 contributing peer reviews and feedback
- 1,596 participating in research and discussions
- 156 BIP authors shaping protocol standards
- Only 69 individuals active across all four domains
The dashboard has three main views:
- Meet the Builders: Individual profiles showing each developer’s commits, reviews, mailing list posts, and Delving discussions.
- Protocol Pulse: A summary of current conversations from the mailing list and Delving Bitcoin.
- Influence Map: Visual connections showing who responds to, debates with, or builds on whose work.
This is early work. The impact scoring for developers is deliberately basic right now — I’m especially eager for feedback from people who live and breathe Bitcoin Core daily.
A couple of specific asks as you explore:
- Do you see any data issues? (For example, I left one playful 2015 “Satoshi” reply attached for now — let me know if any merges look wrong.) Also, how can I pull in more mailing list conversations from before 2011?
- How can we improve Protocol Pulse? What kind of summary or signals would you actually find useful from mailing list and Delving conversations? Trending themes? Key voices? Links to eventual code changes?
Would love your honest thoughts! what feels useful, what’s missing, or what to expand next.
Thanks to everyone who has passed feedback on earlier versions: @Car @JuanGalt @k00b @Murch
Here are the latest dashboard enhancements:
3: Fixed most of the bugs with timeframe-based dev filtering. The UX still needs some work to make it more intuitive. It is on the list for next week.
I think you forgot to share a link to the site:
https://sorukumar.github.io/orange-dev-network
The 'Email para newsletters' circle strikes me as strange:
Cool data, but the Influence Map is a bit hard to read. Especially among the more active contributors basically everyone reviews everyone.
Thanks. Will check out “Email para newsletters” next and fix it.
On the influence map: I’m still trying to make it genuinely useful and easier to read. Right now I’m tweaking a few knobs, mainly the time-decay [exponential decay, λ=0.15] and the way communities are detected, to see what gives the graph a better shape. Ideally, the clusters should start reflecting different generations of developers, with old-timers in one part of the graph and newer gen in another. If that works, someone like sipa should show up as a bridge between those groups [high betweenness centrality].
You’ll also notice the shaded box on the graph. That is meant to capture expertise clusters, basically grouping people by what they tend to talk about. For that, I’m building topic fingerprints and comparing them using similarity scores [cosine similarity, Louvain detection]. I think we still need to be smarter about how we assign expertise, because the top contributors will likely show up across multiple areas rather than fitting neatly into one bucket.
The harder part is that these expertise clusters do not line up neatly with the main network, which is built from who replies to whom [reply graph, PageRank-weighted]. So the challenge now is how to show both layers without making the whole thing confusing. Maybe that means switching between views, or maybe using color and layout in a better way.
Let’s see if I can make the graph genuinely insightful. Otherwise, it’s just a profile map of all devs.
I’m wondering how the work relationship of people could be discovered. Some people reply to each other because they are collaborating. Some people serially reply to each other, because they cannot ever agree. If the latter could be discovered in some manner, and push people apart rather than pulling them together, the clusters may actually be more representative of what’s going on.
let me think through it.
One way could be to have an LLM review the full discussion and output a file with predefined metrics (like collaboration vs conflict signals could be one). We could store that and pull it into the dashboard. Since these patterns don't change often, running it every 3-6 months would probably be enough.
that said, there might be a smarter, cheaper, and deterministic approach using proxy variables. I'll keep thinking on it.
His recent Bitcoin Builders Club got released.
Also on X:
https://twiiit.com/BTCBuildersClub/status/2059258253964349509
A cool dashboard to express the human work around bitcoin.