best-of ranks lists, not projects, and several of its picks are already marked dead

It ranks lists, and the score is computed elsewhere

The unit of ranking here is not a project, it is another list. The README describes a curated list of best-of lists, and the entries are repositories such as best-of-jupyter, best-of-ml-python and best-of-django, each of which is itself a ranked list. So a single lookup adds two layers of opinion: the inner list's editorial choices, then this directory's score.

The score is not editorial. The README says all projects are ranked by a project-quality score calculated based on various metrics automatically collected from GitHub and different package managers. The legend lists what those metrics are: contributors count, fork count, issue count and star count from GitHub, the last update timestamp and download count from the package manager, and the number of dependent projects.

That metric list is the honest way to judge the tool. Every input is an activity or popularity signal. None of them is a measure of whether the library is correct, maintained by people who answer issues, or appropriate for your problem. A popular project that was abandoned a year ago scores well on several of these inputs at once.

The legend admits dead projects sit inside a top-ranked list

The explanation section decodes a set of markers, and three of them are about staleness rather than quality: a new project marker for something less than six months old, an inactive marker at six months with no activity, and a dead marker at twelve months with no activity. Others cover trend direction, a recently added marker, and separate icons for lists built around Python or JavaScript projects.

Here is the part that should shape how you read the page. In the Machine Learning and Data Engineering category, the highest-ranked visible entry, best-of-ml-python at score 14, carries the dead marker. So do awesome-gpts, best-of-streamlit, best-of-ml-rust and best-of-ml-julia. In the Web Development category, best-of-react carries it too. best-of-django is shown without a staleness marker.

Nothing is wrong with a directory surfacing a dead list. The problem is only if you read the score as a recommendation. The score ranks the list; the marker describes the list. They are different axes and the README prints them side by side.

Concretely: best-of-jupyter is shown with the inactive marker at six months, which means it has had no recorded activity for six months, while best-of-django at a lower score of 8 has no marker at all and is the fresher pick in that section.

Categories are uneven, and that unevenness is telling

The contents section divides the collection into eleven categories with the number of projects in each. Machine Learning and Data Engineering leads with six. Web Development follows with five. Documentation and Programming Languages have two each. Native Development, Robot Development, Embedded Development, Development Tools, Internet, and Cryptocurrencies and Blockchain have one each. Others has two.

A directory with one entry in a category is not a directory, it is a pointer. Its real value in those categories is the link, not the ranking. Where it earns its keep is the top two categories, where there are enough competing lists that the score has something to compare against.

The category definitions are also broad. Machine Learning and Data Engineering is described as best-of lists about machine learning, data engineering, data science or other topics related to big data. Web Development covers react, vue, angular, html5, css or other topics related to web development. That breadth means a list filed under Web Development may be barely relevant to a backend or systems task.

The listing itself also hides entries. Several entries appear inside a details block labelled Show 5 hidden projects, meaning the README is truncated by default and only the top item or two per category is visible. Reading the full picture means expanding those blocks or reading projects.yaml.

How the list is generated and updated

The repository layout explains the automation. At the top level there is `projects.yaml`, which is the data file, a `config/` directory, a `template/` directory holding the rendering template, a `history/` directory, and `latest-changes.md` alongside `create-best-of-list.md` and `CONTRIBUTING.md`.

The README makes the contribution paths explicit: open an issue, submit a pull request, or edit projects.yaml directly through the GitHub edit link. For anyone building their own list, there is a separate guide, create-best-of-list.md, which the README advertises as creating your own best-of list in just 3 minutes.

The update cadence is weekly and mechanical. The recent release names are dates rather than semantic versions: 2026.10.08 published on 2026-10-09, 2026.10.01 on 2026-10-02, and 2026.09.24 on 2026-09-25. The recent dated releases show a regular publication cadence, but they do not by themselves explain how each score and marker is recomputed.

This project is not archived and its last push was on 2026-10-09.

Using it, and the licence constraint on reuse

There is nothing to install. The README's own usage lines are clone commands, one per list, which is the whole interface:

git clone https://github.com/ml-tooling/best-of-jupyter

You clone the underlying list you care about and read its README. The site best-of.org is the rendered presentation of the same data.

The licence is CC-BY-SA-4.0, which is worth pausing on for an engineering audience. That is a Creative Commons share-alike licence, so its attribution and share-alike terms are relevant when reusing licensed content. If you plan to fork a best-of list and reuse its prose or structure in an internal document, the share-alike term is the thing to check, along with the per-entry licences of the projects the list points at, which this directory does not track and does not restate. That is a licensing question to answer with your own legal reading, not from this repository.

Where the directory is the wrong tool

The clearest wrong case is using the score to shortlist a dependency. The metric set is entirely signals of popularity and activity, so the ranking systematically favours projects that are widely used and recently touched. The ranking can favour widely used projects over less popular alternatives, while the documented metrics do not directly measure correctness or suitability.

The second wrong case is treating it as a substitute for ecosystem knowledge. Every category here is a wrapper around knowledge that already exists inside the ecosystems. Someone working in Jupyter already knows which notebook tooling is maintained. The directory helps when you are outside the ecosystem, which is exactly its value and also its limit.

The third is assuming freshness. The staleness markers are based on periods without recorded activity, so they indicate inactivity rather than whether a list's recommendations remain suitable. A list can be updated monthly and still recommend a library that was superseded two years ago.

A fair use is navigation: pick two or three lists from the strongest category, open them, and check the dates on what they recommend. A fair thing to avoid is quoting the score at all.

Editorial conclusion

Use best-of as a starting index when you want to find specialised best-of lists for a language or ecosystem, and treat the score as a discovery aid rather than a selection criterion, since the README's own legend marks entries as inactive at six months and dead at twelve. Do not treat a top-ranked entry as a vetted dependency: several lists in the Machine Learning and Web Development categories carry the dead marker in the same README that ranks them highest. Before adopting anything you find here, open the underlying list, check its last commit date, and compare it against a list maintained in the ecosystem you actually work in.

Frequently asked questions

Official sources

1. best-of-lists/best-of on GitHub
2. License: CC-BY-SA-4.0
3. Project website
4. README
5. Releases