Define criteria for inclusion in the Downloads page

[GeoffreyBooth]

Spinning off from https://openjs-foundation.slack.com/archives/C044DNU6TEH/p1739802238093859 per @ovflowd, this issue is to organize our thoughts to eventually create a PR to specify criteria for what external software gets mentioned on the Downloads page. Authors of other projects understandably want the visibility that being on nodejs.org would provide, but it does a disservice to our users to feature a laundry list of projects with no curation.

We could take an entirely subjective approach, deciding that we should exercise editorial judgment in choosing which tools to recommend based on our expertise; but this can lead to a lot of unfocused discussion and hurt feelings, and the most likely end result is that most tools that want inclusion would be included since it’s easier to say yes than no.

One objective way to resolve this is to use the most recent Next 10 survey data. Package managers, operating systems and architectures above certain percentages warrant inclusion on the Downloads page, and projects below the cutoff do not.

To make this decision, I think a PR should be opened to add a new markdown file to the root of this repo listing the criteria that we have agreed to; and a link to this file should be added to this repo’s readme.

[bjohansebas]

Maybe also considering the number of downloads would be a good idea, for example, more than 10,000 weekly downloads?

[ljharb]

For "not npm", download counts are largely impossible to measure, unfortunately, but for things that are npm packages that seems like a good metric.

[mhdawson]

My 2 cents is that we should have the package-managers/all page which can include a wide variety of ways Node.js can be installed, but the drop downs should have a very limited set which are limited to options that install or provide the binaries built by the Node.js project.

[ovflowd]

One of the considerations here is that the dropdown page should allow common/popular installation methods. What does that mean for me?

• Distribution agnostic. Out downloads page focuses on OSs and not variations of a given OS. Said installation methods should work for any variation and version of said OS that is officially supported by currently running Node.js versions. (Maintainer Versions, non EOL)
• These must be fully open source installation methods, not products of a company, if community installation methods. 1st-party installation methods -- those provided by the Node.js project, can bend said rule, for example, Docker.
• These must be commonly used and justified through at least one rubric, which should be either a download count or usage survey from the Next-10 team, for example.

These are my personal rubric score.

[ovflowd]

Alrighty, @nodejs/package-maintenance can we do some vote or agreement? -- For example, you can thumbs up my comment/solution. Ill wait for a few days, and if I don't see any objection, I'll start putting things into action.

[bjohansebas]

On my part, I would just like to know a bit more about point 3, for example, how many minimum downloads it should have, and this could be something controversial, so someone should make that decision.

But other than that, I'm okay with @ovflowd 's comment