I spent some time looking at the March 2026 data from the JetBrains Bus Factor Explorer. The results for Linux systems and database stability are a bit of a wake-up call. We tend to view open source as a massive, self-healing collective. We assume that if a project is popular, there must be a thousand people who know how it works. The data suggests otherwise.

The 2026 Bus Factor Ranking for Databases

When you look at the current rankings, a clear divide emerges. MongoDB currently has a bus factor of 7. MariaDB and Redis both sit at 5. In the world of open source sustainability, 5 is generally considered the threshold for a healthy project. It means the knowledge is spread out enough that the project can survive a few departures.

Then you look at the pillars of the Linux ecosystem. MySQL, PostgreSQL, and SQLite all have a bus factor of 2. This is what we call a low or high-risk state. It means that for these massive, global projects, only two people are central to maintaining the core architecture well enough to fix it when it breaks.

Simulating a Total Knowledge Collapse

It is easy to think that a fork would just solve the problem. If the main devs leave, someone else will just pick up the code. But code is not just text. It is context. Simulations were run to see what happens to the functional parts of the code when the top two contributors are removed from the equation.

For MySQL and SQLite, the result was a 100% loss of functional directories. This includes the storage engines and the SQL parsers. In PostgreSQL, the loss was 83.3%. The code does not disappear, but it becomes a black box. No one left in the room understands the "why" behind the logic. This is how technical debt turns into a security liability. When a new vulnerability is found in one of those "lost" directories, the patch won't come quickly.

Why "Lost" Knowledge Matters for Linux Security

A "lost" directory is code that exists but cannot be safely evolved. If the developers who understand the memory allocation in a database leave, the remaining team might be afraid to touch it. This leads to several issues:

• Security Patch Latency: Vulnerabilities stay open longer because the fix is too complex for new maintainers.
• Feature Rot: The software stops being compatible with new Linux kernel features.
• Maintenance Bottlenecks: Pull requests sit empty because no one is qualified to hit "merge."

The Human Hack and XZ Utils (CVE-2024-3094)

This is not just a theoretical worry about productivity. It is a documented security threat. We saw this play out with the XZ Utils backdoor. That project had a bus factor of one. A single, overwhelmed maintainer was running the show. According to the OpenSSF and OpenJS Joint Alert, a state-sponsored actor spent two years building a relationship with that maintainer. They offered help and slowly gained trust.

They didn't hack the software with a script. They hacked the bus factor. They filled a vacuum of knowledge and used it to insert a backdoor that almost compromised every Linux server on the planet. When a project has a low bus factor,it creates opportunities for abuse. Attackers look for these lonely projects because they are the easiest to subvert.

MariaDB vs. MySQL: A Case Study in Resilience

There is an interesting comparison between MySQL and MariaDB. They share the same history, but their human structures have diverged. In the same simulation where MySQL lost 100% of its knowledge base, MariaDB only lost 16.7%. MariaDB has a bus factor of 5.

This tells us that community governance is a physical security feature. By distributing knowledge across more people, MariaDB has built a project that is harder to kill and harder to subvert. It shows that you can choose resilience if you prioritize contributor density over just shipping features.

Practical Compliance: Auditing Your Supply Chain

If you are responsible for a Linux environment, you have to start looking at your supply chain through this lens. The CISA Open Source Software Security Roadmap emphasizes this kind of radical transparency. They want us to stop looking at just the license and start looking at the sustainability of the people.

How to Evaluate Your Own Projects

You can use the CHAOSS metrics to audit your own dependencies. These metrics help identify which critical FOSS packages are most at risk. Here is what you should look for when choosing a new tool or auditing an old one:

1. Organizational Diversity: Does one company employ all the core devs? If so, a layoff could kill the project.
2. Labor Investment: Are people actually being paid to maintain the code, or is it a hobby?
3. Documentation Quality: Is the knowledge locked in a head or on a wiki? Comprehensive docs make it easier to onboard new experts if the originals leave.

We spend a lot of money on firewalls to keep people out. We should probably spend a little more time making sure the people inside the projects are actually there to stay. Security is not just about the code. It is about the bench of people standing behind it. Check your bus factor before the bus checks you.

Appendix: Simple Breakdown of Server Impact

What actually breaks on your Linux server if the top two developers leave? Here is the "lost knowledge" map.

High-Risk Projects (Bus Factor: 2)

• MySQL: You lose the experts for the storage engine (how data hits the disk) and the SQL parser (how queries are read). Essentially, the brain of the database goes dark.
• PostgreSQL: You lose the experts for the core engine and the interfaces. If your Linux apps stop being able to talk to the database after a kernel update, there is no one left who knows how to fix the bridge.
• SQLite: This is embedded in almost every Linux tool. If the top two devs leave, the knowledge for the entire project is effectively gone. This puts your OS-level tools at long-term risk.

Resilient Projects (Bus Factor: 5+)

• MariaDB: If two devs leave, you only lose knowledge for minor things like packaging scripts. The actual database engine stays fully understood by the remaining team.
• Redis: Even if the top two architects leave, every part of the system remains understood by the rest of the contributors. It is the gold standard for knowledge sharing.