Die Kathedrale und der Basar

Veröffentlicht auf 16. Februar 2018

Der Artikel "Die Kathedrale und der Basar" (Cathedral and Bazaar) ist ein Artikel von Eric S. Raymond, einem Open Source Entwickler der ersten Stunde, welcher die Arbeitsweisen von zentral organisierter Softwareentwicklung (Kathedralen, z.B. damals Emacs, genau geplant, inkrementell verbessert, hierarchische Organisation) mit der von einigen dezentralen, aber erfolgreichen Open Source Projekten (Basar, z.B. Linux oder fetchmail, frühe und häufige Freigaben, verschiedene Ziele, jeder kann mitmachen) vergleicht.

Als Kathedralenbauer hatte er gute Erfahrungen gemacht und erlebte einen ausgesprochenen Schock, als er das erste Mal mit dem Basar konfrontiert war. Vor allem, dass es dennoch funktionierte.

Die gelernten Lektionen im Basar fasst er zusammen als
1. Jede gute Software beginnt mit den persönlichen Sehnsüchten eines Entwicklers.
2. Gute Programmierer wissen, welchen Code sie schreiben sollen. Großartige Programmierer wissen welchen Code sie umschreiben (und recyceln) können.
3. "Plane eine Version für den Papierkorb; auf die eine oder andere Art machst du das sowieso." (Frederick P. Brooks, "Vom Mythos des Mann-Monats", Kapitel 11, in Addison-Wesleys Übersetzung von Arne Schäpers und Armin Hopp)
4. Mit der richtigen Einstellung werden interessante Probleme dich finden.
5. Sobald man das Interesse an seinem Programm verliert, ist es die letzte Pflicht, es einem kompetenten Nachfolger zu überlassen.
6. Die Anwender als Mit-Entwickler zu sehen, ist der Weg zu schnellen Verbesserungen und Fehlerbehebungen, der die geringsten Umstände macht.
7. Früh freigeben. Oft freigeben. Seinen Anwendern zuhören.
8. Wenn man einen ausreichend großen Stamm an Betatestern und Mit-Entwicklern hat, wird jedes Problem schnell identifiziert und die Lösung jedem offensichtlich sein.
9. Smarte Datenstrukturen und dummer Code funktionieren viel besser als umgekehrt.
10. Wenn man seinen Betatester wie die wertvollste Ressource behandelt, werden sie als Redaktion darauf zur wertvollsten Ressource werden.
11. Das Zweitbeste nach eigenen guten Ideen, ist das Erkennen von guten Ideen von Benutzern. Manchmal ist letzteres sogar das bessere.
12. Oft stammen die hervorragendsten und innovativsten Lösungen aus der Erkenntnis, dass die ganze Vorstellung vom Problem falsch war.
13. "Perfektion (im Design) ist nicht erreicht, wenn es nichts mehr hinzuzufügen gibt, sondern wenn es nichts mehr wegzunehmen gibt." (Antoine de Saint-Exupéry)
14. Jedes Tool sollte in der erwarteten Weise nützlich sein, aber wirklich großartige Tools bieten darüber hinaus unerwarteten Nutzen.
15. Beim Entwickeln von Gateway-Software jeglicher Art ist jeder Aufwand gerechtfertigt, um den Datenstrom so wenig wie möglich zu beeinflussen -- und man darf Informationen niemals wegwerfen, außer der Empfänger verlangt es so!
16. Wenn Ihre Programmiersprache in keiner Weise Turing-vollständig ist, können Sie sich mit syntaktischer Glasur anfreunden.
17. Ein Sicherheitssystem ist nur so sicher, wie seine Geheimnisse. Hüten Sie sich vor Pseudo-Geheimnissen.
18. Um ein interessantes Problem zu lösen, fängt man mit einem Problem an, das einen selbst interessiert.
19. Unter der Voraussetzung, dass der Entwicklungskoordinator ein Medium zur Verfügung hat, dass wenigstens so gut ist wie das Internet, und dieser Koordinator weiß, wie man ohne Zwang führt, werden viele Köpfe zwangsläufig besser arbeiten als nur einer.

 

Weitere definierte und verwendetet Gesetze und Prinzipien:

Wirkliche Kommunikation kann es nur zwischen Gleichgestellten geben, weil Untergebene in aller Regel für das Erzählen von gefälligen Lügen belohnt werden, als für das Sagen der Wahrheit. Autoritär organisierte Organisationen neigen daher gerne zum Realitätsverlust unter Entscheidungsträgern. Eine Weiterentwicklung des snafu-Prinzips (Situation normal -- all fucked up).

Linus' Gesetz:
"Given enough eyeballs, all bugs are shallow."
Alle Bugs sind trivial, wenn man nur genügend Entwickler hat.

Delphi-Effekt:
Die gemittelte Meinung einer Masse von etwa gleich kompetenten Beobachtern macht zuverlässigere Vorhersagen, als die eines einzelnen willkürlich herausgepickten Beobachters.

Prinzip des Befehlens:
Disziplin, Befehlen, Bestrafen, Schelten.

Prinzip der Übereinkunft:
Das Prinzip des Befehlens funktioniert bei freien Menschen nicht. Sie werden durch ernst gemeinte Anstrengungen übereinstimmenden Willens, Kooperation und wetteifern zur Zusammenarbeit hin zu einem Ziel geleitet. Ursache ist meistens nicht die ökonomische Natur, sondern die Pflege des jeweiligen Egos und ihrer Reputation.

Für alle die mehr erfahren wollen, kann ich nur empfehlen, sich den sehr lesenswerten Artikel zu Gemüte zu führen.
Quelle: http://www.selflinux.org/selflinux/pdf/die_kathedrale_und_der_basar.pdf
Übersetzt aus dem Originaltext vom 8.8.1999 von Reinhard Gantar
Lizenz: OPL

 

Geschrieben von Robert Bullinger

Veröffentlicht in #Projektmanagement, #Expertise, #Softwareentwicklung, #Agil, #Prozessmodelle

Repost0
Um über die neuesten Artikel informiert zu werden, abonnieren:
Kommentiere diesen Post