Das Reddit-Forum r/opensource hat seine Einreichungsregeln verschärft. Beiträge über KI-Projekte sind dort ab sofort nicht mehr erlaubt — unabhängig davon, ob ein Projekt mit KI erstellt wurde, KI-gestützt entstanden ist oder selbst für KI-Anwendungen gedacht ist. Hinzu kommen weitere Einschränkungen: Vorgestellte Projekte müssen mindestens ein Jahr alt sein und mehrere Mitwirkende haben. Beiträge, die nicht auf Englisch verfasst sind, werden ebenfalls ausgeschlossen.
Die Reaktionen fielen deutlich aus. Als Gegenbewegung entstand bereits ein Konkurrenzforum unter dem Namen r/TrueOpenSource. Die Debatte dreht sich damit nicht nur um KI, sondern auch um die Frage, wer in einer Community definiert, was als ernsthaftes Open-Source-Projekt gilt.
Was hinter den Regeln steckt
Die Kombination der neuen Kriterien ist aufschlussreich. Ein Mindestalter von einem Jahr und mehrere Mitwirkende sind klassische Reifeindikatoren: Sie lassen sich schwer vortäuschen und sagen etwas darüber aus, ob ein Projekt gepflegt wird. Der Ausschluss von KI-Themen wirkt dagegen pauschal — er trifft auch Projekte, die solide Arbeit enthalten.
Erkennbar ist dennoch ein Muster: Communities reagieren auf eine wachsende Menge an Einreichungen, deren Qualität und Betreuungsperspektive sich kaum prüfen lässt. Wenn ein Repository innerhalb weniger Tage entsteht, von einer einzelnen Person stammt und keine erkennbare Historie hat, fehlt der Community jeder Anhaltspunkt für eine Einschätzung. Die neuen Regeln verlagern die Beweislast damit auf Nachweisbarkeit statt auf Technologie.
Warum das für Unternehmen relevant ist
In vielen Entwicklungsteams gehören KI-Assistenten inzwischen zum Alltag — für Boilerplate-Code, also wiederkehrende Standardstrukturen, für Testfälle oder für Refactorings. Das ist unproblematisch, solange die Ergebnisse geprüft, verstanden und verantwortet werden. Problematisch wird es, wenn die Entstehungsgeschichte eines Codestücks nicht mehr nachvollziehbar ist.
Genau hier setzen auch Audits an. Ob interne Code-Reviews, Sicherheitsprüfungen oder Due-Diligence-Prozesse bei Übernahmen: Gefragt wird nach Herkunft, Lizenzlage und Wartbarkeit. Wer auf diese Fragen keine belastbare Antwort hat, steht unabhängig von der tatsächlichen Codequalität schlecht da. Die Reddit-Episode ist dafür nur ein frühes und sichtbares Beispiel.
Dokumentation als Vertrauensanker
Die praktische Konsequenz liegt weniger im Verzicht auf KI als in sauberer Nachvollziehbarkeit. Nützlich sind dabei einige wenige, konsequent gepflegte Punkte:
- Herkunft festhalten: Dokumentieren Sie, welche Komponenten übernommen, welche generiert und welche manuell entwickelt wurden — nicht pro Zeile, aber auf Modulebene.
- Review-Spuren sichern: Pull Requests mit nachvollziehbaren Kommentaren und benannten Prüferinnen und Prüfern zeigen, dass generierter Code tatsächlich bewertet wurde.
- Lizenzen klären: Abhängigkeiten und ihre Lizenzbedingungen gehören in eine gepflegte Übersicht, nicht in eine mündliche Absprache.
- Tests statt Behauptungen: Eine funktionierende Testabdeckung belegt Qualität unabhängig davon, wie der Code entstanden ist.
- Wartungsverantwortung benennen: Wer pflegt das Projekt in zwölf Monaten? Diese Frage sollte dokumentiert beantwortet sein.
Reife lässt sich nicht beschleunigen
Die Anforderung, dass ein Projekt mindestens ein Jahr existiert und mehrere Mitwirkende hat, wirkt auf den ersten Blick willkürlich. Sie beschreibt aber etwas, das in Unternehmensprojekten genauso zählt: Ein System, das nur eine Person versteht, ist ein Risiko. Ein System, das nie einen Release-Zyklus, ein Sicherheitsupdate oder eine Fehlerwelle überstanden hat, ist unerprobt.
KI-gestützte Entwicklung verkürzt die Zeit bis zum ersten lauffähigen Stand erheblich. Sie verkürzt aber nicht die Zeit, die ein System braucht, um sich im Betrieb zu bewähren. Diese Lücke zwischen schneller Entstehung und langsamer Bewährung ist der eigentliche Konfliktpunkt — in Foren wie in Projektbudgets.
Umgang mit pauschaler Skepsis
Für Unternehmen, die Open-Source-Komponenten veröffentlichen oder Teile ihrer Arbeit in Communities einbringen, ändert sich die Ausgangslage. Pauschale Vorbehalte gegenüber KI-Bezügen lassen sich nicht durch Argumentation auflösen, sondern nur durch Substanz: eine Commit-Historie über längere Zeiträume, mehrere beteiligte Personen, sichtbare Reaktionen auf Issues.
Gleichzeitig zeigt die Gründung eines Konkurrenzforums, dass sich solche Regeln nicht durchsetzen, ohne Gegenbewegungen auszulösen. Die Community ist in dieser Frage gespalten. Darauf zu setzen, dass sich eine bestimmte Haltung durchsetzt, wäre riskant. Sinnvoller ist es, Projekte so aufzustellen, dass sie unter beiden Maßstäben bestehen.
Einordnung
Für Web- und Softwareprojekte bedeutet das: Der Einsatz von KI-Werkzeugen wird zunehmend nicht am Ergebnis gemessen, sondern an der Nachvollziehbarkeit des Weges dorthin. Wer Herkunft, Prüfung und Wartungsverantwortung sauber dokumentiert, muss weder Audits noch kritische Communities fürchten. Wer das versäumt, verliert Vertrauen genau dort, wo technische Qualität allein nicht mehr ausreicht.
