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.
