mikas blog

Nagios, das bekannte Open Source Monitoringtool wurde von der Firma Netways unter dem Namen ICINGA geforkt:

• Netways Blog: ICINGA – Nagios ist geforked
• GroundWork: Nagios forked by Icinga, GroundWork’s POV
• Heise: ICINGA: Abspaltung von Nagios vollzogen
• Linux Magazin: Icinga: Entwickler forken Nagios
• Linux Magazin: Interview mit Julian Hein, Netways GmbH, zum Nagios-Fork

Was aber bedeutet das jetzt für die Community?

Bei Nagios hat sich in letzter Zeit relativ wenig öffentlich sichtbares getan. Nagios Hauptentwickler, Ethan Galstad, wurde zum Flaschenhals, weil alles an ihm vorbei muss und er als Einziger im CVS commiten darf. Anregungen, Patches,… greift er anscheinend nicht immer oder nicht schnell genug auf und auf Rückfragen zu lange geplanten und ersehnten Features (die aber noch immer nicht realisiert wurden) reagiert er selbst nicht. Der wohlwollende Diktator (engl: Benevolent Dictator) in einem Projekt ist an und für sich ja nichts Schlechtes – solange die Entwicklung darunter nicht leidet. Ein Beispiel wo das sehr gut funktioniert ist Linus Torvalds mit dem Linuxkernel. Er kann die Unmenge an Patches klarerweise gar nicht mehr alleine abarbeiten und vertraut stattdessen auf erfahrene Maintainer. Diese Maintainer betreuen in der Regel ein bestimmtes Subsystem des Linuxkernels, arbeiten ebenfalls mit der Community zusammen (großteils auf eigenen und von der Linux-Kernel-Mailingliste getrennten Mailinglisten) und stellen das Ergebnis der Arbeit via Versionskontrolle Linus zur Verfügung. Die Maintainer genießen das Vertrauen von Linus, der das Resultat der Arbeit (die durchaus einige Reviews auf Mailinglisten, inklusive der Diskussionsmöglichkeit mit Linus) in seinen offiziellen Kerneltree aufnimmt. Es wird öffentlich und sichtbar kommuniziert – Probleme werden ohne Umschweife (und gerade für Einsteiger manchmal sehr rüde wirkend) direkt auf der Linux-Kernel-Mailingliste angesprochen.

Bei Nagios gibt es diese Art der öffentlichen Kommunikation anscheinend nicht. Ethan Galstad selbst schreibt jetzt auf der nagios-devel-Mailingliste als Antwort zu dem Fork:

2. While it may appear that things are slow to the community, many
things are happening behind the scenes, including:
[…]
– We’ve had to spend considerable resources protecting the Nagios
project against commercial entities that would endanger its future.

Da stecken gleich zwei Probleme auf einmal drin:

1) behind the scenes: Kommunikation hinter dem Vorhang ist sehr schlecht, denn die Öffentlichkeit und auch die
Community bekommen also nichts davon mit. Das wäre noch vertretbar, wenn sich das Projekt weiterbewegt, aber in einem Quasi-Bugfix-Modus wirkt sich das nicht sonderlich community-fördernd aus (siehe Online-Changelog, im Changelog vom Daily-CVS-Snapshot-Tarball steht ganz oben “3.1.0 – ??/??/2008” – das entspricht also nicht einmal dem eigentlichen CVS-Tree, der “3.1.1 – 02/??/2009” im Changelog führt).

2) protecting the Nagios project against commercial entities: wer Konkurrent von Nagios Enterprises (der Firma von Ethan) sein könnte bekommt also was auf den Deckel. Ich verstehe das grundsätzliche Problem von Ethan sehr gut, nur könnte er das für alle Beteiligten viel besser nutzen: statt sich mit anderen Nagios-Dienstleistern anzulegen, sollte er diese unterstützen. Warum? Weil das für Kunden, die Community und sogar sein eigenes Geschäft positiv sein kann:

• Kunden sind nicht von einem einzelnen Dienstleister abhängig und haben damit nicht das Gefühl von Truck Faktor wie auch Vendor Lockin.
• die Community hasst Trademark-Spiele. Ein relaxter Umgang mit der Thematik kann Motivation, Lust und Wille am Projekt fördern, umgekehrt aber jegliche Freude zerstören.
• das eigene Geschäft: Ethan hätte mit seinem Produkt noch weiter reichende Präsenz, könnte Kooperationen schließen (er könnte Fragen zum Core ja vermutlich schneller und besser als Mitbewerber beantworten), Dienstleister zu seinem Partner machen (OEM, zertifizierter Partner, Reseller,…) und das wie virales Marketing nutzen

Also selbst wenn sich bei Nagios in Wirklichkeit mehr tut als die Öffentlichkeit (inklusive meiner Person) wahrnimmt, Ethan hat diesen Fork im Endeffekt erleichtert (um nicht zu sagen: erzwungen). Was sind jetzt die Aussichten? Meine persönliche Einschätzung für die Situation:

• Der Fork scheitert, aber das Original wird wiederbelebt: Ethan Galstad bringt Nagios öffentlich sichtbar wieder in die Schwünge und vermeidet, dass die Nagios-Community zu schnell zu ICINGA abzieht. Die Angst vor dem Fork würde damit das Original wiederbeleben und für alle – bis auf die Leute hinter ICINGA, sofern sie nicht diese Situation bezwecken wollten – Gewinn bringen.
• Der Fork ist erfolgreich: ICINGA liefert schnell genug eine Release, die a) ganz klar Open Source ist, b) keine Nachteile gegenüber Nagios hat und nur geringen Aufwand bei der Migration erfordert und c) ein oder mehrere exklusive Features bietet, die Nagios noch nicht hat, auf die die Nagios-Community aber abfährt. Sollten dann noch langfristig die Release-Politik, die Arbeit mit der Community, die Integration in die relevanten Distributionen und die öffentliche Wahrnehmung passen, werden wohl viele von Nagios zu ICINGA wechseln. Netways, die Firma hinter ICINGA, sollte als Veranstalter der Nagios-Konferenz, Betreiber von u.a. Nagios-Exchange.org und Entwickler von mehreren Nagios-Addons genug Erfahrung haben, um dieses Gewicht zu Stemmen.
• Der Fork ist erfolgreich, aber auch das Original kommt wieder in die Gänge: wenn die Entwickler von Nagios und ICINGA beide ihre Ziele erreichen und vielleicht sogar kompatibel zueinander sind, könnte das die Situation mit dem Engpass in der Entwicklung von Nagios entschärfen. Für den Anwender ist es komplizierter, weil er auf einmal die Qual der Wahl hat. Viel unnötige Energie kann auf beiden Seiten entstehen. Ob diese Situation langfristig tragbar ist, ist nur schwer abschätzbar. Das kann entweder zu einem kompletten Merge (Beispiel gcc + EGCS), zwei Entwicklungsrichtungen die unterschiedliche Augenmerke haben aber sich trotzdem nicht zu weit von einander entfernen (Beispiel MySQL-Forks) oder zu einer komplett konträren Entwicklung führen (Beispiel Ingres).
• Der Fork ist erfolglos, das Original lernt aus der Situation nicht: bei Nagios ändert sich also nichts, gleichzeitig aber schafft auch ICINGA weder den Sprung zum offiziellen Nachfolger noch zu einem ernsthaften Konkurrenzprodukt – das ist die schlechteste Option für alle Beteiligen.

Ich bin gespannt was die beiden Parteien aus dieser Situation machen.

This entry was posted by mika on Thursday, May 7th, 2009 at 12:39 and is filed under Computer, Links, Open Source. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.