[Discussion / Official or semi-official policy of rubygems.org as well as rubygems] Taking over inactive projects

[rubyFeedback]

This issue request concerns itself with potentially old, outdated gems hosted at rubygems.org.

As a first introduction, consider having a look at the following project, as an example:

https://rubygems.org/gems/swing

The last update to it happened on the 16th June 2011.

We soon have 2025, so that means the project was not updated since about 14 years, give or take.

Its github page is also basically dead.

Now ... I am not saying that this project is 100% dead. Perhaps it is just in a super-low effort maintenance mode; perhaps the author still has made local modifications but did not consider publishing updates. Either way, though, I think we can somewhat safely conclude that in most situations, say 98%, such a project is dead.

Should rubygems.org become a graveyard for dead, inactive projects?

To some extent this can not be avoided, I get that. Many projects are hobby-projects, people come and go, so that is to be expected. And, even dead, inactive projects can be useful - you can download projects and tudy the code and use case, sometimes learn from that, adapt code, improve on it. So even an inactive project may be simply better than a non-existing project.

Having said this ... I believe it may be useful for rubygems.org but also the whole gem ecosystem and gem authors and developers, to consider conditions for allowing new projects to replace old projects.

There may be some level of mistrust, that is "can we trust this random account taking over this or that project", but I also believe that most users and developers on rubygems.org are actually not only real people, but also have genuine non-malicious interests, so I definitely think there should be some kind of project deprecation and take-over. Of course this process can be processed and put under certain constraints, but I would also like to remind everyone who is sceptical that new users can sign into rubygems.org, and we should not automatically assume that those wanting to take over a project's "namespace" to be worsely situated than any other random person creating a new account. So I think we should have a standardized, and clearly defined way to process taking over accounts.

I am not entirely certain of which conditions should be established, to allow taking over inactive, dead projects, but I will make some recommendations; perhaps others can build up on this and improve it.

The important thing is that rubygems.org eventually agrees to something similar - and specifies and documents such a process clearly, too.

So my list is just meant as a first starter.

(1) First, I think we need to add some kind of time frame for this that allows a namespace to be taken over. Note that I am not suggesting to delete the old project code; It can just be moved to a subdirectory or so, such as newly_maintained_projects/ or something like that.

What time frame should be used here?

I have no good suggestion that is not random. I believe it can not be too short, because otherwise people may be confused, so I would suggest at the minimum 5 years. But even 5 years may be too short, as sometimes people get distracted with other things - some of them become inactive, others become active again lateron. So, perhaps, 10 years should allow a project's namespace to become "freed" in principle. That is probably a somewhat good time span, better than 5 years.

IF these time spans seem too arbitrary, or if we may have too many cases where projects can be taken over after 10 years even though the original author may want to come back, then I think we can solve this to some extent by adding functionality that allows a gem author to mark his or her projects as "don't allow others to take over this namespace even if I am inactive". This should not be on by default, but if a gem author really wants to do so, he can do so, and then even +10 years of inactivity won't lead to others being able to take over the project. I am not necessarily suggesting this as such, mind you, and perhaps there should be an upper limit (15 years, 20 years), but I wanted to give some flexibility to those gem authors who may want to consider after a while; or optionally, can be contacted automatically via email (more on this in a moment). I know a very few projects which have had been published a long time ago, but then not been updated for many years, before they became active again. For instance, glimmer had its first release in 2008:

https://rubygems.org/gems/glimmer/versions?page=2

It became quite inactive, but since a few years it is again active. Of course we should also consider such use cases, but I believe that most projects actually become inactive - and then dead. I have no statistical data for this, just a gut feeling, but I think we could meta-analyse all published gems and then look at the percentage values of which projects are really inactive, most likely and then we probably conclude that only very few projects become active again.

That way, I think, we have now narrowed this down mostly to folks who are perpetually inactive, so let's think about (2) next. And, again - keep in mind that my numbers above are mostly arbitrary. It could be another number of years of wait just fine. I am more interested in establishing a *process for being able to take over "namespaces" again. (Hopefully ruby itself will have namespaces as additional identifier tags one day, as optional information, but I think we don't have to wait for this here for now; we can establish a process to take over projects at rubygems.org officially, too, irrespective over as to what upstream ruby does.)

(2) Alright - so, a given project is now considered "inactive" as by (1) and we can formalize means how to take over such an inactive, dead project.

What criteria should be used?

Well, spam accounts could be annoying, so I think we should limit this functionality to people who are not newcomers as such, but may have already established one or more gem that seems active and not too useless. I don't want to give a hard download number of gems (many scripts and bots download gems), but I think we could say that a single, well-written and well-maintained gem, may suffice for this criterium. That will probably have eliminated most bots and scripts. This may require a bit of manual look-up, but we can simplify this by checking on other gem's activity, and probably help as identifier here.

(Of course we can omit this, but I want to suggest ways to come to the conclusion that a given gem author could take over a gem. Having a reputation of maintaining ruby code in gems should be useful as one criterium.)

People may say "but this excludes newcomers!". Yes, that is true, and I am not saying that all newcomers are clueless. For this I may recommend that perhaps one or two emails could be exchanged between such a gem author and someone at rubygems.org. This could be handled as interface via rubygems.org itself; and probably require that someone is logged into his or her account at rubygems.org, so even newcomers could still end up as being considered for being able to take over a "namespace". But for the most part, I focus mostly on those who already have a reputation at rubygems.org (and perhaps also use a slight karma system at rubygems.org, e. g. like a badge system; people like cute badges after all; but should only have positive incentives here, e. g. encouragements. Anyway, that's a side comment, it is not so important).

Ideally filing for taking over a project can be done via a webinterface too, so I also suggest using rubygems.org as such an interface. I would also recommend that there is a way to upload the new gem too, so that people can have a sneak peek into it, to see whether that project may be "sufficiently useful" to take over a "namespace" as a new project. I am not saying this review should be too critical, mind you; mostly if it is approved, people just look at a few things, perhaps also give recommendations (optional) - the most important thing is NOT to be too selective (after all newcomers are not scrutizined either), but just to show whether this gem qualifies for replacing another, older project. Perhaps you can also look at how big an old project is, compared to a new project, e. g. to not accept "hello world" gems when the original gem did some real work, such as creating a new pdf file from scratch. Note that I also recommended that the old gem is still existing, so people could still download that old projects; for that I recommend both rubygems.org to allow this (perhaps add a href to point at the old gem download), and for the commandline gem to also accept a flag that does allows this. At any rate, this can be handled - as I wrote my focus is on a PROCESS that allows taking over old, abandoned projects.

Anyway - someone reviewed the new project and comes to the conclusion that this is worthy of replacing the old code. So, with a single button, that someone can approve that project.

(If you'd like to, you can also auto-approve after 3 to 6 months. People taking over inactive projects can probably wait for a little while, so that should not be a huge barrier, hence why I think 3 months are probably acceptable. Could be 1 or 2 months, too; I don't recommend a too long delay here, though, as people may become frustrated.)

(3) At any rate, the formalized process has now been completed, the old gem is moved to another location, a few notices are made (people should also see on the web-interface that there exist older gems with the same name) - and finally the new gem can be published. Here perhaps some grace period should be used that is also a control period, that is, "within 4 weeks a new gem has to be published, or the process is automatically reverted". That way if people for whatever reason become inactive during that time, we can revert to the old situation again.

One can say "but malicious people may publish code" - well, that is in theory possible with ANY gem out there. Even securing something via mandatory 2FA is not a 100% we-can-trust-this-account-now situation either. See xz-utils - the account appeared helpful when in reality it was not. So trust can never be 100% anyway and it is not reasonable to assume that rubygems.org can guarantee 100% trust or even insinuate 100% trust ever. People should still have a way to publish code they wrote. (And if it becomes too much of a hassle to do so on rubygems.org, they can possibly use some alternatives, such as github, gitlab etc... - all depending on how strict the rules are for publishing something on a given platform.)

---

Alright, that's it for a basic outline. Of course some details may be missing, some things need to be discussed - all of that is fine. The most important thing are not the individual steps described above, but more that rubygems.org comes up with some kind of official or semi-official way to take over abandoned gems. Note that we have a somewhat similar situation in the sense that some projects have a "maintainer wanted". So, the same spirit could be applied to old, abandoned gems too, to some extent. (Both should actually be fully documented; I have not checked whether the maintainers wanted is documented, but I vaguely remember that it was described somewhere at rubygems.org. By the way, as another side comment, I understand that rubygems.org is undergoing a visual overhaul. Perhaps someone can also look at the documentation and the organization of the documentation; some parts were nice, a few needed a little bit of update here and there. I can probably give some more feedback on that, but I think it would be easier if rubygems.org itself would come to the conclusion that the documentation should be improved, and then on the blog request for assistance there, so people are more encouraged to give feedback to documentation, say, within 3 months or so; I recommend a time limit to not drag it out too long and to finish a slight overhaul within such a time frame. At any rate, that was all I wanted to say - thank you for reading this issue request so far and potentially considering whether it may be useful to have some official policy in regards to old gems. A few gem names seem quite useful to have; for instance I renamed my own jruby-swing project to swing, because it is so easy to type. But I have had similar thoughts with regards to other projects, too. Remember that I refer ONLY to outdated, abandoned projects here, NOT active ones.)