Vortrag von Alan Cox
Donnernder Applaus empfing den bekannten Kernel-Entwickler Alan Cox, als dieser Punkt 12 Uhr das Podium des Saals 2 im Konferenzzentrum A betrat. Der Saal war mit schätzungsweise 700 Besuchern bis auf den letzten Platz besetzt.
Thema von Alans Vortrag "Dear Mr. Brooks", den er bereits auf einer anderen Linux-Veranstaltung zum Besten gegeben hatte, war das Software-Entwicklungsmodell der Open-Source-Gemeinschaft. Gleich zu Anfang stellte er die Frage, wer schon einmal von Brooks' Buch "The Mythical Man Month" gehört oder es gelesen habe. Dies war nur bei einer Minderheit der Fall.
Brooks' Buch beruht auf Erfahrungen, die bei der Entwicklung des IBM-Betriebssystems OS/360 gemacht wurden. Die darin aufgestellten Regeln werden auch nach 30 Jahren noch als gültig angesehen. Das gilt auch für "Brooks' Law": Das Hinzunehmen von Programmierern zu einem verspäteten Projekt macht es noch später. Daraus folgen die Grundregeln:
- Programmiert wird in Teams mit maximal 6 Mitgliedern
- Die Management-Struktur ist hierarchisch
- Die Kommunikation mit anderen Teams ist limitiert
Ein Design kommerzieller Software folgt folgendem Grundschema:
- formale Spezifikation (soll endgültig sein, was aber nie möglich ist)
- Design-Spezifikation
- Detaillierte Analyse der Interfaces
- Marketing
- Code-Erstellung
Im Gegensatz dazu folgen freie Software-Projekte eher folgenden Grundregeln:
- Kleines, fokussiertes Team
- Hierarchie ist formal oder auch nicht
- Es gibt zahlreiche Berührungspunkte zwischen Teams
Auch die Entwicklung freier Software folgt einem anderen Schema:
- Zuerst wird ein Prototyp entwickelt, der zumindest rudimentär funktionieren muß.
- Eine Webseite wird erstellt. Das ist das Marketing, und es ist enorm wichtig. Das Ziel ist, Entwickler zu finden, nicht Anwender.
- Ein funktionierendes Produkt wird erstellt.
- Dokumentation (vielleicht von Dritten).
Kommunikation findet meist in Mailing-Listen statt, direkte Kommunikation mit den Entwicklern ist üblich.
Erfolgreiche freie Software ist sehr modular aufgebaut. Schnittstellen zwischen Modulen werden minimiert und möglichst weit vereinfacht, denn wer will schon Hunderte von Emails bekommen, die fragen, wie eine Schnittstelle funktioniert? Oft hat ein Modul auch nur eine Schnittstelle zu einem Kern-Modul und keinem anderen sonst. Beispielsweise hat ein Treibermodul im Linux-Kernel normalerweise keine Verbindung zu einem anderen Treibermodul.
Freie Software entwickelt sich kontinuierlich weiter, man kann hier durchaus von Evolution sprechen: Schnittstellen, die dumm oder zu komplex sind, werden nicht benutzt und sterben schließlich aus.
Schnittstellen werden häufig wiederverwendet: eine Schnittstelle hat viele Anwendungen, viele Module haben die gleiche Schnittstelle, externe Plugins werden möglich.
Wieweit gilt nun Brooks' Law für freie Software? Freie Software ist generell verspätet, denn sie wird erst geschrieben, wenn Bedarf entsteht. Fügt man Programmierer zu einem Projekt hinzu, bleibt die Team-Größe dennoch unter sechs Mitgliedern, denn die neuen Programmierer widmen sich neuen (Unter-)Projekten, und Module werden an den existierenden Schnittstellen aufgeteilt.
Nachteile der freien Software-Entwicklung:
- Code-Duplikation (hilft aber oft, die Schnittstellen klein zu halten)
- Code-Duplikation bedeutet auch Bug-Duplikation
- Beispiel-Code muß sehr gut sein, da er vielfach dupliziert wird
Fazit: Design freier Software strebt die Vermeidung von Wissen an. Das heißt, ein Modul soll sowenig wie möglich über andere Module wissen.
An den Vortrag schlossen sich einige Fragen an. Alan antwortete auf die Frage nach ReiserFS, daß dieses wahrscheinlich nicht im Kernel 2.4 enthalten sein wird. Doch werden alle Distributoren natürlich ReiserFS in ihre Kernel integrieren.
Ein Veröffentlichungstermin für Kernel 2.4 steht noch nicht fest. Alan: "Sobald der Kernel stabil ist, werden wir ihn so schnell wie möglich freigeben."
