I'll review it, to understand what is going on. I've been pulling a lot of this info from commits and keys on GitHub, and then use your feedback to override any data mismatches

Thanks. I have an identity resolution script, and anything it can't capture I put in the identity curated list. So I'll handle the two there and run it

fixed it. can you please help me with timelines, at least for all maintainers.

https://github.com/sorukumar/orange-dev-data/blob/main/metadata/sponsors.json

I see that chaincode is assigned to you.

I was adding some new identity features to Orange Dev Network and ended up reviewing CryptoQuick’s profile today. Pretty sure my identity-resolution bugs are now his identity issues.

Quick summary of his Bitcoin work : https://sorukumar.github.io/orange-dev-network/profile.html?uuid=auto_hunter_beast

Daniella, really enjoyed this. Solid analysis and those press release numbers hit hard.

Any plans to expand it? Happy to collaborate on automating the data collection (monitoring public releases...) and doing some smart pragmatic modeling for broader coverage.

I’ve been leaning toward expanding the orange-dev-suite work to 'influencers' so we can generate insights like yours at scale

Also loved your piece on the nostr retention problem.

I'll have a look and report back.

Basically, there's super low activity in the last 3 years compared to their past contributions. I ended up tweaking and reached to the definition to mark Gavin Andresen as retired . he was showing up as active because of his 2022 comment saying he is retired.

At a high level, if someone had, say, 20 reviews before the last 3 years and only 1 in the recent period, they're labeled retired. less than 5 reviews makes them "fading."

I haven't accounted for work in btcpayserver or NBitcoin or Lightning yet, so I see that as a data limitation. However, I need to rethink the methodology , it's even marking 2026 contributors as retired.

Will add it in the next iteration.

Thanks for the feedback, @Murch. That's a big reason we've been able to make all these improvements to the dashboard.

added secp256k1 and bitcoin-core/gui, plus repos like bitcoin-core/guix.sigs. on the profile page, though, I still break the commits into 'core' and 'ecosystem'.

here is how svanstaa profile looks like now.

Just checked the Pool Deep Dive. clean luck/P&L stuff.

A few pools are showing interesting signals on streaks, header-first, and cross-pool moves lately. Worth layering any of those deeper forensics if it's not already in the plan

Love the open-source analytics drop on elektronics.dev. those ASIC charts are gold .

On our end we've been poking at pool forensics (streaks, weird transitions, that sort of thing) in the mining dashboard.

How are you seeing the bigger operators navigate this drawdown? Any patterns standing out on the pool side?

here are the details:

I cross-referenced the StackExchange link you mentioned. Our dataset[https://github.com/sorukumar/orange-dev-data/blob/main/metadata/maintainers.json] actually matches the StackExchange details perfectly, but I had supplemented it with commit data directly from the repository, which caused some quirks in the UI.

1. On the dates for Gavin and Jonas: The data pipeline was dynamically inferring their timelines based on their earliest and latest merge commit dates rather than their official appointment dates. In Gavin's case, his last actual merge action was in 2015 (even though he held keys until 2016). For Jonas, he had made a local merge commit on a PR branch back in 2013, which tricked the script into expanding his timeline. I've updated the logic to strictly use their official appointment dates, so the chart is now historically accurate.
2. On Luke Dashjr: He does have about 9 merge commits in our data from the 2011-2016 era. I assume this was before the modern trusted-keys protocol for merge commits was strictly enforced.
3. On Strategic Maintainers: In the UI, I use dotted/hollow bars for Cory Fields, Carl Dong, and Sebastian Kung (sedited) from 2019–2025. This visually distinguishes that they were Strategic Maintainers (e.g., maintaining the build system, security, or Guix) but did not hold keys to merge into the master branch.

Refining the UI for this chart is still a pending item. I'm planning to move it from the Tracker ("what") over to the Network dashboard ("who") for a cleaner separation of concerns in next iteration.

By the way, what do you think about the approach of visually distinguishing and showing Strategic Maintainers alongside the traditional Committers?

Great catch. You're right. Sebastian has dozens of PRs merged in bitcoin-core/guix.sigs.

However, our current data pipeline only tracks the main bitcoin/bitcoin repository. Since PR #34636 was his first PR merged into the main repo (on June 10th), the script flagged him as a new contributor this week.

To make this clearer on developer profiles, I'm going to start displaying both the authored commit date and the PR merge date.

Quick question: As we expand our data sources (we're already adding BIPs), do you think we should also include satellite repos like secp256k1 and bitcoin-core/gui in our main analytics?

No, haven't seen them share anything publicly on LN.

That said, from the data it looks like when they open a channel with a node and usage is high, they keep adding more channels over time. Definitely a sign of real usage

https://sorukumar.github.io/plebdashboard-ln/profile.html?node=03a1f3afd646d77bdaf545cceaf079bab6057eae52c6319b63b5803d0989d6a72f

Here are the latest dashboard enhancements:

1. Revamped the Product Pulse page
2. Added a summary of discussions on the home page
   
   

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.

One more source to check: Bitcoin Data Labs shares this kind of Lightning data on X every day.

Here's the post: X post

For the detailed dashboard: plebdashboard-ln

By the way, these two nodes have 14 public channels between them, with over 50 BTC in total capacity.

don't see it as extreme either.

In fact, if and when Bitcoin gets big, having a dedicated dev deeply involved in Bitcoin will probably become pretty normal for large companies rather than not.

After all, we'd generally find it more acceptable for big companies to direct resources toward common goods — Bitcoin being one — than not to. It's like how we expect them to contribute to the Linux kernel.

a common observation in the space is that Brink and similar funders tend to support younger devs more often.

• on one hand, younger contributors are usually more flexible and open to new ideas — which helps move things quickly. In big tech I’ve often leaned that way myself, where young talent is preferred for exactly that reason.
• but, on the other hand, this same flexibility can sometimes make them easier to influence (even unintentionally), while more experienced, opinionated veterans with different POVs often get passed over because they can be harder to align or manage. even though you already support some solid older contributors.

How does Brink think about this balance? Are there any intentional approaches to support a broader range of experience levels and viewpoints?

And how do you think Brink should manage or counter this perception? What kind of data or metrics could be tracked and shared with the wider community to build more trust in the process?

Or maybe Brink doesn’t worry about it much. there will always be criticism, and with multiple funders in the ecosystem, these things tend to balance out overall.

Great report, Mike!. Really appreciate the transparency and all the work supporting Core.

A few friendly pieces of feedback. assuming the goal of the report is to maximize transparency and build community trust that there’s no undue influence on Core:

1. Donor Breakdown
   Anonymous donations were huge this year (~60%). It would be helpful to know the total number of contributors broken down a bit more (e.g. individuals vs organizations) without revealing any private details.
2. Branding/ Framing of Supported Developers
   I know this is nitpicking, but referring to them as “Brink engineers” might unintentionally suggest closer control than exists. Using something more neutral like “Bitcoin Core contributors funded by Brink” could better reinforce independence and transparency.
3. Grant Selection Process
   The report mentions the Grant Committee but doesn’t describe how grantees are chosen. A short note on the criteria and any safeguards against bias (personal, ideological) , or donor influence would be very helpful for trust.
4. Conflict of Interest / Governance
   Would be great to see a brief overview to how Brink handles potential conflicts of interest — especially between board/grant committee members, large donors, and grantees.

Overall, fantastic job . the high program ratio and impact are impressive.

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.

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.