Ecosystem and developer activity
The only signals on this platform that operate on a horizon longer than a trading day - and the ones most often measured by counting the wrong thing.
Price, volume and social activity all describe the last twenty-four hours. Developer and community measures describe something slower: whether a project is being built and whether people are staying. They are the least useful inputs for a trade and among the most useful for a question like "is this project still real in two years".
That makes this area relevant to a different audience — analysts, funds, project teams, journalists — and it is measured differently as a result.
What is measured
| Signal | Indicates | Principal weakness |
|---|---|---|
| Repository commits | Ongoing development work | Trivially inflatable; counts activity, not progress |
| Distinct contributors | Breadth of the developer base | Misses paid teams working in private repos |
| Contributor concentration | Key-person risk | Concentration is normal early on |
| Repository count | Scope of the codebase | Forks and archives inflate it |
| Community subscribers | Size of the following | Purchasable; measures accumulation, not retention |
| Social following | Reach | Same, plus dormant accounts persist |
| Engagement per follower | Whether the community is alive | Harder to fake, and rarely reported |
Moonboard's ecosystem score and activity views track signals of this kind over 7, 30 and 90-day windows.
Commit counts measure typing, not progress
Commit count is the most cited developer metric and among the weakest. Committing is under complete control of the party being measured. Splitting work into many small commits, automated dependency updates, formatting passes and generated files all raise the count without corresponding work.
Meanwhile a genuinely productive week can produce three commits, and a team doing serious engineering in a private repository until release produces none at all. The metric is noisy in both directions, and its errors are not random — they favour projects that optimise for the appearance of activity.
What survives scrutiny better is persistence: whether activity continues at some level across quarters. A repository with steady modest activity over two years says something a repository with a burst around a token launch and silence afterwards does not. The shape of the series carries more than its level.
Contributor structure over contributor count
Distinct contributors is more informative than commits, because adding contributors is harder to fake than adding commits. But the count alone misses the question that matters: how concentrated is the work?
A project where one person authors the overwhelming majority of changes carries a specific, identifiable risk regardless of how many contributors appear in the list. That is not automatically bad — most projects begin that way, and some excellent ones stay that way — but it is a different risk profile from distributed authorship, and a headline contributor count hides the difference entirely.
Followers accumulate; engagement decays
Follower and subscriber counts share one structural flaw: they are cumulative. They go up when someone joins and rarely go down when that person stops caring. A community that peaked two years ago retains most of its headline numbers while being effectively dormant.
Engagement relative to community size is the harder and more informative measure. A project with 40 000 followers and 30 people in a daily conversation is in a materially different state from one with 8 000 followers and 300 — and the follower count ranks them the wrong way round.
Growth rate is more informative than level, and both are purchasable. Sudden follower growth with no corresponding change in engagement is a recognisable pattern.
The correlation question
The implicit claim behind every developer-activity metric is that building more leads to being worth more. It is intuitive and it is not established here.
Reasons for caution, all of which any serious study would have to address:
- Reverse causation. Well-funded projects hire developers. Price may drive activity rather than the other way around.
- Survivorship. Projects that failed are absent from most datasets, and they are the ones whose developer activity would be most informative.
- Sector composition. Infrastructure projects generate far more public code than assets whose value rests on distribution or a community.
- Horizon mismatch. If a relationship exists it operates over years, which leaves very few independent observations in a market this young.
Moonboard does not publish a finding on this. It is listed as an open question in research notes, with the biases a study would have to control for.
Why this matters beyond trading
Most crypto data products are built for people deciding what to buy today. Ecosystem measures serve a different set of questions:
- Analysts and funds conducting diligence on a horizon of years, where developer persistence matters more than a week of turnover.
- Project teams benchmarking their own activity against comparable projects.
- Journalists checking whether a project's claims about its development are visible in public activity.
- Researchers studying how open-source ecosystems form and persist.
None of those uses requires a score at all. They require the underlying series and a clear account of what it does and does not include — which is the argument for documenting these measures separately from the trading metrics.
Open questions
- Does developer activity persistence over multiple years correlate with survival, once survivorship bias is properly handled?
- Is contributor concentration a better risk indicator than contributor count?
- How much public repository activity is automated, and does filtering it change rankings materially?
- Can engagement-per-follower be measured consistently enough across platforms to compare communities?
Related
- Data categoriesHow developer and community data is collected
- NarrativesSector classification, which affects all comparisons here
- Social intelligenceThe short-horizon counterpart
- Research notesHow the correlation question would be studied