Nach DeepSeek Harness liest man erneut die Gruppe von Menschen, die Open Source als Erste definiert haben.

Am 19. August veröffentlichte OpenAI Codex Harness vollständig quelloffen. Eine Woche zuvor erreichte DeepSeek Harness mit rasanter Geschwindigkeit bereits über 100.000 GitHub-Stars.

Indem sie den Weg zur Open-Source-Entwicklung einschlagen, haben sie sich aktiv in einen größeren „Marktplatz“ begeben.

Eric S. Raymond ist einer der ersten Prediger der Open-Source-Bewegung. Bereits 1997 stellte er in dem Artikel *Die Kathedrale und der Basar* zwei Modelle der Softwareentwicklung vor: Die Kathedrale wird von einer kleinen Gruppe hinter verschlossenen Türen gebaut, wiederholt verfeinert und dann erst der Öffentlichkeit vorgestellt; der Basar hingegen erlaubt die Beteiligung aller Beteiligten und entwickelt sich gemeinsam durch fortlaufende Veröffentlichungen, Rückmeldungen und Korrekturen weiter.

Nach der Veröffentlichung des quelloffenen Kimi K2 verglich der legendäre Silicon-Valley-Investor Bill Gurley das chinesische Open-Source-Ökosystem auch mit einem Gemüsemarkt, auf dem bewährte Praktiken gemeinsam geteilt werden.

Raymond versuchte damit zu erklären, warum die scheinbar laute und sogar chaotische Linux-Community nicht auseinandergefallen ist, sondern immer stärker geworden ist und die Welt durch Open Source verändert hat. Er stellte fest, dass Innovation nicht unbedingt von einer feststehenden Organisation entworfen werden muss, sondern auch aus den lokalen Beiträgen einer großen Anzahl von Teilnehmern entstehen kann.

Fast dreißig Jahre später erweitert KI die Grenzen des Basars erneut. Im Jahr 2025 wurden auf GitHub mehr als 121 Millionen neue Repositories erstellt, das ist die höchste Anzahl an Neuerstellungen in der Geschichte. Darunter befinden sich über 4,3 Millionen KI-bezogene Repositories.

In der Vergangenheit waren die Teilnehmer auf dem Basar Menschen. Heute treten immer mehr Agenten ebenfalls in diesen Bereich ein.

OpenAI führte einmal ein Experiment mit Codex durch: In fünf Monaten erstellten drei Ingenieure zusammen mit Codex etwa eine Million Zeilen Code und 1500 Pull Requests, ohne dass eine einzige Codezeile von Menschen handgeschrieben wurde.

Dadurch gewinnen viele der Erkenntnisse aus *Die Kathedrale und der Basar* wieder an Bedeutung. Am bekanntesten ist das Linus-Gesetz: Wenn genügend Augen vorhanden sind, werden alle Bugs vollständig sichtbar. Je häufiger Veröffentlichungen und Tests stattfinden und je mehr Menschen teilnehmen, desto leichter lassen sich Probleme entdecken. Open-Source-Communities können um ein Vielfaches mehr technische Arbeitskräfte für ein Problem mobilisieren als die geschlossene Quellcode-Welt.

Wir betreten gerade einen noch größeren Basar.

01

Die Kathedrale und der Basar

Linux war revolutionär.

1991 konnte niemand ahnen, dass ein weltklasse Betriebssystem wie durch Zauberhand aus der Freizeit-Hacking-Arbeit von Tausenden von Entwicklern auf der ganzen Welt entstehen würde?

Sie waren über die ganze Welt verteilt und nur durch wenige dünne Fäden des Internets miteinander verbunden.

Zumindest habe ich das nicht erwartet.

Was wir heute gemeinhin als „Linux-System“ bezeichnen, war ursprünglich nur ein freier Kernel, der von dem finnischen Studenten Linus Torvalds entwickelt wurde. Mit der Entwicklung des Internets ist es zu einer Open-Source-Community geworden, an der sich Entwickler aus der ganzen Welt beteiligen. Die Videos, die Sie heute anschauen, die KI, die Sie verwenden, und die Websites, die Sie besuchen, laufen mit hoher Wahrscheinlichkeit im Hintergrund auf Linux.

Vorher habe ich bereits zehn Jahre lang an der Unix-Entwicklung teilgenommen. Ich war einer der ersten Mitwirkenden von GNU und habe einige Programme entwickelt, die bis heute weit verbreitet sind.

Ich dachte, ich wüsste, wie Open-Source-Software entwickelt werden sollte, aber Linux hat viele Dinge, von denen ich glaubte, sie zu verstehen, auf den Kopf gestellt.

Jahrelang habe ich das Credo von Unix verfolgt: Probleme mit Werkzeugen lösen, schnell einen Demo erstellen und Programme in fortlaufenden Iterationen weiterentwickeln. Aber ich glaubte auch, dass sobald die Komplexität einen bestimmten Schwellenwert überschreitet, eine stärker zentralisierte Planung erforderlich ist.

Ich war überzeugt, dass die wichtigsten Systeme wie der Bau einer Kathedrale abgeschlossen werden müssen: Wenige einsame, herausragende Meister arbeiten hinter verschlossenen Türen und verfeinern das Werk wiederholt; solange der Zeitpunkt nicht gekommen ist, wird keine neue Version veröffentlicht.

Daher hat mich die Entwicklungsweise dieses Studenten sehr überrascht.

Linux hatte kein ruhiges, ernstes Kathedralenprojekt, sondern glich eher einem lauten großen Basar, der voller Menschen mit unterschiedlichen Zielen und Methoden war. Jeder konnte etwas einreichen.

Doch genau aus diesem Basar entstand ein kohärentes, stabiles System wie durch eine Reihe von Wundern.

Als ich allmählich verstand, wie die Linux-Welt funktioniert, wollte ich nicht nur an einzelnen Projekten teilnehmen, sondern auch eine größere Frage verstehen: Warum ist die Linux-Welt nicht im Chaos auseinandergefallen, sondern stattdessen mit einer Geschwindigkeit, die sich Kathedralenbauer kaum vorstellen können, immer stärker geworden?

Bis 1996 begann ich, das zu verstehen.

Ich hatte die perfekte Gelegenheit, meine Theorie zu testen. Ein Open-Source-Projekt wurde mir übergeben, und ich konnte bewusst versuchen, es im Basar-Stil zu betreiben. Ich tat dies, und das Ergebnis war sehr erfolgreich.

Im Folgenden ist die Geschichte dieses Projekts beschrieben.

02

Die Bedeutung der Nutzer

Nutzer zu haben, ist eine großartige Sache.

Das liegt nicht nur daran, dass sie beweisen, dass Sie einen Bedarf decken und etwas richtig machen. Bei guter Verwaltung können sie auch zu Mitentwicklern werden.

Die Unix-Tradition hatte einen Vorteil, und Linux hat diesen Vorteil zu einem erfreulichen Extrem getrieben: Viele Nutzer sind selbst Hacker.

Der Code ist offen. Mit ein wenig Ermutigung helfen Ihnen die Nutzer, Probleme zu diagnostizieren, Verbesserungsvorschläge zu machen und den Code viel schneller zu verbessern, als Sie es alleine könnten.

Bevor Linus Torvalds uns eine andere Möglichkeit gezeigt hat, haben fast alle in der Open-Source-Welt stark unterschätzt, wie viel diese Methode noch leisten kann, wenn die Nutzerzahl stetig wächst und die Systemkomplexität ansteigt.

Ich bin sogar der Meinung, dass das Klügste und nachhaltigste von Linus nicht der Linux-Kernel selbst ist, sondern das von ihm erfundene Linux-Entwicklungsmodell.

Einmal habe ich ihm diese Ansicht persönlich mitgeteilt. Er lächelte und wiederholte einen Satz, den er oft sagt: „Ich bin ein sehr fauler Mensch und nehme gerne Anerkennung für Dinge entgegen, die andere wirklich tun.“

Faul wie ein Fuchs.

Rückblickend lassen sich die Linux-Methode und ihr Erfolg in der Entwicklung der GNU Emacs Lisp-Bibliothek und der Lisp-Code-Archive als Vorläufer finden.

Tatsächlich war meine persönlich erfolgreichste Erfahrung vor fetchmail das VC von Emacs. Es war eine E-Mail-gestützte Zusammenarbeit, die stark an Linux erinnerte, an der insgesamt vier Personen teilnahmen, von denen ich drei bis heute nie persönlich getroffen habe.

VC ist ein Frontend in Emacs für SCCS, RCS und später auch für CVS, das Ein-Klick-Versionskontrolloperationen bietet. Es hat sich aus einem sehr kleinen, groben sccs.el-Modus entwickelt, der von jemand anderem geschrieben wurde. Der Erfolg der VC-Entwicklung lag genau darin, dass im Gegensatz zu Emacs der Emacs Lisp-Code sehr schnell fortlaufende Runden von Veröffentlichungen, Tests und Verbesserungen durchlaufen konnte.

Unsere Geschichte ist kein Einzelfall.

Einige Softwareprodukte verwenden ebenfalls diese zweischichtige Architektur: Der Kern folgt dem Kathedralenmodell, während die Werkzeugsammlung dem Basarmodell folgt. MATLAB ist eines davon.

Personen, die MATLAB und ähnliche Produkte verwenden, stellen oft fest, dass dort, wo eine große und vielfältige Nutzergruppe teilnehmen und mitdenken kann, die wahre Dynamik, Begeisterung und Innovation zu finden ist.

03

Früh veröffentlichen, häufig veröffentlichen

Früh und häufig zu veröffentlichen ist ein entscheidender Schritt in der Linux-Entwicklung.

In der Vergangenheit hielten die meisten Entwickler, mich eingeschlossen, dies für unzuverlässig, sobald ein Projekt etwas komplexer wird. Frühe Versionen haben normalerweise viele Probleme, und die Geduld der Nutzer ist begrenzt – sie darf nicht gleich zu Beginn aufgebraucht werden.

Diese Ansicht hat auch dazu geführt, dass die kathedralenartige Entwicklung allgemein üblich wurde. Wenn das Hauptziel darin besteht, die Nutzer möglichst wenig mit Fehlern zu konfrontieren, sollten Sie eine Version erst nach einem halben Jahr oder noch länger veröffentlichen und zwischen den Veröffentlichungen wie ein Hund unermüdlich debuggen. Der C-Kern von Emacs wurde auf diese Weise entwickelt.

Aber ein Jahr später, als Linux breite Aufmerksamkeit erregte, entstand ein völlig anderes Paradigma.

Linus' offene Entwicklungspolitik stand genau im Gegensatz zum Bau einer Kathedrale. Die Internet-Code-Archive von Linux expandierten schnell, und mehrere Distributionen erschienen nacheinander. All dies wurde von einer beispiellosen Veröffentlichungsfrequenz des Kernsystems angetrieben.

Linus betrachtete die Nutzer als Mitentwickler, veröffentlichte früh und häufig und hörte den Meinungen der Nutzer sorgfältig zu.

Das war keine Innovation von Linus, diese Tradition gibt es in der Unix-Welt schon lange. Seine Innovation bestand darin, diese Methode auf ein Ausmaß und eine Intensität zu heben, die der Komplexität des von ihm entwickelten Systems entspricht.

Bereits 1991 hörten wir, dass er an einem Tag mehr als eine neue Version veröffentlichte. Denn er bemühte sich mehr als jeder andere, Mitentwickler zu fördern, und nutzte das Internet voll aus, um die Zusammenarbeit zu erleichtern.

Diese Methode funktionierte.

Aber warum hat sie funktioniert? Kann ich das auch nachahmen, oder ist das nur ein Genie wie Linus Torvalds möglich?

Linus ist natürlich ein erfahrener Hacker. Wie viele von uns können einen Betriebssystemkernel industriellen Niveaus von Grund auf bauen? Aber Linux brachte keine großen konzeptionellen Durchbrüche. Linus ist zumindest kein Genie für Designinnovationen wie Richard Stallman oder James Gosling.

Meiner Meinung nach ist Linus ein Genie im Bereich Ingenieurwesen und Umsetzung. Er hat einen sechsten Sinn, um Sackgassen zu vermeiden, und die wahre Fähigkeit, den schnellsten Weg von Punkt A nach Punkt B zu finden.

Das gesamte Linux strahlt diese Eigenschaft aus.

Er war der Ansicht, dass wenn die Gruppe von Beta-Testern und Mitentwicklern groß genug ist, fast jedes Problem schnell sichtbar wird, und es immer jemanden gibt, der es mühelos lösen kann.

Wenn genügend Augen vorhanden sind, werden alle Bugs vollständig sichtbar.

Ich nenne das das „Linus-Gesetz“.

Mein erstes Verständnis war, dass für jedes Problem jemand da sein wird, der es versteht. Aber Linus stimmte dem nicht ganz zu. Er sagte, die Person, die das Problem versteht und löst, ist normalerweise nicht die erste, die es entdeckt – „das Entdecken des Problems ist der schwierigere Schritt.“

Wenn Tausende von Entwicklern jede neue Version eifrig prüfen, wird alles einfacher.

Soziologen haben vor vielen Jahren herausgefunden, dass die durchschnittlichen Beiträge oder Urteile einer großen Anzahl von Teilnehmern oft zu besseren Ergebnissen führen als die eines einzelnen Individuums. Das wird als „Delphi-Methode“ bezeichnet.

Was Linus gezeigt hat, ist, dass die „Delphi-Methode“ uns auch bei der Komplexität eines Betriebssystems noch beherrschen kann.

Je mehr Nutzer es gibt, desto mehr Probleme werden entdeckt, da mehr Blickwinkel zur Prüfung zur Verfügung stehen. Wenn die Nutzer gleichzeitig Entwickler sind, wird dieser Effekt noch weiter verstärkt. Diese Vielfalt hilft, Doppelarbeit zu reduzieren.

Das Werkzeugkasten einer Person eignet sich genau zur Lösung dieses Problems. Für sie ist dieses Problem einfach.

Linus hat sich noch einen Trick vorbehalten. Wenn schwere Mängel auftreten könnten, erlaubt die Versionsnummerierung des Linux-Kernels den Nutzern, selbst zu wählen: Verwenden Sie die ältere „stabile“ Version, oder gehen Sie das Risiko von Fehlern ein, um die neuesten Funktionen in der aktuellsten Version zu nutzen.

Den Nutzern die Wahl zu geben, macht beide Versionen attraktiver.

04

Komplexität mit vielen Augen zähmen

Insgesamt kann der Basar den Debug-Prozess beschleunigen. Um zu verstehen, warum das funktioniert, muss man die tägliche Zusammenarbeit zwischen Entwicklern und Testern beobachten.

Nutzer, die sich nicht für den Quellcode interessieren, neigen dazu, nur oberflächliche Symptome zu melden. Sie betrachten die Laufzeitumgebung als selbstverständlich, sodass sie oft wichtige Hintergrundinformationen übersehen und selten eine Reihe von Schritten angeben, mit denen sich der Fehler stabil reproduzieren lässt.

Tester schauen von außen hinein, während Entwickler von innen heraus schauen. In geschlossenen Entwicklungsmodellen sind beide in ihren jeweiligen Rollen gefangen, reden aneinander vorbei und werden leicht gegeneinander verärgert.

Open Source bricht diese Fesseln.

Beide Seiten können ein gemeinsames Modell auf der Grundlage des Quellcodes aufbauen, was die Kommunikation erheblich erleichtert.

Wenn die Fehlerbedingungen auf Quellcodeebene beschrieben werden können, auch unvollständig, lassen sich die meisten Fehler erfassen. Wenn einer Ihrer Beta-Tester darauf hinweisen kann: „In Zeile nnn gibt es ein Randproblem“ oder