Now that I diversified, I don't need to worry.
I'm meanwhile trying to reduce the bus factor in my own business, which is just me + outsourcers. I'm documenting what I do and creating processes, and am going to see a lawyer to make a will.
I'm only 28, but if anything happened where either I died or couldn't work, I'd want to be able to hand things off without it being an unusable mess.
(reducing my own bus factor also makes it easier to outsource)
Multiplication could plausibly be involved if the cost to the project compounds with the number of lost team members.
At elementary OS, we work hard to keep our bus factor healthy, and it should also become a priority on other projects as, unfortunately, we keep coming across "dead" open-source projects because the lead (and sometimes sole) developer of the project had to move their focus to another project or to real-life work.
I wonder, though, if there's an easy way to "measure" a given project's bus factor and would love to know more about it.
When I was a new college hire, I thought that would be a good situation. And while it has its perks, it also has many downsides. But the biggest one came when I decided it was time for me to move on.
I wanted to stay with the company and move to a new project. It seemed like a great fit, the new project wanted me...but the director of the old organization told me I had to stay responsible for the old product for 3-6 months before I could formally transition. I had to basically threaten to quit in order to have that number reduced.
If you are in this situation, make sure that either the company is working to increase the bus number and give you some more resources or that the company realizes your importance and compensates you accordingly. I didn't quite realize that my employer saw me as being the critical engineer until after trying to leave. In hindsight it's obvious, but since I started right out of college as a junior developer under people who knew everything about the problem space, my mindset was never "I am the expert", even long after those actual experts had left.
So: you would like the factor to approach n.
Note that often (e.g. when comparing bus factor of projects of different sizes) it makes sense to normalize by dividing by the size of the team in which case the answer to asogi's question is "Yes, normalized bus factor is 1/n"
Consider two projects, a one-man project with a bus factor of, obviously, 1, and a 100-man project with so much redundancy within the group that the bus factor is an impressively robust 50. The standard bus factor immediately tells us that the big project is much much less fragile.
The "normalized bus factor" you describe (1 for the solo project, 1/2 for the huge project) perversely tells us that the big project is much more fragile, in that it will be disabled by the loss of 50% of the team, while the solo project will only go down after a full 100% of the team is eliminated.
Why does it make more sense to count redundancy by "percentage of the team, whatever size the team might be" rather than by "number of setbacks before project failure"? In general, the bigger team really does make the project more robust, not less robust.
There's probably already some name and many theorems in graph theory for both of these ideas.
(longer term I want to put myself out of the equation)