The least-read part of any post is the source list at the bottom. For a long
time I looked at mine like a badge of conscience: if the links are still
standing, the work is sound. On 12 October those links went through a
liveness count:
seven returned 404 and seventy-five had moved to a different address.
That measurement told me how healthy the list was. What it did not tell me
was this: where does the list look?
This time I counted that. I did not like the number — and in its first form
it was wrong, and the wrong part was not only the number. My explanation of
the cause did not hold either.
What I counted, and what I could not
The repository holds 1,415 Turkish posts (measured on commit 67f09d8c, with
this post left out of the count). 325 of them carry an official-sources
section, and those sections contain 2,189 external links in total. The
remaining 1,090 posts are not source-free, they are source-unrecorded: they
were produced before that section settled into the writing as a habit.
I am stating the denominator up front, because the denominator of a ratio is
its most easily hidden part. 2,189 links belong to 325 posts. Nothing more.
The first table came out in the wrong unit
I ran the first query and the answer looked perfectly clear: 30.2% of the
links — 661 of them — came from a single domain, github.com. Exactly the
kind of bad number that makes you want to write a post. I was about to put
down the sentence "a third of my sources come from one place" when I noticed
the unit error.
github.com is not a publisher, it is a landlord. The URI standard draws
this line from the start: of the authority part of an address it says
"governance of the name space defined by the remainder of the URI is
delegated to that authority," and the host is only one subcomponent of that
authority. GitHub's own documentation says repositories are owned
"individually" or shared within an organization. So the distance between
github.com/torvalds/linux and github.com/systemd/systemd is no smaller
than the distance between nginx.org and sqlite.org.
I split those 661 links by owner: 157 separate owners, 188 separate
repositories. The top ones, in order: torvalds/linux (202),
systemd/systemd (57), git/git (42). There was no monopoly in the middle;
there was a folder I had been counting wrong.
I changed the unit and counted again: for hosting sites the owner, for
everything else the domain, each treated as one "publisher."
At the publisher level the table reads: 546 distinct publishers, the
largest being github.com/torvalds with a 9.2% share, and the top ten
adding up to 34.9%. On top of that, 350 publishers appear exactly once across
the whole corpus. That distribution is not bad; it even has a long tail worth
being proud of.
Then I split the same table by calendar month, and the pride ended there.
A quarter of the publishers
| Month | Posts with sources | Links | Distinct publishers | Linux share | Median publishers per post |
|---|---|---|---|---|---|
| 2026-05 | 1 | 7 | 2 | 14.3% | 2 |
| 2026-07 | 18 | 151 | 116 | 0.0% | 7 |
| 2026-08 | 95 | 620 | 328 | 0.6% | 4 |
| 2026-09 | 95 | 751 | 131 | 32.1% | 4 |
| 2026-10 | 86 | 490 | 78 | 27.6% | 3 |
| 2026-11 (first 13 days) | 30 | 170 | 47 | 18.2% | 3 |
Note the first column's name: these are not all the posts published that
month, only the ones carrying a source section. In July the gap is a chasm —
200 posts went out that month and only 18 of them have a source section.
After August the coverage is nearly complete: 95 of August's 97 posts, 95 of
September's 96, 86 of October's 86. The single post on the 2026-05 row is
there so the table does not lose it; a reader adding the columns should land
on 325 and 2,189.
In August I published 95 posts carrying a source section, and they rested on
328 separate publishers. In October I published 86 posts, and they rested
on 78 separate publishers: a basin 4.2 times smaller.
That last column matters too: the median number of publishers per post fell
from seven to three, yet three is still a reasonable number. Look at any
single post and you see work that was "verified from a few different places."
The narrowing is invisible in one post; it shows up in the corpus. Audit a
library book by book and you will not find a gap on any shelf; step back and
you see that every shelf comes from the same press.
Comparing August with October is apples to oranges
When I first wrote this table the cause was ready at hand: in September the
topic queue ran dry, the pipeline started picking topics on its own, and
every topic it picked led to the kernel. A tidy story. What was missing: that
wide 328 of August was not a product of my attention.
I looked at the message of the first commit that added each post. Of
August's 95 posts, 72 arrived with feat: auto-generated content — the
old bulk pipeline, running over a topic calendar written in advance. In
October the number of posts from that pipeline is zero; 84 of the 86 come
from today's agent pipeline. So August and October are not two months of the
same author, they are months of two different production systems.
The old pipeline's breadth was not curiosity either. 48 of August's 95
posts carry exactly eight sources — median eight, a narrow spread. The
pipeline applied a fixed quota per post, and the topics on that calendar were
product write-ups; each product led to its own documentation, so each post
brought a new publisher by construction. October's median is five, spread
from three to thirteen.
The honest comparison, then, is the one inside a single system:
September 131 publishers, October 78. That is still a narrowing — 1.7
times — but not 4.2. The number in the title is not wrong, it is incomplete:
part of the gap between August and October is explained by the authoring
regime, the rest by topic selection.
Separating the two did not suit me, which is why I am writing them out
separately.
Four separate publishers, one tree
The publisher count is still too optimistic a measure. Look at the first four
names on my list: github.com/torvalds (202 links), git.kernel.org (91),
docs.kernel.org (87), www.kernel.org (32). They count as four separate
publishers. Together they are 412 links, that is 18.8% of all my sources.
All four sit around the same project. The kernel's patch-submission guide
tells you to clone the mainline tree from
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git: the same
tree you see on GitHub under the name torvalds/linux. There is one place
here where I have to be careful — I could not find an official sentence
on kernel.org's pages saying "the GitHub repository is a mirror," so I am not
writing that. The evidence I do have is more modest but sufficient: the
official clone address and the GitHub repository name the same tree.
My diversity counter was celebrating four doors into the same upstream as
four separate sources. September's jump in the Linux share, from 0.6% to
32.1%, sits exactly here.
Why the gate never complained
This blog's source discipline is not an intention, it is code.
source-policy.mjs went live on 17 August 2026 and asks two things of every
post: at least 3 unique official sources, at least 2 unique official
hosts.
The gate did not complain even once in October or November. And it was right
not to: of the 116 posts published in those two months, 45 sit at exactly 2
hosts and 51 at 3 — 82.8% living between the threshold and one step above
it. The minimum became the norm over time; that is how gates usually work,
nobody collects bonus points.
I had already written about scale outstripping the gate on this blog: when
forty-four posts in a row came from a single category
no indicator turned red, and the lesson there was "no gate puts two posts
side by side and asks whether they resemble each other." Six weeks later I am
measuring the second face of the same gap: back then the composition had
narrowed, this time the evidence base.
There is a second trace in the same place: the allowlist of permitted sources
has 71 entries, and 62 of them have been used so far. The nine never used
are: canonical.com, golang.org, haproxy.com, haproxy.org,
mistral.ai, traefik.io, truenas.com, typescriptlang.org, vite.dev.
My intention was broad when I wrote that list; my practice never got there.
Why I did not trust the "new publisher" count
My first pass found a far more striking series: the number of publishers
encountered for the first time each month. 115 in July, 298 in August, 95 in
September, 24 in October, 12 in the first 13 days of November. A decline
ready-made for a headline.
I did not publish it, because that series falls on its own. After reading 546
publishers, running into a new one gets mechanically harder; saturation draws
the same curve as narrowing. A measurement agreeing with your thesis does not
make it evidence.
With the same suspicion I asked about monthly concentration by share rather
than by count: the largest publisher's share in August is 3.1%, with
docs.github.com. In September it rises to 18.2% with github.com/torvalds,
in October 11.4% with git.kernel.org, in November 10.0% with
www.rfc-editor.org. After August no month returned to that scatter.
Where I tried to refute myself
The weakest point of this measurement is that it only counts the source list.
Yet the documents that are valuable but not on my allowlist get cited as
inline links in the body of the post. When I say "my basin narrowed," I
may simply never have counted the part of the basin that lives in body text.
I counted it. Across all body text outside the source sections there are
306 external links going to 142 publishers; 58 publishers appear only
in body text and never made it into a source list. The body does carry an
uncounted basin.
But that basin is not widening. August's body text holds 78 links and 41
distinct publishers; October and November's body text holds 97 links and 44.
While the source list fell from 328 to 78, the body went from 41 to 44. The
body does not compensate for the source section's narrowing; it sits in its
own steady narrowness.
Had I skipped this check the post would still stand, but a reader would
rightly have asked "did you look at the body?"
If you want to repeat the measurement
I am writing the method as it is, because a reader has to be able to
recompute this table. I matched the source heading with the gate's own
regular expression — case-insensitive, accepting the English variants
alongside Resmî Kaynaklar. That matters: one post in the corpus has its
heading written as ## Resmî kaynaklar, in lower case, and carries eight
links. Counting case-sensitively would have dropped that post and shown
August as 326 rather than 328 — I would have been measuring my own policy
with a stricter definition than the policy's own. After that I extracted the
Markdown links from the section under the heading, took each address's host,
and where the host was github.com or gitlab.com appended the first path
component to build the "publisher" unit, then split those by the
publishDate field into months.
That landlord rule covers two names only, because this corpus has no other
tenancy. If yours does — sourceforge.net, codeberg.org, bitbucket.org,
readthedocs.io, npmjs.com, *.github.io — the rule is the same: any
address that rents out name space has to be split at the tenant level. Skip
that and your counter shows you a wider world than you have.
I stepped into three traps along the way. The first is language twins: every
post has an English counterpart and the same sources sit in those files too,
2,203 more links. Counting both would have pushed the total to 4,392 and
changed the diversity table not one bit — a twin brings no new publisher, it
counts an existing one twice. The second is the case sensitivity above. The
third: this post itself is not in the count; when you repeat it, its four
sources will be in the table as well.
Ask your own setup
- Is the unit you count genuinely independent? Any counter that treats a landlord as a publisher and a mirror as a second source inflates diversity.
- Are the two periods you compare the same system? If the production method changed, the gap in your hands may be a regime difference rather than a behavioural one.
- Is the drop saturation or narrowing? The cleanest way to separate them is to put two periods of similar volume — and the same pipeline — side by side.
- At what scale does your quality gate work? A gate that works per item cannot see anything that happens at portfolio level.
Conclusion
The real lesson I take from this is not the scale of gates — I learned that
six weeks ago and still did not see this narrowing coming. The real lesson is
the unit of the counter. What I took to be diversity got counted with a unit
of my own making, and as long as that unit was wrong the count did nothing
but reassure me. I counted a domain as a publisher; I counted four
doors into the same tree as four sources; I counted months from two different
production pipelines as two months of the same author. All three errors
pushed the counter up — that is, in my own favour.
The unit of measure is the definition of the thing you are trying to measure.
A wrong unit does not hand you a wrong answer; it hands you a reassuring
one, which is far harder to notice.
My next move is to turn this count into a check that runs once a month: the
distinct publisher count of the last 30 posts, and the largest publisher's
share. For a starting threshold I will take the September-October band —
warn if 30 posts rest on fewer than 40 distinct publishers, or if a single
publisher passes 20%. That may not be the right threshold, but starting
somewhere beats not measuring.