Suggestion: maintainers guidance and platform/forum for finding new maintainers

[indutny]

In the light of recent problems with malicious changes introduced into a popular npm package. I'd like to suggest addressing the hand-over problems that most of maintainers face. Namely, it is hard to:

• find a new maintainer for a project
• communicate ownership change to package users
• check trustworthiness of the new owner

[ljharb]

Is it? It seems like in this case, no attempt was made to vet the new owner.

[indutny]

@ljharb that's partly due to a lack of official process and guidance. If we'd have a platform for connecting good maintainers with projects that need them, and tracking the project after the transfer - that incident could have been avoided.

[ljharb]

How would such a system be imposed on the entire ecosystem, or even a significant portion of it? If it’s opt-in, i doubt it would prevent much of anything - and to a much lesser degree than 2FA which does prevent things, but only protects npm accounts/packages that enable it.

Separately, it doesn’t seem like the package in question necessarily needed a maintainer nor did the owner want one - someone just asked to maintain it, and the owner had no interest in continuing to do so.

[indutny]

Most maintainers (especially of popular packages) are acting in a good will. 2FA and other "enforcement" policies don't solve aforementioned problem.

necessarily needed a maintainer

If an author doesn't support library and a person asks to maintain and develop it, the author would definitely consider a maintenance a necessity. After all, that's critical component of OSS contribution model - gathering feedback from users and helping them get the features they need and fix the bugs that they experience.

From personal experience, it is natural to give up on a project after working on it for a long time (and not needing it for personal/business reasons anymore). It isn't obvious, however, what should be done in such case and where the maintainer should be looking for help (or if they should at all). Having forum/platform would relieve me of a lot of responsibility for my old projects, which unfortunately I can no longer fulfill.

[balupton]

Regarding the call for 2FA. @open-company got attacked a few months ago, and at least for that case, enforcing 2FA was one of the things we did to help alleviate the problem in the future:

https://github.com/opencompany/www.opencompany.org/issues/176

[ljharb]

@balupton i wasn’t at all attempting to minimize the benefit of 2FA, more pointing out that until it’s adopted on a wider scale, and/or until people can audit their dep graph against which things are protected by 2FA, that it’s not a systemic solution.

Similarly, while i think guidance, and a forum for responsible transitions of project ownership, are both useful, i don’t think it actually mitigates the recent issues much until there’s a systemic solution.

[mcollina]

I 100% agree with @indutny sentiment. I would also add another point:

• let the companies that profit from the ecosystem contribute back

It's connected to the other 3 points, because these companies have the financial incentives of keeping the ecosystem healthy.

IMHO the foundation could help with this.

[mhdawson]

I agree with @indutny as well. Having "best practices" would provide guidance on how the community believes situations should be handled. If the maintainer follows that guidance they can feel comfortable that they have done the right thing in terms of a handover. It's much harder if each maintainer has to make that call on their own (which of course they are still free to do). This won't prevent all problems but I think it would help.

This fits well with one of the streams we had in mind for this team:

Building, documenting and evangelizing guidance, tools, and processes (for example LTS for modules) that make it easier for maintainers to manage multiple streams and accept help from those who depend on their module."

although it probably needs a bit of rewording to that clear.

[gabrielsimas]

We need security testing using OWASP guides on npm packages. You can count on me for whatever you need. I'm here to help and make Node.js grow even more.

[Qard]

Perhaps a way to deal with the abundance of write-once-and-leave modules on npm we could have a user on npm that anyone could just add as a collaborator to their projects to indicate that we are welcome to just add others interested in continuing or taking over development of that package. It reduces the burden of us having to reach out to package maintainers all the time, making it quicker and easier for us to just step in and make security fixes ourselves as-need, or hand over the module to someone else more committed to its maintenance, if someone interested comes along.

[ljharb]

Now that seems like an actionable and in-scope approach - basically making this group an npm user that maintainers can choose to add, with strict policies on when we can in any way use that access.

[mcollina]

I like that approach quite a lot.

Note that we already have https://www.npmjs.com/~nodejs-foundation that does this for all projects under the Node.js organization.

[aoberoi]

I think there’s a possibility of confusion when a user encounters a package that says nodejs-foundation is an owner: it reads as a signal that the package is officially supported (and possibly funded) by the foundation, when in actuality it’s quite the opposite - potentially nobody is maintaining the package and it’s just in a pool that is “up for grabs”.

I’m my opinion this idea sounds like it would exacerbate the problem because a committee of people less familiar with the original goals, intent, and implementation of a package would be in control of its destiny.

[aoberoi]

I believe the first step in finding a new maintainer for a package is admitting and signaling that a package doesn’t have a healthy maintenance plan so that users can make more informed choices. Often times, if users know this at install time, they would look for an alternative package (or if they work at a company where they had the freedom to sponsor that would be awesome too).

On GitHub, repos can be marked as “archived”. This setting turns on a prominently placed banner so that users who are discovering the repo understand that there isn’t any garauntee of maintenance with that project.

In npm, packages can be marked deprecated to achieve a similar effect. The CLI will warn installers that a package they depend on is deprecated.

If you believe that this sort of warning could push users away from packages that are in disrepair, not healthy, or otherwise forgotten, then I have an observation. It doesn’t seem that authors of packages are taking advantage of the npm deprecate command as often as they should be. Why do we think that is? Here are some thoughts:

• nobody suggested to the maintainer that they should deprecate and that this would be a best practice.
• the warning isn’t “loud” enough or in the right places to make a difference to installers (maybe it should appear on the npm site and/or in npm audit)
• the warning is noisy and takes too much time to parse and understand if there’s an action needed as an installer.
• the deprecate function doesn’t meet the needs of marking a package as unmaintained because it’s inherently tied to semver ranges - and this is a different concept all together.

This raises an interesting question in my mind. What is this group’s relationship to npm, Inc.? Many of the points I just made come down to product decisions of the company, so there’s no real chance at influencing them unless we partner closely. Packages and how they work ultimately depend on npm (and specifically the registry), in some ways more than they depend on node itself. I think the sooner we partner, the more success we’ll have.

[wesleytodd]

In general I support the need for this, but I have a few concerns:

find a new maintainer for a project

Often times "finding a new maintainer" is not the correct path forward. Sometimes deprecating and moving to a new implementation is best. Sometimes just automating the day-to-day patches would enable the current maintainer to continue. I think it would be best to recognize the full life cycle of OSS projects so we make the right suggestions to maintainers. If we are too myopic on finding new maintainers we will miss the mark and that anything we recommend should recognize there are other paths.

communicate ownership change to package users

This to me is a large and dangerous gap we have right now. There is no way to know in your dependency tree if a module has changed owners (let alone to an untrusted user). In theory this is as important of a change as a major semver bump, but there is no tooling built around it at the moment.

IMO this should be high on the list of goals for this group to help with.

check trustworthiness of the new owner

This is a very difficult problem, and one I think we should avoid. In the worst case scenario we recommend the wrong people and they use that trust to do harm. In the best case this is just a popularity contest where users are rewarded for being in the "in crowd". Even maintaining a black list is almost impossible because users can change "identity" so easily.

I do not have a solution for this, as I personally do try to vet contributors before I use a module. But a group effort on this seems more dangerous than the good it provides.

---

I think it is clear that interest is high in this working group, but it will be very easy to get distracted at the sheer number of things we could do to help. I am worried that we will get distracted by things like "checking trustworthiness" and miss on the important and actionable things like notifying users of a change in ownership. To that goal, I think it would be worth opening each of the above conversations as separate issues and then having someone strongly curate each discussion.

[wesleytodd]

Forgot one comment:

I think there’s a possibility of confusion when a user encounters a package that says nodejs-foundation is an owner: it reads as a signal that the package is officially supported

I fully agree with this, it would sends the wrong message. I think this would be something to discuss with npm and see if they would be willing to have a registry feature for designating an inheritor. Something which does not show on the page, but does allow for the account to take over management in the case of an emergency or special circumstances.

[sam-github]

@mcollina I wonder if the node-foundation/streams working group could start a sub-group to build common, useful utility modules? This package-maintenance group requests for membership seems to indicate there are volunteers available, but they don't always have a place to put their time. Even when they put their time in, it doesn't always go anywhere, which is discouraging. Streams aside, I think there is more energy available to maintain packages than is being effectively used at the moment. cf. https://github.com/jahewson/node-byline/issues/49, where someone stepped up to solve a problem (arguably a security one, even), but the maintainer hasn't responded (with absolutely no criticism intended, all of us who maintain packages can understand the burden of doing so!). I have used byline a lot in the past, but we are inlining it now, https://github.com/strongloop/strong-log-transformer/pull/8.

Recent events have high-lighted the risks of using lots of small packages, but its worth remembering the pain of inlining utility package functionality is also real!

Sorry if this was the wrong thread, I tried to find the most appropriate one.

[mcollina]

@sam-github I'm +1 on that proposal. I think we should discuss during the meeting and identify who is available for doing work.

I would prefer if we avoid creating a subteam for the time being, just to keep things simple.

[wesleytodd]

Sorry if this was the wrong thread, I tried to find the most appropriate one.

This seems like a different proposal than the original one here, and I don't think anyone has brought this specifically in any other issues. I have feels on this topic, but I don't want to derail this conversation. @sam-github maybe you can open it as a separate issue to continue the conversation? If you do, can someone mark these comments as off topic to keep this one focused?

[balupton]

I wonder if the node-foundation/streams working group could start a sub-group to build common, useful utility modules?

This seems like a different proposal than the original one here, and I don't think anyone has brought this specifically in any other issues.

Seems like it would fit within #17 or #5

[wesleytodd]

Seems like it would fit within #17 or #5

Maybe I am miss-understanding the ask here, but I thought this was about directly supporting tools like node-byline or building new ones. Which is different than helping those maintainers choose or setup automation tooling.

[mhdawson]

@sam-github I agree with @wesleytodd that while what you are suggesting might be a way of addressing the same root issue, its a different topic and probably best covered in a separate issue.

[mhdawson]

@indutny would it make sense to close this issue at this point? The original topic is included in the discussion on creating "baseline practices" in https://github.com/nodejs/package-maintenance/issues/119 and its probably best to carry out the discussion as part of that work.

[Eomm]

I think this is related to #214 tool

I would close this issue since it has accomplished its duty 👍

[jonchurch]

Making this as stale? to bring up with others in the group. Several people have suggested closing this, but since there's a lot of good info here I want to make sure it's captured and linked to from anywhere relevant before the close happens.