best-of-jupyter: a machine-ranked index of 300 Jupyter projects

What best-of-jupyter actually is, and who it is for

The README opens with a claim that is easy to misread: a curated list of 300 open-source projects grouped into 13 categories, all ranked by a project-quality score calculated from metrics collected from GitHub and various package managers. There is no runtime here. There is no package to install, no CLI, no server. The artefact is a README plus a projects.yaml file, regenerated on a weekly cadence, with releases named after dates (2026.08.27, 2026.08.20, 2026.08.13).

That shape tells you who it serves. If you are standing up a JupyterHub deployment and need to know which authenticators and spawners exist before you write your own, the 15 authenticators and 8 spawners sections give you a candidate set in one page. If you are hunting for a kernel for an unusual language, the 43-entry kernels section is a better starting point than a general search engine, because every entry has already been reduced to a repository link, a package manager link and a set of collected metrics. The audience is the person doing reconnaissance, not the person who has already decided.

The list is also explicit that it is open to correction. The README invites issues, pull requests, and direct edits to projects.yaml. That matters, because a generated ranking with no human review path would be a dead document within a quarter.

How the quality score is assembled, and what it does not measure

The README states the score is calculated from various metrics automatically collected from GitHub and different package managers. The explanation block enumerates the inputs it displays: combined project-quality score, star count, contributor count, fork count, issue count, last update timestamp on the package manager, download count, and number of dependent projects. It also carries status markers: new (under 6 months old), inactive (6 months without activity), dead (12 months without activity), trending up or down, recently added, and a warning marker described as e.g. missing/risky license.

Read that list again and notice what is absent. There is no test coverage signal, no security advisory feed, no measure of whether the maintainer responds to issues rather than merely accumulating them. Issue count is displayed, but an issue count is ambiguous on its own: a high number can mean an active project with a busy user base or an unmaintained one with a backlog. The contributor count and the dependent-project count are popularity proxies as much as health proxies. The score is a composite, and composites hide their weights. The README does not publish the weighting formula, so you cannot tell whether download count or last-update recency dominates a given ranking.

That is the central trade-off of the project. Automation buys weekly freshness across 300 entries, a volume no volunteer curator would sustain by hand. It costs you the ability to audit why one project sits above another. The inactivity markers are the most defensible part of the output, because they are simple threshold rules that a reader can verify by opening the repository and looking at the commit history. The composite score is the least defensible part, for exactly the opposite reason.

What the entries look like in practice

Each project is a collapsible block with a heading that carries the score and star marker, a one-line description, and a licence badge. Underneath, one line per distribution channel, each with its own collected metrics and a copyable install command.

The JupyterLab entry, for instance, lists GitHub with a git clone command, PyPi with pip install jupyterlab, Conda with conda install -c conda-forge jupyterlab, and npm with npm install @jupyterlab/ui-components, each annotated with download and dependent counts and an update timestamp. The JupyterHub entry follows the same pattern and adds a Docker Hub line, docker pull jupyterhub/jupyterhub. Docker Stacks gets a GitHub clone plus a single docker pull jupyter/scipy-notebook line, and carries the inactive marker in its heading.

This per-channel layout is the most practical thing in the repository. A project can be healthy on PyPi and stale on Conda, and the timestamps sit side by side so you can see it. Timestamps in the sample entries are not uniform: the Jupyter entry shows a Conda timestamp months behind its PyPi timestamp, and Docker Stacks shows an older Docker Hub timestamp than its neighbours. Whether that reflects a real packaging gap or a collection artefact is something you would have to confirm on the package manager page itself.

The categories are uneven by design. Interactive Widgets and Visualization holds 56 projects and JupyterLab Extensions holds 52, while Jupyter Components holds 3 and Others holds 4. If your question is about widgets or Lab extensions, the list is dense enough to be worth reading end to end. If your question is about Jupyter Components, you are looking at a category that barely exists yet.

Getting it onto your machine: clone, or edit projects.yaml

There is nothing to install. The README gives one acquisition path, and it is the GitHub clone shown in the entries themselves:

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

If you want to change the list rather than read it, the README points at a single file: projects.yaml, editable directly through the GitHub web editor at the edit/main/projects.yaml path, or via a pull request. The README also links an issue template for additions and updates. So the contribution workflow is: edit the YAML, open a pull request, and let the weekly regeneration pick it up.

There is no documented local build step in the supplied material, and no config keys beyond the YAML entries themselves. The repository is not described as producing a runnable tool. If you were expecting a scoring script you can run against your own project set, the material does not show one. The list is generated by tooling that lives elsewhere; the README points to a separate create-best-of-list guide on the best-of-lists organisation for anyone who wants to build a comparable list. Treat that as the honest boundary of what this repository contains: data, presentation, and a contribution path, not an engine.

Where the ranking misleads you

The failure mode is substitution. A ranked list invites you to treat rank as a recommendation, and the score cannot carry that weight. Consider the two structural problems.

First, the metrics favour projects that are distributed broadly. A kernel that ships only on GitHub and is used by a handful of research groups will collect low download and dependent counts regardless of whether it works well. The README's own description of the score as calculated from GitHub and package manager metrics confirms the bias: distribution breadth is being measured, and distribution breadth correlates with age and institutional backing more than with fitness for your problem.

Second, the staleness markers are thresholds, not judgements. A project marked inactive at 6 months without activity may be finished rather than abandoned. A small, complete extension that has not needed a change in eight months will be flagged the same way as one whose maintainer walked away. The dead marker at 12 months is a harder signal, but it still cannot distinguish a stable project from an orphaned one.

There is a third limitation that the README states outright: the warning marker covers missing or risky licences. That means the list itself knows some entries have licence problems, and it flags rather than filters them. If you are assembling a dependency set for a commercial product, an entry carrying that marker is not a candidate until you have read its licence yourself. The list is a pointer, and pointers do not transfer rights.

The wrong-tool case is narrow and clear. If you need a vetted dependency with a security posture, a support commitment, or a compatibility guarantee against your Jupyter version, this list gives you none of those. It gives you names.

How it compares to a hand-curated awesome list

The obvious alternative is a conventional awesome-style list, a README maintained by human contributors with entries added when someone finds them useful. The difference in approach is mechanical, not stylistic.

A hand-curated list is edited on human judgement. Entries appear because a maintainer decided they belonged, and they tend to persist even after the project stops moving, because nobody notices. Ordering, when it exists, is usually arbitrary or thematic. The strength is that a knowledgeable curator can include a project that is excellent but obscure, and can exclude a famous one that is broken. The weakness is decay: no curator revisits 300 links on a schedule.

best-of-jupyter inverts both properties. Nothing enters on taste; entries enter because they were added to projects.yaml, and their position is then determined by collected metrics. Every entry is re-measured weekly, so the staleness markers stay current and the score moves. The cost is that the list cannot tell you a project is good, only that it is widely distributed and recently released. A hand-curated list can carry a sentence of opinion. This one carries a number.

For a reader, the practical consequence is that the two are complementary rather than competing. Use the generated list to enumerate the field and to spot which projects have gone quiet, then use whatever human commentary you trust to judge the shortlist. Neither one substitutes for opening the repository.

Licence, maintenance and the cost of staying current

The repository is licensed CC-BY-SA-4.0. That is a content licence, not a software licence, which fits what the repository contains: a README, a YAML data file, and generated presentation. If you republish or adapt the list, the share-alike term applies to your adaptation. This is not legal advice, and the interaction between a CC-BY-SA-4.0 compilation and the licences of the 300 projects it describes is a question for your own counsel. The list's own warning marker exists precisely because those underlying licences vary and some are flagged as missing or risky.

Maintenance cost to you as a consumer is close to zero. You clone once, or you read the rendered README on GitHub, and the weekly releases (the sample shows three consecutive weekly releases in August 2026) keep it fresh without any action on your part. The cost appears only if you contribute: editing projects.yaml means your entry must survive the next regeneration, and a project whose metrics fall will drift down the ranking regardless of how well you described it.

For the maintainers, the cost is the collection pipeline itself. The README states the score is computed automatically from GitHub and package manager APIs, and that the list is regenerated weekly. That is a scheduled job with external dependencies, and its accuracy is bounded by what those APIs return. When a package manager changes its metadata format, the timestamps and download counts in the entries degrade silently until the pipeline is fixed. Nothing in the supplied material describes how that failure would surface to a reader.

Editorial conclusion

Adopt best-of-jupyter as a discovery index when you need breadth across 13 Jupyter categories and want a machine-collected signal about whether a project is still receiving package releases. Do not adopt it as a procurement or dependency decision tool: the score blends popularity and maintenance proxies, so a small, actively maintained kernel can rank below a large, slow-moving one. Before you pick anything from the list, open the project's own repository and check the licence field the list flags with the warning marker, because the list itself is CC-BY-SA-4.0 and says nothing about the licence of the projects it points at.

Official sources

1. Issues
2. License: CC-BY-SA-4.0
3. ml-tooling/best-of-jupyter on GitHub
4. README
5. Releases