-
Notifications
You must be signed in to change notification settings - Fork 129
Feature: Claim Abandoned Projects #1385
Comments
Interesting idea, I've had this issue with term.js -> xterm.js and pty.js -> node-pty, the first had a PR merged which directed people to the new maintained repo but not the latter. I definitely don't think claiming a repo is a good idea as it's not yours to claim, but maybe a message pointing to another repository (not necessarily a linked fork) that the maintainer can suppress if they want? |
How about a button the repository owner can click to mark the repo as abandoned that would show an option on the repo home page to let users request claim to it. This would send a notification to the owner, to which they can accept or reject the transfer of ownership to said user. |
Is there currently any way to claim an abandoned project through GitHub support or similar? |
@quassy I'd say that's a question for GitHub Support, and they'd almost certainly want you to try to reach out to them first - contacting them should be a last resort:
But after these fail, you could just ask them at Edit: Fix a typo |
I doubt just any open-source licensing is enough to vacate an author's rights to their identity or source code, so OP's option 1 may be very problematic. GitHub may be concerned re: that legal can of worms.… |
@TPS Some licenses could be interpreted as such, particularly permissive licenses like the BSD-derived licenses. But no matter the scenario, I feel this should be a support-only system similar to how npm, CPAN, and other similar package registries (ones that don't do reverse domain package names) handle requests to take over particular names. |
I think this is most likely the strategy we would aim for and I imagine we will use metrics to show whenever a fork is more active such that users can always find these forks. |
What I would consider the optimal solution: Write a "script"/some code, that uses the github API to do the following:
|
An abandonned project is like a project that has no more commit since years and may be many pull requests |
How this discussion ended up? |
a small part (mostly just 1.) of the solution I outlined in my comment above can be found at I did not check everything, but would imagine that it is possible to do as a script external to github, using the GitHub API. |
The solution suggested in #562 might solve this. |
This is becoming more and more of an issue every single day. Perhaps the top 3 contributors could be offered to take over or become an admin automatically after 28 days of abandonment (unless explicitly turned off, then this jumps to 90 days). There are so many good abandoned projects out here that just end in dozens of network forks without rime or reason and no easy way to update package names for distribution on popular networks (pypy) etc. |
@expresspotato Totally agree! that is the perfect solution. however, Github just doesn't care. If it ever did, it would have given some relief to thousands of devs a long ago. |
You can now appoint successors which will have your repositories transferred over to them after your death. |
@Richienb I guess that helps out with this situation. In the event that you haven't died, you just have to fake your death and obtain a legitimate death certificate so that GitHub will hopefully transfer the project to the person requesting it. |
these last comments doesnt make any sense. We talk here about projects, where no-one knows if author just left programming that project or is dead. The point is that S/HE had not a will to maintain or transfer the project and is unreachable. |
My comment was clearly sarcastic. Its appointed successors are obviously not a solution to this problem. |
This still doesn't really solve anything with these tons of open source projects that are hosted on github and the owner disappears (kidnapping, death, doesn't care, made it rich, who knows). A better solution would be to put the project up for grabs with other contributors after say 6 months of no logins. The original owner can always claim it back. I always see tons of integrations to old Python libraries that are no longer being maintained and it's pain to rename them and post them back up... These projects usually have tons of waiting pull requests, issues open or closed and irritate millions of people in the process. |
6 months isn't really a good enough barometer on its own - there exist projects that just don't change enough to meet that bar (especially among smaller libraries like https://github.com/micromatch/nanomatch that are genuinely that stable). But I do agree that it might be worth figuring out something. |
Perhaps it could be setup as an optin mechanism? E.g., @github could e-mail to the (source) OSS repo owner(s) every year, asking them to actively commit to repo maintenance. If they don't respond (or choose to respond in the negative) after a reasonable time period & additional contact, declare repo abandoned & offer ownership to most active current forkers. |
@sindresorhus wouldn't want to commit to every one of his thousand repositories every year to avoid them being taken. Even still, this doesn't come with npm rights so the repo on it's own is pretty useless. |
@Richienb Mine was the 1st-pass at a solution, &, of course, should be tweaked. In your example, how does 1 maintain 1k repos, anyway, unless people in an org would? Also, npm is a GitHub property now, so I'm sure that detail could be fixed. |
According to an interview, this is because most modules are mostly done on the first commit and maintenance is provided by the community when they need it.
|
in the end, however much details of when and how ownership changes and how it can change back we define, it will remain an issue between "private ownership" and "community ownership", in a simplified, broad sense. |
I understood it so, that there would be many ways of remain the owner of a project, not just committing. |
Because they often have a software license declaring who owns the code.
|
As long as the project is open source, I can not understand this as a valid argument.. can you explain?
That surely is a valid argument (malicious takeover). Can this be achieved though, by just taking over control of the repo, without getting any private keys or access to emails? |
The
That is almost exactly what happened in that case. |
I think the least intrusive way for this to be done is to just list popular forks and allow users to pick which one they want to use themselves without replacing the original one. |
ahhh :/ |
That would be forking. |
I mean, giving access to the original repo. so others can change the code available under the original URL. |
@Richienb IANAL, but afaict, copyright has to do with code ownership, not the repo itself, nor who maintains that code. Also afaik, for any (F)OSS license on, e.g., https://choosealicense.com/, @ most, simply attributing code authors' copyright from date to date, again e.g. "©️@TPS 2015-2019" [or whatever you have set in your |
@TPS Code ownership is an important thing to take into account as a maintainer. You don't have to think much about it when you own the copyright, but you certainly do when it's someone else's copyright. And this impacts code contributions, code usage, among other things. (If you start maintaining GPL code base, you can't give people permission to incorporate it in closed-source products, even non-commercial ones. Only the copyright holder can do that.) This might be alleviable to a degree by the owner transferring it to something like "$PROJECT creators", "$PROJECT developers", or something else to that effect that incorporates an open-ended group of people they may or may not be in, but this of course still takes explicit action to do, and only goes to show the complexities of copyright. So yes, it has relevance here. Obligatory disclosure: I am not a lawyer and this is not legal advice. This is purely my own opinion based on my own personal research, my prior experience as an open source maintainer in such a situation, and my own current understanding of the law. If you want legal advice, go consult with your attorney. |
@isiahmeadows You make my point: When it comes to open-source software code copyright, the terms of the law & the governing license is what matters, which generally do not cover where the code is hosted nor who has privileges in that repository — that's covered in the licensing between the repo hosting provider (GitHub, Inc, in these cases) & each user upon signup/subscribing. Again, IANAL, but I don't think GitHub cedes inviolate ownership of a GitHub repo (which they host themselves, right?) to anyone but themselves. Or did anyone see something else in, e.g., https://docs.github.com/en/github/site-policy/github-terms-of-service? |
I was just making the point that copyright isn't irrelevant, and that there are in fact logistics to address around transferring repo ownership that aren't just pure giving someone else admin access. There also of course the issue of malicious takeovers as well, something that has proven itself to be able to happen in the past. |
Problem:
Abandoned projects can get forked but it loses the central place
Solution:
If a project is abandoned and licensed open source it should be able to be claimed by the community. E.g. last commit > x days + x people voted with a button "this repo has been abandoned" should open up a function to either
claim this repository as the new maintainer
or define a fork as the main fork.
Otherwise, everybody forks it to solve their most important issues but the project loses its centralized place and dies. Eventually, somebody starts a new repo with a similar name which is hard to find via google.
Example:
E.g. aheckmann/gridfs-stream#128 (comment)
used by a lot of people and everybody just forking it to fix their particular problem.
The text was updated successfully, but these errors were encountered: