Void Linux project leader has disappeared
voidlinux.eu
voidlinux.eu
>We have contacted freenode support. We see hope to regain access to the VoidLinux IRC Channels. IRC is an essential tool for communication of the core team.
what is github/freenode supposed to do in this case, allow a takeover? allowing takeovers opens up a can of worms whenever a project gets forked and both sides claims to be the "rightful" owner of the project.
Serious question, from the perspective of the providers: is death a valid reason to transfer control of someone else's intellectual property? Legally, wouldn't that be the property of the person's estate?
The only potential problem is if the account has any private repositories, but GH could archive and/or delete those beforehand.
Having copyright over the code means being able to provide copies under a license of their choice. They still wouldn't be able to do that: relicensing the code would be illegal. They could only use it under the same license they already had.
The Github account is not IP, it's just a property of Github's system, and it belongs to them (GH), not to the copyright holder.
Luckily, one of our group of friends worked for GitHub and helped facilitate the transfer. Not sure how we would have done it otherwise.
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.
Sounds fairly benign. Ownership transfers happen all across the web with, to give a few examples, subreddits, social media handles, messaging groups, etc. Why can't Github do the same?
Edit: GH could also be in for liability claims should the original owner re-appear (at least in general, if not this particular case), and would need to check identity of the involved parties and whatnot, which is going to be very costly.
Nobody is giving away the current org - github would just be vacating the old name so somebody else can have it.
This is bound to become a bigger issue in the future as more and more names get used then fall into disuse.
The lesson is again why it it so important for any organization or project to have a continuity plan and not to have any one person as a gatekeeper.
"Account names may not be inactively held for future use. (...) Inactive accounts may be renamed or removed by GitHub staff at their discretion."
Brilliant.
You don't really own part or any of the project if you don't have administrative access to it. It's that simple. If you feel like you should, then you need to arrange that with the person who currently does.
These are project organizational issues that GitHub shouldn't be expected to waste their time on.
The organization on GitHub was registered by an individual on behalf of the open source project. Now that the person can no longer be contacted, control needs to be transferred to someone else representing the open source project. It's that simple.
While I agree with that logic on some level, this sounds exactly like the same arguments that every tech company uses to detach itself from the social consequences of the service it provides.
The expectation that you must always be reachable is toxic and one of the reasons I burned out of checking my email more than a couple times per month.
1. Github rename Void Linux to Void2 Linux as per above policy.
2. Register Void Linux to existing team.
3. Fork Void2 Linux as Void Linux.
Problem solved.
Forking is the only allowable option if the owner does not respond. Being able to take over a project's organization and official repo can be easily abused.
There is nothing to take over, it would just be nice to not have to move the repository and notify the 700+ github forks of our repository to change the upstream.
If there's an easy way for them to recover all the accounts, do that, but if it starts taking months, it's time to fork.
Github is a rather different sort of entity...
You said that the 10 active member have full write access. But the admin can revoke that access at any time. These 10 members do not own the repo whatever the current permissions they have. It is like appointing a CEO with all powers to a company. He can do anything but he still doesn't own it.
Github runs repos/orgs for many people, business and big co. Ownership shouldn't be taken lightly there.
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.
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.
If you want someone to volunteer their time, you'd better treat him well.
> They also wanted to erase me from the history of the project. I was wiped out of the AUTHORS file.
If your characterizations are accurate they defrauded your users as well and in a major way. Many of your users wouldn't wish to continue using your software if its leadership got changed in a deceitful manner. If I'm reading this correctly they were pushed essentially a fork they haven't agreed to. Care to name names in case some users on HN fell pray to this fraud and possibly provide proof that what you allege did occur?
> I was wiped out of the AUTHORS file.
INAL. If they wiped your name from license text then you may also have a strong case for copyright infringement as many licenses require attribution.
And just to be sure, I think most if not all of the contributors would be happy to hear back and know if everything is alright. The lead was a very central and active part of the community until over a year ago.
Forking the project would kill the original, all servers are payed for and maintained by currently active contributors. We can not simply pull the plug and ask users to switch, if we do this this has to happen over a long time period until we know there are not many users left and there is no significant amount of traffic on the repository mirrors.
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).
Unfortunately, this is really one of the only ways to test how "open" your code is. You can have the entire source up on GitHub, but if the stack depends connecting to a blackbox server which you don't control, the whole thing quickly falls apart.
Redundancy and documentation are absolutely key for any kind of project, particularly open source.
If the remaining team fork Void, I shall probably continue to use it, nice system, easy to use and decent repositories.
Right now, a practical concern is the status of the update server and the various mirrors.
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.
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.
Solving the human problem with humans - trust someone else with the keys if you have a collaborative project
My apologies!
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.
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.
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.
This can be expensive and time-consuming in the US, at least.
I see no reason why a legal entity is needed here. Just set it up, keep all your credentials in a place that's accessible in a contingency, and move on with life.
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.
If the project has bandwidth you should consider doing fire drills for your important scenarios. Push a major version, upgrade infrastructure, etc
- Is he/she fine?
- Did something happen?
- Can we help?
That led me to conclude that nobody asked those things.
Let me put it this way, do you really think that, in the three months since this person disappeared, out of the dozens of people who have a far closer relationship to him than you do and a far greater personal stake in his wellbeing, that you are really the first person to consider whether something might have happened—to the point that you're comfortable to grandstand with a public indictment about how "sad" their behavior is?
You are the worst kind of person. Fuck you.
If it’s some kind of pissing contest could they potentially have legal exposure?
One common thread between a job, and contributing to free software, is that you are often collaborating with others and helping each other as a team.
There’s nothing inherently wrong from moving on from either one, but there is a vast spectrum of ways to make the transition - from productive and retaining friends, to bridge burning.
If there was some unforeseeable emergency in the PMs life he shouldn’t be criticized for that.
Let’s assume the positive, he’s probably a great guy, there’s a rational explanation, and he’ll end up making things right. The problem is sometimes other people might just be making dick moves, which really doesn’t help either party.
Too often it seems the case that the first I hear of a promising project is of its demise via Hacker News. Hopefully this isn't such a case, and the organisation can get back on its feet in spite of this.
https://github.com/WebTales/rubedo/issues/1477
It's got an organisation behind it, but not a word for almost a year now.
https://github.com/voidlinux/void-packages/pulse https://github.com/voidlinux/void-packages/graphs/commit-act...
The missing bits on the github side are permissions to add/change organization team members.
Ben Hsieh, owner of "react-native-fetch-blob", a native (iOS and Android) module for filesystem access and network requests fro React Native.
Does anybody know what happened to him?
I'm asking because I had "Contributor" status for his project on Github and was left with the pieces.