SelfLinux Einleitung Die Kathedrale und der Basar Abschnitt 9 | SelfLinux-0.13.0

| Die Kathedrale und der Basar | Autor Formatierung OPL

#### 9 Voraussetzungen für den Basar-Stil

Frühe Kritiker und das Testpublikum für dieses Dokument fragten sehr oft nach den Voraussetzungen für eine erfolgreiche Basar-geführte Entwicklung, darunter sowohl Fragen nach der Qualifikation für den Projektleiter und den Zustand des Codes zum Zeitpunkt der Veröffentlichung für die Gemeinde der Mit-Entwickler.

Es sollte klar sein, dass man nicht von Null an im Stile des Basars entwickeln kann [ IN]. Man kann am Basar testen, debuggen und verbessern, aber es wäre sehr schwer, ein Projekt im Basar-Modus zu beginnen. Linus versuchte das gar nicht erst, und ich auch nicht. Ihre keimende Entwicklergemeinde muss etwas Lauffähiges und Testbares haben, um damit spielen zu können.

Wenn man mit dem Aufbau der Gemeinde beginnt, benötigt man ein herzeigbares, überzeugendes Versprechen. Ihr Programm braucht nicht besonders gut zu funktionieren. Es kann sehr ungeschliffen, von Bugs geplagt, unvollständig und spärlich dokumentiert sein. Was es aber nicht verfehlen darf, ist, (a) zu laufen, und (b) potentielle Mit-Entwickler davon zu überzeugen, dass es sich in absehbarer Zukunft zu etwas wirklich ordentlichem entwickeln lässt.

Linux und fetchmail gingen mit starken und attraktiven Designs an die Öffentlichkeit. Viele Menschen haben hier vom Basarmodell, wie ich es präsentierte, die korrekte Auffassung, dass dies das allerwichtigste ist und zogen daraus den Schluss, dass für den Projektleiter ein hohes Maß an Intuition für gutes Design und viel Cleverness unentbehrlich sind.

Linus aber holte sich sein Design von Unix. Ich erbte meines vom Vorfahren popclient (obwohl es sich später noch ganz schön ändern sollte, und zwar überproportional im Vergleich zu Linux). Muss der Leiter/Koordinator eines Entwicklungsbasars wirklich über herausragendes Talent für Design verfügen oder kann er damit durchkommen, das Designtalent anderer zu nutzen?

Ich denke, dass es für den Koordinator nicht lebenswichtig ist, ein Design von atemberaubender Brillanz zu stiften, dass es aber für ihn lebenswichtig ist, ein gutes Design anderer als solches zu erkennen.

Sowohl das Linux- als auch das fetchmail-Projekt liefern Indizien dafür. Linus, der kein besonders origineller Designer ist (wie vorher schon erklärt), zeigte doch ein eminentes Talent für das Erkennen guter Designs und für die Integration in den Linux-Kernel. Und ich habe auch schon beschrieben, wie die mächtigste, einzelne Design-Idee hinter fetchmail (SMTP Forwarding) Eingang in meine Software gefunden hat.

Das erste Publikum dieses Dokuments machte mir durch den Hinweis ein Kompliment, dass ich für das Unterschätzen von Originalität beim Designen für Basar-Projekte anfällig wäre, da ich selbst einiges davon besäße und daher als selbstverständlich nähme. Das könnte stimmen; Design (im Gegensatz zu Coding und Debugging) ist sicherlich meine größte Stärke.

Das Problem mit der Cleverness und der Originalität beim Software-Design ist aber, dass beides zur Gewohnheit wird -- man beginnt, die Dinge auszuschmücken und zu verkomplizieren, obwohl man sie doch eigentlich robust und simpel halten sollte. Mir sind schon ganze Projekte um die Ohren geflogen, weil ich eben diesen Fehler machte, aber bei fetchmail schaffte ich es, mich zurückzuhalten.

Ich glaube also, dass das fetchmail-Projekt zum Teil deswegen erfolgreich war, weil ich meine Tendenz, clever zu sein, unter Kontrolle hielt, was (wenn schon sonst nichts) ein Einwand gegen die Wichtigkeit von Design-Originalität für Basar-Erfolge ist. Denken Sie nur an Linux: nehmen wir an, Linus Torvalds hätte versucht, sämtliche grundlegenden Innovationen im Design von Betriebssystemen während der Entwicklung selbst zu erfinden; erscheint es dann als wahrscheinlich, dass der resultierende Kernel so stabil und erfolgreich wäre wie der, den wir haben?

Ein gewisses Minimum an Kompetenz für Design und Codierung ist natürlich notwendig, aber ich erwarte, dass fast jeder automatisch über mehr als dieses Minimum verfügt, der ernsthaft über die Gründung eines Basar-Projektes nachdenkt. Der interne Reputations-Markt der Open Source-Gemeinde übt einen subtilen Druck auf die Leute aus, und verhindert, dass sie den Keim für ein Unternehmen legen, dem sie nicht gewachsen sind. Bisher hat das allem Anschein nach tadellos funktioniert.

Es gibt aber noch eine weitere Kompetenz, die normalerweise nicht mit der Entwicklung von Software in Verbindung gebracht wird, die aber für Basar-Projekte ebenso wichtig ist wie Findigkeit beim Design -- oder sogar noch wichtiger. Der Koordinator oder Leiter eines Basar-Projekts muss mit Leuten umgehen und kommunizieren können.

Das sollte einleuchten. Um eine Entwicklergemeinde aufzubauen, muss man Menschen begeistern und für seine Sache interessieren können und bewirken, dass sie mit dem eigenen Anteil am Aufwand zufrieden sind. Technischer Glamour wird das meiste der Beinarbeit auf diesem Weg erledigen, aber er alleine ist bei weitem nicht die ganze Geschichte. Der persönliche Eindruck, den man vermittelt, ist ebenfalls ausschlaggebend.

Es ist kein Zufall, dass Linus ein netter Kerl ist, der bewirkt, dass die Leute ihn mögen und ihn unterstützen wollen. Es ist kein Zufall, dass ich ein extrovertierter und energischer Mensch bin, der das Arbeiten in der Gruppe sehr genießt und einiges von der Selbstdarstellung und dem Instinkt eines Kabarettisten hat. Um das Basarmodell zum Funktionieren zu bringen, hilft es enorm, wenn man wenigstens ein bisschen Charme hat, um die Menschen für sich einzunehmen.