Spaltung, Streit und Konflikte drohen der Open-Source-Community immer wieder zu schaden. Bislang haben Forks aber auf Dauer eher Vorteile mit sich gebracht, wie die weitgehende Wiedervereinigung von Compiz und Beryl im Projekt Compiz Fusion zeigt.

In der Open-Source-Community prallen oft extreme Gegensätze aufeinander: Großen Unternehmen, die mit freier Software ihr Geld verdienen, stehen Idealisten gegenüber, die das Entwicklungsmodell freier Software als Vorbild für die ganze Gesellschaft sehen. Dazwischen tummelt sich ein unüberschaubares Feld von Entwicklern mit verschiedenen Motiven und unterschiedlichem kulturellen, sozialen und geografischen Hintergrund.

Vielfalt und Gegensätze

Die äußerst heterogenen Zusammensetzung der freien Entwicklergemeinde bringt genauso Vor- wie auch Nachteile mit sich. Einerseits führt sie zu großer Flexibilität, weil sich immer wieder Experten finden, die etwa für exotische Hardware entsprechende Patches schreiben, oder auch Freiwillige, die freie Software in Sprachen übersetzen, die für kommerzielle Unternehmen wirtschaftlich uninteressant wären. Andererseits führen unterschiedliche Mentalitäten oft zu Meinungsverschiedenheiten, die nicht selten – Stichwort Flamewars – zu heftigen und nicht immer sachlichen Auseinandersetzungen eskalieren.

Entbrennt ein solcher Streit zwischen den Entwicklern eines Softwareprojekts, droht etwas, das sowieso nur bei Open-Source-Programmen möglich ist: eine Abspaltung oder ein Fork. Eine Gruppe oder Person beteiligt sich nicht mehr an der gemeinsamen Entwicklung, sondern entwickelt den Programmcode in eine andere Richtung weiter und ruft somit ein neues Projekt ins Leben.

Open-Source-Lizenzen sind die rechtliche Basis der Forks. Der Quelltext freier Software gehört niemandem und steht allen Interessenten unbeschränkt zur Verfügung, sowohl den Projektteilnehmern selbst als auch bislang völlig Unbeteiligten. Niemand kann sie daran hindern, den Code zu übernehmen und auf dieser Basis ein neues Projekt zu starten, auch wenn die nüchterne Effizienzkalkulation dafür spräche, dass alle miteinander kooperieren.

Eine treffende Beschreibung des Phänomens findet sich bereits in dem Aufsatz “Homesteading the Noosphere” von Eric S. Raymond aus dem Jahr 2000: “Die wichtigste Eigenschaft eines Forks ist, dass er miteinander konkurrierende Projekte hervorbringt, die danach keinen Code mehr austauschen können, und damit die potenzielle Entwicklergemeinde spaltet.” [1]

Spalten oder an einem Strang ziehen?

Dass es in der Geschichte der freien Software nur wenige große Projekt gibt, bei denen es tatsächlich zur Spaltung gekommen ist, zeigt, dass sich die Entwickler der Nachteile bewusst sind. Meist finden sie Kompromisse, um weiterhin an einem Strang zu ziehen. Daher sind die Resultate der bislang vollzogenen Forks auch nicht so dramatisch, wie Raymond vor sieben Jahren annahm.

1997 spaltete sich eine Gruppe von etwa 25 Entwicklern vom GCC-Projekt [2] ab und rief EGCS (Experimental/Enhanced GNU Compiler System, [3]) ins Leben. EGCS vereinte zahlreiche kleinere Forks, die Features umsetzten, die die GCC-Maintainer nicht in den offiziellen GCC-Zweig aufnehmen wollten. Die Folgen des Forks waren jedoch eher produktiv. 1999 erklärte die Free Software Foundation, zuständig für die GCC-Entwicklung, EGCS auf Grund seiner effektiveren Entwicklung zum offiziellen GCC, was die Spaltung beendete.

Für große Besorgnis sorgte in der Linux-Community 2003 der drohende Fork von Xfree86 [4], dem fast alternativlosen Grafikserver für Linux und andere Unix-Betriebssysteme. In diesem Fall waren nicht technische, sondern lizenzbezogene Fragen Anlass zu Meinungsverschiedenheiten, und 2004 kam es deshalb tatsächlich zur Abspaltung. Jedoch führte der Fork auch in diesem Beispiel nicht zu einer spürbaren Schwächung, weil sich fast alle Xfree86-Entwickler dazu entschlossen, zum Ersatzprojekt X.org [5] zu wechseln. Es hat sich in einem nahtloses Übergang als neuer Standard-Grafikserver aller namhaften Linux-Distributionen etabliert.

Das jüngste Beispiel für einen Fork hat nun ebenfalls gezeigt, dass sich die Open-Source-Community durchaus bemüht sinnvolle Kompromisse zu schließen, um ihre Kräfte zu erhalten. Die Rede ist von den 3D-Desktops Beryl [6] (siehe Abbildung 1) und Compiz [7] (Abbildung 2), das vor allem durch den schwedischen Programmierer David Revemann (Abbildung 3) begründet wurde. Compiz war das erste der beiden Projekte und sollte den Unix- und besonders den Linux-Desktop mit Transparenz und anderen optischen Effekten ausstatten. Es stammt aus dem Hause Novell; die Firma ist Hauptfinanzier der Entwicklung und hat damit auch die Kontrolle darüber, welche Patches und Plugins in Compiz einfließen.

Wegen der zurückhaltenden Politik bei der Integration neuer Plugins gründeten einige Compiz-Entwickler im vergangenen Jahr den Compiz-Fork Beryl. Sie warfen Novell außerdem vor, dass die Entwicklung hinter verschlossenen Türen ablaufe, und wollten an dem neuen Projekt nach Art des am Basar orientierten Open-Source-Entwicklungsmodells arbeiten und darin in ihren Augen wichtige Features unterbringen.

Abbildung 1: 3D-Desktops statten die grafische Oberfläche mit optischen Effekten wie dem Desktop-Cube aus, der die virtuellen Desktops beim Wechsel auf einen räumlich wirkenden Würfel projiziert.

Abbildung 2: Compiz sorgt für Transparenz: Verdeckte Fenster scheinen im 3D-Desktop auf Wunsch durch.

Abbildung 3: David Revemann gilt als einer der Vorreiter bei der Entwicklung des 3D-Desktops. Seine Arbeit schätzen sowohl die Compiz-Entwickler als auch die zeitweiligen Konkurrenten von Beryl. (Bild © Guy Lunardi)

Konkurrenz und Kooperation

Die Beryl-Entwickler hatten zwar angekündigt ihren Code so zu schreiben, dass er möglichst ohne große Umstände auch in Compiz zu integrieren wäre, doch zeichnete sich nach einigen Releases ab, dass die beiden Projekte dennoch auseinanderzulaufen begannen. So kam es schon bald zu Inkompatibilitäten und auf manchen Grafikkarten funktionierte der eine 3D-Desktop besser, auf anderen der andere. Außerdem gab es mehr und mehr Features, bei denen sich die Anwender mit einer Wahl zwischen Beryl oder Compiz entscheiden mussten – es drohte das von Raymond beschriebene Szenario, dass sich zwei konkurrierende Projekte in unterschiedliche Richtungen entwickelt würden.

Umdenken

Die Entwickler der 3D-Desktops sind inzwischen offenbar zu der Überzeugung gelangt, dass es ineffizient sei, an zwei Projekten parallel zu arbeiten, und haben zumindest einen ersten Schritt in Richtung Vereinigung getan. Unter dem Namen Compiz Fusion [8] haben sie ein neues Projekt gegründet, das Beryl und die Compiz-Extras zusammenführt. Bei denen handelt es sich um Erweiterungen, die Compiz-Maintainer als nicht grundlegend und in puncto Usability als wenig fortschrittsbringend einstufen. Dazu gehören vor allem Plugins und der Compiz Config Settings Manager [9], ein Werkzeug zur komfortablen Konfiguration der 3D-Oberfläche. Beispiele für Extra-Plugins aus Compiz Fusion sind das animierte Minimieren und Maximieren von Fenstern sowie Schneeflocken, die auf den 3D-Desktop rieseln.

Eine vollständige Vereinigung zwischen den Forks wird es wohl in naher Zukunft trotzdem nicht geben. Stattdessen arbeiten weiterhin vor allem die Novell-Programmierer an Compiz weiter, während Compiz Fusion eine durch die Community entwickelte Erweiterung darstellt. Aus dem Beryl-Zweig fließen lediglich jene Teile in Compiz Fusion ein, die nicht vom Windowmanager abhängen und sich also mit dem von Compiz bereitgestellten Windowmanager vereinbaren lassen.

Inzwischen hat Compiz Fusion eine erste Entwicklerversion veröffentlicht, eine stabile Ausgabe soll in Kürze folgen. Mit dem Kompromiss geht die Hoffnung einher, dass Compiz und Compiz Fusion künftig Bestandteile von immer mehr Linux-Distributionen werden und der 3D-Desktop sogar zum Standard avanciert. Dies gehört bislang zwar auch zu den Zielen mehrerer großer Distributoren, wegen der noch bestehenden Schwierigkeiten mit einigen Grafikkarten riskieren die Herstellen es aber derzeit noch nicht, Compiz als Standard-Windowmanager einzusetzen.

Fluch und Segen

Forks sind also einerseits, wie von Raymond befürchtet, eine durchaus reale Bedrohung für die Effizienz von Open-Source-Projekten. Die Entwicklung freier Software setzt viele unterschiedliche Kompetenzen voraus, ein erfolgreiches Projekt braucht Programmierer, Übersetzer, Handbuchautoren und Benutzer, die Software testen und Verbesserungsvorschläge machen. Spaltet sich das Entwicklerteam, fehlt es schnell an allen Ecken und Enden.

Doch ist die Möglichkeit, einen Fork abzuspalten, ein fester Bestandteil der Open-Source-Welt und ihrer Lizenzen. Die Community ist als Ganzes zwar auf Selbstdisziplin angewiesen, um unnötige Spaltungen zu vermeiden. Andererseits bietet ein Fork einen letzten Ausweg, wenn zu stark divergierende Interessen die Zusammenarbeit unmöglich machen. Beim GCC-Projekt und bei Compiz waren dies neue Features versus Stabilität als konkurrierenden Ziele.

Birnenauflauf mit Speck

Bei Open-Source-Projekten zeigt sich beispielhaft, wie auch unterschiedliche Talente zusammenarbeiten können: Fällt dem einen das Schreiben von Progammcode in C leichter, so sind andere Teammitglieder in den natürlichen Sprachen versierter und arbeiten lieber an der Dokumentation oder übersetzen die Benutzeroberfläche. Ein Beispiel aus der Kochkunst, in dem sich gegensätzliche Zutaten zu einem harmonischen Ganzen fügen, ist ein leckerer Birnenauflauf, dem etwas Speck eine besondere Würze verleiht.

Zutaten: 750g frische, vollreife Birnen oder wahlweise eine 850-Milliliter-Dose Birnen, eine unbehandelte Zitrone, zwei bis drei Teelöffel Zucker, 150g Butter, eine Prise Salz, zwei Eier, 300g Mehl, ein Päckchen Backpulver und 225g Frühstücksspeck.

Zur Zubereitung die Birnen schälen und halbieren, die Kerngehäuse entfernen. Die Schale der Zitrone abreiben und den Saft auspressen. Wasser, Zitronensaft und Zucker aufkochen. Frische Birnen darin fünf bis acht Minuten ziehen lassen, den Sud aufbewahren. Bei Birnen aus der Dose lediglich den Saft zum Wasser und zum Zitronensaft hinzufügen. Fett, Salz und Zitronenschale schaumig rühren, die Eier unterziehen. Mehl und Backpulver hinzufügen und mit dem Sud oder Saft zu einem glatten Teig verrühren.

Boden und Rand einer Auflaufform mit Speck auslegen. Die Speckscheiben sollen etwa drei Zentimeter über den Rand der Form hinausragen. Nun die Hälfte des Teigs in die Form geben und die Birnen drauflegen. Den Rest des Teigs darüber verstreichen und mit Speck bedecken. Den Auflauf im vorgeheizten Backofen zirka eine Stunde backen, danach sofort servieren. (pkr)