Pour le point qui me dérange ici, c'est que toute la valeur de votre solution, à savoir
les services hébergés, sont annoncés comme n'étant pas Open. Partant de là, il ne me sera
pas possible d'intégrer votre solution dans son ensemble en autonomie, encore moins de
la forker.
Les moteurs de réputation et de comportement sont très utiles je pense et la valeur est principalement là. Les services hébergés ne sont que la valeur permettant de faire vivre la société, pas des entraves au logiciel. Notre comptabilité, notre plan marketing et tout un tas d'autres aspects ne sont pas open source, je le concède. Cela discrédite t'il l'utilité du code fait par l'équipe et distribué en MIT ? J'en doute, mais là encore, ce sont des points de vue.
Je suis preneur de vos retours cependant. Comment avez vous procédé pour vos propres productions open source ? Quelle license avez vous choisit ? Avez vous pu les maintenir dans le temps sans aucun modèle de monétisation ? Nous n'avons pu le faire que pour 3 logiciels de notre coté, qui se retrouve maintenant sans support pour deux d'entres eux, bien qu'encore très utilisés.
Dans mon expérience d'utilisateur et de contributeur opensource, les projets non financés sont souvent moins solides et durables car leurs teams ont besoin de se nourir et doivent faire des arbitrages entre travail et temps personnel. Le fait d'avoir un modele économique est donc, en général, un meilleur gage de durabilité. Ici, il me semble honnête puisque la communauté bénéficie d'un logiciel utile, performant et gratuit, à vie.
Elle bénéficie aussi de toute la curation des signaux effectuée en central, ce qui n'est pas sans cout non plus. Elle peut également s'en passer si elle le souhaite et avoir "juste" un fail2ban moderne et plus efficace. Si elle voit des entraves ou un déclin dans le soft, cette communauté pourra même le forker. Alors oui, pas notre backoffice API, ni notre site web, mais cela me semble assez loin de l'Open Source Washing.
Désolé que vous ne puissiez utiliser notre solution dans votre banque pour ces raisons.
[^] # Re: Business model ?
Posté par Philippe_CrowdSec . En réponse à la dépêche CrowdSec : la cybersécurité collaborative, open source et gratuite pour Linux. Évalué à 1.
Les moteurs de réputation et de comportement sont très utiles je pense et la valeur est principalement là. Les services hébergés ne sont que la valeur permettant de faire vivre la société, pas des entraves au logiciel. Notre comptabilité, notre plan marketing et tout un tas d'autres aspects ne sont pas open source, je le concède. Cela discrédite t'il l'utilité du code fait par l'équipe et distribué en MIT ? J'en doute, mais là encore, ce sont des points de vue.
Je suis preneur de vos retours cependant. Comment avez vous procédé pour vos propres productions open source ? Quelle license avez vous choisit ? Avez vous pu les maintenir dans le temps sans aucun modèle de monétisation ? Nous n'avons pu le faire que pour 3 logiciels de notre coté, qui se retrouve maintenant sans support pour deux d'entres eux, bien qu'encore très utilisés.
Dans mon expérience d'utilisateur et de contributeur opensource, les projets non financés sont souvent moins solides et durables car leurs teams ont besoin de se nourir et doivent faire des arbitrages entre travail et temps personnel. Le fait d'avoir un modele économique est donc, en général, un meilleur gage de durabilité. Ici, il me semble honnête puisque la communauté bénéficie d'un logiciel utile, performant et gratuit, à vie.
Elle bénéficie aussi de toute la curation des signaux effectuée en central, ce qui n'est pas sans cout non plus. Elle peut également s'en passer si elle le souhaite et avoir "juste" un fail2ban moderne et plus efficace. Si elle voit des entraves ou un déclin dans le soft, cette communauté pourra même le forker. Alors oui, pas notre backoffice API, ni notre site web, mais cela me semble assez loin de l'Open Source Washing.
Désolé que vous ne puissiez utiliser notre solution dans votre banque pour ces raisons.