Als im letzten ADMIN-Heft mein Kollege Brendel die Vielfalt an Open-Source-Software lobte, war ich, vorsichtig gesagt, etwas überrascht. Denn der Schwerpunkt dieses Heftes zeigt, wohin das führt: Mehr als ein Dutzend Ableger des Monitoring-Paketes Nagios gibt es mittlerweile, da drängt sich doch schnell die Frage auf, wem dieses Chaos nützen soll.

Heute existieren über 300 Linux-Distributionen mit mindestens vier verschiedenen Paketmanagement-Systemen [1]. Neuerdings fangen die Linux-Entwickler an, verschiedene Init-Systeme wie System-V, Upstart, Systemd und so weiter zu verwenden. Jetzt muss sogar ein neues Logging-Subsystem her, meint Lennart Poettering, der sich schon durch die Neuerfindung von Linux-Audio per Pulseaudio einen Namen gemacht hat.

Natürlich haben Hersteller und Systemhäuser Interesse daran, Geld zu verdienen. Da mag es naheliegen, sich ein freies Software-Paket zu nehmen, es ein bisschen anzupassen und dann mit dem eigenen Stempel zu versehen. Doch auch sonst scheint die Neigung weit verbreitet zu sein, einen Fork oder gleich ein komplett neues Projekt zu starten. Prinzipiell gibt es dagegen wenig zu sagen, schließlich leben wir in einem freien Land, und jeder kann mit seiner Zeit anfangen, was er will. Wer beispielsweise anfängt, das Programmieren zu lernen, findet nur schwer ein Anwendungsfeld, das noch gänzlich unberührt ist. Außerdem ist es für Anfänger fruchtbar, ein Projekt von Grund auf zu entwickeln – auch wenn es Vergleichbares schon gibt.

Not Invented Here

Jenseits solcher Fälle neigen aber auch gestandene Programmierer bei freien und kommerziellen Linux-Distributionen dazu, Dinge zu programmieren, die es eigentlich schon gibt. Oft drängt sich der Eindruck auf, der Grund dafür sei einfach, dass das Bestehende von jemand gemacht wurde, der nicht zum eigenen Team gehört. Im englischsprachigen Raum ist das als "Not Invented Here" (NIH) bekannt: Wenn es nicht von uns ist, muss es schlecht sein, also neu gemacht werden. Dabei läge der Sinn von freier Software doch eher darin, gemeinsam an einem Projekt zu arbeiten, Fehler zu finden, zu beheben und es damit Stück für Stück ein bisschen besser zu machen. Vorbilder dafür finden sich im Bestand der GNU-Software, etwa der GNU-Compiler, der Editor Emacs und der zahllosen Bibliotheken und kleinen Tools, die teilweise mehr als 20 Jahre alt und entsprechend ausgereift sind.

Heute hat sich die Situation umgekehrt: Kleinste Unstimmigkeiten führen sofort zur Neugründung eines Projektes, wie man es etwa bei Google beobachten kann, das sich das Motto "Don't be evil" auf die Fahnen geschrieben hat. Existierende Open-Source-Webbrowser wie Firefox waren nicht gut genug, also musste das eigene Chrome her. Betriebssysteme für Mobiltelefone gab es ebenfalls schon als freie Software, sogar auf Linux basierend, doch Google wollte lieber Android neu erfinden, einschließlich einer neuen Runtime-Umgebung, die aber Java doch so ähnlich ist, dass Google nun darüber mit Oracle im Patentstreit liegt.

Neuerfinder Google

Seit Neuestem stößt sich Google auch an Javascript, das mittlerweile auf eine mehr als 10-jährige Geschichte mit entsprechend ausgereiften Tools, Standardisierung durch die ECMA und Know-how von Entwicklern zurückblicken kann. Jetzt soll es die Neuerfindung "Dart" richten, denn schließlich leistet man sich mit Milliardenbudget nicht umsonst Sprachentwickler wie Gilad Bracha. Dass Dart [2] sich wieder nur minimal von anderen Programmiersprachen unterscheidet, muss nicht stören. Vermutlich lassen sich die anstehenden Probleme eines Web 3.0 nur damit lösen. Die ebenfalls schon bei Google von Rob Pike und Ken Thompson entwickelte Programmiersprache Go fristet derweil ein Nischendasein.

Vom Ubuntu-Hersteller Canonical erreicht uns die Nachricht, man verabschiede sich demnächst von der NoSQL-Datenbank CouchDB, weil diese nicht wie gewünscht skaliere. Man rechne für den eigenen Subskriptionsdienst Ubuntu One mit einem Wachstum bis zu Millionen Benutzern, und das könne CouchDB nicht stemmen. Die Lösung für das Problem sieht Canonical aber nicht etwa darin, eine der mehr als 20 existierenden NoSQL-Datenbanken auf dem Markt oder eine gute alte SQL-Datenbank mit Sharding (verteilt über viele Rechner) zu verwenden. Damit kommen zwar Top-Ten-Websites wie Twitter und Facebook zurecht, bei Canonical soll es aber lieber eine Eigenentwicklung mit dem Arbeitstitel U1DB richten.

Was bringt es?

Die Vorteile der chaotischen Entwicklung sind fragwürdig. Natürlich müssen gelegentlich Pakete oder Subsysteme komplett erneuert werden, sonst gäbe es keinen technischen Fortschritt. Andererseits ist die Schrotflintenmethode auch dafür nur eingeschränkt geeignet: Jeder entwickelt munter vor sich hin, und irgendwann wird sich schon zeigen, was brauchbar ist. Problematisch wird dieses Verhalten dann, wenn es sich, wie etwa in der Linux-Welt, auf den Zustand des Gesamtsystems auswirkt. Zu viel Zersplitterung wird zur Zumutung für den Anwender oder Administrator, der sich einem riesigen Angebot gegenübersieht, aus dem er auswählen muss. Gleichzeitig leidet die Kompatibilität von Systemen wie Ubuntu und Red Hat immer mehr: Nicht nur das Paketmanagement unterscheidet sich, auch für das Init-System oder den Bootloader muss der Administrator komplett umlernen.

Kollege Brendel führt im letzten ADMIN-Heft als Vorteil die Auswahl an, die dem Anwender durch die Vielzahl an Software für den gleichen Zweck zu Verfügung steht. Meistens ist die große Auswahl aber eher Bürde als Chance. Wie soll denn ein Anwender aus den 40 Monitoring-Systemen auswählen, die es auf dem freien und kommerziellen Markt gibt?! Der Psychologe Barry Schwartz hat in seinem Buch "The Paradox of Choice --Why More is Less" dargelegt, wieso ein Überangebot die Unzufriedenheit steigert. Wenigstens für die IT-Magazine und -Websites hat die Sache ein Gutes, so lässt sich sarkastisch anfügen: Solange der Wildwuchs an freier Software weitergeht, gibt es für uns etwas zu schreiben.

Alles begann damit, dass wir uns wieder einmal Monitoring-Software angesehen haben. Zabbix, OpenNMS, natürlich Nagios, aber auch seine vielen Ableger. Gut ein Dutzend Projekte und Produkte haben wir allein in der Sparte Nagios-Nachfahren und Abkömmlinge gezählt. Lösungen, die hauptsächlich das freie Nagios und andere Open-Source-Komponenten integrieren wie Groundworks oder Open IT-Cockpit, solche die mehr eigenen Code einbringen wie Centreon und wieder andere, die nur die Architektur übernehmen, um auf dieser Grundlage völlig neue Software zu entwickeln, wie zum Beispiel Shinken.

Angesichts der Menge drängt sich allerdings eine Frage geradezu auf: Sind das nicht viel zu viele Anläufe auf dasselbe Ziel? Ist das nicht reine Ressourcenvergeudung? Wo könnten die Entwickler stehen, wenn sie an einem Strang zögen, statt jeweils ihr eigenes Süppchen zu kochen? Kurz: Kann das effizient sein? Das Nein muss einem auf der Zunge liegen. Denn das Rad ein Dutzend Mal zu erfinden führt zwangsläufig zu Dubletten und Überschneidungen.

Doch ist Effizienz hier überhaupt der richtige Maßstab? Auf Anhieb übersetzt man effizient mit wirtschaftlich, und dann scheint außer Frage zu stehen, dass damit eine Grundvoraussetzung bezeichnet ist. Doch könnte das nicht vorschnell gefolgert sein? Manchmal erhellt eine Analogie zu scheinbar fernliegenden Bereichen die Zusammenhänge. Hier zum Beispiel ein Blick auf natürliche Ökosysteme.

Analogie Ökosystem

Effizient – zumindest aus der Sicht des menschlichen Nutzers – sind etwa Monokulturen. Alle Pflanzen lassen sich dort über einen Kamm scheren, sei es bei Aussaat oder Ernte, beim Düngen oder bei der Bewässerung: Es reicht jeweils eine Kalkulation, eine Art von Maschine. Der Preis dieser Effizienz ist allerdings Anfälligkeit – denn ohne Schädlingsbekämpfung verwandelte sich leicht die ganze Kultur in das Schlaraffenland eines Ungeziefers oder Pilzes oder in Windbruch oder dürres Ödland. Die Geschichte ist voll von solchen Katastophen von der großen Hungersnot infolge der irischen Kartoffelfäule um die Mitte des 19. Jahrhunderts bis zu 40 Prozent Ertragsverlusten durch Pflanzenkrankheiten in Entwicklungsländern heute.

Ein Gegenspieler der Effizienz ist die Diversität. Die Artenvielfalt markiert zugleich den Gegenpol zur Verletzlichkeit der Monokultur. Ein Biotop aus lauter unterschiedlichen Arten wäre sehr stabil, denn was hier den einen gefährdet, ließe den Nächsten kalt, und viele Mitspieler könnten sich gegenseitig ersetzen. Dafür müsste man es viel differenzierter bewirtschaften. Wollte man der Stabilität wegen die Verschiedenheit aber auf die Spitze treiben, dann verwandelte sich auch dieser Vor- in einen Nachteil: Die Widerstandskraft würde mit Stagnation erkauft, denn wo im Extremfall nur noch wenige Individuen pro Art existierten, da wäre Fortpflanzung wegen der zu geringen Populationsdichte kaum mehr möglich. Aus diesem Grund maximiert die Natur weder die Effizienz noch die Diversität, sondern strebt nach einem Gleichgewicht beider Faktoren. So vielfältig wie möglich, ohne dass es zu einem Stillstand kommt, so effizient wie es geht, ohne zu leicht verwundbar zu sein.

Dieser Gedanke lässt sich übertragen: Eine vielfältige Software-Landschaft bietet Alternativen für mancherlei Ansprüche und wirkt einem Vendor Lock-In entgegen. Gäbe es aber nur noch Programm-Unikate, explodierten die Wartungs- und Schulungskosten, gäbe es keinen Erfahrungsaustausch zwischen den Anwendern mehr, lohnte es für Dritte kaum, Erweiterungen zu programmieren, müssten jedoch andererseits die Software-Preise in extreme Höhen schnellen. Aus dieser Perspektive sollte man also eher fragen: Markieren ein Dutzend Nagios-Ableger eine gesunde Balance?

Für alle ist Platz

Sie scheinen zumindest überwiegend ihre Nischen gefunden zu haben. Alle haben Kunden, die meisten erreichen sie auch über Partner, für die sie extra Programme auflegen. Schon potenzielle Kunden können mit einer Ausnahme überall kostenlose Demoversionen herunterladen, manchmal auch vorinstallierte Demos via Internet ausprobieren. Mehr als die Hälfte der Anbieter von Nagios-Nachfahren offerieren Trainings, alle auf die eine oder andere Weise Support und zusätzliche Informationen (Referenzen, Newsletter, News, Mailinglisten, FAQ, How-tos, Foren, Chats, Blogs, Dependancen in sozialen Netzen und so weiter). Der Umfang ist unterschiedlich – sehr ausgeprägt ist der Service für Kunden etwa bei Centreon oder OP5, etwas zurückhaltender gerieren sich Neteye oder Open IT-Cockpit – aber allen kann man das Bemühen attestieren, eine lebendige Community zu entwickeln.

Nagios und seine Nachfahren scheinen also ein vielfältiges und stabiles Biotop zu bilden, das etlichen Akteuren eine Nische bietet, in der sie ihr Auskommen finden. Darin tummeln sich sowohl Projekte, die in erster Linie von kommerziellen Interessen geleitet werden, als auch solche, die den Open-Source-Gedanken hochhalten und mehr oder weniger vom Idealismus ihrer Entwickler leben. Was funktioniert, hat recht. Es fände sich wohl auch nur schwer eine Rechtfertigung für eine Effizienzpolizei. Zumal das Biotop ja insoweit sogar auch effizient ist, als überall dasselbe Funktionsprinzip und Architekturmodell zum Einsatz kommt und die für die Flexibilität einer Nagios-Lösung so entscheidenden Plugins sehr oft ohne Änderungen nachnutzbar sind.

Das Rad ist übrigens im wirklichen Leben tatsächlich mehrfach erfunden worden. In Mesopotamien und der Induskultur, dem Alpenvorland, im Nordkaukasus, in Südpolen stößt man unabhängig voneinander um die Mitte des 4. Jahrtausends vor Christus auf erste Räder und Karren. Trotzdem handelt es sich dabei um eine der größten technischen Errungenschaften des Menschen überhaupt.