Which open-source project is used where, for how long, and how widely — verifiably anonymously?
Prometheus is a decentralized, fully public platform for the anonymous measurement of the reach and usage duration of open-source projects inside other software. Four parallel capture modes deliver complementary views, k-anonymity is a schema constraint, all accepted aggregates are Open Data, and no single actor controls the platform.
1. Why now — and why like this#
Open-source software carries the digital value chain, but nobody knows systematically who uses which OSS project where, for how long and in what depth. Existing tools deliver fragments (NPM downloads, GitHub stars, Libraries.io manifests), without runtime usage, without usage duration, without verifiable anonymity and without an Open Data guarantee.
This gap hurts four stakeholder groups at once:
- OSS maintainers & foundations have no solid data basis for funding applications, roadmap prioritisation or sunset decisions.
- Software vendors with OSS components do not know their dependency health state in depth (which deps are going stale, which are actively developed, which are being hot-replaced).
- Research & the public have no reproducible data backbone for investigating OSS ecosystems.
- The security community can only classify supply-chain risks retroactively (after a CVE), not prospectively (which unmaintained libraries are widely deployed).
Prometheus addresses that gap anonymously, decentrally and Open-Data-first. Those are not marketing adjectives — they are architecture constraints, made binding in §3 and in the risks (03-risikoprofil.md).
2. Four capture modes (in parallel)#
Each mode shows a different section of the OSS lifecycle. They are operated in parallel so that their overlaps enable plausibility checks and their blind spots compensate for one another.
| Mode | Who instruments | What becomes visible | Binding in phase |
|---|---|---|---|
| A — Self-instrumentation in an OSS lib | The OSS maintainer embeds a minimal SDK (< 50 LOC) | install event, session-start, session-duration bucket, feature-flag counter — runtime usage & usage duration | Phase 1 (JS, Python); Go/Rust/Java/.NET from P1-Ph3 |
| B — End-user agent in the host software | The software vendor embeds a local daemon | dep-tree scan, module load events, call intervals — reach beyond self-instrumentation | Phase 2 |
| C — Hybrid local aggregator | Optional daemon, bundling A + B | k-anon check, signature, window stamp, collected submission bundle | Phase 2 (optional from phase 1) |
| D — Public registry scraping | Platform / mirror operator | Manifest reach from npm/PyPI/Maven/crates/Go mod + GitHub crawl — lower bound on reach | Phase 1 |
Important: modes A + D are the phase-1 MVP (see 02-poc-spezifikation.md). They run independently and complement each other: D shows reach via public manifests, A shows usage duration via runtime telemetry. Modes B + C follow in phase 2, once the federation model has stabilised.
Architecture decision: ADR-v2-0002 — four-mode multimodal capture.
3. Non-negotiable principles#
| Principle | Consequence |
|---|---|
| k-anonymity as a schema constraint | Default k=5; in aggregates sensitive to employee protection (modes B/C) k≥25. The mirror rejects submissions without sufficient k-attestation. |
| The schema rejects PII | The submission schema has no fields for user_id, email, hostname, ip or maintainer names in the clear. Defense in depth against SDK/agent bugs. |
| PII never on disk | Raw events only in RAM/tmpfs in the local aggregator; disk stores only already anonymised aggregates. |
| Open Data by default | All accepted aggregates are public (CC-BY-4.0, the standard proposal — final choice in ADR-v2-0004). No tenant separation, no paywall, no login for read access. |
| Decentralization | Several mirrors replicate the same aggregates (gossip / pull federation). No central authority. The submission protocol is openly specified (ADR-v2-0001). |
| Verifiability instead of trust | Every mirror publishes a Public Audit Log (Sigstore-Rekor style, hash chain). Cross-mirror consistency is checkable. |
| Egress-only at the end user | Local aggregators (modes A/B/C) initiate all connections; there is no reverse channel from mirrors to end users. |
| EU hosting preferred, decentralization binding | Bootstrap mirrors in the EU; later mirrors worldwide are possible, with GDPR responsibility sitting with the respective operator. |
Aggregate key (canonical): (project_id, version_id, cohort_id, window_start). project_id follows the PURL standard (pkg:npm/<name>, pkg:pypi/<name>, pkg:maven/<group>/<artifact>, …). Aggregate windows are 1h and 1d (1min locally only).
4. Stakeholder personae#
| Persona | What they need | What Prometheus delivers |
|---|---|---|
| OSS maintainers | Evidence of reach & activity — for funding, roadmap prioritisation, sunset decisions | Reach aggregates (D) + runtime cohorts (A), public, without having to run a data pipeline themselves |
| Foundations (Apache, Eclipse, CNCF, NGI, OpenSSF) | An ecosystem health dashboard for programme decisions | An aggregated view across all mirrors, trends, correlation of reach × activity × maintainer count |
| Software vendors with OSS components | Dependency health, supply-chain early warning | Snapshots of their own dep-tree health, comparison with the industry aggregate (all retrievable from Open Data) |
| Research & the public | A reproducible data backbone for OSS studies, journalism, policy | Open Data dumps (CC-BY-4.0), Public Audit Log, API + daily Parquet/CSV snapshots |
Foundations are the cross-section between maintainers and research — they sponsor mirrors, curate PURL catalogues, drive standardisation. In the stakeholder .cards view (see 00-design-system.md) they are represented as a prose cross-reference, not as a card of their own.
5. Target architecture (overview)#
Detailed diagrams: system-overview.md, data-flow.md, assets/federation-overview.svg.
Core components:
- Local aggregator (inside the library or as a daemon): receives mode A/B events, keeps the k-anon buffer in RAM/tmpfs, validates the schema, builds the aggregate, signs it, egresses.
- Submission protocol (
ADR-v2-0001): JSON schema (versioned), HTTPS POST to a mirror, signature header, k-anon attestation stub (phase 1: declarative; phase 2: ZK-SNARK), window stamp. - Mirror: ClickHouse-compatible aggregate store, submission API, Open Data API, daily snapshot dump (Parquet/CSV), Public Audit Log, gossip endpoint.
- Open Data API: read-only REST/GraphQL, no auth for read access.
- Public Audit Log: a Sigstore-Rekor-compatible hash chain of all accepted submissions, checkable across mirrors.
6. Roadmap (three phases)#
| Phase | Duration | Content | Acceptance tests |
|---|---|---|---|
| 1 — Reach & Runtime MVP | ~10 weeks | Registry scraping (D, track A of the POC spec) + self-instrumentation SDK JS+Python (A, track B of the POC spec). One reference mirror in the EU, Open Data snapshots, Public Audit Log from day 1. | K1–K7 (see 02-poc-spezifikation.md) |
| 2 — Federation & ZK | ~Q3 2026 | End-user agent (B), hybrid aggregator (C), ZK-SNARK attestation for k-anon, a second independent mirror, gossip federation. | Cross-mirror consistency, ZK attestation overhead < 200 ms |
| 3 — Threshold consensus | ~Q1 2027 | ≥ 3 mirrors, threshold consensus for "canonical aggregates". (The further SDK languages Java/Go/Rust/.NET, the build-tool plugins Maven/Gradle/cargo/npm and the cross-language conformance suite were pulled forward and already implemented in P1-Ph3 — see sprints/INDEX.md.) | Sybil resistance, eclipse resistance, ≥ 3 independent mirror operators |
Visually: assets/roadmap-v2.svg.
Implementation status (P1-Ph3, 2026-06): the SDK family covers six languages (JS, Python, Go, Rust, Java, .NET). Build-tool plugins (Maven, Gradle, cargo, npm) wire the SDK into a build with a one-liner and write a config stub on a
did:keybasis — no private key material on disk. A cross-language conformance suite (src/proto/conformance+tools/conformance-runner, CI jobconformance-all) enforces byte-identical submissions across all SDKs; a language that deviates turns CI red.
7. What Prometheus is not#
- Not a vendor lock-in tool — Open Data, no central operator, the protocol specification is open.
- Not a telemetry vacuum — only k-anonymised aggregates leave the local aggregator; PII is excluded at the schema level.
- Not an SBOM generator — Prometheus measures what and how long, not what is inside. SBOM tools (Syft, CycloneDX, SPDX) are complementary.
- Not a vulnerability scanner — Prometheus supplies a reach signal; whether a widely used library has a CVE is answered elsewhere (OSV, GHSA).
- Not a maintainer ranking — no person-related aggregates, no maintainer identifiers in submissions.
- Not a platform under one logo — no "Inneso Prometheus", no single tenant; every mirror belongs to its operator, and the Open Data standard is the only bracket around them.
8. Cross-references#
- POC specification:
02-poc-spezifikation.md - Risks:
03-risikoprofil.md - Stakeholder brief:
04-executive-summary.md - Zero-knowledge building blocks:
05-zero-knowledge-vorschlag.md - Open questions:
06-offene-punkte.md - Architecture detail:
system-overview.md,data-flow.md,threat-model.md - Design system:
00-design-system.md - ADRs (v2):
ADR-v2-0001-dezentrales-foederationsmodell.md,ADR-v2-0002-vier-modi-multimodal-erfassung.md,ADR-v2-0003-aggregat-key-ohne-tenant.md,ADR-v2-0004-open-data-lizenz-und-public-audit-log.md - v1 archive:
files/v1/(SaaS adoption concept before the 2026-05-26 pivot)