OSS-Veröffentlichung: Mehr als Code hochladen

Ein internes Tool öffentlich zu schalten dauert zwei Minuten: Repository auf public, README dazu, fertig. Die Rechnung kommt später — als Issue ohne Reproduktionsschritte, als Pull Request gegen einen umbenannten Branch, als Mail einer Rechtsabteilung, die wissen will, ob die Lizenz kommerzielle Nutzung erlaubt. Darauf gibt es keine gute Antwort, wenn vorher niemand entschieden hat, was das Projekt sein soll. 

Sieben Entscheidungen kosten vor dem Launch ein paar Stunden und legen fest, welche Erwartungen Nutzer und Beitragende haben dürfen. Die siebte ist erst in den letzten zwei Jahren dazugekommen. 

1. Maintenance-Status ehrlich benennen

Repositories behaupten implizit, aktiv gepflegt zu werden, weil sie nichts Gegenteiliges sagen. Ein Badge von shields.io räumt das in einer Zeile ab: 

!Maintenance

Drei Stufen reichen: actively-developed mit laufender Roadmap, passive-maintenance für Bugfixes ohne neue Features, archived für Referenzcode. Wer passive-maintenance deklariert, muss nicht rechtfertigen, warum ein PR drei Wochen liegt. Wer archived deklariert, erspart Nutzern eine überflüssige Evaluierung. 

2. Die Lizenz ist eine Produktentscheidung

MIT ist die Voreinstellung vieler Projektgeneratoren und steht deshalb auch in Repositories, zu deren Ziel sie nicht passt. choosealicense.com führt durch die Auswahl, sobald das Ziel klar ist: 

Für Token-Governance war Apache-2.0 die Wahl, weil die Lizenz eine ausdrückliche Patentlizenz der Beitragenden enthält. MIT schweigt zu Patenten, und das fällt auf, sobald eine Firma das Projekt durch die Due Diligence schickt. 

3. Contribution Guidelines als Onboarding

Eine CONTRIBUTING.md beantwortet, was ein Beitragender vor dem ersten Commit wissen muss: Wie melde ich einen Bug? Gehört ein Feature-Vorschlag in eine Discussion oder in ein Issue? Wie sieht der Workflow aus — Branch-Strategie, Commit-Convention, CI? Welche Issues sind als good first issue gelabelt? Wie läuft Review ab, und welche Tests werden erwartet? Issue- und PR-Templates nehmen einen Teil der Antworten vorweg, weil sie Version, Reproduktionsschritte und verlinktes Issue direkt abfragen. 

Als Faustregel: Wenn der erste PR mehr als drei Runden „bitte formatieren“, „bitte Tests ergänzen“ braucht, fehlen die Guidelines. Bei Token-Governance ist die CONTRIBUTING.md drei Zeilen lang, und jeder externe PR kostet dort zwei Review-Runden für Formalien. Sauber entschiedene Lizenz, vernachlässigtes Onboarding — die sieben Punkte sind voneinander unabhängig, und jeder einzelne kann fehlen. 

4. Ein Release ist mehr als ein Tag

Ein Tag markiert einen Commit. Ein Release liefert alles für den Versionswechsel: Changelog, fertige Artefakte, bei Breaking Changes einen Upgrade-Guide und eine Deprecation-Policy mit konkreter Vorwarnung (üblich: eine Major-Version). Der Weg von Tag zu Publish gehört automatisiert, sonst bleibt bei jeder Version ein Schritt liegen. SemVer regelt nur die Nummer, den Changelog muss man selbst schreiben. keepachangelog.com begründet, warum generierte Listen dafür nicht reichen: 

„Don’t let your friends dump git logs into changelogs.“ 

Ein Git-Log sagt, was committet wurde. Ein Changelog sagt, was sich für den Nutzer ändert. Nutzer updaten selten aus Neugier, sondern weil ein CVE oder eine Abhängigkeit sie dazu zwingt — je kürzer der Weg dahin, desto weniger Altversionen bleiben im Feld. 

5. Security-Policy mit belastbaren Zusagen

Eine SECURITY.md braucht vier Angaben: 

• Meldeweg: ein privater Kanal — GitHubs Private Vulnerability Reporting oder eine dedizierte Mailadresse, kein öffentliches Issue
• Erstreaktion: eine konkrete Zusage, etwa 72 Stunden
• Fix-Zeitraum: nach Schwere gestaffelt, etwa 30 Tage für Critical bei Offenlegung nach 90 Tagen
• Unterstützte Versionen: eine Tabelle, welche Minor-Versionen noch Patches bekommen

Dazu gehört präventives Scannen der Abhängigkeiten: Dependabot oder Renovate für Updates, Trivy im CI für Images und Lockfiles. Mein GitLab-Review-Bot hatte das von Anfang an, und dort ist nie Nachrüstarbeit angefallen. Warum CVE-Scanner allein nicht genügen, steht in [[KI-Security-Updates-Artikel]]. 

6. Community Health messen und darauf reagieren

Das CHAOSS-Projekt definiert Metriken für Projektgesundheit. Fünf davon sind auch für ein Einzelprojekt handlungsleitend: Time to First Response, Time to Merge, Anzahl aktiver Beitragender (inklusive Reviews und Triage, nicht nur Commits), Bus Factor und das Verhältnis von Stale zu offenen Issues. 

Bei meinen Context-Engineering-Tools liegt der Bus Factor bei 1, eine GOVERNANCE.md existiert nicht, CODEOWNERS enthält einen Namen. Die übrigen Metriken sehen gut aus, weil ein einzelner Maintainer schnell reagiert — bis er es nicht mehr tut. Ich persönlich halte den Bus Factor für die Zahl, die sich am schwersten verbessern lässt: nicht durch mehr Arbeit, sondern nur dadurch, dass man Review-Rechte und Release-Schlüssel abgibt. 

Messen allein ändert nichts: Stale-Bot konfigurieren, good first issue pflegen, aktive Beitragende in MAINTAINERS eintragen und ab etwa drei Maintainern eine GOVERNANCE.md mit Rollen und Konfliktlösung schreiben. 

7. Dokumentation hat ein zweites Publikum

Seit etwa zwei Jahren liest ein Coding-Agent das Repository oft vor dem ersten Menschen: Er erzeugt Integrationscode, bevor jemand die Library überhaupt evaluiert. Was in der Dokumentation fehlt, erfindet er. Für diesen Leser gibt es eigene Konventionen. AGENTS.md beschreibt sich so: 

„A simple, open format for guiding coding agents, used by over 60k open-source projects.“ 

Die Datei liegt im Repository-Root und enthält, was aus dem Code nicht ableitbar ist: Build- und Testbefehle, Projektstruktur, Konventionen, Sperrzonen. Für Projektwebsites gibt es mit llms.txt ein Gegenstück. 

Daraus ergibt sich eine Rückkopplung: Agenten schreiben die Dokumentation, die Agenten lesen — generierte READMEs und AGENTS.md-Dateien, von einem Modell erzeugt, vom nächsten konsumiert. Es fehlt die Korrekturschleife. Ein Mensch, der einem falschen Codebeispiel folgt, öffnet ein Issue; ein Agent probiert eine Variante und macht weiter. Dagegen hilft ausführbare Dokumentation: Beispiele, die im CI gegen die aktuelle Version laufen. 

Agenten sind auch Produzenten. Daniel Stenberg hat für curl dokumentiert, was das für Punkt 5 bedeutet: 415 Vulnerability-Reports, davon 64 echte Sicherheitsprobleme (Januar 2024), bei wachsendem Anteil maschinengenerierter Falschmeldungen. 

„Better crap is worse — when reports are made to look better and to appear to have a point, it takes a longer time for us to research and eventually discard it.“ 

Mit diesem Volumen sind 72 Stunden Erstreaktion schwer zu halten. Praktikabel ist, in der SECURITY.md KI-Unterstützung offenlegen zu lassen und Reports ohne reproduzierbaren Proof of Concept direkt zu schließen. Von den sieben Punkten halte ich persönlich diesen für den folgenreichsten: Ein Teil der Dokumentation richtet sich an Leser, die nicht nachfragen und Fehler stillschweigend weiterverarbeiten. 

Checkliste vor dem ersten Announce

• [ ] README: Zweck, Installation, Quickstart, Lizenz, Maintenance-Status, Links zu Guidelines/Security/Changelog
• [ ] LICENSE, passend zum Projektziel
• [ ] CONTRIBUTING.md: Workflow, Templates, Erwartungen
• [ ] SECURITY.md: Meldeweg, Reaktionszeiten, unterstützte Versionen
• [ ] CHANGELOG.md ab v0.1.0
• [ ] CI: Tests, Lint, Build, Dependency-Scan auf jedem PR
• [ ] Release-Workflow automatisiert: Tag → Changelog → Artefakte → Publish
• [ ] Issue- und PR-Templates
• [ ] CODEOWNERS
• [ ] AGENTS.md: Build- und Testbefehle, Konventionen, Sperrzonen
• [ ] Codebeispiele aus README und Quickstart laufen im CI
• [ ] GOVERNANCE.md ab etwa drei Maintainern

Nach dem Launch

Die Veröffentlichung ist Tag 1, der Rest ist Betrieb: 

Die Archivierungsfrage ist der unbequemste Teil dieses Takts. Ein Projekt rechtzeitig auf archived zu setzen ist ehrlicher, als es zwei Jahre halbtot weiterzuführen. 

Fazit

Der Aufwand lohnt nicht für jedes Repository. Ein 200-Zeilen-Skript ohne Nutzer braucht keine GOVERNANCE.md; dort genügen Lizenz, README und ein ehrliches Maintenance-Badge. Die Liste skaliert mit dem Anspruch. Für Punkt 7 gilt das mit einer Einschränkung: AGENTS.md und llms.txt sind Konventionen, keine Standards, und eine veraltete AGENTS.md schadet mehr als keine, weil sie gelesen und geglaubt wird. 

Garantien gibt es trotzdem nicht. Vollständige Guidelines und saubere Releases ziehen keine Beitragenden an, sie verhindern nur, dass die Leute, die ohnehin kommen, an Formalien scheitern. Der Unterschied zeigt sich im Betrieb: Ein öffentliches Repository ohne diese Entscheidungen produziert Issues ohne Kontext, nicht mergebare PRs und Nutzer, die ohne Rückmeldung abwandern. Ein Projekt, das sie getroffen hat, übersteht den Wechsel seines Erstellers. 

Welches eurer Repositories ist öffentlich, aber nicht veröffentlicht? Schreibt’s in die Kommentare.

Links

• shields.io (Maintenance-Badges): https://shields.io
• Choose a License: https://choosealicense.com
• Semantic Versioning 2.0.0: https://semver.org
• Keep a Changelog: https://keepachangelog.com
• CHAOSS (Community-Health-Metriken der Linux Foundation): https://chaoss.community
• GitHub Open Source Guides: https://opensource.guide
• Dependabot Security Updates: https://docs.github.com/en/code-security/dependabot/dependabot-security-updates/about-dependabot-security-updates
• Renovate Configuration Options: https://docs.renovatebot.com/configuration-options/
• Trivy: https://trivy.dev/
• AGENTS.md (laut Projektseite 60.000+ Projekte): https://agents.md
• llms.txt (Jeremy Howard, September 2024): https://llmstxt.org
• Daniel Stenberg, „The I in LLM stands for intelligence“: https://daniel.haxx.se/blog/2024/01/02/the-i-in-llm-stands-for-intelligence/