Die Open Source Community ist vor allem und in erster Linie eine Gemeinschaft freier Individuen. Dies merkt man nicht zuletzt an der schon immer immanenten Tendenz (Software-)Projekte zu spalten und Eigenentwicklungen voran zu treiben. Die verwendeten freien Lizenzen ermöglicht es quasi jeden Code beliebig zu verwenden und dann selbst weiter zu verbreiten – meist ebenfalls unter einer freien Lizenz.
Der Erfolg freier Software beruht genau auf diesen Grundlagen. Die unglaubliche Vielfalt im Open Source-Universum wäre nie entstanden, wenn freie Individuen immer zur geregelten Mitarbeit in geordneten Projekten verdammt gewesen wären um ihre Ideen einzubringen. Zudem ist das ehrenamtliche Engagement bei vielen Softwareprojekten immer noch die Grundlage der Entwicklung, wenngleich natürlich auch viele Entwickler für ihre Mitarbeit bezahlt werden. Genaue Zahlen zur Verteilung beider Gruppen dürfte niemand haben. Ehrenamtlich aktive Entwickler sind naturgemäß noch viel weniger bereit sich dem Diktat eines Projekts unterzuordnen, wenn ihre Ziele nicht mehr zum Projekt passen. Kritiker des manchmal etwas zerfaserten Eindrucks der freien Softwarewelt, sollten sich dies immer wieder vor Augen führen.
Abspaltungen und Entwicklungsschübe
Man muss sich nur einige der Forks der vergangenen Jahre anschauen um die positiven Entwicklungsschübe hinter dieser Grundtendenz freier Softwareentwicklung zu sehen. Dabei gibt es grundsätzlich zwei Typen von Abspaltungen.
Im ersten Fall führt eine Abspaltung zur Abwanderung der meisten Entwickler und Anwender und das Originalprojekt stirbt. Der Fork nimmt dann einfach den Platz ein, es gibt aber weiterhin nur eine Anwendung. Das bekannteste aktuelle Beispiel für solch einen Fork ist LibreOffice. Es zeigt gleichzeitig die positiven Möglichkeiten einer solchen Abspaltung. LibreOffice hat sich beispielsweise zu einem wirklich vital entwickelten Projekt gemausert, nicht nur verglichen mit den aktuellen Fortschritten bei Apache OpenOffice, sondern auch im Vergleich mit dem früheren Entwicklungstempo bei OpenOffice.org.
Im zweiten Fall führt eine Abspaltung zur Entwicklung zweier parallel entwickelter Projekte. Hier sind GNOME und MATE zwei gute Beispiele. Die grundsätzliche Unvereinbarkeit der Vorstellungen über ein gutes Bedienkonzept für eine Desktopumgebung führte zur Spaltung in zwei Projekte, wobei MATE den GNOME 2-Entwicklungsstand fortführte. Heute werden beide Projekte aktiv vorangetrieben und es dürfte außer Zweifel stehen, dass die Aufspaltung keinem der Projekte geschadet hat.
Hinter beiden Modellen steht letztlich der Grundsatz, dass man einen ehrenamtlich arbeitenden Entwickler nicht zwingen kann an einem Projekt mitzuarbeiten, dessen Grundausrichtung er nicht (mehr) teilt. Durch die Abspaltung geht seine Entwicklungskraft zwar dem Originalprojekt verloren, aber es ist äußerst zweifelhaft, ob er bei einem fiktiven (z.B. lizenzrechtlichen) Abspaltungsverbot, seine Arbeitskraft weiterhin in den Dienst des Originalprojekts gesteckt hätte.
Dies ist auch das grundsätzliche Problem hinter Parallelentwicklungen und Nischenentwicklungen. Aus der Anwender-Community kommen oft Rufe, die z.B. KDE-Entwickler sollten sich mal auf dieses oder jenes konzentrieren, anstatt mehrere Neuentwicklungen zu lancieren. Doch können die ehrenamtlich arbeitenden Entwickler möglicherweise bei einigen speziellen Projekten mangels Expertise gar nicht mitarbeiten oder würden es auch nicht wollen.
Mangel an Arbeitskraft bei Projekten
Diesen positiven Tendenzen stehen erhebliche Risiken gegenüber. Besonders deutlich wird das zur Zeit bei den Distributionen. Es gab schon immer viele Distributionen und das ist auch sinnvoll. Debian und Arch Linux bedienen beispielsweise derart unterschiedliche Zielgruppen und repräsentieren so divergierende Entwicklungsideen, dass eine Vereinheitlichung Irrsinn wäre.
In den vergangenen Jahren hat sich aber eine expotenziell wachsende Zahl von Distributionen etabliert. Es wird gespalten um der Spaltung willen, weil kaum noch jemand bereit ist “einfach so” an einem Projekt mitzuarbeiten.
Gleichzeitig ist die Paketierung von Software nicht zu vergleichen mit der Entwicklung selbiger. Während bei Letzterer ein legitimes Argument ist, dass nicht jeder Entwickler die Fähigkeit hat, an jedem Bestandteil mitzuarbeiten, ist Paketierung eine distributionsübergreifend ziemlich ähnliche Tätigkeit. Jemand der an Debian mitarbeitet, kann dies per se auch bei Ubuntu und umgekehrt.
Der Aufspaltungswahnsinn hat hier zu einem kritischen Entwicklermangel bei vielen Projekten geführt, eben weil es viel schöner für das eigene Ego ist, die eigene Distribution zu lancieren, als mühevoll bei Debian oder openSUSE mitzuarbeiten. Während der Mangel an Beitragenden bei z.B. openSUSE bereits länger öffentlich thematisiert wird, verschwindet das Problem bei z.B. Debian hinter der großen Zahl von offiziellen Debian-Mitgliedern oder der Undurchsichtigkeit der internen Kommunikation wie z.B. bei (K)Ubuntu.
Wirklich problematisch wird dies, wenn in der Projektentwicklung umfangreiche Änderungen anstehen oder große Projekte angestoßen werden. Das verbreitete Toolkit Qt hat z.B. mit Qt-Webengine eine grundlegende Bibliothek zur Darstellung von z.B. Internetseiten auf Basis des Chromium/Blink-Codes erhalten. Diese Bibliothek löst das veraltete WebKit ab und wird sukzessive in verschiedene Softwareprojekte implementiert. Den ersten Schritt machte vor einigen Wochen Qupzilla, aber auch die aktuellen Versionen von KMail oder Akregator benötigen diese Bibliothek. Gleichzeitig ist die Wartung von Qt-Webengine ebenso aufwändig, wie die Wartung von Chromium selbst. Die Bibliothek wurde deshalb immer noch nicht für Debian und darauf basierende Distributionen gebaut – einfach weil das zuständige winzige Team damit vollkommen überfordert ist. Stattdessen wird darüber nachgedacht alle darauf aufbauenden Pakete aufzugeben.
Positive Entwicklungsschübe kann man durch zu Vielzahl an neuen Distributionen kaum verzeichnen, die Probleme aber inzwischen für jeden Anwender fühlbar. Hoffentlich wird das manchen Beteiligten bewusst, bevor das gesamte Distributions-Ökosystem nachhaltig in Mitleidenschaft gezogen wird.
Bilder:
Einleitungsbild und Beitragsbild von von TukTukDesign via pixabay
