Beim vierten Internationalen Linux-Kongress am 22. Mai 1997 in Würzburg trug Eric S. Raymond erstmals sein Essay über Open Source Entwicklung «The Cathedral and the Bazaar» vor. Darin verglich Raymond anhand eigener Erfahrungen die Vor- und Nachteile der im Open-Source Bereich verbreiteten Entwicklungsmethode des «Basars» mit dem Vorgehen bei der Entwicklung von kommerziell orientierter Software. Obwohl Raymond 1993 bereits zehn Jahre Erfahrung in der Entwicklung von Open-Source-Software hatte, war er der Meinung, dass ab einer gewissen Komplexitätsstufe nur ein zentralistischer Ansatz mit guter Vorausplanung ein grosses Projekt zum Erfolg führen könne. Er glaubte, wichtige Software wie Betriebssysteme oder ein grosser Editor wie Emacs müssten so gebaut werden wie Kathedralen, sorgsam geplant und von einem kleinen Team entwickelt ohne die vorzeitige Freigabe von Beta-Versionen. Dem gegenüber erinnerte Linus Torvald's Stil der totalen Delegation von Aufgaben und häufigen und frühen Freigaben an einen wild durcheinander plappernden Basar mit verschiedenen Zielsetzungen und Ansätzen. Wenn jeder liefert, was er will, konnte das doch nicht zu einem stabilen System führen.
Raymond wollte es wissen; er beschloss sein nächstes Projekt nach eben diesem Basar-Stil durchzuführen. Es ging darum, einen neuen POP3 Email-Client zu entwickeln, nämlich das Programm fetchmail. Im Laufe des Projekts formulierte Raymond 19 Erkenntnisse, die einen guten Einblick in die Basar-Kultur geben:
- Jede gute Software wird von einem Entwickler geschrieben, der ein persönliches Problem lösen will.
- Gute Programmierer wissen, was sie schreiben müssen. Brillante wissen, was sie neu schreiben müssen (und was sie wiederverwenden können).
- Plane, eine Version zu verwerfen; du wirst es sowieso tun.
- Wenn du die richtige Einstellung hast, werden dich interessante Probleme finden.
- Wenn du das Interesse an einem Programm verlierst, ist es deine Pflicht, dieses einem kompetenten Nachfolger zu übergeben.
- Wenn du deine Benutzer als Mitprogrammierer betrachtest, ist dies der einfachste Weg zu schneller Verbesserung und effizientem Debugging.
- Veröffentliche früh. Veröffentliche häufig. Und höre auf die Benutzer.
- Mit einer hinreichend grossen Gruppe von Betatestern und Mitentwicklern wird fast jedes Problem schnell erkannt und die Lösung von jemandem gefunden.
- Schlaue Datenstrukturen und einfacher Code (im englischen Original: „dumb code“) funktionieren viel besser als andersherum.
- Wenn du deine Betatester wie deine wertvollste Ressource behandelst, werden sie dies auch werden.
- Fast so gut wie eigene gute Ideen zu haben, ist es, gute Ideen von den Benutzern zu erkennen. Manchmal ist letzteres besser.
- Meist entstehen die brillanten Lösungen aus der Erkenntnis, dass das Problem falsch verstanden wurde.
- Perfektion (im Design) ist nicht erreicht, wenn man nichts mehr hinzufügen kann, sondern wenn nichts mehr entfernt werden kann.
- Jedes Tool soll so funktionieren, wie erwartet. Aber ein wirklich gutes Tool ermöglicht Verwendungszwecke, an die du niemals gedacht hättest.
- Wenn du Schnittstellencode schreibst, verhindere um jeden Preis, den Datenstrom zu verändern – und verwirf nur etwas, wenn dies der Empfänger verlangt.
- Wenn deine Programmiersprache nicht ansatzweise Turing-vollständig ist, kann syntaktischer Zucker dein Freund sein.
- Ein Sicherheitssystem ist nur so sicher wie sein Geheimnis. Vermeide Pseudogeheimnisse.
- Um ein interessantes Problem zu lösen, suche eines.
- Mit ausreichend guter Kommunikation, wie über das Internet, und Führung ohne Zwang, sind viele Köpfe immer besser als einer.
Ob diese Erkenntnisse nach 23 Jahren auch heute noch ihre Gültigkeit haben, kann jeder Entwickler für sich selbst entscheiden. Ich selbst würde alle von ihnen unterschreiben.
Quelle: https://www.selflinux.org/selflinux/pdf/die_kathedrale_und_der_basar.pdf
Bildnachweis: Giulia Forsythe, CC0 1.0 Universell
