Feature: Claim Abandoned Projects
360disrupt opened this issue · 39 comments
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.
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:
- Assuming they list their email publicly, have a contact form on a personal website, have a Twitter linked to their profile, or similar, ask them through that means. (This is surprisingly effective and is usually the first thing to try.)
- File an issue and wait a reasonable amount of time first to have the previous maintainer transfer ownership to you. (This could work, as long as you have an appropriate title.)
But after these fail, you could just ask them at support@github.com. You'd just want to point to the radio silence as evidence for the project being completely abandoned and a user being basically inaccessible. They may reach out initially themselves to try to confirm the radio silence themselves, particularly if you couldn't do step 1, but they could potentially help you here.
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.
- or define a fork as the main fork.
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:
- It takes as argument the URL to a github repo, lets say
https://github.com/someUserX/projectY/. - It creates a new GitHub organization called
projectY, and therein forks the original repo; so we will gethttps://github.com/projectY/projectY/. - It adds the original author and all authors of pull requests (already merged and still open) as organization administrators.
- It re-creates all (open) pull-requests from the original repo in the new fork.
- ... and does the same with the (open) issues.
- If github does not do this anyway, it notifies all the admins of the new repo.
- it creates a last pull request to the old repo, including a notice and link to the new repo on top of the README
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
this SO question "How to get a list of all forks of a GitHub repo on Linux?".
I did not check everything, but would imagine that it is possible to do as a script external to github, using the GitHub API.
somebody would have to code it.
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.
It was also suggested exactly as you say: https://github.community/t/a-suggestion-addressing-the-abandoned-repositoreis/144264
however, Github just doesn't care. If it ever did, it would have given some relief to thousands of devs a long ago.
however, 2020 and left without care.
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.
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.
You can now appoint successors which will have your repositories transferred over to them after your death.
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.
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.
and to me, open source projects belong to the community, not their original creators. this is what the creators declared themselves by declaring them open source. why should we care so much about protecting their right of control over the project?
as long as there is an option to reclaim the control, i care little if my projects are taken away from me, if they are given to the most active contributors, or even to whoever wants them, as long as the control given to the new maintainer(s) is again not written into stone.
Also, the more we have such mechanisms, and the more they are being used, the more we will see issues such as that with npm, or mvn or whatever rights, or further issues, turn up, and we can go about finding solutions for those.
I understood it so, that there would be many ways of remain the owner of a project, not just committing.
why should we care so much about protecting their right of control over the project?
Because they often have a software license declaring who owns the code.
as long as there is an option to reclaim the control, i care little if my projects are taken away from me, if they are given to the most active contributors, or even to whoever wants them, as long as the control given to the new maintainer(s) is again not written into stone.
why should we care so much about protecting their right of control over the project?
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?
as long as there is an option to reclaim the control, i care little if my projects are taken away from me, if they are given to the most active contributors, or even to whoever wants them, as long as the control given to the new maintainer(s) is again not written into stone.
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?
As long as the project is open source, I can not understand this as a valid argument.. can you explain?
The LICENSE file declares someone as the maintainer for some code. For GitHub to have a policy that automatically breaks that license by transferring it away from the original owner would be breaking copyright.
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?
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.
The
LICENSEfile declares someone as the maintainer for some code. For GitHub to have a policy that automatically breaks that license by transferring it away from the original owner would be breaking copyright.
ahhh :/
so what about giving additional access to others, not removing it from the original owner?
so what about giving additional access to others, not removing it from the original owner?
That would be forking.
I mean, giving access to the original repo. so others can change the code available under the original URL.
That would of course still come with the issue of the malicious takeover, but not the copyright one.
The
LICENSEfile declares someone as the maintainer for some code. For GitHub to have a policy that automatically breaks that license by transferring it away from the original owner would be breaking copyright.
@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 LICENSE* file] & otherwise acting according to that file's terms is what's required.
@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.