Why 'Who Last Touched This File' Is the Wrong Question

karl-heinz reichel — Wed, 27 May 2026 19:20:47 +0000

A file can have five contributors on record and still be fully owned by
someone who left the company fourteen months ago.

The commit history looks healthy. The risk is invisible.

This is the gap that most repository analytics tools don't close — and
the reason I built Calyntro around a different concept: temporal ownership.

The Problem with Static Ownership Snapshots

Standard ownership tools take a snapshot. They look at the current state
of the repository and assign files to whoever touched them most recently,
or most often, within a fixed window.

That snapshot misses something critical: time.

Consider a module where one developer wrote 80% of the code over a
two-year period, then left 18 months ago. Since their departure, three
other developers have each made small fixes. A static tool shows:
four contributors, recent activity, looks fine.

What it doesn't show: the architectural decisions, the implicit
constraints, the edge cases that were never documented — all of that
left with the person who built it.

Temporal Ownership: A Different Question

Calyntro tracks what we call temporal ownership — who wrote the code,
when they wrote it, whether they are still active in that module, and
whether anyone else has built real understanding of it since.

The question is not "who owns this file today?"

It is: "who would be left holding it if the person who built it walked
out the door tomorrow?"

This distinction matters most in modules with high churn — code that
is actively changing. A siloed module nobody touches is a known, stable
risk. A siloed module that changes every sprint is an incident waiting
to happen.

What This Looks Like in Practice: MongoDB

We ran Calyntro against the MongoDB open-source repository — roughly
500,000 commits, one of the most professionally maintained codebases
in the world. Structured contribution guidelines, active code review,
long-term maintainers.

Here is what temporal ownership analysis found:

17 of 43 modules show measurable knowledge risk
2 modules at 100% silo ratio — one person, no meaningful backup
1 developer holds exclusive knowledge of 161 files in a single module
The module with the highest churn rate carries 38.2% silo risk

That last combination is the most dangerous: code that changes constantly,
understood by exactly one person.

This is not a startup with three engineers and no processes. If knowledge
concentration shows up in MongoDB, it shows up everywhere.

The Metrics Calyntro Uses

Silo Ratio
The share of files in a module where a single developer holds exclusive
knowledge. A silo ratio of 100% means one person is the sole knowledge
holder for every file in that module.

Bus Factor
The number of people whose departure would immediately create a knowledge
gap. A bus factor of 1 is a single point of failure.

Churn Rate
How actively a module is changing. High churn combined with high silo
risk is the most dangerous combination.

Knowledge Risk Score
A combined metric that weights silo ratio, churn, and the activity status
of knowledge holders. It surfaces modules that need attention — before
a departure forces the issue.

How It Works Technically

Calyntro reads only Git history — not your source code.

No code leaves your system. No agents. No instrumentation. The analysis
runs against commit metadata: who committed what, when, to which files,
how often.

Stack:

Backend: FastAPI + DuckDB (embedded, no external database required)
Frontend: React + Vite
Deployment: Docker, fully self-hosted
All metrics accessible via open REST API

The DuckDB approach for analytical queries over Git history was one of
the more interesting technical decisions — it handles the time-series
aggregations cleanly without needing a dedicated database server. Happy
to go into detail on that in the comments if there's interest.

Try It

Live demo running against the MongoDB repository: demo.calyntro.com

Self-hosting docs: calyntro.com

If you've dealt with knowledge loss after a key engineer left — or you're
trying to figure out which parts of your codebase are quietly becoming
single points of failure — I'd genuinely like to hear how you're
approaching it.