Prevent orphaned packages

[Satyam]

Recently I had been involved in a change of ownership of a package because the owner had been AWOL for half a year (which in this pandemic year is significant) and did not answer nor showed any activity here and elsewhere. (Fortunately, he is back.)

I was wondering if there could be a way to prevent packages from being orphaned.

Clearly not all packages deserve being preserved, but those that show a healthy number of weekly downloads (threshold to be determined) are a good candidate. If they further show an active community (a good number of PRs or issues in GitHub).

If any such package has a single owner and no collaborators, it might be a good idea for a bot to send the owner of that package an invitation to get some help by adding collaborators.

With the combined information about user activity that can be collected from both npm and GitHub, it should be easy to identify packages at risk of becoming orphans if the single owner shows no activity for a while.

Due to the inactivity in maintaining the package I mentioned above, several forks had been made on GitHub whose only purpose seemed to have been to update the dependencies, some of which were deprecated or soon to be. All this creates unnecessary noise instead of concentrating the community effort on a single package.

Over time, I've seen unattended packages being supplanted by other packages with similar names and no clear improvements over the original, just a way for the community to get going somehow. Once again, this dilutes the strength of the community and trashes the registry with clones nobody really needs, had the original been kept alive.

And should the single owner remain absent for a while, the bot itself could also send an invitation to the contributors to the package to a discussion of what to do with it and initiate a transfer of ownership. The invitation could go to those who:

• contributed PRs
• forked it
• answered issues of other developers

The main and most immediate action would be to invite the owners of valuable single-owner packages to enable at least 1 other active collaborator, a backup if you will, just in case.

Thanks

[MylesBorins]

Hey @Satyam

Thanks for bringing this up. It definitely is less than ideal what we currently have. I know that folks do have some mixed feelings about what should happened with "abandoned packages". For example, even if package has a large amount of adoption handing over publish writes to another party is not always the best decision to make from a security perspective (even with the permission of the original owner). Often forking a project can be the appropriate solution.

There is also a high level question about what the role of npm should be here. Should we actively be trying to ensure highly adopted packages are well maintained? TBH I don't think the answer to this question is yes, we don't have the resources to staff projects and I personally don't think that in our role as stewards we should be meddling in the day to day operations of the projects we host. Our goal should be making a registry with high availability and having clear and consistent policies about how to handle these types of situations. We have an item on the roadmap next quarter to explore our npm/roadmap#28

While this is imho out of scope for npm, I do know that the OpenJS foundation, and specifically the Node.js project, has a package-maintenance team specifically looking into this problem space. To me, this is a much more appropriate place for folks to be discussing and thinking about how to handle these kinds of problems that affect the community at large.

I'm going to mark this as answered but please feel free to keep the conversation going and ask any questions you might havel.

[Satyam]

There is a capability you (npm + GitHub) has that the document you mention does not address, nor it can. You can check the last access of the owner even if there is no trace of any modification to what is available on the public API: replies to issues, merging PRs and such that the document you refer to mentions. That is just an example. I would assume you can guess the level of activity of any user without breaching the privacy of the user. Just check whether the user logged in recently.
That was the idea anyway, but I'm fine with this, no need to re-open the issue.

[Satyam]

I think that what I mean to determine could be called fragility. A package might be very well maintained by its owner and have a high score on that, but if the owner is the only maintainer, that maintainability score is fragile if that single maintainer falls under the wheels of a tram, or gored by a wild pig (we do have both nearby, so yes, I'm kidding but not imagining things).

The fragility score would be inversely proportional to the number of active maintainers, active being measured somehow in the number of weeks since the last contribution of each maintainer, the fewer the weeks, the more active. Sharing the maintenance with a second person would make the package less significantly fragile (half as much), and might keep its maintainability score even if each puts less effort into it.

Announcing a future fragility score might be a good inducement to owners of packages to start looking for collaborators, thus preventing, quite in advance, a package from being orphaned.

I usually find that naming a thing allows me to get a handle on an otherwise vague concept. In this case fragility is the word that describes it.

[ljharb]

I maintain almost 300 packages, and very few of them have more than one maintainer. The reason for that is not a lack of effort on my part, but that there simply aren’t that many people who simultaneously have the motivation, desire to learn and/or experience, the confidence, and most importantly, are in the right place at the right time to make themselves known.

if you have a solution to find these people and connect them to single-maintainer projects, i would dearly love to hear about it - but penalizing me and my projects isn’t going to achieve it, I’m pretty certain.

[Satyam]

And I congratulate you for that feat, as Romans congratulated their generals with a Roman Triumph, the famous parade where the general, in his chariot, had a slave holding a laurel crown above his head who every now and then whispered to his ear "remember you are mortal".

Assigning a score to the problem does not create the problem. The problem does exists, I am suggesting a way to measure it.

I didn't invent the pandemic but it is here. Has npm seen an increase in requests to transfer ownership? I know I started thinking about this issue because of a package owner who had gone AWOL just 6 months ago, no activity on any of his repositories, no activity on his twitter or facebook accounts in that same period. Fortunately the guy came back again (didn't ask, don't want to intrude) but the experience taught me something: I'd like to know if the package I am using does have a single weak, fragile, link.

It might not necessarily be catastrophic, I live by the beach in the Mediterranean, I left some unfinished business behind. I am 65, it was bound to happen. It is only fair that you can enjoy the same privilege even younger, if you so chose. I just want to know how that impacts the packages I use.

Finding a way to promote collaboration would be great. Stack Overflow does great assigning brownie points to contributors, thus promoting their participation. Could cross-collaboration with owners of other packages be the key? Perhaps the key is to promote collectives, of which there are already many. I am sure those discussions are going on elsewhere. Perhaps the fragility score might be a way to put some liveliness on those discussions.

[MylesBorins]

@Satyam assigning a score to a problem that we have neither the resources or interest in solving also does seem to be particularly helpful. There are other scores that could potentially be helpful such as the work being done on criticality score. Overall I think we should focus on surfacing information that is actionable.

[Satyam]

@MylesBorins You are right. Thanks.