The code != the project, and situations like this one demonstrate this. In a typical open source project, it's relatively easy to ensure continuity of the codebase, but continuity of the organization, and all the meta that enable communication, collaboration, coordination, is a challenge. Doubly so are hardcoded trust anchors that need to be moved: project and artifact names, IRC channels, domain names, keys and certs(!), contributor rights and permissions, URLs for artifacts.
Further, there's no good literature on what one's supposed to do in this case, or how to architect one's organization to be resilient to such situations. Even having a council of superadmins wouldn't solve all of the above -- if any service dependency doesn't natively support more than one administrator, the same credential would have to be shared among all admins, leading to a comparable set of problems: arguably worse, as one rogue actor can take control of portions of the management infrastructure.
There's a real lack of maturity in identity and access management for the needs of multi-leader organizations in spaces like domain hosting, code hosting, IRC channels, and, y'know, nearly everything else.
Further, there's no good literature on what one's supposed to do in this case, or how to architect one's organization to be resilient to such situations.
Perhaps not specifically tailored for open source software projects, but areas such as key person risk and business continuity aren't exactly under-researched. The "trick" is to know you need it, and it's not a particularly pleasant conversation.
GitHub would actually be a good home for something like this. A secure repository (as secure as cloud-hosted can be) of keys and stuff, and a mechanism for "opening the vault" and naming new administrators (say, a unanimous vote of n out of m listed contributors).
Comments
The code != the project, and situations like this one demonstrate this. In a typical open source project, it's relatively easy to ensure continuity of the codebase, but continuity of the organization, and all the meta that enable communication, collaboration, coordination, is a challenge. Doubly so are hardcoded trust anchors that need to be moved: project and artifact names, IRC channels, domain names, keys and certs(!), contributor rights and permissions, URLs for artifacts.
Further, there's no good literature on what one's supposed to do in this case, or how to architect one's organization to be resilient to such situations. Even having a council of superadmins wouldn't solve all of the above -- if any service dependency doesn't natively support more than one administrator, the same credential would have to be shared among all admins, leading to a comparable set of problems: arguably worse, as one rogue actor can take control of portions of the management infrastructure.
There's a real lack of maturity in identity and access management for the needs of multi-leader organizations in spaces like domain hosting, code hosting, IRC channels, and, y'know, nearly everything else.
Perhaps not specifically tailored for open source software projects, but areas such as key person risk and business continuity aren't exactly under-researched. The "trick" is to know you need it, and it's not a particularly pleasant conversation.
GitHub would actually be a good home for something like this. A secure repository (as secure as cloud-hosted can be) of keys and stuff, and a mechanism for "opening the vault" and naming new administrators (say, a unanimous vote of n out of m listed contributors).
I mean, wasn't this basically the same issue that CentOS ran into several years back?