[discussion] Policy around forking OSS when no longer maintained

[rxmarbles]

this conversation started up in our company around an OSS package that appears to no longer be maintained (PR's have been opened and issues as well). It is mentioned in our doc https://github.com/nodejs/package-maintenance/blob/master/docs/drafts/DEPRECATE-GUIDELINES.md#identifying-unmaintained-package on how to identify an unmaintained package, but we did not address the "reasonable amount of time" for these situations.

[mhdawson]

@rxmarbles can you clarify the question/topic for discussion. Is it an ask around what a reasonable amount of time is?

[rxmarbles]

@mhdawson Correct that is the question we are looking to resolve.

[dominykas]

I'm not sure it makes sense to define such a time in absolute terms? It probably varies very much on a case-by-case basis, but more importantly - what does "forking" even mean?

As you open the PRs with fixes, you're already pushing the "fork" button. At work, we've had quite some cases where we'd publish a fork either on public npm as scoped package or internally, I've also been installing packages directly from git, when I couldn't land my PRs in a timely manner (and timely is a simple "when I could no longer wait").

But the question here is broader than just "fork" and publish your own copy. That happens a lot. The implication is that you will be maintaining that fork, or at least that you'll be making some commitment to do that. For top-level packages that's probably not a big deal and if the original maintainer is really inactive - there's not even the upstream to consider.

The hassle really begins when you need the forked package to be used in another package, owned by someone else. And that, I think, is not something that we can put a simple time based value on, as it also depends on the severity of the issues being solved. Which means that this is something that needs to be discussed with the users the package you're trying to fork - are they willing to use your fork? Are they willing to trust you to maintain that fork any better than the original maintainer?

There is also the case that the "reasonable amount of time" really can't be measured since "last activity". In reality, when packages die, they die slowly. You might see a commit or a response from the author every other month, but no npm publish, etc, so there's multiple signals to look into anyways.

My personal opinion - fork, and don't worry if it's reasonable. As of npm 6.9.0 you can use aliases in package.json, so your hands are untied - one day of inactivity might be perfectly reasonable to fork and to try to convince the community to use your fork.

So tl;dr - we should not define what "reasonable amount of time" means.