Sourceforge did this to me a few decades ago. I had created an open source project and was leading a group of developers. I told my group I'd be out of town for a week on vacation. Some members decided they wanted control of the project so they told sourceforge I abandoned it, which wasn't true of course. When I got back, sourceforge wouldn't hand control back to me. It turned me off open source to be honest. At that point I backed out of any other projects I had founded or was participating in. I then dove headlong into proprietary software as a career.

You can argue that it's open and one should be okay with that kind of behavior. But, imagine if Linus lost complete control of Linux, repository, websites, mailing lists and the group and was pushed to the side. We wouldn't have Linux today as we know it.

You can fork if this happens to you. But, the team members who wanted the project could have forked. They only performed a takeover because they wanted power and all the spoils of the effort that went into building the group, website, the name, developers, the claim of being the original project, social connections and user base. They also wanted to erase me from the history of the project. I was wiped out of the AUTHORS file. They had control of the blog entries, its message and direction of the project. It is dirty, underhanded and I am sure I am not the only one who it has happened to.

Regarding freenode, we've already received and acted upon an email from an appropriate person in the project, from their @voidlinux.eu address to our projects support email.

Based on this, we've added access flags for those active contributors enabling them to administrate their channels on freenode, and reassured them that if there's anything else we can do to help, we'd be happy where we're able to.

For now, the Void Linux channels are back with active contributors and should be able to run as intended.

The only responsible and correct thing to do is to fork it! That's what open source licenses allows as a built in mechanism for these kinds of situations.

The github organization has 10+ active members with full write access to all projects/repos. The only missing permission for the organization is to change/add new team members. We asked to get permissions to change teams for one of the senior contributors who are part of the organization since 5+ years.

Freenode wouldn't be setting some kind of legal precedent, they'd just be making a judgment call. It seems like an easy one if the guy is truly missing.

Github is a rather different sort of entity...

> what is github/freenode supposed to do in this case, allow a takeover?

Of course. The group has a reasonable case to ownership of the project, and no one else (specifically the awol user) is contesting the handover.

[edit]: I did not even realize this would be a contentious point to make. I see lot of what-aboutisms (and downvoting): but let's take this concrete example for the story we're reading:

(1) Does anyone want to contest that the parent posters are not owners of the project (with commit access, and regarded by the project's community as it's leaders).

(2) We're not talking transferring away a govt. provided identity here. It's the github/irc project handle so it's owners can use it given the prior owner is awol.

(3) I agree there may be scenarios where this may not be as cut and dried, which is why i specifically mentioned ownership of a project, and no contention.

I'm not sure the ownership is disputed? perhaps the original owner has had an accident or suffering a mental or other illness. Github/Freenode could attempt to reach out to the current account holder to verify he/she is still alive as a first step I guess

I'm not knowlegable in Githubs licences and TOS, but perhaps a judge may order transfer of ownership of all the data because of valid reasons.

> 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).

I mean, wasn't this basically the same issue that CentOS ran into several years back?

Sharing the power is also really important. I founded the project PhpWiki back in 1999, and eventually saw the need to grant admin access to other developers. I haven't done any development on the project in about fifteen years but it's still going.

https://sourceforge.net/projects/phpwiki/

First off, I'm surprised an open project has such a high bus factor. There should always be a contingency plan.

The IRC channel could have easily been protected if a second or even third trusted member of the team was given admin privileges and/or access to bots. The domain and github accounts are tricky because of ownership and financial payments.

The right way to do this would be to form an organization (non profit, etc) and register all the domains and accounts to that entity. Then delegate access to one or more trusted members with the founder as the head.

And finally, let this be a lesson to open developers. If you want to participate in a large open project, check the bus factor and proceed with caution.

Debian has key distribution system. Every critical password/key/etc. is divided into `n` parts, where `m` parts (obviously m < n) can assemble the data back.

These are used primarily for repository private keys, revocation keys and like.

In this scenario, in case of emergency, secondary level officials can assemble the key (or secret) if something unfortunate occurs to the top level management.

For Debian FTP Archive secret keys, Debian uses 3 out of 5 arrangement, as can be seen in https://ftp-master.debian.org/keys.html. See SSSS holders section.

This is not a tech problem waiting for a tech solution; it's a people problem. Project managers/admins/maintainers need to be able to share power for long-term survival (exceptions are rare). This is step one and for most projects there are no ways around that.

If that's the case, then we can talk about tech solutions, but for the most part that's sharing account data for SPOF-y things like domain and hosting contracts.

Perhaps timelock[1] variants could be implemented if a usable option comes up. The idea being that if access or activity is dormant for a period of time t, then at t+1 secondary keys can be used. This presumes that organizations wishes to maintain a "single focal point" and not simply share the access amongst several individuals.

Timelocked secondary keys/credentials could be used as a fail safe. If one wants to really design safety into the system, ensure each admin-level key is revokable, and then wait for t duration.

[1] https://en.bitcoin.it/wiki/Timelock

For starters having more than one person with admin / owner level of access. At least three is better but even two people reduces these risks and significantly lowers bus factor.

What most companies have is access controlled by an organizational superuser team.

At large companies, this means that each team has full or near-full control over their "jurisdiction." IT has full control over LDAP accounts, and since they're a team, one person going AWOL won't affect the org as a whole. There are also infra teams that control domain routing and hosting providers.

Perhaps core infrastructure passwords for a project could be placed in a dead-man's-switch escrow service, where they will only be released to a larger core team if NONE of the (potentially multiple) project leaders with those passwords check in for a certain period. Current blockchains/crypto don't permit this without a trusted third party escrow service, though, AFAIK.

Register as a (non-profit) corporation, appoint a board and keep all important credentials in escrow. Assign job titles and job specifications to all key personnel; if you don't know exactly who is responsible for what, you can't make contingency and continuity plans. Reject all pull requests that aren't comprehensively documented.

It sounds like a lot of work, but it has a tremendous RoI. The advantages of corporate personhood more than outweigh the administrative burden for a serious open-source project. The issues affecting Void are practically moot if accounts and domains are owned by a corporate person rather than a natural person.

It's obviously overkill for a personal side-project, but I'd consider it essential once you're starting to worry about your bus factor. If no-one involved in your project wants to deal with this admin, find someone who does. There are a lot of non-technical people who would still like to contribute to the free software movement.

I feel like this is more of a human problem than a tech problem. Tools like github should allow org owners to declare a "will" of sorts when they go missing, including conditions to meet, who has access and contact methods. But maybe that puts an unacceptable burden on services like this.

I think the primary measure is simply "think about it in advance". The major requirement is just to make sure that multiple people have the necessary admin accesses; this is seldom technically tricky. You just need to take an afternoon to list up all the resources your project has and for each (a) who has access and (b) who has permissions to change the access rights. Then review it occasionally to make sure the list still has enough active members on it to be safe. It's also a useful document to have around so that when somebody says "who do I need to talk to to get access to our foo servers" you know the answer.

> Furthermore, we’re in contact with a non profit organisation that helps open source projects to manage donations and other resources. We hope that we can announce further details in a few weeks.

That's a strong claim. What led you to conclude that nobody asked any of those things?

Plenty of people are, or want to, but the point is that no one knows except the maintainer and he's not responding.