Erschienen in Telepolis (09.03.99) und Netpol-Digest 13 (15.03.99)
Die mäandrierende Evolution freier Software
Im Zentrum der Entwicklung freier Software bahnt sich ein Wechsel an. Der bisherige Standard-Compiler GCC[1] wird zunehmend durch eine Weiterentwicklung unter dem Kürzel EGCS[2] verdrängt. Compiler sind jene Programme, die den Quelltext eines Programms in für den Prozessor verständliche Anweisungen übersetzen. Für freie Software, die in den Archiven des Netzes überwiegend im Quelltext bereitgestellt wird, ist damit ein deutlicher Schnitt verbunden.
Als äußere Anzeichen des Übergangs können die Entscheidungen der deutschen Linuxdistributoren Delix und SuSE, den GCC zumindest im Ansatz durch den EGCS zu ersetzen, gewertet werden. Unterdessen brodelt unter den Nutzern die Gerüchteküche. Der GCC werde nicht mehr weiterentwickelt, EGCS sei für C++, die objektorientierte Variante der Programmiersprache C gedacht, beide Compiler würden beizeiten wieder zu gemeinsamem Code geführt und so weiter.
Die im Halloween-Papier von Microsoft[3] angeführte angebliche Schwäche der freien Software, nämlich die Tendenz zur Spaltung der Entwicklung (code forking) scheint sich hier zu vollziehen. Die seltsame Evolution freier Software offenbart sich bei genauerem Hinsehen.
Lange Jahre stand mit dem GCC (GNU C Compiler) ein Werkzeug bereit, hinter dem sich kommerzielle Konkurrenten zum Teil verstecken mußten. Die vom GCC generierten Programme waren oft genug kleiner und schneller als die seiner kommerziellen Pendants. Folgerichtig sparte sich zum Beispiel Steve Jobs' ehemalige Firma Nextstep die Entwicklungskosten für einen eigenen Compiler und unterstützte gleich den GCC.
Freie Software, wie Linux, verdankt einen guten Teil der eigenen Qualitäten auch dem GCC. Die Mahnungen des Compilers beim Übersetzen halfen, Ungenauigkeiten im Quellcode von vornherein zu vermeiden.
In der Zeit zwischen Ende 1995 und Anfang 1998 blieben aktualisierte Versionen des GCC aus. Das Programm wurde, nachdem Richard Stallman[4], wie in so vielen freien Softwaredingen die Vorlage geliefert hatte, in den letzten Jahren hauptsächlich von Richard Kenner betreut. Stallman erklärt die Entwicklungspause mit der Überarbeitung eines Teils des GCC (exception handling). Der Entwickler, der sich damit befaßte, ließ sich Zeit, erreichte jedoch nicht den vom GNU-Projekt gewünschten Stand an Effizienz und sauberer Programmierung. Entgegen Kenners ablehnender Haltung entschied sich Stallman trotzdem für die Übernahme des Codes und damit die Veröffentlichung von GCC 2.8. Er fürchtete die Aufspaltung der Entwicklung und sah schon zu viel Zeit vergeudet.
Tatsächlich bildete die 95er Version des GCC die Basis für eine Reihe von Weiterentwicklungen, darunter auch der EGCS. Auslöser war zum einen die lange Verzögerung beim GCC, aber auch der Wunsch, die Möglichkeiten neuerer Prozessoren auszureizen. Zwei andere Motive scheinen in der Rückschau möglicherweise noch entscheidender gewesen zu sein.
Die GNU-Programme hatten gegenüber anderen Projekten der freien Software den Vorteil eines Zeitvorsprungs. Stallman hatte die Arbeit am GCC bereits Mitte der 80er Jahre aufgenommen. Auf die eingeflossene Erfahrung konnte, wie im Fall von Linux, aufgebaut werden. Nach 1995 wurde möglicherweise ein Wendepunkt erreicht. Mit einem Mal stellte weniger der Compiler Ansprüche an den Code, sondern die Programmierer entwickelten mehr Anforderungen an den Compiler.
Nach Auskunft von Richard Kenner gesellt sich an dieser Stelle ein weiteres Moment hinzu: der GCC wurde immer mehr auch für kommerzielle Produkte eingesetzt. Die Ansprüche von Firmen und Hackern entwickelten sich auseinander: Hie industrielle Stabilität, dort experimentelle Ansätze. Als Problem stellte sich heraus, daß die Weiterentwicklungen des EGCS aus Mangel an Freiwilligen nicht in den GCC einfließen konnten.
Das andere Motiv besteht in der gewandelten Art der Entwicklung. In den Äußerungen Stallmans wird auch das Modell von Software-Entwicklung deutlich, in der Verantwortlichkeit und Entscheidungsbefugnis auf wenige Schultern verteilt sind. Das ruhige, von außen nicht nachvollziehbare Vor-sich-hinwerkeln entspricht dem geschlossenen Entwicklungsmodell, das Eric Raymond 1997 in seinem einflußreichen Papier »The Cathedral and the Bazaar«[5] als die Kathedrale skizziert: Wenige Zauberer arbeiten, abgeschottet von der Außenwelt, mit aller Sorgfalt an der Entwicklung.
Dagegen stellt Raymond den Basar: Mit Linux habe sich ein Entwicklungsstil durchgesetzt, der mit unwahrscheinlicher Schnelligkeit verläßliche und stabile Ergebnisse erziele. Und das, obwohl die Strategie dem bis dahin gewohnten Stil der Kathedrale diametral entgegengesetzt sei: ein einziger großer brabbelnder Basar mit unterschiedlichen Vorhaben und Ansätzen. Basierend auf der Analyse der Linux-Entwicklung und eigener Erfahrung präsentiert er Empfehlungen für die öffentliche Entwicklung von Software, die auf einen sich selbst verstärkenden Regelkreis hinauslaufen: Die häufige Veröffentlichung der Quellen erlaubt ein Testen der Software auf breiter Basis, was wiederum ein Feedback bewirkt, das die Entwicklung zur nächsten Veröffentlichung vorantreibt.
Das EGCS-Projekt benutzt Raymonds Schlußfolgerungen aus eigener Erfahrung als Rezept. Jeffrey A. Law, als Compiler-Ingenieur bei der Firma Cygnus[6] beschäftigt und seit langem an GNU-Projekten beteiligt, schildert die Situation zwischen 1995 und 1997 als frustrierend. Die Beiträge (patches) verschiedener Entwickler zum GCC wurden kaum verwendet, Richard Kenner hüllte sich in Schweigen und die Frustration entlud sich in hitzigen nicht-technischen Debatten. Die internen Versuche, das Entwicklungsmodell des GCC zu verändern, schlugen fehl, und so regte Law im August 1997 die Entwicklung eines GCC3 an.
Die Vorbehalte von Stallman und Kenner gegen eine Spaltung der Entwicklung wurden nur hinsichtlich des Namens berücksichtigt: der EGCS war geboren. An die Stelle der Programmierung im stillen Kämmerlein traten öffentliche Mailing-Listen, auf denen Änderungen diskutiert werden, eine ganze Reihe von Beitragenden wird in die Entwicklung mit eingebunden[7] und erneuerte Quellen werden mit schöner Regelmäßigkeit zur Verfügung gestellt.
Die wichtigste Änderung dürfte die organisatorischen Zuständigkeiten betreffen. Statt eines mehr oder minder wohlwollenden Diktators, der allein den Überblick behält und die Quellen hütet, trägt nun ein Steuerungskomitee bestehend aus 13 Personen die Verantwortung. Das Komitee wacht über die Einhaltung der selbstverordneten Regeln[8], trifft Entscheidungen über die generelle Ausrichtung des Projekts und - ein zentrales Anliegen - sorgt für die Kommunikation nach außen und innerhalb des Projekts. Die konkrete Arbeit am EGCS erledigt nun ein Kreis von Entwicklern in Eigenverantwortung.
Der Zuspruch, den das Projekt erfährt, scheint den Initiatoren recht zu geben. Seit dem 1. Januar 1999 sind 26 Änderungen von neun Leuten in den GCC eingeflossen. Im gleichen Zeitraum wurden über 400 Änderungen von 50 - 60 Beitragenden für den EGCS berücksichtigt.
Ein Maß für Qualität kann die reine Menge der Veränderungen nicht sein, und die Frage, ob nun der Basar oder die Kathedrale sich besser zur Softwareentwicklung eignen, wird damit kaum beantwortet. Kooperation in verschiedenen Modellen funktioniert über das Netz, wie nicht nur das GNU-Projekt zeigt, seit Jahren. Kathedrale und Basar unterscheiden sich vor allem in der Menge an Staub, die der Basar aufwirbelt. Wird Kenners Hinweis auf den hemmenden Zwiespalt von kommerziellen und experimentellen Interessen Ernst genommen, scheint es eher, daß zwischen Entwicklern von freier Software und Industrie noch eine Lücke gefüllt werden muß: Die notwendige Arbeit am Übergang zwischen Experiment und gewünschter Robustheit ist zu wenig glamourös, um freiwillig übernommen zu werden.
Was GCC und EGCS angeht, scheinen sich die Beteiligten, nach ursprünglichen internen Querelen der konkurrierenden Entwickler, zu einigen. Stallman hofft, der EGCS werde die Stelle des GCC im GNU-Projekt übernehmen, und Law spricht von einer Vereinigung der Entwicklung. Kenner dagegen favorisiert die Zweigleisigkeit: Wenn sich Experimente im EGCS bewährt haben, sollen sie im GCC übernommen werden. Die Gespräche sind am Laufen. Auch die Lücke scheint erkannt: Intel will Cygnus darin unterstützen den Compiler für Pentium-Prozessoren zu optimieren[9].
[1] http://www.gnu.org/software/gcc/gcc.html[2] http://egcs.cygnus.com/
[3] http://www.opensource.org/halloween1.html
[4] http://www.gnu.org/people/rms.html
[5] http://www.tuxedo.org/~esr/writings/cathedral-bazaar
[6] http://www.cygnus.com/
[7] http://egcs.cygnus.com/thanks.html
[8] http://egcs.cygnus.com/mission.html
[9] http://www.cygnus.com/news/intel.html