Welches Open-Source-Projekt wird wo, wie lange und wie verbreitet genutzt — verifizierbar anonym?
Prometheus ist eine dezentrale, vollständig öffentliche Plattform zur anonymen Messung von Verbreitung und Nutzungsdauer von Open-Source-Projekten innerhalb anderer Software. Vier parallele Erfassungsmodi liefern komplementäre Sichten, k-Anonymität ist ein Schema-Constraint, alle akzeptierten Aggregate sind Open Data, und kein einzelner Akteur kontrolliert die Plattform.
1. Warum jetzt — und warum so#
Open-Source-Software trägt die digitale Wertschöpfungskette, aber niemand weiß systematisch, wer welches OSS-Projekt wo, wie lange und in welcher Tiefe nutzt. Bestehende Werkzeuge liefern Bruchstücke (NPM-Downloads, GitHub-Stars, Libraries.io-Manifeste), ohne Runtime-Nutzung, ohne Nutzungsdauer, ohne verifizierbare Anonymität und ohne Open-Data-Garantie.
Diese Lücke schadet vier Stakeholder-Gruppen gleichzeitig:
- OSS-Maintainer & Foundations haben keine belastbare Datengrundlage für Fördermittel-Anträge, Roadmap-Priorisierung oder Sunset-Entscheidungen.
- Software-Hersteller mit OSS-Bestandteilen kennen ihren Dependency-Health-Zustand nicht in der Tiefe (welche Deps verwaisen, welche werden aktiv weiterentwickelt, welche sind hot-replaced).
- Forschung & Öffentlichkeit haben keinen reproduzierbaren Daten-Backbone zur Untersuchung von OSS-Ökosystemen.
- Sicherheits-Community kann Lieferketten-Risiken nur retroaktiv (nach CVE) einordnen, nicht prospektiv (welche unmaintainten Libs sind weit verbreitet).
Prometheus adressiert diese Lücke anonym, dezentral und Open-Data-first. Das sind keine Marketing-Adjektive — sie sind Architektur-Constraints, die in §3 und in den Risiken (03-risikoprofil.md) bindend gemacht werden.
2. Vier Erfassungsmodi (parallel)#
Jeder Modus zeigt einen anderen Ausschnitt des OSS-Lebenszyklus. Sie werden parallel betrieben, damit ihre Schnittmengen Plausibilitäts-Checks ermöglichen und blinde Flecken sich gegenseitig kompensieren.
| Modus | Wer instrumentiert | Was wird sichtbar | Verbindlich in Phase |
|---|---|---|---|
| A — Self-Instrumentation in OSS-Lib | OSS-Maintainer baut minimales SDK ein (< 50 LOC) | install-Event, session-start, session-duration-bucket, feature-flag-counter — Runtime-Nutzung & Nutzungsdauer | Phase 1 (JS, Python); Go/Rust/Java/.NET ab P1-Ph3 |
| B — Endnutzer-Agent in Host-Software | Software-Hersteller embeddet lokalen Daemon | Dep-Tree-Scan, Modul-Lade-Events, Aufruf-Intervalle — Reichweite über Self-Instrumentation hinaus | Phase 2 |
| C — Hybrid lokaler Aggregator | optionaler Daemon, A+B bündelnd | k-Anon-Prüfung, Signatur, Window-Stempel, gesammeltes Submission-Bundle | Phase 2 (optional ab Phase 1) |
| D — Public-Registry-Scraping | Plattform / Mirror-Betreiber | Manifest-Verbreitung aus npm/PyPI/Maven/crates/Go-mod + GitHub-Crawl — untere Schranke Verbreitung | Phase 1 |
Wichtig: Modi A+D sind der Phase-1-MVP (siehe 02-poc-spezifikation.md). Sie laufen unabhängig und ergänzen sich: D zeigt Verbreitung über öffentliche Manifeste, A zeigt Nutzungsdauer über Runtime-Telemetrie. Modi B+C kommen in Phase 2, wenn das Federation-Modell stabilisiert ist.
Architektur-Entscheidung: ADR-v2-0002 — Vier-Modi-Multimodal-Erfassung.
3. Harte Grundsätze (nicht verhandelbar)#
| Grundsatz | Konsequenz |
|---|---|
| k-Anonymität als Schema-Constraint | Default k=5; in Beschäftigtenschutz-Sensiblen Aggregaten (Modi B/C) k≥25. Mirror lehnt Submissions ohne ausreichende k-Attestation ab. |
| Schema rejects PII | Submission-Schema hat keine Felder für user_id, email, hostname, ip oder Maintainer-Klartextnamen. Defense-in-Depth gegen SDK-/Agent-Bugs. |
| PII niemals auf Disk | Roh-Events nur RAM/tmpfs im lokalen Aggregator; Disk speichert nur bereits anonymisierte Aggregate. |
| Open Data als Default | Alle akzeptierten Aggregate sind öffentlich (CC-BY-4.0, Standardvorschlag — finale Wahl ADR-v2-0004). Keine Tenant-Trennung, keine Paywall, kein Login für Lese-Zugriff. |
| Dezentralisierung | Mehrere Mirrors spiegeln dieselben Aggregate (Gossip / Pull-Federation). Keine zentrale Authority. Submission-Protokoll offen spezifiziert (ADR-v2-0001). |
| Verifizierbarkeit statt Vertrauen | Jeder Mirror veröffentlicht Public Audit Log (Sigstore-Rekor-Stil, Hash-Chain). Cross-Mirror-Konsistenz prüfbar. |
| Egress-only beim Endnutzer | Lokale Aggregatoren (Modi A/B/C) initiieren alle Verbindungen; kein Reverse-Channel von Mirrors zu Endnutzern. |
| EU-Hosting bevorzugt, dezentral verbindlich | Bootstrap-Mirrors in EU; spätere Mirrors weltweit möglich, GDPR-Verantwortung jeweils beim Betreiber. |
Aggregat-Key (kanonisch): (project_id, version_id, cohort_id, window_start). project_id folgt dem PURL-Standard (pkg:npm/<name>, pkg:pypi/<name>, pkg:maven/<group>/<artifact>, …). Aggregat-Windows sind 1h und 1d (1min nur lokal).
4. Stakeholder-Personae#
| Persona | Was sie braucht | Was Prometheus liefert |
|---|---|---|
| OSS-Maintainer | Belege für Reichweite & Aktivität — für Fördermittel, Roadmap-Priorisierung, Sunset-Entscheidungen | Reach-Aggregate (D) + Runtime-Kohorten (A), öffentlich, ohne dass sie selbst eine Datenpipeline betreiben müssen |
| Foundations (Apache, Eclipse, CNCF, NGI, OpenSSF) | Ökosystem-Health-Dashboard für Programm-Entscheidungen | Aggregierte Sicht über alle Mirrors, Trends, Korrelation Reach × Aktivität × Maintainer-Anzahl |
| Software-Hersteller mit OSS-Bestandteilen | Dependency-Health, Supply-Chain-Frühwarnung | Snapshots der eigenen Dep-Tree-Gesundheit, Vergleich mit Branchen-Aggregat (alles aus Open Data abrufbar) |
| Forschung & Öffentlichkeit | Reproduzierbarer Daten-Backbone für OSS-Studien, Journalismus, Policy | Open-Data-Dumps (CC-BY-4.0), Public Audit Log, API + tägliche Parquet/CSV-Snapshots |
Foundations sind Querschnitt zwischen Maintainern und Forschung — sie sponsern Mirrors, kuratieren PURL-Kataloge, treiben Standardisierung. Sie sind in der Stakeholder-.cards-Sicht (siehe 00-design-system.md) als Fließtext-Querverweis dargestellt, nicht als eigene Card.
5. Zielarchitektur (Übersicht)#
Detaillierte Diagramme: system-overview.md, data-flow.md, assets/federation-overview.svg.
Zentrale Komponenten:
- Lokaler Aggregator (Bibliothek-intern oder Daemon): empfängt Modi-A/B-Events, hält k-Anon-Buffer in RAM/tmpfs, prüft Schema, baut Aggregat, signiert, egress.
- Submission-Protokoll (
ADR-v2-0001): JSON-Schema (versioniert), HTTPS-POST an Mirror, Signatur-Header, k-Anon-Attestation-Stub (Phase 1: deklarativ; Phase 2: ZK-SNARK), Window-Stempel. - Mirror: ClickHouse-kompatibler Aggregate-Store, Submission-API, Open-Data-API, täglicher Snapshot-Dump (Parquet/CSV), Public Audit Log, Gossip-Endpoint.
- Open Data API: Read-Only REST/GraphQL, keine Auth für Lese-Zugriff.
- Public Audit Log: Sigstore-Rekor-kompatible Hash-Chain aller akzeptierten Submissions, cross-mirror prüfbar.
6. Roadmap (drei Phasen)#
| Phase | Dauer | Inhalt | Akzeptanztests |
|---|---|---|---|
| 1 — Reach & Runtime MVP | ~10 Wochen | Registry-Scraping (D, Track A der POC-Spec) + Self-Instrumentation-SDK JS+Python (A, Track B der POC-Spec). Ein Referenz-Mirror EU, Open Data Snapshots, Public Audit Log ab Tag 1. | K1–K7 (siehe 02-poc-spezifikation.md) |
| 2 — Federation & ZK | ~Q3 2026 | Endnutzer-Agent (B), Hybrid-Aggregator (C), ZK-SNARK-Attestation für k-Anon, zweiter unabhängiger Mirror, Gossip-Federation. | Cross-Mirror-Konsistenz, ZK-Attest-Overhead < 200 ms |
| 3 — Threshold-Konsens | ~Q1 2027 | ≥ 3 Mirrors, Threshold-Konsens für „kanonische Aggregate". (Die weiteren SDK-Sprachen Java/Go/Rust/.NET, Build-Tool-Plugins Maven/Gradle/cargo/npm und die sprachübergreifende Conformance-Suite wurden vorgezogen und bereits in P1-Ph3 umgesetzt — siehe sprints/INDEX.md.) | Sybil-Resistenz, Eclipse-Resistenz, ≥ 3 unabhängige Mirror-Betreiber |
Visuell: assets/roadmap-v2.svg.
Umsetzungsstand (P1-Ph3, 2026-06): Die SDK-Familie umfasst sechs Sprachen (JS, Python, Go, Rust, Java, .NET). Build-Tool-Plugins (Maven, Gradle, cargo, npm) klinken das SDK per One-Liner in einen Build ein und schreiben einen Konfig-Stub auf
did:key-Basis — kein private-key-Material auf Disk. Eine sprachübergreifende Conformance-Suite (src/proto/conformance+tools/conformance-runner, CI-Jobconformance-all) erzwingt byte-identische Submissions über alle SDKs; eine Sprache, die abweicht, lässt CI rot werden.
7. Was Prometheus nicht ist#
- Kein Vendor-Lock-in-Tool — Open Data, kein zentraler Träger, Protokoll-Spezifikation offen.
- Kein Telemetrie-Saugnapf — nur k-anonymisierte Aggregate verlassen den lokalen Aggregator; PII ist Schema-seitig ausgeschlossen.
- Kein SBOM-Generator — Prometheus misst was und wie lange, nicht was drin ist. SBOM-Tools (Syft, CycloneDX, SPDX) sind komplementär.
- Kein Vulnerability-Scanner — Prometheus liefert Reichweiten-Signal; ob eine weit verbreitete Lib eine CVE hat, beantworten andere (OSV, GHSA).
- Kein Maintainer-Ranking — keine personenbezogenen Aggregate, keine Maintainer-Identifier in Submissions.
- Keine Plattform unter einem Logo — kein „Inneso Prometheus", kein einzelner Tenant; jeder Mirror gehört seinem Betreiber, der Open-Data-Standard ist die einzige Klammer.
8. Querverweise#
- POC-Spezifikation:
02-poc-spezifikation.md - Risiken:
03-risikoprofil.md - Stakeholder-Brief:
04-executive-summary.md - Zero-Knowledge-Bausteine:
05-zero-knowledge-vorschlag.md - Offene Punkte:
06-offene-punkte.md - Architektur-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-Archiv:
files/v1/(SaaS-Adoption-Konzept vor Pivot 2026-05-26)