Es wäre so schön, wenn Open-Source-Projekte einfach so funktionieren würden. Aber es wäre naiv, das vorauszusetzen. Auch Softwareentwickler haben Egos. Sind leidenschaftlich, wenn es darum geht, ob die geschweifte Klammer ans Ende der Zeile oder den Anfang der nächsten gehört. Haben einen Dickkopf, wenn sie das eine Feature unbedingt genau so haben wollen. Können mit der Art des Mitentwicklers nicht. Verheddern sich in Klein-Klein-Diskussionen. Und es gibt anders als im bezahlten Job keinen Vorgesetzten oder eine Autorität, die Entscheidungen erzwingen könnten.
In offenen Communities wie Apache arbeiten Committer aus verschiedenen Ländern und Kulturen mit unterschiedlichen Muttersprachen und Englischkenntnissen verteilt über alle Zeitzonen teils in ihrer Freizeit, teils als Teil ihres Jobs zusammen. Und eigentlich ein Wunder oft funktioniert das auch. Schwierig wird es, wenn Geld hinzukommt. Und wenn Zeitdruck aufgebaut wird.
In Technologiebereichen, die besonders innovativ und zukunftsträchtig sind, wachsen neue Geschäftsfelder schnell. Start-up-Firmen gründen sich und ziehen besonders zurzeit im Silicon Valley Risikokapitalgeber an wie Licht die Mücken. Ausgestattet mit diesem Geld wächst die Notwendigkeit, massiv zu wachsen und den Markt in kurzer Zeit schnell mit Produkten und immer neuen Verbesserungen und Features zu füttern. Ist die Basis dieser Produkte ein Apache-Projekt, führt das fast zwangsläufig zu Spannungen im Projekt. Einerseits müssen sich alle Committer auf gemeinsame Ziele verständigen, was durch immer neue Diskussionen über die Zeit ausgependelt wird. Unternehmen verstehen diese Prozesse oft nicht, oder sie scheinen ihnen als unnötig und unproduktiv, zumindest aber überflüssig, hinderlich und zu langwierig. Ist das Unternehmen nun stark mit dem Open-Source-Projekt verbandelt, muss es den Spagat schaffen zwischen seinen eigenen Interessen und denen des Projekts, die ja auch irgendwie die eigenen sind, aber eben nicht die Kerninteressen und jedenfalls kaum diejenigen der Manager und Investoren.
Aber genauso wie manche Manager sich als Alphatiere gerieren, spielt der eine oder andere Open-Source-Entwickler sich als Committer-Diva auf, die natürlich zu viel Durchblick in die vermeintlich fehlende Urteilskraft der anderen hat, um sich zu einem Kompromiss herablassen zu müssen. Ein einziges solches Ego reicht dann schon, um die Weiterentwicklung nachhaltig zum Stoppen zu bringen. Denn bei Apache kann jeder Committer gegen jede Codeänderung sein Veto einlegen, solange er es technisch begründet. Code, der mit einem Veto belegt wurde, kann nicht in ein Release einfließen und muss im Extremfall aus dem Code-Repository entfernt werden. Vetos sind nicht einfach durch Mehrheitsentscheidungen zu überstimmen und werden leider auch politisch eingesetzt. Meiner Meinung nach sind langstehende Vetos ein Zeichen für unreife Projekte. Denn das folgende Fondermannsche Korollar der Open-Source-Projektreife gilt: In einem gereiften und funktionierenden Open-Source-Projekt werden Vetos schnell aufgelöst.
Ein Beispiel für ein vetoschwangeres Projekt ist Apache Hadoop [1]. Von der generellen Marschrichtung über konkrete Zuschneidung von Releases bis hin zu technischen Detailfragen überall kommen Vetos zur Anwendung. Hadoop ist dabei eine noch recht junge Software in einem stark innovativen Umfeld, die sehr großes Spezialwissen benötigt, besonders umfangreiche Hardware zum Testen und sowohl von Real-Time-Datenbanken wie auch im Batch-Prozessing-Umfeld eingesetzt wird. Es ist also zu erwarten, dass es hier an bestimmten Punkten im Lebenszyklus zu Verwerfungen kommt. Das war in der heißen Phase von J2EE-Servern auch nicht anders. Dass diese jedoch nicht überwunden werden, ist kein gutes Zeichen.
Hadoop wird von vielen Unternehmen eingesetzt, die auch in der Open-Source-Szene aktiv sind, wie Facebook und Twitter. Aktiv in der offenen Entwicklung sind vor allem Yahoo! [2] und Cloudera [3]. Yahoo! betreibt die größten bekannten Hadoop-Cluster. Cloudera steht Unternehmen, die Hadoop einsetzen, mit Rat und Tat zur Seite. Beide haben neben der Arbeit an Apache Hadoop eigene Distributionen veröffentlicht, die buchstäblich Hunderte von Patches enthalten, die sich im letzten Hadoop-Release noch nicht finden. Man könnte also sagen, dass es einen stillen Fork gibt, bei dem sich zumindest Cloudera entschieden hat, das Projekt selbst weiterzuentwickeln, um überhaupt auf seinem Markt beweglich zu bleiben und Kundenwünsche zu erfüllen.
Die heutige Situation rund um Hadoop ist also alles andere als erfreulich. Es ist nämlich nun extrem schwierig und aufwändig, bei diesen Patches die Spreu vom Weizen zu trennen und dann nach Apache Hadoop zu portieren. Gleichzeitig müssen Cloudera [4] und Yahoo! [5] ihre eigenen Forks weiterpflegen. Zu ähnlichen Erkenntnissen scheint auch Yahoo! gekommen zu sein. Im Januar kündigte der Hadoop-Hauptkontributor an, dass man die eigene Distribution nicht mehr weitertreiben und stattdessen alle Energie auf Apache konzentrieren wolle [6]. Auch Cloudera bekannte sich in einer Reaktion zu Apache Hadoop als Hauptentwicklungslinie, hält allerdings an einer eigenen Distribution fest. Das ist angesichts des Geschäftsmodells von Cloudera nicht verwunderlich [7].
Die Schritte hin zum nächsten Hadoop-Release sind klein, aber sie werden gemacht. Doch noch sucht der Hadoop-Elefant den Weg aus der selbstgewählten Sackgasse und dreht sich tapsig um sich selbst. Es ist heute unklar, welcher Branch mit welchen Features wirklich veröffentlicht werden wird und wann. Zumindest aber scheinen die Egos mittlerweile verstanden zu haben, dass ich nicht gleich besser ist. Und irgendwann werden auch die Vetos ohne viel Aufhebens aufgelöst werden, ähnlich wie das bei anderen gesetzteren Projekten mittlerweile auch der Fall ist.
Bernd Fondermann (bernd.fondermann[at]brainlounge.de) ist freiberuflicher Softwarearchitekt und Consultant in Frankfurt a. M. Er beschäftigt sich mit innovativen Open-Source-Technologien wie Apache Hadoop und Lucene und ist Member der Apache Software Foundation und Vice President Apache Labs.
Links & Literatur
http://hadoop.apache.org
http://developer.yahoo.com/hadoop/
http://cloudera.com
http://archive.cloudera.com/cdh/2/hadoop-0.20.1+169.113.releasenotes.html
https://github.com/yahoo/hadoop-common/blob/yahoo-hadoop-0.20.100/YAHOO-CHANGES.txt
http://developer.yahoo.com/blogs/hadoop/posts/2011/01/announcement-yahoo-focusing-on-apache-hadoop-discontinuing-the-yahoo-distribution-of-hadoop/
http://www.cloudera.com/blog/2011/02/some-news-related-to-the-apache-hadoop-project/
In offenen Communities wie Apache arbeiten Committer aus verschiedenen Ländern und Kulturen mit unterschiedlichen Muttersprachen und Englischkenntnissen verteilt über alle Zeitzonen teils in ihrer Freizeit, teils als Teil ihres Jobs zusammen. Und eigentlich ein Wunder oft funktioniert das auch. Schwierig wird es, wenn Geld hinzukommt. Und wenn Zeitdruck aufgebaut wird.
In Technologiebereichen, die besonders innovativ und zukunftsträchtig sind, wachsen neue Geschäftsfelder schnell. Start-up-Firmen gründen sich und ziehen besonders zurzeit im Silicon Valley Risikokapitalgeber an wie Licht die Mücken. Ausgestattet mit diesem Geld wächst die Notwendigkeit, massiv zu wachsen und den Markt in kurzer Zeit schnell mit Produkten und immer neuen Verbesserungen und Features zu füttern. Ist die Basis dieser Produkte ein Apache-Projekt, führt das fast zwangsläufig zu Spannungen im Projekt. Einerseits müssen sich alle Committer auf gemeinsame Ziele verständigen, was durch immer neue Diskussionen über die Zeit ausgependelt wird. Unternehmen verstehen diese Prozesse oft nicht, oder sie scheinen ihnen als unnötig und unproduktiv, zumindest aber überflüssig, hinderlich und zu langwierig. Ist das Unternehmen nun stark mit dem Open-Source-Projekt verbandelt, muss es den Spagat schaffen zwischen seinen eigenen Interessen und denen des Projekts, die ja auch irgendwie die eigenen sind, aber eben nicht die Kerninteressen und jedenfalls kaum diejenigen der Manager und Investoren.
Aber genauso wie manche Manager sich als Alphatiere gerieren, spielt der eine oder andere Open-Source-Entwickler sich als Committer-Diva auf, die natürlich zu viel Durchblick in die vermeintlich fehlende Urteilskraft der anderen hat, um sich zu einem Kompromiss herablassen zu müssen. Ein einziges solches Ego reicht dann schon, um die Weiterentwicklung nachhaltig zum Stoppen zu bringen. Denn bei Apache kann jeder Committer gegen jede Codeänderung sein Veto einlegen, solange er es technisch begründet. Code, der mit einem Veto belegt wurde, kann nicht in ein Release einfließen und muss im Extremfall aus dem Code-Repository entfernt werden. Vetos sind nicht einfach durch Mehrheitsentscheidungen zu überstimmen und werden leider auch politisch eingesetzt. Meiner Meinung nach sind langstehende Vetos ein Zeichen für unreife Projekte. Denn das folgende Fondermannsche Korollar der Open-Source-Projektreife gilt: In einem gereiften und funktionierenden Open-Source-Projekt werden Vetos schnell aufgelöst.
Ein Beispiel für ein vetoschwangeres Projekt ist Apache Hadoop [1]. Von der generellen Marschrichtung über konkrete Zuschneidung von Releases bis hin zu technischen Detailfragen überall kommen Vetos zur Anwendung. Hadoop ist dabei eine noch recht junge Software in einem stark innovativen Umfeld, die sehr großes Spezialwissen benötigt, besonders umfangreiche Hardware zum Testen und sowohl von Real-Time-Datenbanken wie auch im Batch-Prozessing-Umfeld eingesetzt wird. Es ist also zu erwarten, dass es hier an bestimmten Punkten im Lebenszyklus zu Verwerfungen kommt. Das war in der heißen Phase von J2EE-Servern auch nicht anders. Dass diese jedoch nicht überwunden werden, ist kein gutes Zeichen.
Hadoop wird von vielen Unternehmen eingesetzt, die auch in der Open-Source-Szene aktiv sind, wie Facebook und Twitter. Aktiv in der offenen Entwicklung sind vor allem Yahoo! [2] und Cloudera [3]. Yahoo! betreibt die größten bekannten Hadoop-Cluster. Cloudera steht Unternehmen, die Hadoop einsetzen, mit Rat und Tat zur Seite. Beide haben neben der Arbeit an Apache Hadoop eigene Distributionen veröffentlicht, die buchstäblich Hunderte von Patches enthalten, die sich im letzten Hadoop-Release noch nicht finden. Man könnte also sagen, dass es einen stillen Fork gibt, bei dem sich zumindest Cloudera entschieden hat, das Projekt selbst weiterzuentwickeln, um überhaupt auf seinem Markt beweglich zu bleiben und Kundenwünsche zu erfüllen.
Die heutige Situation rund um Hadoop ist also alles andere als erfreulich. Es ist nämlich nun extrem schwierig und aufwändig, bei diesen Patches die Spreu vom Weizen zu trennen und dann nach Apache Hadoop zu portieren. Gleichzeitig müssen Cloudera [4] und Yahoo! [5] ihre eigenen Forks weiterpflegen. Zu ähnlichen Erkenntnissen scheint auch Yahoo! gekommen zu sein. Im Januar kündigte der Hadoop-Hauptkontributor an, dass man die eigene Distribution nicht mehr weitertreiben und stattdessen alle Energie auf Apache konzentrieren wolle [6]. Auch Cloudera bekannte sich in einer Reaktion zu Apache Hadoop als Hauptentwicklungslinie, hält allerdings an einer eigenen Distribution fest. Das ist angesichts des Geschäftsmodells von Cloudera nicht verwunderlich [7].
Die Schritte hin zum nächsten Hadoop-Release sind klein, aber sie werden gemacht. Doch noch sucht der Hadoop-Elefant den Weg aus der selbstgewählten Sackgasse und dreht sich tapsig um sich selbst. Es ist heute unklar, welcher Branch mit welchen Features wirklich veröffentlicht werden wird und wann. Zumindest aber scheinen die Egos mittlerweile verstanden zu haben, dass ich nicht gleich besser ist. Und irgendwann werden auch die Vetos ohne viel Aufhebens aufgelöst werden, ähnlich wie das bei anderen gesetzteren Projekten mittlerweile auch der Fall ist.
Bernd Fondermann (bernd.fondermann[at]brainlounge.de) ist freiberuflicher Softwarearchitekt und Consultant in Frankfurt a. M. Er beschäftigt sich mit innovativen Open-Source-Technologien wie Apache Hadoop und Lucene und ist Member der Apache Software Foundation und Vice President Apache Labs.
Links & Literatur
http://hadoop.apache.org
http://developer.yahoo.com/hadoop/
http://cloudera.com
http://archive.cloudera.com/cdh/2/hadoop-0.20.1+169.113.releasenotes.html
https://github.com/yahoo/hadoop-common/blob/yahoo-hadoop-0.20.100/YAHOO-CHANGES.txt
http://developer.yahoo.com/blogs/hadoop/posts/2011/01/announcement-yahoo-focusing-on-apache-hadoop-discontinuing-the-yahoo-distribution-of-hadoop/
http://www.cloudera.com/blog/2011/02/some-news-related-to-the-apache-hadoop-project/