Well this prevents my plan of "I'm never gonna die because I have to maintain this OSS project".
In the spirit of other legacy / succession features, is there an opposite option to prefer the account vanishes from the platform entirely?
This also reminds me of Debian WNPP listing where you can see requests of succession because of age/health/disinterest/etc. https://www.debian.org/devel/wnpp/
> In the spirit of other legacy / succession features, is there an opposite option to prefer the account vanishes from the platform entirely?
Earlier this year maintainer of MIT licensed zinit* somewhat disappeared from the internet. Issues weren't being addressed/replied to etc. This of course is fine, they're not expected to provide support or continue maintaining the project if they don't want to. However, in the past few months, the maintainer decided to remove all repos and organisations relating to zinit, causing everyone's profiles to suddenly stop working. People weren't able to initialise their dot files on a new machines. There was no backups nothing. I happened to do update my dot files to the latest version of all the plugins hours after the deletion of the repos, and my whole profile completely broke. I sat there for a good few hours trying to recover. Luckily git is graceful.
Unless there's a method to archive your public OSS repos, removing your profile means all your code will be gone too. At best that's an inconvenience to hobbyists, and at worst, it can break production systems.
In the case of zinit, luckily the community came together and were able to scrape back the latest code based on the local git repos of individuals. I think there are still some repos that have to be recovered.
* zinit is a zsh profile manager, allows for managing binaries, plugins, and other things.
I assume you don't mean these production systems are depending on reliable access to code in a third-party Github repo because that's fairly easily remedied by at least forking the repo once that repo becomes a dependency (not to mention potentially very dangerous in case of malicious changes), but I'm curious what the scenario you're referring to here is.
I assume you don't mean these production systems are depending on reliable access to code in a third-party Github repo
When are people going to stop feigning surprise at this? Being completely unable to deploy a new server just because pypi/npm/github etc. is down has been best practice and standard operating procedure for years now.
Keeping a complete audited mirror of everything needed to deploy your product and only pulling code for production from machines you have complete control over is so 2005.
The same happened to me and I decided to switch to antibody for plugin management. I no longer trust the maintainer as a viable option after what the author said on an earlier thread:
"I'm the projects' owner and I can delete them anytime I want. And that just happened – I've had some say major doubts whether I want the time-consuming projects to go on, so I've deleted them"
I didnt know that the community took up maintenance though. I will have to check it out.
It's not really the responsibility of solo OSS repo owners to resolve this.
It's likely no-one paid us for the code, we did it for a variety of reasons (itch to scratch, thought it was cool, intellectual interest, etc) but few to none of those reasons was to create an ongoing responsibility over the code.
For my repos, I chose a permissive licence... either MIT, BSD 3 clause, or even AGPL. You can fork away to your hearts content, and I don't have to be involved in that so long as you respect the licence it came under.
This does mean that if you are one of the tens of thousands of projects that imported code I wrote (or downstream from that the hundreds of thousands of websites that use those projects)... then yeah, you've got to fork and update your references, etc. And I am 100% OK with others (even a huge number of people) having to do such a piece of work... because no-one paid me to be responsible for the code I gave to everyone else.
This likely comes off as harsh, but I maintain a few repos that are widely used and the only way to make this enjoyable is to not accept the responsibility for things that I don't have to accept. I wrote the code, you can use the code, whilst I'm alive and using the code I'll maintain the code... but otherwise the licenses make you responsible for your own use of the code, I am not obligated to do more than I've done. The code can freeze in time and fade away, if others care then they can step up... if they care now, they can become co-maintainers or they can pay for the code so I choose to take responsibility for continuity.
I agree in general, but doing something like adding the project to https://www.codeshelter.co/ so someone else can pick it up if you're no longer interested in it doesn't seem like such a huge hassle, no?
I definitely agree that we shouldn't demand things from maintainers, though.
Sadly, the scenario that the successor feature is intended to prevent has very much become reality in the past. The creator of Luacheck (Peter Melnichenko) passed away a couple of years ago, and ever since then the GitHub repository has been in a state of limbo. Multiple unofficial forks have come and gone, but Peter's is still the first result on Google if you search "luacheck". It isn't even possible to change the README or pin an issue to get people's attention about the primary fork; to this day people are still posting issues to the old repo.
And Luacheck is "the" Lua static analysis tool that pretty much everyone uses, so it's a very significant problem.
In the spirit of other legacy / succession features, is there an opposite option to prefer the account vanishes from the platform entirely?
This also reminds me of Debian WNPP listing where you can see requests of succession because of age/health/disinterest/etc. https://www.debian.org/devel/wnpp/