# OpenTelemetry Ecosystem Explorer: a registry, a pipeline and a React app for finding OTel projects

> The OpenTelemetry Ecosystem Explorer is not a tracing tool. It is a three-part system that scrapes metadata from OpenTelemetry projects into a registry, builds a database from it nightly, and serves the result as a React/Vite site. Here is what the repository actually contains, and where it stops.

**open-telemetry/opentelemetry-ecosystem-explorer** — A repository for the OpenTelemetry Ecosystem Explorer, a tool to help users discover and learn about the various projects in the OpenTelemetry ecosystem.

- Repository: https://github.com/open-telemetry/opentelemetry-ecosystem-explorer
- Website: https://explorer.opentelemetry.io/
- Stars: 30 · Forks: 55
- Language: TypeScript
- License: Apache-2.0
- Published: 2026-08-27 · Updated: 2026-08-27 · Language: en
- Canonical page: https://hysenlabs.com/projects/open-telemetry-opentelemetry-ecosystem-explorer

## The problem: OpenTelemetry metadata is scattered across dozens of repositories

OpenTelemetry is not one project. It is a collector, several language instrumentation libraries, a specification, a semantic conventions document, and a long tail of contrib repositories, each with its own release cadence and its own README. If you want to know which Java instrumentation version supports a given semantic convention, or which collector components exist, the answer is spread across GitHub. The Ecosystem Explorer exists to collapse that into one browsable place.

The audience is narrow and specific. It is for people evaluating OpenTelemetry before committing to it, for contributors who need to see what already exists so they do not duplicate it, and for maintainers of ecosystem projects who want their work discoverable. It is not for someone who wants to instrument an application. The README describes the repository as components related to a web application that helps users discover and explore the various projects available in the OpenTelemetry ecosystem. Discovery, not instrumentation.

The project runs under the OpenTelemetry Communications SIG, which meets every two weeks on Tuesday at 9:00 AM PT according to the README. That governance detail matters more than it looks: it means the roadmap is decided in a public SIG meeting rather than by a single vendor, and the maintainers listed are drawn from Grafana Labs, Causely and elsewhere.

## Three components, one data flow: registry, automation, explorer

The repository README lays out three components, and the split is the most informative thing about the design.

ecosystem-registry is the raw data registry storing metadata from various projects, updated nightly. This is the source of truth. It is data, not code, which is why the top-level repository listing includes a projects/ directory alongside the three component directories.

ecosystem-automation holds the pipelines that extract metadata and build the database. The pyproject.toml confirms the shape of this: it declares a uv workspace whose members are ecosystem-automation/*, with named dependencies including collector-watcher, configuration-watcher, java-instrumentation-watcher, dotnet-instrumentation-watcher, js-instrumentation-watcher, explorer-db-builder and v1-registry-sync. Each watcher is a separate package with its own source tree, and one of them, golang-instrumentation-watcher, is explicitly excluded from the workspace. That exclusion is worth noting: a Go instrumentation watcher exists in the tree but is not wired into the workspace build, so a contributor working on it is on their own for dependency resolution.

ecosystem-explorer is the React/Vite web application. It reads the built database and renders it. The public instance is at explorer.opentelemetry.io.

The flow is one-directional: watchers pull metadata from upstream OpenTelemetry repositories, the registry stores it, the db-builder turns it into a queryable database, and the front end reads that database. Nothing flows back upstream. If you are looking for a tool that writes to OpenTelemetry projects, this is the wrong repository.

## Installing and running the pieces: Bun for the front end, uv for the pipeline

The repository is a polyglot monorepo and the README does not give a single install command. It points new contributors at the Quick Start section of CONTRIBUTING.md, and at component-specific READMEs for ecosystem-explorer and ecosystem-automation. Those files are where the real instructions live.

What the root files do tell you is the toolchain. The root package.json declares engines.node as >=18.0.0, and the repository carries both a .bun-version file and a bun.lock, so the front end is built with Bun rather than npm. The root scripts are lint and format only, and they delegate into the explorer directory:

```bash
bun run lint:md
cd ecosystem-explorer && bun run lint
```

Running the root lint script executes markdownlint-cli2 across the repository and then runs the front end's own lint inside ecosystem-explorer. If you only want to check the front end, the second line is the one that matters.

On the Python side, pyproject.toml requires Python >=3.11 and declares the automation packages as a uv workspace. The repository ships a uv.lock and a .python-version file, so the intended entry point is uv rather than pip:

```bash
uv sync
uv run pytest
```

The dev dependency group includes pytest, pytest-cov, ruff and pre-commit, which means uv run pytest is the test path for the watcher packages once the workspace is synced. Ruff is configured with a line length of 120 and targets py311.

For the web application itself, the README defers to ecosystem-explorer/README.md, which is not reproduced here. Read that file before assuming a dev server command; the root README does not name a port or a start script.

## Where the repository is thin, and where it is the wrong tool

The most obvious gap is that the root README never explains how to run the site locally. It gives the public URL and then hands off to CONTRIBUTING.md and the component READMEs. For a project whose whole output is a web application, that is a real friction point for a first-time contributor.

The second gap is the golang-instrumentation-watcher exclusion. It sits in ecosystem-automation/ but is excluded from the uv workspace in pyproject.toml. A reader cannot tell from what is published whether that is a temporary state, a deprecation in progress, or a package that needs a different build setup. The pyproject.toml simply excludes it, and no comment explains why.

The third issue is the nightly cadence of the registry. The README states the registry is updated nightly. That means the data behind the site is at most about a day stale, which is fine for discovery and useless for anything that needs to reflect a release published an hour ago. If you need current version numbers for a dependency decision, go to the upstream repository, not to the Explorer.

Finally, this is not a tool to install into a production system. There is no runtime library here, no SDK, no collector component. Treating it as part of an observability pipeline is a category error. It is a catalogue.

## How it differs from reading the OpenTelemetry documentation or the contrib repository

The natural alternative is the OpenTelemetry documentation site and the opentelemetry-collector-contrib repository itself. The difference is in what each is optimised for.

The docs site is prose: it explains concepts, teaches instrumentation, and describes configuration. It is written and edited by humans, and it is the right place to learn what a span is. The contrib repository is the code: it contains the actual collector components, their implementations and their release history. Reading it tells you exactly what exists, at the cost of navigating a very large repository.

The Ecosystem Explorer takes a third approach. It extracts metadata from those upstream sources into a structured registry and presents it as a queryable catalogue. The advantage is coverage and comparability: instead of reading a dozen READMEs, you can look at entries produced by the same extraction pipeline. The disadvantage is that it is one step removed from the source. Anything the watchers do not extract simply is not in the registry, and the site cannot show you what the pipeline never captured.

A second alternative, for the front end specifically, is to skip the site and read the registry data directly. Since ecosystem-registry is described as raw data, anyone who wants to build their own view over it can do so without touching the React application. That is arguably the more durable interface, because the data outlives any particular UI.

## Licence, maintenance and the cost of keeping a registry current

The repository is licensed Apache-2.0, and pyproject.toml repeats that as license = { text = "Apache-2.0" }. For anyone consuming the registry data or reusing the front end, Apache-2.0 permits commercial use and modification and includes a patent grant. It also requires that you preserve the licence and notice files and state significant changes. This is a description of the licence text, not legal advice; if you plan to redistribute the registry data, read the LICENSE file in the repository and make your own determination.

The maintenance cost is the part worth thinking about before you depend on it. The repository states that the registry is updated nightly, which means there is a scheduled job somewhere doing the extraction and the database build. That job is the load-bearing piece. If the watchers break because an upstream repository changes its layout, the registry stops advancing, and the site keeps serving the last good build without necessarily making the staleness obvious. Anyone building on top of the registry should check the timestamps of the data rather than assume it is fresh.

For contributors, the cost is per-watcher. Each watcher is its own package with its own source directory, its own tests and its own upstream target. Adding a new language or component means writing a new watcher package and registering it in the uv workspace, following the pattern of the seven already listed. That is a real amount of work, and it explains why the set of watchers is finite rather than exhaustive.

## Conclusion

Adopt the Ecosystem Explorer if you need to look up what exists in the OpenTelemetry ecosystem, or if you maintain a project whose metadata should appear there and you are willing to open a pull request against the registry. Do not adopt it as a dependency of your observability stack: nothing in the repository describes a collector, an exporter or a tracing API, and the site is a discovery front end. Before relying on anything, verify three things in the repository itself: whether the nightly registry update is still running, whether the ecosystem-automation workspace still builds under the uv workspace declared in pyproject.toml, and whether the ecosystem-explorer README documents the Bun version the front end expects. The registry is the artefact worth watching, because the React app is only a view over it.

## FAQ

### What is the OpenTelemetry Ecosystem Explorer for?

It is a web application that helps users discover and explore the various projects available in the OpenTelemetry ecosystem. The public instance is at explorer.opentelemetry.io, and the repository contains the registry, the automation pipelines and the React/Vite front end behind it.

### Who is behind the OpenTelemetry Ecosystem Explorer?

The README says the project runs under the umbrella of the OpenTelemetry Communications SIG, which meets every two weeks on Tuesday at 9:00 AM PT. The listed maintainers are Jay DeLuca, Severin Neumann and Vitor Vasconcellos, with Marylia Gutierrez and Luca Cavenaghi as approvers.

### What database does the OpenTelemetry Ecosystem Explorer use?

The README does not name a database engine. It states only that ecosystem-automation contains pipelines that extract metadata and build the database, and that ecosystem-registry stores the raw metadata, updated nightly. The specific engine is not documented in the root README.

### How do you install the OpenTelemetry Ecosystem Explorer?

The root README does not give install steps; it points to the Quick Start in CONTRIBUTING.md and to the component READMEs for ecosystem-explorer and ecosystem-automation. The root package.json and pyproject.toml indicate Bun for the front end and uv with Python 3.11 or later for the automation workspace.

## Sources

- [Official documentation](https://explorer.opentelemetry.io/)
- [Official README](https://github.com/open-telemetry/opentelemetry-ecosystem-explorer#readme)
- [Project repository](https://github.com/open-telemetry/opentelemetry-ecosystem-explorer)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/open-telemetry-opentelemetry-ecosystem-explorer