Defining a policy for new and existing dependencies to manage Supply Chain risk

[matglas]

During the work on new functionality the topic of dependency management came up. This was in regards to one of the dependencies that was being used. The dependency showed signs of not being maintained for a long time, over 6 years, and the maintainer seems inactive. These signs make a dependency a risk factor.

During the Community call we discussed that there needs to come a policy for the acceptance of new dependencies and rules for reviewing existing dependencies.

The topic of discussion is: what kind of policy should we use embrace for witness and go-witness to manage new and existing dependencies to minimize risk from the supply chain?

As a SSCS project the goal is also to show an example of good Supply Risk Management in Open Source.

Some questions to ask:

• are there good examples of Supply Chain Risk Management in OSS regarding dependency management that we can draw lessons from?
• what do we as a project want to implement?
• what rules or best practices do we thing are important in our context?

[Eh2406]

The dependency showed signs of not being maintained for a long time, over 6 years, and the maintainer seems inactive. These signs make a dependency a risk factor.

There are definitely risks to abandon projects. If a change is needed is hard to get it published. If the account is taken over it's less likely the original author will notice the unauthorized activity. But...

what kind of policy should we use ... to minimize risk from the supply chain?

As a SSCS project the goal is also to show an example of good Supply Risk Management in Open Source.

If the act of abandoning the project is sufficiently stigmatized in the community your building then that stigma itself can be a potent tool for package take over. It is easy for maintainer to accept questionable contributions if the alternative is publicly being labeled an abandoned project. Especially if they care about their users, which most maintainers do, and the community norm is to have to stop using abandoned projects. You put the maintainer in an awkward situation of making all of their users to a lot of work or trusting a new contributor. This is not hypothetical. This is the exact bullying tactics used to get “Jia Tan” the commit bit on XZ.

Inasmuch as this discussion is a question of "what should this project due to balance its risks", I am not a member or user of this project and so do not have an opinion. Inasmuch as this discussion is setting an example for Open Source in general, I would ask that we remember that everything is trade-offs. There are risks involved in every decision especially dogmatic ones. Whatever decision ends up being made, please be public and honest about the risks and disadvantages.