Counting Cardano builder activity: weekly commits and 30-day releases across 15 core repos from the GitHub API

At The Cardano Record most of what we publish comes from our own cardano-db-sync node. This segment is the exception. You can't read builder activity from the chain, so it comes from GitHub, and no db-sync table is involved.

The question it answers is narrow. How many commits landed on the default branch of a fixed set of core Cardano repos last week? How does that compare with their recent weeks? And how many releases did those repos publish in the last 30 days?

What is measured

We take two readings per repo:

• Commits per week on the default branch, from GitHub's /stats/commit_activity endpoint. One call per repo returns the last 52 weeks, with one commit count per week.
• Releases published in the last 30 days, from the /releases endpoint.

From those we derive four figures per repo:

1. last week's commits
2. the average of the 12 weeks before last week
3. the 52-week total
4. the percent change of last week against that 12-week average

The same figures are also computed across all repos combined. The baseline is the 12 previous weeks, so the week being judged is not part of its own average.

The repo list is fixed, and it is a sample

The list doesn't change from run to run, and it is shown on screen whenever the segment airs. It covers the core stack:

• node, ledger, consensus and networking
• Plutus, the CLI and the API
• db-sync and GovTool
• Aiken, Hydra, Mithril and Dolos
• the wallet backend and the Mesh SDK

That makes 15 repos. It isn't "all of Cardano", and the segment is not allowed to call it that. Most of the ecosystem's dapps, wallets and libraries are outside the list. Because the list is fixed, this week's total and last quarter's total always count the same repos.

Fetching: unauthenticated on purpose

The fetcher reads no credential. GitHub allows a small number of unauthenticated calls per hour, and one refresh fits inside that allowance. A refresh makes one commit-activity call per repo, at most one retry per repo, and one releases call per repo. Cron runs it once a day.

python3 sources/builders.py --refresh      fetch from GitHub, write CACHE
python3 sources/builders.py                print the cached block

The commit-activity endpoint has one quirk to plan for. If GitHub hasn't computed a repo's statistics yet, it doesn't return them. It replies that it is still computing, and the fetcher has to ask again. That is what the retry budget is for.

The refresh writes a cache, and the episode reads the cache. So the GitHub data is always a little older than the episode snapshot, and we report by how much.

How it is checked

• Coverage. The block records how many repos answered next to how many are listed, plus a missing field that names any repo that failed. In this run 15 of 15 answered and missing was empty. A total over 14 repos should never be presented as a total over 15.
• The totals add up. We added the per-repo figures while writing this. Last week's commits sum to 391, which matches the reported total. Releases split as 3 (Plutus) + 3 (Cardano CLI) + 1 (Node) + 1 (Aiken) + 1 (Wallet backend), which is 9 across 5 repos, also matching.
• Freshness. The data was fetched at 2026-10-18 10:21:04 UTC. The snapshot it fed was taken at 2026-10-19 07:30:01 UTC, so the data was 21.2 hours old when used. The week being measured starts 2026-10-11.
• No second source today. Our rules ask for a cross-check against an independent source where one exists, and for us to say so when one isn't done. Here it isn't done. We read GitHub's own statistics and don't recount commits from the git history ourselves.

Traps

A commit is not progress. One large feature can be one commit, and a typo fix is another. The segment says "commits" and never "progress" or "development speed". Comparing repos by commit count mostly tells you how each team commits.

Default branch only. Work on feature branches isn't counted until it is merged. Four repos had zero commits on their default branch last week: Networking, db-sync, Aiken and the Wallet backend. Two of those four still published a release in the last 30 days: Aiken v1.1.24 and Wallet backend v2026-10-07. A zero week on the default branch is a fact about the default branch, nothing more.

Small baselines make large percentages. The Mesh SDK had 6 commits last week against an average of 2.4. That is 150% above average (our calculation) and only a few commits in absolute terms. db-sync's baseline is 1.2 a week. We show the raw counts next to any percentage so its size can be read.

One week is noisy. Hydra had 5 commits last week against an average of 29.1, yet 1,509 over 52 weeks. Node had 4 against 19.3. The weekly figure says what happened last week. Read without the longer series beside it, it doesn't describe a trend.

Release names aren't comparable. The latest tags read 1.72.0.0, cardano-cli-11.4.0.0, 11.1.3, v1.1.24 and v2026-10-07. Each repo has its own scheme, some numbered and one dated. We count releases and list the latest tag, and we never compare version numbers across repos.

Results

Week starting 2026-10-11. Fetched 2026-10-18 10:21 UTC and used in the snapshot of 2026-10-19 07:30 UTC.

Repo	Last week	Avg previous 12 wks	Last 52 wks	Releases 30d	Latest release
Consensus	85	43.2	1,454	0	-
Plutus	63	44.9	2,524	3	1.72.0.0
Mithril	61	62.9	3,146	0	-
Cardano CLI	52	12.9	433	3	cardano-cli-11.4.0.0
Ledger	45	43.8	1,891	0	-
Dolos	35	16.2	556	0	-
GovTool	23	16.2	293	0	-
Cardano API	12	30.2	1,088	0	-
Mesh SDK	6	2.4	141	0	-
Hydra	5	29.1	1,509	0	-
Node	4	19.3	975	1	11.1.3
Networking	0	5.8	570	0	-
db-sync	0	1.2	194	0	-
Aiken	0	7.6	237	1	v1.1.24
Wallet backend	0	24.4	901	1	v2026-10-07
All 15	391	360.2	15,912	9 (5 repos)

Last week was 8.6% above the 12-week average across all 15 repos.

The archive of our episodes, each with its transcript and the figures it used: https://cardanorecord.com/episodes.html