Jean Gabes a écrit 467 commentaires

Il me semble que github aspire une grande majorité des projets. Si quelqu'un a des chiffres ça serait intéressant d'ailleurs.

Plus sérieusement que l'armée de troll qui ne va pas tarder à se lancer à l’assaut, est-ce que certains ont des stats sur justement le nombres de projets lancés par rapports aux types de licences, et à projet "équivalents" (pas de gros car la licence joue moins) quel type a le plus de contributions.

Par exemple avec toute l’effervescence nodejs et javascript, je pense que les types BSD poussent forts. Est-ce que d'autres domaines restent fortement typés GPL?

J'ai ma petite idée en tant que mainteneur de projet GPL sur les résultats, mais j'aimerai bien des statistiques réelle que mon ressenti :)

Ne t'inquiète pas, on va s'arranger héhéhé :)

Pénalisant pour l'image et la dilution des forces, mais ça permet également d'abaisser la barrière d'entrée de nouveaux projets (plus dur de faire face à un "gros" que X plus petits). Donc au final l'écosystème n'est pas si mal en point. De plus ils s'éloignent de plus en plus les uns des autres, donc on va avoir des situations plus claires pour choisir LE bon outil à sa situation. Ca donne plus de travail aux consultants ;)

C'est pas faux, mais on s'amuse bien dans le milieu justement, c'est une sorte d'animation de la communauté comme une autre :p

Ce n'est pas complètement faux non plus. La raison est historique, le site a été monté par ses auteurs précédents, mais la société a réclamé la propriété de l'enregistrement DNS car il y avait nagios dans le nom, ce que les auteurs ont fait (pour ne pas se froisser avec l'auteur de nagios). Donc on était dans une situation "anormale" en effet après tout, là c'est un mal pour un bien, ça clarifie les choses et on va avoir un équivalent nagios-exchange.org/monitoring-exchange.org (oui c'est pas la première fois que cette histoire se passé :) ).

Oui en effet, je l'ai déjà dis dans le passé et ça se vérifie: il est mon premier "commercial" :). Mais il bat un nouveau record en terme d'image. Ce qui est ironique c'est que c'est justement pour protéger son image qu'il fait tout ça…

Le plus fort c'est que commercialement il n'y a aucun intérêt à faire ça. Le pire qu'il peut être "reprocher" aux mainteneur des sondes était de dire clairement qu'elles étaient également pour les autres outils du monde nagios (centreon-engine, icinga, naemon et shinken). Enfin bon ce n'était pas non plus un crime si grave, pas de quoi flinguer le site sans aucun avertissements…

J'ai beau chercher là j'ai du mal à comprendre ce qu'il a fait. D'habitude il y a une raison commerciale assez claire, mais là ce sont juste les sondes, et je vois mal comment les modifier pour les monétiser.

Oh mais je ne disais pas du tout que c'était débile d'aller vers là, bien au contraire :)

Le truc c'est qu'à chaque fois que l'on parle d'économie & open source/libre on arrive au modèle des services genre intégration. Mais voila, ce modèle fait vivre les intégrateurs, pas les dev/éditeurs justement. Il ne faut donc pas s'étonner que de plus en plus d'outils s'orientent vers de l'open core ou cherchent à rendre l'utilisation sur certains OS payantes (en gros pour 99% des personnes devoir recompiler sous Windows est de l'ordre de l'impossible, donc on a bien créé une barrière virtuelle ici), ou la pub (on utilise la popularité de l'outil, mais ça demande donc une audience monstrueuse, qui par définition ne sera atteinte que par quelques outils seulement).

Pour le Big Daddy c'est bien ce que je disais. Le modèle est valide car justement de gros acteurs ont tout intérêt à ce que l'outil se développe fortement pour booster leur propre business. Donc là aucun soucis à ce que ça reste open source.

Mais dans le monde "normal", avec un outil "normal" on a pas la visibilité de Firefox, ni de gros acteurs qui veulent payer les dev (car on fait un outil qui concurrence les offres des gros par exemple). Or les intégrateurs sont ravis de pouvoir faire du chiffre avec la version open source, mais ne participent que très très peu au dev (quand ils participent tout cours…). Pouvoir payer un salaire avec du dev à la demande ça se fait, mais si on veux pouvoir embaucher pour faire plus de dev par exemple là ce n'est plus tenable comme modèle.

Le modèle open source n'est donc pas viable comme tel dans le système économique actuel. Or en effet il faut être réaliste et l'adapter (genre open core). Ce qui m'étonne c'est que beaucoup semblent encore penser que ce modèle est viable pour tous les outils. Or non, il ne l'est pas. On a quelques exceptions bien sûr, mais soyons sérieux dans la majorité des cas ça ne marche pas.

Il ne faut donc pas s'étonner que de plus en plus d'outil (surtout d'infrastructure) s'orientent vers de l'open core. On avait déjà Nagios et Centreon, on a aussi Puppet, Cfengine, Nginx et prochainement Shinken. C'est dommage mais bon réalité fait loi :)

Je me demande si ce n'est pas la méthode la plus efficace pour que l'auteur ne développe plus du tout sur la version libre :)

Le fait d'en arriver à un tel modèle économique devrait se faire poser des questions à pas mal de monde de la communauté, car c'est de plus en plus la norme. On en arrive à quand même contourner l'esprit (accès sans limite) avec une astuce (source!=binaire), il y a un vrai soucis d'adéquation entre le principe du libre et le système économique actuel. On pourra avoir quelques victoires de temps en temps sur des niches qui s'y prêtes bien (Firefox et OpenStack avec leur modèle économique "big daddy" ou RedHat avec son modèle "masse critique permettant la certification par les grosses applications"), mais on est pas prêt d'arriver à le généraliser en l'état.

Pourquoi ne pas envoyer directement un mail à l'auteur de naemon? Il est très ouvert et réponds volontiers aux mails :)

Ah ce n'est pas du click and run c'est certain :p

Les deux sont pensés pour être des frameworks de supervision et non pas des "solutions". Ils sont donc à mettre dans les mains de quelqu'un qui souhaite maîtriser réellement sa supervision, en la concevant de bout en bout (même si dans Shinken on a à disposition des recettes pour les cas classiques, l'admin est encouragé à les adapter à son besoin).

Facilité ou flexibilité en gros :)

Pour info on a de petits soucis de perf sur www.shinken-monitoring.org, je suis en train de creuser ça.

Sinon pour icinga, c'est assez vaste en fait. En gros surtout du distribué (load balancing ET haute dispo), une focus sur la recherche des problèmes sources et une notion d'importance métiers sur les alertes (savoir qu'un serveur est tombé c'est bien, savoir qu'il a impacté à 20 niveaux de dépendances en dessous une application critique c'est mieux :) ).

Par contre icinga vient de base avec une interface de configuration (lconf de mémoire) là où il faut le mettre en place soit même pour Shinken. Ils ont aussi repris et amélioré l'interface de Nagios, là où Shinken a la sienne (en fait elle ne présente pas les mêmes choses tout simplement).

Le mieux ça reste encore de tester les deux, et d'aller lire le hors série Linuxmag de septembre 2012 dédié à Shinken pour mieux voir ce dont il est capable :)

Malheureusement ce sont ceux qui font le plus de bruits en effet. Je ne doute pas qu'il y ai aussi une armée de bonne volontés qui travaille à faire encore mieux que les cgroups pour les BSD, mais par définition ils travaillent, donc on ne les entends pas c'est dommage.

Tout à fait. Demander à ce que tous les noyaux soient au même niveau quand on souhaite améliorer les souches supérieures reviendrait à ne pas avancer. Linux et les BSD n'avancent pas sur les mêmes sujets en effet, mais est-ce un mal? De plus personne n'a le droit de demander à un autre d’arrêter d'avancer sur un sujet car son "camp" ne suit pas le rythme. Par contre ça doit motiver à suivre, voir innover ;)

Il me semble qu'elle a une petite sœur dans le genre, un peu plus large, ça a été évoqué dans un commentaire de la (longue) histoire Linkeo.

Puis bon, si je le fais c'est que je n'aurais pas encore compris comment ne pas me retrouver dans cette situation. Or là ça restera gravé dans ma mémoire au fer rouge, donc je suis sûr de ne pas l'oublier lors de mes prochains échanges avec des SSII/LL (j'arrive de moins en moins à faire de différence entre elles à vrai dire quand on parle des plus grosses).

Par ces clients là, car il pourraient en appeler à une sorte de diffamation : ils pourraient rétorqués que par rapport à certains contrats cadres qu'ils ont avec d'autres fournisseurs ça va leur porter préjudice.

Puis bon à la limite c'est le jeu, pourquoi pas. Ensuite à moi de faire comprendre que la règle sera que désormais pour avoir de l'aide, faudra faire un effort. Ca ne sert à rien de se plaindre d'une situation, autant en tirer des leçons pour ne pas recommencer les mêmes erreurs plus tard :)

Je ne suis pas sûr car je ne peux pas prouver qu'ils l'utilisent après tout :(

Pas tout le reste. La documentation du projet reste (non documenté un code ne sert à rien), ni l'accès au forum car c'est un lieu d'échange pour ceux qui veulent s'entraider autour du projet.

Mais tout ce qui demande un certain investissement ou engagement (temps de réponse, support et donc présence) doit être uniquement disponible que pour ceux qui sont prêts à en payer le prix. Il en est de même pour l'industrialisation de la solution. Ceux qui souhaitent faire la leur le peuvent, ceux qui ne veulent pas faire cet effort eux même devront en payer le prix. On ne leur enlève aucune liberté au final, car ils ont toujours moyens de le faire eux même s'ils veulent.

J'aimerai que ça marche autrement, mais dans les faits non, si tu donnes tout gratuitement, pourquoi les personnes te rémunéreraient? Pour tes beaux yeux? J'aimerai, mais non, d'expérience ça ne marche pas. On va juste t'en demander encore plus. Exemple : il n'y a pas 10min on m'a demandé par tel du support gratuit sur un gros compte qui utilise Shinken car j'ai eu le malheur d'en faire dans le passé espérant que ça aiderait le projet. Bah là non, ça n'a en rien aidé le projet (même pas une référence :( ), donc là non, fini. RedHat a montré la voie, il suffit de suivre leur exemple désormais :D

Salut,

Je dois bien avouer être dans la même situation, et sur le même "marché" de la supervision en plus :D

Avec le temps que je dis que monter la communauté puis en vivre n'était pas une solution très viable, car ça signifie faciliter l'accès à l'outil, or c'est encore ça le plus monétisable (cf RedHat justement). Vu que ta structure est petite, tu auras des soucis à t'aligner sur des prestations face aux SSII qui vont envoyer des stagiaires sous payés, il ne faut pas se leurrer.

Monter une grosse communauté signifie aider lors de la résolution des problèmes (support gratuit donc), implémenter de nouvelles fonctionnalités sur la demande d'un utilisateur car elles te plait vraiment et que ça va améliorer l'outil, et donc agrandir la communauté.

Or là il y a un soucis, car tu auras une grosse communauté, de gros utilisateurs (et bravo pour les références, j'attends encore des références pour 3 banques, 2 ministères et 1 constructeur allemand d'automobile "officielle" pour Shinken….) mais toujours aucun business model.

Là je vais être un peu sec, et cois mois ça me fait aussi mal qu'à toi d'en arriver là : fais ton deuil de monter une grosse communauté, penses d'abord à remplir ton assiette et payer ton loyer. Laisses les sources disponibles, mais place les VM sous licences genre gratuit pour pré-production sur 3mois, mais payant (et cher) sur de la production. Laisses de disponible facilement tout ce qui touche aux environnements libres, mais fait payer cher tout ce qui touche au propriétaire (genre le déploiement de sondes exchange ou weblogic).

Au final ceux qui font du libre, et uniquement du libre ne seront pas, ou peu, impactés car ils auront les sources, et s'ils prennent du temps (libre => "tu as du temps ou de l'argent?") ils pourront faire ce qu'ils souhaitent. Les autres se fichent bien du libre, ils veulent quelque chose qui marche et c'est tout. Et bien parfait, ils peuvent l'avoir et ce rapidement (genre une VM appliance toute prête), mais faut passer par la case achat.

Tu ne peux pas être totalement ouvert, déjà industrialisé (étonnant pour un outil facilitant l'industrialisation justement non? ;) ), réactif et vivre de ton outil. Tu vas te faire bouffer tout cru. C'est quelque choses que peuvent se permettre les grosses fondations qui sont financées de manières indirectes par ce que produit l'outil (genre HP vend des serveurs, et donc doit faire en sorte que Linux marche bien dessus).

RedHat fait très bien cela. Or tu n'as pas de support ou même accès aux rpm sans avoir déliés ta bourse. Tu peux partir sur CentOS, mais RedHat s'en fiche, car quand tu veux du support "imputable" (en cas de soucis majeur faut pouvoir rejeter la faute sur quelqu'un d'autre dans les grosses sociétés…) tu prends du RH, pas de la CentOS. Ceux qui partent sur CentOS n'auraient de toute manière jamais payés RedHat, donc RedHat n'a rien perdu, même "potentiellement".

Bref, pars à la campagne un jour ou deux, fais le point. Mais je te conseille de ne laisser que les sources de disponible, et que les versions faciles d'installations ne sont disponibles pour de la prod que si tu puisses en vivre. Vires donc tes VM toutes prêtes, elles te font du mal. Tu pourras vivre de ton travail direct : coder! et non pas tenter de vivre d'un moyen indirect genre de la prestation d'installation où tu seras en concurrence quasi déloyale avec des SSII qui vendent n'importe quoi et n'hésitent pas à mentir à leur client!

Bon courage, je comprends parfaitement ce que tu ressens, et que ça te déchire d'en arriver là. Mais mieux vaut qu'une partie du projet soit libre et qu'il continue à vivre, plutôt que tu te crames littéralement et qu'au final ils disparaisse totalement. Penses à comment le business model que tu montes va aider le projet, mais ne t'attends pas à ce que le projet te fournisse naturellement un business model. Est-ce dommage? Oui, car avec des moyens comme le revenu universel, on n'aurait pas besoin d'en arriver là. Mais ça n'est pas en place, et c'est pas demain que ça arrivera, donc on rentre les mouchoirs dans la poche, et on rentre dans le jeu en acceptant les règles à défaut de pouvoir les changer. Tu peux tenter le crownfounding, mais vu le marché, je n'y compterais pas trop (encore moins sur les dons, ça n'a jamais fonctionné pour du dev, et ça ne fonctionnera jamais).

Tu parles de Merethis à un moment (éditeur de Centreon et divers modules sous licences autour de Centreon). Sache qu'ils ont raison. S'ils n'étaient pas passés par ça, il n'y aurait plus de Centreon actuellement vu qu'ils étaient en concurrence sur de la prestation sur leur outil face à de grosses SSII qui faisaient du dumping sur les prix pour juste entrer sur les comptes et vendre ensuite d'autres outils à plus fortes rémunérations.

Bonne chance en tout cas, car c'est une décision très dure à prendre et à assumer. Mais poses-toi la question : combien sont ceux qui vont te crier dessus et qui vivent réellement de leur code (tu es un codeur, pas un formateur ou intégrateur) sur ce marché là en montant leur société? Les râleurs râleront, mais sincèrement, peu importe ce que tu fais, ils râleront quand même, ne les écoute pas et avance.

En effet, un module de Shinken permet de transformer des data lues des nodes collectd en data pour des services Shinken. ensuite ils seront soit transférés aux backend de perfdata (genre PNP ou Graphite), mais certaines données peuvent également être "analysées" afin de vérifier si elles sont bonnes ou pas.

Shinken ne garde pas lui même l'historique et ça ne fait que transiter par lui, donc point de RRDCache dans l'histoire (mais PNP le gère lui par contre à la sortie).

Pour les graphiques, les deux poids lourds restent PNP et Graphite. Je préfère ce dernier car il est possible de le mettre en architecture hautement disponible, même si le rendu des graphiques est très… moche faut le dire :)

En fait elle est juste cachée, il est très simple de la réactiver, mais vu qu'on a pas eu de temps pour l'avancer, et qu'on a eu pas mal de posts sur le forums sur "pourquoi ça bug là?" avec très très peu d'aide ensuite, j'ai préféré la cacher afin que seuls des personnes motivées et qui comprennent ce que beta signifie y auront accès :)

En fait c'est déjà possible de le détourner pour ça. Ce qu'il va manquer c'est justement les enchainements entre des actions. Shinken le fait, mais quand ça va "mal", un $U le fait au contraire quand ça va bien. Sinon conceptuellement ça reste lancer des scripts sur certaines périodes de temps bien précises, et les enchainer suivant les résultats :)

Concernant les outils liés, ce sont surtout tout ce qui est lié aux logs (logstash & co) et des outils de visualisations de graphes (genere PNP4Nagios ou Graphite).

Pour la partie la plus difficile, c'était clairement le calcul correct des périodes de temps, avec des cas un peu tordu genre "le prochain avant dernier mardi de novembre sachant qu'on est en décembre et qu'on a exclu les jours pairs du mois". Faire un algo efficace et complet pour résoudre ça m'a demandé 1 mois complet à l'époque. Certaines autres fonctionnalités n'étaient pas triviales non plus, mais rien d'un tel ordre de complexité :)

Mais de rien :D