Nagios : de l’open source à l’open core ?

Posted in Nagios by Nap on April 20, 2010 8 Comments

L’open core : Community/Enterprise

Je viens de tomber sur deux posts intéressants ici et qui traitent d’un problème qui se répand de plus en plus dans les logiciels ouverts touchant au monde de l’administration et supervision système : le modèle Community/Enterprise, déjà utilisé par Zenoss par exemple. Ce modèle à un nom en fait : open core.

Le principe est simple : une version open source, nommée Community, est fournie. Une version Enterprise, privatrice, est également présente et est la seule version supportée par la société éditrice du logiciel . Cette version possède des fonctionnalités bien plus avancées que la Community. Il est dit qu’au bout d’un moment, les avancées de la version Enterprise sont avantageux pour la community. Mais on peut se demander si ce n’est pas exactement l’inverse qui est plus réaliste.

Si l’on regarde un peu les versions Community de logiciels utilisant déjà ce principes, on s’aperçoit qu’un risque majeur les touchent déjà : le seuil de fonctionnalités. Comme va l’évoquer notre très cher JP Troll dans un de ses futurs articles (scoop inside  :mrgreen: ), ceci consiste à limiter le nombre de fonctionnalités que l’on fait entrer dans la version communautaire pour toujours garder un avantage certain à la version Enterprise.

Prenons deux exemples déjà utilisé dans un des deux articles cités : Zenoss et Hyperic-hq dans leurs versions communautaires. Les courbes ci-dessous sont la taille du code de ces versions fournies par ohloh.

Zenoss :

zenoss

Hyperic :

hyperic

On note un certain plafond, tout particulièrement pour Hyperic-hq. Les développeurs se sont endormis? Certainement pas. Mais pourquoi chercher à améliorer la version shareware de leur outils?

Oups, le terme est sorti. Shareware. Ne nous voilons pas la face, les versions communautaires y ressemblent fortement : limitées, elles demandent de passer à la version complète pour en profiter réellement. Au moins, ce n’est pas limité dans le temps, c’est déjà ça. De plus, il est toujours possible de forker, même si dans les faits, personne ne s’y attaque (vous avez vu un peu le nombre de lignes de code de ces outils? ;-)   ).

Mais ce modèle implique que les patchs proposés dans la version communautaire soient “laissés” à l’éditeur pour qu’il puisse les intégrer à la version privatrice.

Et Nagios ?

Mais alors où est le rapport avec Nagios finalement? Regardons un peu sa courbe de développement :

nagios-codehistory

Vous allez me dire que c’est une habitude chez Ethan (l’auteur principal de Nagios) d’avoir un tel fonctionnement, ce qui est particulièrement compréhensible après tout et l’on n’a rien à y redire. Mais regardons un peu ce qu’il a annoncé sur la mailing list :

“There is nothing broken or wrong with Nagios Core the way it is.”

Ah.. bah rangez vos patchs, la courbe va rester plate un moment alors… Mais pourquoi refuser toute avancées majeure? Nagios XI tout simplement? (pour rappel, Nagios XI est une solution privatrice basée sur Nagios éditée par Nagios Enterprise).

Après tout nous avons également “Our commercial Nagios XI solution is not 100% Open Source, and it probably won’t ever be in its entirety. [...] Most all other commercial Nagios solutions out there go the same route.” et “commercialization of Nagios is going to expand in the future, so we can continue to provide more great solutions for the people that need them.”

Le modèle “open core” est assez bien annoncé lorsque l’on met tout bout à bout. Procès d’intentions? Je pense que l’on a assez d’éléments pour dire que non.

Modèle efficace dans le cas de Nagios?

Outre le fait qu’un modèle purement open source (et non logiciel libre), et a fortiori open core, n’est pas efficace (cf article sur l’art de la guerre), on peut se poser la question si l’open core va bien fonctionner dans le cas de Nagios.

Pas si sûr. Contrairement à Zenoss et Hyperic, le code de Nagios est à tous ses auteurs respectifs, donc impossible de changer ou rajouter un licence. La solution XI ne peux pas rajouter un broker fermé il me semble, vu qu’il se charge dans un code GPLv2 (je peux me tromper sur ce point). Donc au pire, c’est le contour de la solution qui va être fermé. On a d’ailleurs eu une reprise en main de NDO, ce n’est pas pour en rajouter un autre, mais bien l’utiliser comme base, même si le schémas de la base justement est critiquable.

Contrairement à Zenoss et Hyperic encore une fois, l’offre “Enterprise” a mis du temps à se lancer. Des solutions alternatives existent déjà, et sont de très bonnes qualités (Centreon, Op5 Monitor 5). Pour Op5, un des développeurs principal de Nagios est même de la partie, avec son couple Merlin/Ninja.

Pour avoir un vrai modèle open core efficace, Nagios Enterprise a raté le coche. Il ne peut pas “boucler” des points clés de l’outil pour saper la concurrence, et arrive même après elle. Son auteur y pensait peut être depuis le début, mais il aurait du faire comme les autres dès ce moment là.  Maintenant au milieu du guet, on va juste avoir une dispersion des solutions. Toute basées sur le même cœur oui, mais solutions qui vont devenir (ou sont même déjà) incompatibles entre elles. Centreon va lancer son propre broker (dont les fonctionnalités font saliver d’avance :) ), Op5 lui part sur Merlin, et Nagios XI reste semble-t-il en NDO. Heureusement pour les utilisateurs, Centreon et Op5 semblent se mettre d’accord sur un modèle de base commun, ce qui est particulièrement bien pensé.

Ne nous voilons pas la face, la véritable intelligence ne va plus être dans le cœur de Nagios, mais bien dans ses solutions externes. Il va rester l’ordonnanceur central avec ses petits défauts de conceptions qu’on lui connait pour les environnements distribués, mais les corrélations, la notion d’évènement et les analyses vont se faire au niveau d’au dessus. Et tant mieux après tout, ce n’est pas à un ordonnanceur de gérer cela.

Je reste persuadé que lorsque l’on parle d’outils de supervision, l’apport de la communauté est indispensable. De plus, aucune entreprise, même de taille moyenne,  ne se lancerait dans un projet de supervision sans support et surtout sans intégration. Les licences ne sont qu’un facteur limitant (le nombre de machines explosent dans les datacenters, une solution sans licence à l’agent est nettement avantagée). Nagiox XI a un intérêt, c’est l’éditeur lui même. Mais le code de Nagios n’évolue plus trop, donc l’intérêt de ce choix est limité pour les utilisateurs.

Ethan avait-il seulement le choix de partir sûr cette solution? Si l’on reste pragmatique, je ne pense pas. Même en partant d’une solution libre (pardon, open source) qui existait déjà, il perdait sa légitimité d’auteur principal (du cœur oui, de la solution non), véritable argument marketing. Monter sa propre solution avec seulement des briques libres prends plus de temps qu’en faisant des concessions privatrices. Simple problématique de time to market finalement.

Est-ce dommageable ?

Dans les faits, le seuil de fonctionnalités est déjà présent depuis un moment pour le cœur Nagios. On n’a donc pas à avoir peur de l’avenir, on y est déjà.

Heureusement, les moyens de “bloquages” d’avancées en open source ne sont pas totalement actifs, en tout cas pour les solutions. Le cœur? Il va rester ce qu’il est, un très bon ordonnanceur. Tout le monde va sortir l’intelligence de l’outil. Question de modularité après tout. La phase de transition va être pénible, mais le temps que l’utilisateur a toujours une solution libre à sa disposition, ceci reste acceptable.

Nagios ne sera jamais totalement comme Zenoss finalement, et tant mieux. Il va aller vers autre chose. Il faut juste attendre vers quoi. Ou bien amorcer soit même la transformation en regardant ce qui est le plus propice à l’instant t pour arriver à une situation qui nous est avantagée, car il parait que c’est ce qu’il y a le plus efficace ;-)

Ceci va également être l’occasion de voir un peu l’affrontement des modèles open source et open core. Cette année va décidément être marrante :)

Art of (free software) war

Posted in Général by Nap on April 18, 2010 9 Comments
Ce texte fait suite à la lecture de trois ouvrages : « Richard Stallman et la révolution du logiciel
libre », « L’art de la guerre » de Sun Tzu, et « Traité de l’efficacité » de François Jullien. Si le
premier est une oeuvre bien connue des acteurs du monde du libre, les deux dernières méritent
également d’être lues. L’art de la guerre est le grand classique sur la vision des affrontements du
point de vue chinois. Le second en est un approfondissement. Il présente les pensés occidentales et
orientales de l’efficacité de la guerre, mais aussi plus généralement de toute activité humaine. Ce
sont justement ces idées que je vais tenter d’appliquer au monde du libre. Je n’ai fait que tenter
d’appliquer ce qu’il explique si bien à notre environnement.

Lors de la lecture de la biographie de Richard Stallman sortie dernièrement (et dont je recommande chaudement la lecture), un chapitre m’a un peu interpellé : celui qui montre la différence entre le mouvement Open Source et celui du Logiciel Libre.

L’Open Source se concentre sur l’obtention de logiciels les plus performants et stables possibles. C’est une vue purement technique qui pense que la méthode de développement ouverte est la plus performante possible. Ils s’opposent ainsi aux logiciels privateurs en proposant des logiciels ouverts performants.

Le Logiciel Libre repose quant à lui sur la sauvegarde des libertés des utilisateurs. Le fait d’avoir des logiciels au code ouvert n’est qu’une nécessité pour arriver à ce but. Ce n’est pas l’objectif final. Sa principale méthode reste la persuasion sur l’importance de la sauvegarde des libertés. Il s’oppose également aux logiciels privateurs.

J’ai cherché à savoir lequel était le plus “efficace” dans cette guerre face aux logiciels privateurs. Pour cela, j’ai fais un parallèle entre ces deux protagonistes et les méthodes occidentale et chinoise de la stratégie. Les idées utilisées pour décrire l’efficacité de ces dernières sont celles de l’essai “Traité de l’efficacité” de François Jullien (disponible ).

Au final, on voit que le logiciel libre est plus efficace dans cette guerre que le mouvement open source. Ceux qui veulent savoir pourquoi peuvent accéder à cette étude sur ce lien : étude sur l’art de la guerre appliqué au logiciel libre. Une version PDF est également disponible là.

La réponse de l’auteur de Nagios

Posted in Nagios by Nap on March 2, 2010 3 Comments

Ca y est, l’auteur de Nagios a répondu à la lettre ouverte sur la mailing list ici. Réponse assez complète, mieux que la blague qu’il nous a sorti sur “nagios-drama”. Voici ce que l’on peut retenir de sa réponse :

  1. il ne lâche pas la partie open source, les fond de XI permettrons de développer d’avantage la partie open source
  2. XI n’est pas open source car il utilise des modules externes qui ne le sont pas
  3. la commercialisation de Nagios va se développer
  4. la gestion du trademark ne sera pas assouplie
  5. c’est lui qui dirige depuis 11ans, ça ne va pas changer comme ça
  6. le core est bien comme il est, pas besoin de changements, ou alors dans les addons

Bon le point 1 tant mieux, reste à le voir en action. Pour XI ok, de toute manière c’est son application, il n’a pas à justifier son choix de licence après tout. On voit mieux comment ça va s’articuler avec le point 3 : on est bien parti pour avoir une version Enterprise complète (XI) et une communautaire. Ca ressemble bien à Zenoss pour çe point là, espérons que le développement de la partie open source n’est pâtira pas.

Le point 4 est ce qu’il est, même si il protège un peu trop son trademark en ce qui concerne l’affaire nagios-fr/icinga au point de jouer contre son camp. Le point 5 bah pas grand chose à dire.

Le point 6 lui est plus discutable. Je suis d’avis que ce n’est pas le core qui est bien, mais les idées qui propose (la gestion de la configuration, le support des sondes de checks et de notification) mais son implémentation le limite à des environnements de taille moyenne : les petits environnements tournent en général sous Windows, là où Nagios ne tourne pas, et les grands on besoin de bien plus de performances que Nagios propose pour l’instant, et surtout a besoin d’une centralisation de certaines choses comme les notifications et d’une supervision distribuée et hautement disponible.

Au moins on sait où on va maintenant avec Nagios, on a les grandes lignes, le virage de la phase business (open source : dev, communauté puis business) est amorcé. Espérons qu’on ne tombe pas dans le ravin.

Nagios : l’auteur tente de museler sa communauté pour cause d’avoir été trop libre!!

Posted in Nagios by Nap on February 23, 2010

C’est un cri d’alarme de la communauté Nagios que je me permets de relayer ici. En effet, après une longue phase d’ignorance de cette communauté de la part de l’auteur de l’outil, nous sommes arrivés à un point qui semble sans retour : l’auteur tente de museler la communauté française pour avoir été trop ouverte!!

Revenons un peu sur les faits : lancé il y a plus de 10ans, Nagios est encore à l’heure actuelle l’outil de référence dans le monde de la supervision open source, et de sérieux concurrents comme Zabbix ou Zenoss commencent à lui faire de l’ombre. Dans le domaine de l’open source, et tout particulièrement celui de la supervision, la force des outils reposent sur leur communauté. Celle de Nagios a été fleurissante pendant des années. Cependant, depuis environs deux ans, l’absence de réponse de l’auteur principal aux propositions de cette communauté a légitimement irrité cette communauté, au point de voir fleurir un fork il y a environs un an, nommé Icinga.

Là où l’histoire se complexifie se passe dans la sphère économique des sociétés utilisant et supportant Nagios. Comme pour beaucoup de logiciels commençant à prendre de l’ampleur, après plus de 8 années dédiées au projet l’auteur a légitimement crée une société de support et d’intégration nommée “Nagios Enterprise” et qui a déposé le nom “Nagios”. Le fork “Icinga” est issu de membres de la communauté Nagios qui sont employés par “Netways”, société allemande qui fait elle aussi du support et de l’intégration de Nagios. Si la licence GPLv2 est respectée, l’opportunisme et le manque de fair-play de cette société a fortement irritée l’auteur de Nagios et le reste de la communauté qui est restée fidèle dans sa grande majorité au projet initial.

Cette histoire semble avoir malheureusement eu un effet collatéral : l’auteur de Nagios s’est retourné contre sa communauté et l’ouverture qui a permis ce fork en l’ignorant encore davantage si c’était encore possible, en ne répondant pas par exemple à des propositions d’amélioration substantielles de code. Dernier affront en date et non des moindres : l’auteur demande à ce que lui soit cédé l’enregistrement DNS nagios-fr.org afin qu’il puisse réunir une communauté plus “corporate” car celle-ci a parlée sur son site du projet open source, mais félon à ses yeux, Icinga. Posts qui de plus n’étaient pas particulièrement élogieux. Fork qui au final aura plus coupé l’auteur de sa communauté que simplement un projet en deux.

La coupe est pleine pour la communauté qui se veut aussi ouverte que les outils qu’elle défend. Dans logiciel Open Source, il y “free as in beer” mais aussi “free as in speech”. Olivier Jan, fondateur et leader de cette communauté francophone, a ainsi répondu [1] qu’il ne serait pas possible de se laisser dicter ce sur quoi la communauté pouvait parler. Pour ne pas risquer une hypothétique assignation en justice (pour protection de trademark), il a donc été décidé d’obtempérer à l’attaque en déplaçant le site de la communauté vers monitoring-fr et de donner nagios-fr.org à la société Nagios Enterprise une fois la migration finie.

C’est donc avec une lettre ouverte [2] au titre de “The nagios community wants to keep its open soul” que la communauté demande où ce projet se dirige, s’il sera toujours ouvert et respectueux des principes même des l’open source. Des questions se posent en effet sur la réelle volonté de laisser ce projet open source en gelant la partie GPL et en l’incluant dans une solution fermée (”Nagios XI” éditée et diffusée sous peu par Nagios Enterprise) qui sera vraisemblablement seule à évoluer dans les années à venir. La communauté demande encore comment elle est perçue, si elle a encore sa place et si elle est tenue de tenir sa langue dans sa bouche sous peine de poursuite judiciaire en cas de non respect de la sacro sainte parole corporate de Nagios Enterprise.

Cette communauté fortement active ces dernières année est supportrice de l’industrialisation et le support de Nagios par des sociétés de logiciels libres, mais à la condition de pouvoir garder son âme. Nous souhaitons tous que Nagios conserve son rang qui ne l’oublions pas lui a été apporté grâce au soutient de toute sa communauté et que le projet revienne à la “bonne époque” où les codeurs et personnes de bonne volontés avaient encore leur mots à dire face à la communication marketing.

Espérons que cette lettre ne restera pas lettre morte, car ceci finirait de creuser le gouffre qui sépare l’auteur de Nagios et sa communauté qui est la vraie force motrice du projet et ferait le nid d’un fork qui diviserait encore la communauté, et qui rajouterai encore des noms tabous sur les sites traitant de Nagios.

Toutes les personnes souhaitant apporter leur soutient à notre démarche peux le faire en votant sur http://ideas.nagios.org/a/dtd/22035-3955 (pas besoin d’avoir un compte) qui est le site des idées de Nagios.

[1] : http://www.nagios-fr.org/2010/02/accuse-nagios-fr-org-levez-vous/
[2] : https://sourceforge.net/mailarchive/forum.php?thread_name=20100223103544.9upjoc1mbogwwc4o%40intra.expertise-online.net&forum_name=nagios-devel

EDIT: l’auteur a répondu. Voir pour sa réponse.