Moonlytics.io
Data / Developer activity

Developer activity data

Daily public repository metrics for digital asset projects. A measurable, falsifiable record of what got built — and a data point that is routinely over-interpreted.

What developer activity is not

High commit counts are not a quality signal, not a fundamentals score, and not an investment signal. Repository metrics are trivially inflatable, vary by an order of magnitude between engineering cultures, and say nothing about whether the code is good or the project is solvent. Treat this series as one input to be read against others, never as a verdict.

What this data is

Two daily series per covered project. The first describes the repositories: cumulative stars, forks, issues and merged pull requests, plus a four-week rolling commit count. The second describes the people: distinct contributors and their cumulative contributions.

Coverage is the same curated set of 69 assets as the rest of ecosystem data, because the series depends on a repository pointer that is maintained per asset.

Where it comes from

Metrics are collected from public code hosting through the metadata provider's record for the asset, which carries the project's repository URLs. Projects often list several; the recorded set is what gets measured. Where the provider's URL was wrong — pointing at a mirror, an archived organisation, or a personal fork — the asset record carries an explicit override flag showing that the pointer was corrected by hand.

How to read the fields

Only one field in the repository series is a rate: commit_count_4_weeks. Everything else is cumulative, and cumulative counters have a specific failure mode — they look healthy forever. A project that stopped shipping two years ago still has all its stars.

The useful readings are therefore differences and ratios:

  • Commit rate over time — is commit_count_4_weeks trending up, flat or decaying?
  • Contributor breadth — is pull_request_contributors growing, or is one person holding the repository up?
  • Issue hygiene — closed_issues / total_issues, tracked over time rather than as a snapshot.
  • Attention versus work — star growth against commit rate. They diverge more often than not.

Available fields

Repository series

starsintegerCumulative stars across the tracked repositories.
forksintegerCumulative forks.
subscribersintegerWatchers on the tracked repositories.
total_issuesintegerIssues ever opened.
closed_issuesintegerIssues closed. The ratio against total_issues is more informative than either number alone.
pull_requests_mergedintegerCumulative merged pull requests.
pull_request_contributorsintegerDistinct accounts whose pull requests have been merged.
commit_count_4_weeksintegerCommits in the trailing four weeks. The only genuinely rate-based field in the series.
code_additions_4_weeksintegerLines added in the trailing four weeks. Frequently null upstream.
code_deletions_4_weeksintegerLines removed in the trailing four weeks. Frequently null upstream.
createdDatetimestampUTC collection timestamp for the daily record.

Contributor series

contributorsintegerDistinct contributors to the tracked repositories.
contributionsintegerCumulative contribution count across those contributors.
createdDatetimestampUTC collection timestamp for the daily record.
daily repository record
[
  {
    "createdDate": "2026-08-29T11: 01: 04.188Z",
    "forks": 36426,
    "stars": 73168,
    "subscribers": 3967,
    "total_issues": 7743,
    "closed_issues": 7380,
    "pull_requests_merged": 11215,
    "pull_request_contributors": 846,
    "code_additions_4_weeks": null,
    "code_deletions_4_weeks": null,
    "commit_count_4_weeks": 108
  }
]

The nulls in that sample are real, not illustrative. Code addition and deletion counts are unavailable upstream for many projects even where commit counts are present.

Update frequency

Daily. The repository series is collected around 11:00 UTC and the contributor series around 15:00 UTC, each at a stable hour so that day-over-day differences compare like with like. Values often repeat between consecutive days — a four-week commit window genuinely does not move much in twenty-four hours, and the series reflects that rather than manufacturing motion.

Limitations

  • Public repositories only. Projects that develop privately and publish releases look dead here and are not. This is the single largest source of misreading.
  • Repository selection bounds everything. Only the repositories recorded on the asset are measured. A monorepo, a split ecosystem or a client maintained by a separate organisation will skew the series in either direction.
  • Metrics are gameable. Commit counts, stars and forks can all be manufactured cheaply. Nothing in this series attests to effort or quality.
  • Cumulative fields never fall. Read rates and differences.
  • Nulls are common. Especially in code churn fields. Null means unavailable, not zero activity.
  • Forks are not deployments. A high fork count reflects interest and copying, not usage.

Which applications use it

Developer series contribute to the ecosystem view on moonboard.ai, always presented as a trend against other ecosystem series rather than as a standalone rating.

Related