We Ran a Knowledge Risk Scan on FastAPI - Here's What a Healthy, Founder-Led Repo Actually Looks Like
TL;DR: We built Kinlyze to map knowledge concentration risk in codebases using nothing but Git history. To showcase what it surfaces, we scanned FastAPI - one of the most well-maintained open-source projects out there. The results are a textbook example of what founder-led development looks like structurally, and a perfect baseline for understanding what the same patterns would mean inside your company's codebase.
Why FastAPI?
FastAPI is a gold standard for open-source project maintenance. Sebastián Ramírez has built and maintained a framework that powers production systems across thousands of companies, has meticulous documentation in multiple languages, and a contributor community of 535 people. The project is actively developed, well-governed, and in excellent health.
That makes it the ideal benchmark. When you scan a well-maintained, founder-led repo, you get a clean structural fingerprint - one person driving the vision, others contributing docs, translations, and targeted fixes. The patterns Kinlyze surfaces here aren't problems to fix. They're the expected signature of a strong single-maintainer project.
The real question is: do these same patterns appear in your team's codebase - where they would be a problem?
What Is Kinlyze?
Kinlyze is a CLI tool that analyzes knowledge concentration risk in engineering codebases. You point it at a Git repository, and it produces a full risk report: a knowledge heat map, bus factor analysis, developer departure profiles, user flow risk mapping, and grouped risk alerts.
The key design constraint: Kinlyze never reads your source code. It works entirely from Git metadata - commit timestamps, file paths, author info, and lines-added/deleted counts. No diffs, no file contents, no tokens or secrets. One git log call, everything parsed in memory.
./kinlyze --repo /path/to/your/project
No API keys, no dashboards to configure, no CI integration required. A terminal report in seconds.
The FastAPI Scan
Here's the summary Kinlyze produced after scanning FastAPI:
| Metric | Value |
|---|---|
| Files analyzed | 1,358 |
| Modules found | 196 |
| Total commits | 7,015 |
| Contributors | 535 |
| User flows detected | 6 |
| Risk alerts | 14 |
The first insight Kinlyze surfaces:
94% of the repository is authored by Sebastián Ramírez. 184 of 196 modules have a single primary contributor.
For FastAPI, this is entirely expected - and frankly, it's a sign of how deeply invested the maintainer is. The project is his creation, his vision, and his continued commitment. The 535 contributors mostly provide translations, documentation, and focused patches. The deep structural knowledge lives with the person who designed and built the framework.
This is what a healthy founder-led project looks like under the hood. Now imagine seeing this exact same pattern in a company's production codebase where "the founder" is just an employee who might change jobs next quarter. Same data, very different risk profile.
Runtime vs. Low-Impact - Cutting Through the Noise
Kinlyze flagged 193 modules as having a bus factor of 1. That sounds alarming - until you look at the breakdown:
- 93 modules are runtime-critical (core framework code, tests, security, API layer)
- 100 modules are in examples, templates, docs, or generated code
This automatic classification is one of Kinlyze's core design decisions. A bus factor of 1 on fastapi/security is a fundamentally different kind of concentration than a bus factor of 1 on docs/vi/docs. Both are surfaced, but clearly distinguished, so teams don't waste time cross-training someone on Vietnamese documentation when the auth layer needs attention first.
How the Scoring Works
Most "bus factor" tools just count commits. Developer A has 50 commits, Developer B has 10 - so A owns 83%. This is dangerously simplistic. What if A's 50 commits were all one-line typo fixes, and B built the entire payments module in 10 commits?
Kinlyze scores ownership through three weighted signals, each designed to reflect how knowledge actually accumulates in engineering teams.
1. Change Significance - The Leniency Principle
Not all commits represent equal knowledge. Kinlyze applies a significance multiplier based on how much code was actually changed:
| Lines Changed | Multiplier | What It Represents |
|---|---|---|
| 1–5 lines | 0.1× | Typo fix, comment, whitespace |
| 6–20 lines | 0.4× | Small bug fix, config tweak |
| 21–100 lines | 0.75× | Feature addition, refactor |
| 101+ lines | 1.0× | Major feature, new module |
A developer who made 50 single-line fixes scores almost nothing. A developer who wrote one 300-line feature scores heavily. This is the leniency principle - minor changes don't make you the owner.
In FastAPI's case, this is exactly why Sebastián Ramírez's ownership score is so dominant. He isn't just making the most commits - he's making the most meaningful commits. The significance weighting confirms what anyone familiar with the project already knows: the deep knowledge is his.
2. Recency - Knowledge Fades
Code written three years ago and never revisited represents fading knowledge. Kinlyze applies a recency multiplier so that current active contributors outweigh historical authors:
| Commit Age | Multiplier |
|---|---|
| 0–30 days | 3.0× |
| 31–90 days | 2.0× |
| 91–180 days | 1.0× |
| 181–365 days | 0.5× |
| 365+ days | 0.1× |
This is particularly interesting in the FastAPI scan. Sebastián Ramírez's last activity was just 1 day before the scan - his recency multipliers are maxed out. Meanwhile, several other contributors show 100+ days of inactivity, which naturally decays their scores. In a team codebase, this decay is the early warning system: "Your payments expert hasn't touched the payments module in six months - their knowledge is fading."
3. The Composite Formula
These signals combine into a per-developer ownership score for each file:
ownership = (commit_score × 0.40)
+ (exclusivity × 0.40)
+ (criticality × 0.20)
- Commit Score (40%): How actively and recently you've worked on the file, weighted by change significance
- Exclusivity (40%): What fraction of the file's total weighted activity you own - the core risk signal
- Criticality (20%): How business-critical the file is (auth, payments, and infra paths score higher than readmes)
File scores are then aggregated up to the module (directory) level to produce the heat map.
User Flow Analysis - The Layer Most Tools Miss
This is where Kinlyze goes beyond typical bus-factor tooling. A module-level heat map tells you which directories have concentrated ownership. But it doesn't answer a more important question: does one person own an entire user journey end to end?
Kinlyze groups related modules into user flows - logical groupings that represent end-to-end capabilities like Authentication, Payments, Testing, or Infrastructure - and computes a flow-level bus factor.
Here's what it found in FastAPI:
| User Flow | Bus Factor | Primary Owner | Ownership |
|---|---|---|---|
| Authentication | 1 | Sebastián Ramírez | 100.0% |
| Middleware | 1 | Sebastián Ramírez | 100.0% |
| Testing | 1 | Sebastián Ramírez | 89.7% |
| Infrastructure | 1 | Sebastián Ramírez | 86.5% |
| API Layer | 1 | Sebastián Ramírez | 82.8% |
| Data Persistence | 1 | Sebastián Ramírez | 76.6% |
Every user flow has a bus factor of 1. Authentication and Middleware are 100% single-owner.
For FastAPI, this makes perfect sense. The person who designed the authentication model, built the middleware layer, and wrote the test suite is the same person who designed the framework itself. That's not a risk - that's the nature of founder-led development.
But here's the mental exercise: replace "Sebastián Ramírez" with "that senior engineer who's been at your company for four years." Suddenly the same table reads very differently. That's the insight Kinlyze is designed to surface.
Developer Departure Profiles
Kinlyze generates a departure-impact profile for each contributor, answering: "What would it cost if this person became unavailable?"
| Developer | Knowledge Share | Impact | Sole Owner Of |
|---|---|---|---|
| Sebastián Ramírez | 86.5% | CRITICAL | 69 modules |
| Nils Lindemann | 3.2% | LOW | 1 module |
| Rafael de Oliveira Marques | 3.0% | LOW | 0 modules |
| Jonathan Fulton | 2.1% | LOW | 0 modules |
| Marcelo Trylesinski | 1.5% | LOW | 0 modules |
In FastAPI, the departure profile confirms what the community already knows - this project is deeply identified with its creator, who continues to actively and consistently maintain it. The contributor tail is long but thin: 535 people, most with fractional knowledge shares.
In a corporate engineering org, a developer profile showing 86.5% knowledge concentration would be an immediate flag for knowledge-transfer planning. Not because the person is going to leave - but because you don't get to choose when people become unavailable. Parental leave, sabbaticals, reassignments, illness - availability risk isn't just about resignation.
Risk Alerts - Grouped, Not Spammed
A naive tool fires one alert per module and calls it a day. 196 modules with bus factor 1? That's 196 alerts. That's not risk management - that's noise.
Kinlyze groups alerts by owner and pattern. Instead of 91 separate alerts, you get:
CRITICAL - Bus factor 1: Sebastián Ramírez is a single point of failure for 91 runtime modules. (93 additional low-impact modules in examples/templates/docs.)
Flow-level alerts are surfaced separately because they represent a different category of risk - not just "this directory" but "this entire capability":
CRITICAL - Flow risk: Testing is one resignation away from unmaintainable. Sebastián Ramírez owns 89.7% of the entire Testing flow (83 modules).
And low-impact risks are clearly deprioritized:
LOW: Nils Lindemann owns 2 low-impact modules in examples/templates/docs. Consider whether these modules need maintainer redundancy.
This tiering - runtime-critical vs. low-impact, grouped by owner, sorted by severity - makes the output actionable rather than overwhelming.
Trend Detection
Kinlyze also tracks whether knowledge concentration is improving, stable, or worsening by comparing bus factors between two 90-day windows.
In the FastAPI scan, most modules show → (stable), with a few showing ↓ (worsening) - meaning their bus factor actually dropped recently. For a team codebase, a worsening trend is the earliest possible warning: knowledge is concentrating before a departure happens, giving you time to act.
The Takeaway: Same Pattern, Different Context
The FastAPI scan isn't a cautionary tale - it's a demonstration.
Every pattern Kinlyze surfaced - the 94% ownership concentration, the bus-factor-1 user flows, the single-person departure profile - is completely natural for a founder-led open-source project with a dedicated, active maintainer. FastAPI is in great hands, and the data reflects that.
The value of running Kinlyze isn't in discovering that FastAPI depends on its creator. Everyone knows that. The value is in having a tool that quantifies these patterns objectively - so that when you run the same scan on your company's production codebase, you don't have to guess. You'll see exactly where knowledge lives, who holds it, which user flows are concentrated, and whether distribution is getting better or worse.
Because in a corporate codebase, a 94% knowledge concentration number isn't a sign of dedication. It's a risk that needs a plan.
Try It Yourself
Kinlyze is a single binary. No dependencies, no signup, no network calls.
./kinlyze --repo /path/to/your/project
Some useful flags:
# Last 90 days only
./kinlyze --repo . --days 90
# Top 20 riskiest modules
./kinlyze --repo . --top 20
# JSON output for CI pipelines
./kinlyze --repo . --json
The full FastAPI scan - 7,015 commits, 535 contributors, 1,358 files - completed in seconds.
Check it out at kinlyze.com or on GitHub.
Questions, feedback, or want to share your own scan results? Drop a comment or connect on LinkedIn.
Top comments (0)