After we launched the beta version of our tool in November, the clearest critical comment we heard was related to our methodology for calculating developer interest in a blockchain. More precisely, we heard feedback on the decision to only count activity on one GitHub code repository toward each blockchain’s “developer score.”

The critique was that the methodology behind the CEX was insufficient to measure developer interest across each project.

As an example, bitcoin’s reference implementation is Bitcoin Core (which is the repository the CEX tracks). While that works fine for bitcoin, ethereum is implemented through several clients, which includes the largest repository (Geth, which we track), but also the independently developed, interoperable, but equally important Parity client (whose repository is not currently tracked in the CEX), as well as clients such as cpp-ethereum and still others.

By counting bitcoin’s single client, critics said the CEX painted a more accurate picture of developer interest in bitcoin, but by counting only one client for ethereum, the explorer missed out on some of the developer interest on that blockchain.

Our logic for the conservative approach was that we wanted to get the beta version of our tool off the ground with a lowest common denominator — developer interest in core protocols as implemented in their principal client. Comparisons of highly heterogeneous blockchains is a challenge and we wanted to have a solid foundation before we expanded data points and methodology any further.

The plan from there was, and is, to grow the list of code repositories we track. Our ambition is to soon track GitHub activity beyond the core protocol and client implementations all the way to associated projects built off of that blockchain, including wallets, dapps and layer-two solutions like state channels and sidechains.

After we launched and heard the criticisms, we set out to implement our full vision and expand the repos and activity on GitHub we tracked. When we started, however, we quickly realized the complexity of this task. What we wanted to do meant tracking thousands of projects and repositories. What we needed was a solution that could scale to the complexity and size of the industry and that could capture developer interest and activity in a blockchain from “head to toe.”

Our solution is now to go directly to developer communities, enabling the coders powering various blockchains to provide their input on our methodology in a setting that’s most apt given their work.

That is, Coindesk Data has now published the methodology and data sources for the CEX’s developer interest in GitHub itself.

There are several master files in our new repository to get the effort launched: one for the repos we currently track, another for the weights we give each data point, and finally another for the methodology of how to integrate associated projects in the future.

The goal is to use GitHub’s workflow tools to help us scale this important metric. Now, anyone can make a pull request for CoinDesk Data to follow a repository, to change weights given to a certain data point or to help inform any larger methodology change.

The hope is that this forum will help us harden the methodology, spark debate and scale our coverage to every corner of GitHub related to our industry. We look forward to your continued feedback.