11 ms·

Void Linux project leader has disappeared

172 points by MindTooth 8y ago

robin_reala 8y ago
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?
- otoburb 8y ago
  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 https://en.bitcoin.it/wiki/Timelock
- btown 8y ago
  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.
- verandaguy_alt 8y ago
  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.
  - walshemj 8y ago
    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.
- koolba 8y ago
  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.
  - sirmike_ 8y ago
    Is this the famous three is two, two is one and one is none?
- infogulch 8y ago
  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.
  - corobo 8y ago
    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
    - infogulch 8y ago
      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.
      - corobo 8y ago
        I think it was on my part that jumped to code when I read “conditions to meet” there then My apologies!
- blattimwind 8y ago
  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.
  - deleted 8y ago
    [deleted]
- MisterTea 8y ago
  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.
  - icebraining 8y ago
    The Software Freedom Conservancy might be able to help: https://sfconservancy.org/ https://sfconservancy.org/
- jdietrich 8y ago
  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.
  - LyndsySimon 8y ago
    > 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.
- bayindirh 8y ago
  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 https://ftp-master.debian.org/keys.html. See SSSS holders section.
- pm215 8y ago
  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.
  - pacaro 8y ago
    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
gruez 8y ago
>We contacted Github, but they declined any help to regain access to the organisation. >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.
- anilgulecha 8y ago
  > 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.
  - tannhaeuser 8y ago
    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.
    - 282883392 8y ago
      "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?
AdmiralAsshat 8y ago
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.
- wainstead 8y ago
  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/
WhitneyLand 8y ago
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?
- budu3 8y ago
  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.
- aeosynth 8y ago
  "Don't develop free software; if you ever decide to abandon a project, no one will ever hire you again."
  - WhitneyLand 8y ago
    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.
deleted 8y ago
[deleted]
mkobit 8y ago
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 https://news.ycombinator.com/item?id=12885549 [2]: https://github.com/spotbugs/spotbugs https://github.com/spotbugs/spotbugs
a-nikolaev 8y ago
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.
- gnode 8y ago
  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.
niftich 8y ago
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.
- mseebach 8y ago
  > 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).
- neuromantik8086 8y ago
  I mean, wasn't this basically the same issue that CentOS ran into several years back?
keithpeter 8y ago
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.
tmikaeld 8y ago
Reminds me of Rubedo: https://github.com/WebTales/rubedo/issues/1477 https://github.com/WebTales/rubedo/issues/1477 It's got an organisation behind it, but not a word for almost a year now.
- duncaen 8y ago
  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/pulse https://github.com/voidlinux/void-packages/graphs/commit-activity https://github.com/voidlinux/void-packages/graphs/commit-act... The missing bits on the github side are permissions to add/change organization team members.
  - tmikaeld 8y ago
    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.
ItsMe000001 8y ago
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 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.
simlevesque 8y ago
I'm kinda surprised that this does not happen more often.
tzs 8y ago
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.
deleted 8y ago
[deleted]
reflexing 8y ago
Arch Linux and OpenWrt projects have successfully used Software in the Public Interest http://spi-inc.org http://spi-inc.org to resolve their problems. I recommend it to use by Void too.
- duncaen 8y ago
  > 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.
  - reflexing 8y ago
    I think it'll be nice to mention what organisations are you in contact with currently.
znpy 8y ago
The sad things imho is that no one asked: - Is he/she fine? - Did something happen? - Can we help?
- craftyguy 8y ago
  Plenty of people are, or want to, but the point is that no one knows except the maintainer and he's not responding.
- carussell 8y ago
  That's a strong claim. What led you to conclude that nobody asked any of those things?
  - znpy 8y ago
    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.
    - carussell 8y ago
      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.
deleted 8y ago
[deleted]

172 points by MindTooth 8y ago

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?

otoburb 8y ago
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 https://en.bitcoin.it/wiki/Timelock
btown 8y ago
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.
verandaguy_alt 8y ago
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.
- walshemj 8y ago
  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.
koolba 8y ago
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.
- sirmike_ 8y ago
  Is this the famous three is two, two is one and one is none?
infogulch 8y ago
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.
- corobo 8y ago
  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
  - infogulch 8y ago
    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.
    - corobo 8y ago
      I think it was on my part that jumped to code when I read “conditions to meet” there then My apologies!
blattimwind 8y ago
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.
- deleted 8y ago
  [deleted]
MisterTea 8y ago
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.
- icebraining 8y ago
  The Software Freedom Conservancy might be able to help: https://sfconservancy.org/ https://sfconservancy.org/
jdietrich 8y ago
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.
- LyndsySimon 8y ago
  > 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.
bayindirh 8y ago
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 https://ftp-master.debian.org/keys.html. See SSSS holders section.
pm215 8y ago
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.
- pacaro 8y ago
  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

gruez 8y ago

>We contacted Github, but they declined any help to regain access to the organisation. >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.

anilgulecha 8y ago
> 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.
- tannhaeuser 8y ago
  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.
  - 282883392 8y ago
    "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?

AdmiralAsshat 8y ago

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.

wainstead 8y ago
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/

WhitneyLand 8y ago

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?

budu3 8y ago
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.
aeosynth 8y ago
"Don't develop free software; if you ever decide to abandon a project, no one will ever hire you again."
- WhitneyLand 8y ago
  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.

deleted 8y ago

[deleted]

mkobit 8y ago

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 https://news.ycombinator.com/item?id=12885549 [2]: https://github.com/spotbugs/spotbugs https://github.com/spotbugs/spotbugs

a-nikolaev 8y ago

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.

gnode 8y ago
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.

niftich 8y ago

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.

mseebach 8y ago
> 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).
neuromantik8086 8y ago
I mean, wasn't this basically the same issue that CentOS ran into several years back?

keithpeter 8y ago

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.

tmikaeld 8y ago

Reminds me of Rubedo: https://github.com/WebTales/rubedo/issues/1477 https://github.com/WebTales/rubedo/issues/1477 It's got an organisation behind it, but not a word for almost a year now.

duncaen 8y ago
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/pulse https://github.com/voidlinux/void-packages/graphs/commit-activity https://github.com/voidlinux/void-packages/graphs/commit-act... The missing bits on the github side are permissions to add/change organization team members.
- tmikaeld 8y ago
  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.

ItsMe000001 8y ago

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

simlevesque 8y ago

I'm kinda surprised that this does not happen more often.

tzs 8y ago

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.

deleted 8y ago

[deleted]

reflexing 8y ago

Arch Linux and OpenWrt projects have successfully used Software in the Public Interest http://spi-inc.org http://spi-inc.org to resolve their problems. I recommend it to use by Void too.

duncaen 8y ago
> 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.
- reflexing 8y ago
  I think it'll be nice to mention what organisations are you in contact with currently.

znpy 8y ago

The sad things imho is that no one asked: - Is he/she fine? - Did something happen? - Can we help?

craftyguy 8y ago
Plenty of people are, or want to, but the point is that no one knows except the maintainer and he's not responding.
carussell 8y ago
That's a strong claim. What led you to conclude that nobody asked any of those things?
- znpy 8y ago
  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.
  - carussell 8y ago
    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.

deleted 8y ago

[deleted]