One developer. 161 files. The highest churn rate in the entire repository.
This is not a startup with three engineers and no processes. This is MongoDB — one of the most widely used, most professionally maintained open-source codebases in the world. Thousands of contributors. Years of accumulated engineering discipline.
And still: a single person holds exclusive knowledge of 161 files in a module that changes more than any other.
Why MongoDB?
We chose MongoDB deliberately. Not because it is a cautionary tale, but because it is the opposite: a project that does almost everything right. Structured contribution guidelines, active code review, long-term maintainers. If knowledge risk shows up here, it shows up everywhere.
That is the point.
What Calyntro measures — and why it is different
Most tools answer a simple question: who last touched this file?
That is useful, but it misses the most important dimension. A file can have five contributors on record — but if four of them left two years ago, the knowledge effectively lives with one person. The commit history looks healthy. The risk is invisible.
Calyntro tracks temporal ownership: who wrote the code when it was written, accounting for team changes, role transitions, and contributors who have since moved on. The result is a picture of where knowledge actually lives today — not where it once lived.
The analysis below is based on the MongoDB open-source repository, main branch.
The numbers
17 of 43 modules are affected
Across the entire repository, 17 of 43 modules show measurable knowledge risk. That is nearly 40% of the codebase carrying concentration that would make a handover difficult or incomplete.
The risk score Calyntro assigns combines two dimensions: silo ratio (how concentrated ownership is) and churn rate (how actively the code is changing). A module with high silo ratio but low churn is a sleeping risk. A module with both high silo ratio and high churn is an active one — decisions are being made constantly, by someone who may not be there tomorrow.
src_third_party: the critical case
The src_third_party module has a 38.2% silo risk. It also has the highest absolute churn rate in the entire repository — nearly 3.9 million lines changed over the observation period.
That combination is what makes it the highest-priority finding in this analysis. High churn means the code is evolving continuously. High silo risk means most of that evolution is happening inside one person’s head. Every commit, every decision, every tradeoff — understood by one developer.
One developer also holds exclusive knowledge of 161 files within this module alone.
Two modules at 100% silo risk
bazel_resmoke and jstests_change_stream_fsm both show 100% silo risk. No distributed ownership. No meaningful backup. If the responsible developer were unavailable tomorrow — through illness, resignation, or any unplanned absence — there is no one who fully understands these modules.
In a codebase of this scale and maturity, that is a structural finding, not a personnel one.
3 of 5 sole owners are flagged at risk
Calyntro identifies 5 developers who hold exclusive knowledge across significant parts of the codebase. Of those, 3 are flagged as at risk — meaning their ownership concentration is high enough that a departure would create an immediate gap.
What this means for engineering teams
The instinct when seeing numbers like these is to look for someone to blame. A developer who hoarded knowledge. A team that failed to enforce reviews. A process that broke down.
That instinct is wrong.
Knowledge concentration is a structural consequence of how software grows. Modules accrete complexity over time. The people who understand them best are the ones who built them — and in most organisations, those people move on. What was once a shared understanding quietly becomes a single point of failure, without any single decision causing it.
The problem is not behaviour. It is visibility.
In our conversations with CTOs and engineering leads, the pattern is consistent: teams sense that critical dependencies exist, but they cannot locate them precisely. They find out when someone hands in their notice. Or after.
What changes when you can see it
Visibility does not solve the problem automatically. But it changes what is possible.
With a clear picture of where knowledge is concentrated, engineering leads can make deliberate decisions: prioritise documentation for high-risk modules, adjust review processes, plan onboarding before a departure rather than after. The risk does not disappear, but it becomes manageable — because it is no longer hidden.
That is what this analysis is designed to surface.
What this looks like for your codebase
The numbers above come from a public repository. The same analysis applies to private codebases — and in our experience, the findings are often more concentrated, not less.
If you are curious what knowledge risk looks like in your own codebase, we are happy to run the analysis and walk through the results with you.
This analysis is based on the MongoDB open-source repository, main branch, as of May 2026. Developer names have been anonymised.