What is Pale Moon’s bus factor?

[Mæstro]

I have sometimes wondered about what will happen many years hence to the Pale Moon browser. A recent discussion in the off-topic board on current XUL learners, which I cannot seem to locate, had brought this back to mind. The titular number refers to how many Pale Moon developers would need be chosen to star in isekai series before development on the browser would cease. Last year’s events prove it is greater than one, but how is it?

[Moonchild]

The term was first applied to software development, where a team member might create critical components by crafting code that performs well, but which also is unavailable to other team members, such as work that was undocumented, never shared, encrypted, obfuscated or not published.

Aside from some work that is undocumented which would possibly considerably slow adoption, all code is shared openly in the project. Nothing is encoded or obfuscated, and while not everything is published publicly, those parts are not critical to the actual software. So... as long as there are interested people wanting to continue working on Pale Moon, there is always the possibility to do so without the need for redeveloping critical components. What does that make the bus factor? Infinite?

[vannilla]

That factor is to be considered in terms of transfering knowledge between old and new developers in a way that while learning there is someone that can explain the more obscure parts.
Especially in a large project like UXP it is also best applied in terms of components, rather than the whole thing.
The main issue with a low bus factor, regardless of availability of code or tools, is that when the bus hits, anything involving the component with a low score will inevitably halt development until someone manages to get the same knowledge entirely on their own.
Low bus factors are surprisingly common even on projects that are more popular than Pale Moon, usually because the component is very specialized, requires a certain knowledge and people are not motivated to work on it for one reason or another.
For example, among the contributors to GNU Emacs pretty much everyone and their mothers can work on elisp code, like the "standard library", to fix bugs or make it more performant, but the people that know how the rendering component works can be counted on your fingers.

[Moonchild]

Well in that case it's simply unknown. I have no idea how many people have familiarized themselves with the various components of Goanna, because that is directly related to how many people have familiarized themselves with the same components in Gecko. It could be as low as 1, for some components, or it could be several dozen. In addition, it also depends on how quickly people can educate themselves in the components "when a bus hits". But as said there are no components that are simply private, obfuscated or otherwise inaccessible in the project that would prevent others from quickly picking up development if something catastrophic were to happen.