Salut,
J’étais en train de répondre au message Job scheduler / ordonnanceur en mode cluster, mais je me rend compte que ma réponse est complètement hors-sujet. Comme je n’aime pas rédiger pour rien, voilà dans un nouveau thread ce que je voulais répondre :
Pour moi, il y a 3 voies pour publier du libre (il y en a peut-être plus, mais je ne les pas en tête, ou je ne les connais pas):
-
Peu importe ton business model, pour assurer la mission que tu te donnes, tu as besoin de développer un soft. Le soft développé n’est pas le cœur de ton activité. Par exemple, si tu fais de la sécu, le moteur de sécu n’est pas le cœur de l’activité, le cœur sera les règles que tu vas entrer dans le moteur. Du coup, tu publies ton logiciel avec une licence Open-Source. Cela peut apporter de la robustesse et de la richesse via les contributions, et si le soft n’est pas adopté, ça ne change rien à ton business. C’est le cas de pas mal de grosse boutique comme Twitter ou Facebook. Le code est Open-Source, et l’avis de la communauté des utilisateurs compte énormément. Les contributions externes sont acceptées (sous réserve de qualité). Même si l’éditeur aura le dernier mot, l’évolution du soft est décidée par la communauté. Pour moi, c’est le meilleur modèle, car la motivation à utiliser, maintenir et faire évoluer le soft est partagé par tous les acteurs.
-
Deuxième modèle, tu crées un soft sous licence Open-Source complet, et tu montes ton business autour de la maintenance, du support, et du packaging. Par exemple, tu crées une base de données complète et totalement fonctionnelle. Tu acceptes l’avis de la communauté et ses choix, et accepte les contributions (toujours sous réserve de qualité). Tu aura pour client des sociétés dont le support est un enjeu pour le décideur. Tu peux ajouter au packaging « pro » du logiciel Open-Source des outils externes qui facilitent l’intégration, par exemple un connecteur JDBC, ou un agent de supervision pour un soft proprio utilisé uniquement par dans grosses boites. Tu peux fournir tes propres packages avec des « features » de la version N backporté dans la N-1 “stable”, … Attention, avec ce modèle n’importe qui peut packager ton soft Open-Source et te concurrencer. On trouve par exemple : nginx ou varnish.
-
Dernier modèle, c’est le Open-Core qui consiste donc à créer un soft Open-Source qui se limite à la partie « core » du software, et le fournir complet en version pro. Ce modèle ne peut pas être piloté par la communauté des utilisateurs, car si un contributeur fourni un patch qui ajoute une fonctionnalité de la version « pro », tu ne l’accepteras pas. La définition de la partie « core » est très discutable entre le point de vue du l’utilisateur et celui du développeur. Par exemple, Neo4j ne permet pas de montée en perf sur la version CE (exemple peut-être périmé). Elastic-Search ne fournis pas de sécurité sur la version CE (exemple peut-être périmé). Selon moi, la montée en perf et la sécurité sont des options « core », selon les éditeurs non. Comme c’est l’utilisateur qui fait le choix de l’usage d’un soft et non l’éditeur, l’utilisateur va ajouter une dimension « coût de la licence » à son comparatif, et la solution ne sera peut-être plus retenue. J’ai aussi entendu cette remarque « Je ne vois pas pourquoi je contribuerai à un soft payant, je travaille gratuitement et une société revend mon boulot. J’y gagne quoi ? ». Je ne suis pas d’accord avec ces propos car le gain est d’avoir la feature que l’on souhaite maintenu par quelqu’un d’autre. Cela dit, j’ai déjà entendu ces propos, et d’un certain point de vue, je peux les comprendre.
Perso, je doute que monter une boutique dont la raison d’être est de contribuer à l’Open-Source soit viable.
-
Le cas du point 1 me semble le plus sain, mais le leitmotiv « Open-Source » devient secondaire. T’a un business model qui parait viable et pour atteindre ton but, tu publies une partie de tes logiciels en Open-Source. Ce n’est pas la partie Open-Source qui est le centre du business et tu atteins le but secondaire qui est de participer à l’Open-Source.
-
Le cas du point 2 est de plus en plus rare. On a affaire à un projet Open-Source qui a été largement répandu et utilisé. Le concepteur peut en faire un business. Le prérequis c’est de monter un projet qui sera répandu. Donc pour que ce modèle fonctionne, le projet Open-Source doit être massivement utilisé. Pour moi ce prérequis n’est pas un bon moteur à la conception d’un projet. Je pense qu’un projet sain doit avant tout avoir pour ambition de répondre à un besoin, et pas être une machine marketing. Ça me parait donc difficile de baser un business sur ce concept. L’alternative pourrait être de surfer sur la vague d’un autre projet source déjà massivement adopté, comme Perconna avec MySQL.
-
Le cas du point 3 est un business model ou tu te lance dans la vente de software. Le fait de publier le « core » en Open-Source permet d’avoir un pied dans des sociétés qui vont grossir dans leur besoin. Le soft doit donc apporter quelque chose de génial et d’inégalé, sinon au moment de « scaler » une société ajout la dimension coût de la licence a son comparatif et peut prendre un autre produit. La publication Open-Core permet aussi à ton marketing de communiquer sur le canal de communication « communauté Open-Source ». L’effort marketing est aussi couteux qu’indispensable, car le cas où tu crées et publie un projet Open-Source et qui devient massivement adopté est un peu légendaire (bien que possible). Quoi qu’il en soit, c’est très long. Les gros projet Open-Source/Open-Core de cette décennie ont été poussés par du marketing. Par exemple Docker ou Kubernetes.
Pour moi, c’est le premier choix qui est le plus pragmatique. Tu choisi de remplir une mission, et tu vends ton service. Si tu as besoin d’un soft pour remplir ta mission, tu peux le mettre en Open-Source. Après si ton soft contient l’ « intelligence » de ton service, tu t’expose à des conséquences.
De mon côté, la mission de ma boutique c’est d’apporter de la cyber-sécurité aux sociétés qui n’ont pas les moyens d’y accéder. Pour accomplir cette mission, on a (entre-autres) développé un WAF qui répond à certains besoins que je ne trouve pas dans les WAF Open-Source. L’intelligence de mon service c’est les règles que je mets dans ce WAF et pas la technologie développée. Donc un jour ce WAF sera proposé en Open-Source. De la même manière, on a conçu une base de données avec des propriétés particulières que je n’ai pas trouvées sur le marché. Ce qui compte c’est la manière d’utiliser la base et de collecter les info, pas la techno en elle-même. Elle aussi sera mise un jour en Open-Source. En revanche, nos sites web métier / batch de traitement / collecteur de data / … contiennent le cœur du métier, ils resteront fermés.
Attention à un autre point : Fournir un projet open source c’est vachement plus couteux en temps que ce qu’il n’y parait. Il faut animer la communauté, répondre à des questions support, faire des release et donc avoir un politique de release. Ces derniers temps je vois beaucoup de soft ou on prend toujours le dernier commit branche master. Cette manière de publier permet difficilement d’assurer un support car la version déployée devient éphémère. Il faut également tester le fonctionnement sur plusieurs distribs/archi. Rester en contact avec les packagers des différentes distribs. Étudier les évolutions des différentes dépendances qui peuvent casser l’API (par exemple faires les modifications pour passer de OpenSSL 0.x à OpenSSL 1.1.x). Rédiger un coding-style, et un guide pour les contributeurs. Préciser une manière de faire du « bug report ». Mettre en place une chaine de CI. Si ce boulot est négligé le succès du soft arrive plus difficilement. Et bien sûr, Tout ce temps/boulot il faut le financer. (C’est d’ailleurs pour ces raisons que je n’ai pas encore publié mes soft en Open-Source.)
