Void Linux project leader has disappeared(voidlinux.eu)
voidlinux.eu
Void Linux project leader has disappeared
https://www.voidlinux.eu/news/2018/05/serious-issues.html
100 comments
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.
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.
This is definitely a horrifying story, and I feel terrible that you had to go through this! That being said, I'm not sure that open source software is what's to blame here; it sounds more like Sourceforge (along with the nasty people who stole your project, of course) was the main issue; I think the lesson that I and others can learn from is not that open source allows theft, but that relying on a single external service (Github, Sourceforge, etc.) for everything can lead to a loss of control.
This all seems incredible.
> 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.
> 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.
I left that out in my post because I've moved on. I may seem a bit triggered, but that is because reading about this Void project possibly doing the same thing to someone else right here in such public view just brought back strong memories. What the void guys are doing is clearly wrong, they should fork with another name, with a separate website, github, mailing list, etc. If the users want to follow them they will. Performing a takeover, even if the guy really is missing, is underhanded. If you see any project doing this, it should set off alarm bells. And, the open source community as a whole should start digging into some of these projects and see if proper attribution is being given. Because, I can guarantee there's a percent of those of us who were erased for political or personal reasons. I made peace with my exit, others might still be clenching their fists over it.
I'm sorry to hear about your experience with this, but this is simply not the case here.
There is a big blog post about it, no one is trying to boot anyone out.
Yes the article does not mention names, but its easy to find out and verify commit histories and social media accounts.
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.
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.
Plus, of course, as you have pointed out, you have a non-trivial amount of goodwill built up for the name "void".
Sticking to the proprietary side of the fence makes a lot of sense for you. Steve Jobs is among the many who would tell you that you could never get ousted from your own company as long as it creates proprietary products.
They may have tossed him out of the company but he still gets credit for having created it, and saving it again later. These guys wiped me from open source history. When you aren't making money, credit is one of the few perks. But, I get your point.
If you quit, the story ends there. If you mount a comeback, you can re-rewrite history and be the creator and savior of your project.
Sure you can get fired, but at least you got paid for your work.
If you want someone to volunteer their time, you'd better treat him well.
If you want someone to volunteer their time, you'd better treat him well.
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.
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.
Honestly, this is a regular part of open source projects. Void says they "really like the brand" so they don't want to fork, but it's better to not have these kind of attachments and be free to just start over.
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.
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.
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.
I understand your frustration. But it'll really disturbing to see Github transfer ownership without the real owner approval.
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.
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.
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...
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.
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 hope you're kidding. GitHub has no legal basis for transferring ownership, and it would be a publicity fiasco if they did. A "reasonable case to ownership" at best would allow to bring the case to court.
They don't need legal basis, it's their platform. You don't "own" an account. Plus, they do warn you:
"Account names may not be inactively held for future use. (...) Inactive accounts may be renamed or removed by GitHub staff at their discretion."
https://help.github.com/articles/name-squatting-policy/
"Account names may not be inactively held for future use. (...) Inactive accounts may be renamed or removed by GitHub staff at their discretion."
https://help.github.com/articles/name-squatting-policy/
"Github transfers organizational ownership after owner becomes inactive"
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?
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?
Or alternatively, github could rename this org since the owner is no longer in contact and then let the currently active group have the name.
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.
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.
IANAL, but apart from a private entity having such power being problematic (to say the least) who's going to put stuff on GitHub if it can be gamed to take away your control?
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.
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.
What's with all the legal bluster in your comments here? Not only do the liabilities you're trying to conjure up not exist, but this is not even the first occurrence of something like this happening with GitHub. They have a documented policy for freeing up inactive names. (Spoiler alert: it's allowed, and they've done it.)
I would agree, even in the case of a documented death, the heirs/estate would be the one to decide a transfer of ownership and to whom.
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.
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.
so you can take over a project simply because the real owner is away?
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.
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.
The development is still continuing, there are 10+ contributors with write access to all repositories in the organization.
The only missing bit is permissions to change/add new team members to the organization.
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.
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.
I do not see the danger of abuse. This is not about a takeover by someone entirely unrelated to the organization and repositories. This is about transferring ownership of an established open source organization to those who already have write-access to all repositories and are in fact now running the project. This seems fair when the original owner can no longer be contacted for months. Why should the organization be forced to fork because of this?
"Of course" is jumping the gun here
Getting your projects transferred away because you can't (or choose not to) answer emails for a period of time is hostile.
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.
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.
Then you shouldn't use GH: https://help.github.com/articles/name-squatting-policy/
How is that related? You can easily be active on a GitHub account and still check your email infrequently.
Fair enough, though always_good is replying to a situation where the user is neither.
But that's a policy on name-squatting. Something that doesn't apply here. The creator isn't squatting on the name they created and I would be surprised if Github would commute the name at their discretion unless considerable time passed, something I don't necessarily have a problem with on a long enough time scale. Though there there's a point on that time scale where I'd expect the new owners to just consider a new name.
> Inactive accounts may be renamed or removed by GitHub staff at their discretion.
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.
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.
Good policy. Then I can just watch for people to go on vacation via their Instagram, and while they're out I'll contact GitHub and say "Hey this person is unreachable! Give me control of their projects!"
Brilliant.
Brilliant.
I think that what anilgulecha meant by ownership is that there are probably quite a few committers. So they are not just some random people taken from the street. It's not so clear cut, but there is something to it. It would not be good for your contributors to take the carpet from under your feet, but at the same time part of the project already belongs to them.
Those details don't really matter, because the point it's not realistic to expect a company with so many projects and users like GitHub to be making those kind of individual calls.
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.
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.
> it's not realistic to expect a company with so many projects and users like GitHub to be making those kind of individual calls
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.
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.
Especially because they have so many projects and users they are expected to make individual calls. GitHub is the home for many open source projects and should care for the needs of their community.
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.
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.
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
> 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
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?
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?
This is an interesting legal question. Intellectual property is part of a person's estate, but intellectual property isn't what's important here, rather control of a GitHub account (and management of permissions it controls). Facebook and Google for instance do not allow descendants to simply inherit accounts, and provide some controls for users to specify wishes for their post-mortem account management. Github seems not to have any policy on death.
They wouldn't be transferring control of IP. The original author or their estate maintain ownership of the copyright. They would just be transferring control of the GH account.
The only potential problem is if the account has any private repositories, but GH could archive and/or delete those beforehand.
The only potential problem is if the account has any private repositories, but GH could archive and/or delete those beforehand.
What is this if not IP?
The right to exercise control over an asset is common for normal property at least.
Yes, but the property here is control over the legal rights of the code, not the Github account.
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.
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.
When a friend of mine passed away, GitHub changed his account into an org for us, so we could use it for a memorial.
Luckily, one of our group of friends worked for GitHub and helped facilitate the transfer. Not sure how we would have done it otherwise.
Luckily, one of our group of friends worked for GitHub and helped facilitate the transfer. Not sure how we would have done it otherwise.
If the project can reach said person, why would Github/Freenode be able to?
*can't
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.
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. 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).
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?
We had a similar issue with the Korora Project. Founder stepped down to focus on life for a bit, main developer went AWOL. Between the two, all build server access was cut off to the remaining members.
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.
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.
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/
https://sourceforge.net/projects/phpwiki/
Well I hope that Mr Pardines is OK and well and perhaps just having an extended break. I remember the shock of Ian Murdock's death (founder of Debian although long dissociated from Debian at the time of his death).
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.
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.
Sounds similar to the FindBugs project (discussed here [1]). The result from that episode was a fork into SpotBugs [2].
[1]: https://news.ycombinator.com/item?id=12885549
[2]: https://github.com/spotbugs/spotbugs
[1]: https://news.ycombinator.com/item?id=12885549
[2]: https://github.com/spotbugs/spotbugs
What reasonable measures could have been put in place that would both avoid this bus factor and balance the other way against the risk of a project running into problems from split management?
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.
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.
The Software Freedom Conservancy might be able to help: https://sfconservancy.org/
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.
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.
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.
[deleted]
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
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
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.
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.
The way we used to do it in our bit of BT was for passwords to be limited and to be written down put in an envelope and stored in the fire safe.
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.
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.
> Register as a (non-profit) corporation
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.
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.
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.
You first say it's a human problem rather than tech then go on to suggest solving it with tech!
Solving the human problem with humans - trust someone else with the keys if you have a collaborative project
Solving the human problem with humans - trust someone else with the keys if you have a collaborative project
Writing a document explaining how a customer service rep at some company should go about transferring ownership of your account is not solving the problem with tech. I listed things that the document should include that a human can execute, not an automated system.
I think it was on my part that jumped to code when I read “conditions to meet” there then
My apologies!
My apologies!
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.
This is a little like backups. If you don’t test restore, then the value of your backups is low.
If the project has bandwidth you should consider doing fire drills for your important scenarios. Push a major version, upgrade infrastructure, etc
If the project has bandwidth you should consider doing fire drills for your important scenarios. Push a major version, upgrade infrastructure, etc
Arch Linux and OpenWrt projects have successfully used Software in the Public Interest http://spi-inc.org to resolve their problems. I recommend it to use by Void too.
The sad things imho is that no one asked:
- Is he/she fine?
- Did something happen?
- Can we help?
- Is he/she fine?
- Did something happen?
- Can we help?
That's a strong claim. What led you to conclude that nobody asked any of those things?
At the time of writing that comment, no one in this thread had asked those question. Also, on the page linked, the author was not asking those question.
That led me to conclude that nobody asked those things.
That led me to conclude that nobody asked those things.
After the leader of a substantial project disappears, in the ~20 minutes of incidental contact you have with the issue after having only just been introduced to it having not stumbled over a particular discussion out of sheer dumb fucking luck, you conclude that means the discussion never occurred. Do you really think that's a sound conclusion?
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.
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.
Plenty of people are, or want to, but the point is that no one knows except the maintainer and he's not responding.
I hope the PM is ok. But if they haven’t suffered some kind of severe illness how do they even apply for a job in the future if this becomes well known?
If it’s some kind of pissing contest could they potentially have legal exposure?
If it’s some kind of pissing contest could they potentially have legal exposure?
Yep. On a human level, I really hope the PM is okay. Maybe open source communities can setup a way for core team members to check in on each other on personal level.
"Don't develop free software; if you ever decide to abandon a project, no one will ever hire you again."
Not even close I think.
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.
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.
Project hosting sites should perhaps have a built in mechanism to make it easier to deal with these situations. Perhaps a dead man's switch that if tripped allows those with write access to the project to appoint a temporary replacement leader. If the missing leader returns he can reclaim leadership. If he does not return, then after a certain time has passed, the temporary leader becomes the permanent leader.
Wishing the best resolution to this situation. Have been a Void Linux user since last May and enjoying it lots, the best Linux distro by far.
This is the first I've ever heard of it, and it seems like the distro that'd suit me well.
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.
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.
Reminds me of Rubedo:
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/WebTales/rubedo/issues/1477
It's got an organisation behind it, but not a word for almost a year now.
Its differnet, we have 10+ team members with full write access to the repository and development is still ongoing.
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.
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.
Of course, I'm absolutely not saying that it's the same situation - it just reminded me about how bad it can actually become if you can't replace the main developers of a project.
[deleted]
I'm kinda surprised that this does not happen more often.
I would like to take this opportunity and ask about another disappearance of a project leader, even if it's only a minor project:
Ben Hsieh, owner of "react-native-fetch-blob", a native (iOS and Android) module for filesystem access and network requests fro React Native.
https://github.com/wkh237
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.
Ben Hsieh, owner of "react-native-fetch-blob", a native (iOS and Android) module for filesystem access and network requests fro React Native.
https://github.com/wkh237
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.
[deleted]
[deleted]
>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.