OpenTelemetry Ecosystem Explorer: a nightly registry behind a React app

Three components and one nightly data path

The repository holds three components and the split explains how fresh the site is. `ecosystem-registry` is the raw data registry, storing metadata from the various projects, and it is updated nightly. `ecosystem-automation` is where the pipelines live that extract that metadata and build the database. `ecosystem-explorer` is the React and Vite web application people actually read at https://explorer.opentelemetry.io/. So no one hand edits the catalogue: a scheduled job collects data, a builder assembles the database, and the front end consumes it. The registry being nightly is the whole freshness contract, and it also means a project added today may not appear until the next run. The proposal that started the work lives in the community repository rather than here, so the design rationale is documented one level up from the code that implements it.

One repository, three runtimes, three version files

The root directory pins three toolchains at once, which is unusual and explains most of the layout. JavaScript work runs on bun, evidenced by `bun.lock` and a `.bun-version` file. Node 18 or newer is required by the root manifest's engines field, with `.nvmrc` for the exact version. Python 3.11 or newer is required by the project metadata, with `.python-version` and a `uv.lock` alongside `pyproject.toml`. Add `.pre-commit-config.yaml`, `.prettierrc.json`, `.markdownlint-cli2.yaml` and an `.editorconfig` and you have a repository where a single markdown change has to satisfy two linters and a formatter, in two languages, before it lands. Two other top level directories suggest the same split in practice: `acceptance-tests/` for checking the assembled site and `projects/` sitting beside the three components.

The root package has no build step, only lint and format

The root `package.json` is marked private at version 0.0.0 and exposes four scripts. `lint` runs the markdown linter and then changes directory into the web app to run its own lint, so the repository root delegates rather than duplicating. `lint:md` and `lint:md:fix` call markdownlint-cli2 directly. `format` and `format:check` run prettier in write and check mode. Three dev dependencies are pinned exactly: markdownlint-cli2 at 0.23.2, prettier at 3.9.6 and prettier-plugin-tailwindcss at 0.8.1. That last plugin is the tell, since a Tailwind plugin inside prettier means class ordering is enforced automatically, and its presence in the root manifest is what ties the frontend's styles to the same formatting pass as the documentation.

Eight Python packages, seven pulled from the workspace

The Python side names its own architecture in the dependency list. Four watchers do the extracting: collector, configuration, java-instrumentation and dotnet-instrumentation, joined later by js-instrumentation and python-instrumentation. Two packages do the plumbing around them, `v1-registry-sync` for syncing and `explorer-db-builder` for building the database. Every one of those is declared as a workspace source rather than a versioned release, and the workspace itself is the `ecosystem-automation/*` glob with one exclusion, the golang instrumentation watcher. That single exclusion is the reason a Go component can live in the same directory without being pulled into the Python environment.

Ruff selects the S rules, and three files are exempted

The Python lint configuration targets `py311` with a line length of 120, and the selected rule families are E, F, I, N, W and S. That last family is the security checks, and they are the reason for a block of per-file ignores. Three files are exempted from S603, which flags subprocess calls: `repository_manager.py`, `version_detector.py` and `testing.py`, listed once for the watcher common package and again for the configuration watcher. The comment above them gives the reason, namely that these files invoke git through subprocess with statically typed, internally controlled arguments, so the rule produces only false positives there. Everything else in the repository stays under the security rules.

Two version numbers, neither of them published

The two manifests disagree on a version and neither number means anything to a consumer. The JavaScript manifest says 0.0.0 and is private, while the Python manifest says 0.1.0 for a project whose package list is internal only. There are no GitHub releases at all, so the site is deployed from a branch rather than from a tag, and the root carries a `netlify.toml` that indicates where the front end is served from. The last commit landed on 2026-09-26, and the repository is not archived. Treat the version fields as internal bookkeeping, and use the site itself, at explorer.opentelemetry.io, as the thing with a stable address.

Fortnightly meetings and four named maintainers

Governance is explicit. The project runs under the umbrella of the OpenTelemetry Communications SIG, which meets every two weeks on Tuesday at 9:00 AM Pacific, with the Zoom link and any schedule changes published on the OpenTelemetry community calendar and notes kept in a public document. Day to day discussion happens in the `#otel-ecosystem-explorer` and `#otel-comms` Slack channels. Four people are listed as maintainers, Jay DeLuca at Grafana Labs, Severin Neumann at Causely, Vitor Vasconcellos, and Luca Cavenaghi at Akamas Labs, with Marylia Gutierrez of Grafana Labs as approver and Pablo Baeyens recorded as an emeritus maintainer. Contributors are pointed at a quick start section in CONTRIBUTING.md and to per component documentation under `docs/`.

Editorial conclusion

Use it as a directory of OpenTelemetry projects and as a reference for how a community-run catalogue is kept fresh without a human editor. Do not expect a database dump, an API, or a versioning scheme you can pin: the packages are private, the versions disagree with each other, and the update cadence is one nightly pass.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository