Open source et logiciel libre

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):

  1. 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.

  2. 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.

  3. 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.)

5 J'aime

Je suis à 100% d’accord.

Moi et à mon boulot on est très open-source : on n’utilise quasiment que ça.
Mais les projets que l’on développe ne le sont pas (nous développons un framework PHP et un CMS qu’on laisse propriétaire).

Depuis longtemps on aimerait les passer en open-source mais on ne l’a toujours pas fait pour les raison que tu annonces : pas le temps d’animer une communauté, …

Cela nous fait perdre parfois des prospects qui préférerait une solution open-source mais ça reste assez rare : souvent on arrive à les convaincre en leur expliquant tous les “à côté” que l’on propose : accompagnement, assistance, maintenance, suivi, évolutions sur-mesure, hébergement, backup, …

Mais un jour, j’espère qu’on arrivera à passer ça en open-source.
C’est toujours intéressant d’avoir des critiques et des propositions de l’extérieur.
C’est une bonne façon de s’améliorer.

3 J'aime

C’est une fausse excuse : au mieux faite par ignorance, au pire par malhonnêteté.

Libérer son code ne demande rien de plus qu’un fichier LICENSE et une ligne dans ton README. Rien de plus. Tout mon code sous GitLab est publié ainsi.

Ce qui prends du temps, c’est de récupérer les contributions tierces et permettre à d’autre d’améliorer ton code. Et ça oui, c’est du boulot, parce que la fourche (fork) de Damocles est au dessus de ta tête.

Donc quand dans ta boite on te fais la réponse ci dessus, personnellement je la traduirais par un truc du genre:

On ne libère pas notre code par ce que l’on a aucune certitude que l’on va pouvoir en tirer un profit.

Des CMS & Framework PHP y’en a des pleines cagettes. Avant d’avoir suffisamment de contributeurs tiers pour que ça soit un problème de plus à gérer, à mon avis vous aurez eu le temps de voir venir, par ce que sans coup de pub il faudrait qu’il se démarque techniquement des autres pour attirer des contributeurs (et c’est tout à fait possible).

3 J'aime

Je reprend ici une citation de @thierry.f.78 pour éviter de polluer le thread original

Je ne m’étale pas sur le mélange code libre & code open-source : ce n’est pas pareil. Un logiciel peut très bien être privateur (fermé) avec du code open-source. C’est le modèle de Google depuis longtemps et Microsoft s’y met activement depuis l’arrivée de Satya Nadella.

Les 4 libertés nécessaires à un logiciel libre d’après la FSF sont les suivantes :

  • la liberté d’exécuter le programme, pour tous les usages ;
  • la liberté d’étudier le fonctionnement du programme et de l’adapter à ses besoins ;
  • la liberté de redistribuer des copies du programme (ce qui implique la possibilité aussi bien de donner que de vendre des copies) ;
  • la liberté d’améliorer le programme et de distribuer ces améliorations au public, pour en faire profiter toute la communauté.

Bref, si tu soumet un patch à un mainteneur, il reste libre de l’intégrer (ou pas) à son code. Ça ne remet pas en cause le caractère libre du code : mais charge à toi de maintenir ton fork (en respectant les termes de la licence initiale). Mais si ton fork n’a pas la même capacité de contribution, ton projet risque de ne pas être maintenable longtemps.

La magie du libre est là, tu souhaites faire différemment : vas-y !
Pas mal de projets raconteront ça mieux que moi, les 1er exemples qui me viennent en tête sont :

  • Owncloud/Nextcloud;
  • Openoffice/Libreoffice;
  • ou en plus symbiotique Debian/Ubuntu.
3 J'aime

J’aimerais bien que tu développes cette affirmation car ces propos prêtent à confusion.

Tes propos ne sont pas tout à fait vrais. Si on prend le cas d’Elasticsearch qui est en modèle open-core, certains plugins sont fermés, notamment celui qui concerne l’authentification et les permissions. Etant donné la modularité du logiciel, tu peux sans souci publier ton propre plugin en open source pour remplacer une fonctionnalité issues des extensions privées, d’ailleurs il y en a pour le support de l’authentification et des permissions par exemple.

C’est une approche que je trouve plus sympa que celle de Gitlab qui adopte aussi l’approche open-core en proposant une version CE et une version EE ayant des fonctionnalités inédites, comme Gitlab ne gère pas de système d’extensions, il n’est malheureusement pas possible de contribuer facilement.

Sinon tu as oublié de mentionner un modèle économique, celui du SaaS (que Gitlab pratique aussi).

1 J'aime

Pour Google je pense que c’est clair. Tous leurs services ne sont pas publiés, mais le nombre de projets ouverts qu’ils ont maintenu et/ou maintiennent est probablement sans égal.

Côté Microsoft :

  • Steve Ballmer, le précédent CEO, était ouvertement hostile au logiciel libre. Sa comparaison de Linux avec le communisme était un témoin spéctaculaire de sa politique (et celle de Bill Gates).
  • Satya Nadella, l’actuel CEO, à déclaré à sa nomination «Microsoft loves Linux»… la transition est notable. C’est un ancien de Sun Microsystem, entreprise emblématique du libre et de l’open-source avant ses difficultés ayant entraîné le rachat par Oracle (mais ce n’est probablement pas la plus évidente des explications). J’imagine que ses précédentes fonctions dans la division cloud pourraient aussi expliquer sa politique ouverte : cette division à du se développer sans la rente de monopole offerte par les licences Office & Windows.

Côté produit c’est assez évident la liste des codes source publiés est ici et certains projet emblématiques sont publié ou bénéficie de large contributions de Microsoft : dotNet core, VScode, PowerShell, TypeScript, chromium, Linux, electron, etc.

Le SaaS ne peut pas être compatible avec du logiciel libre. À moins de donner un accès serveurs permettant de s’assurer que le code en production correspond bien au code publié.

1 J'aime

Je parle ici de modèle économique. Et dans ce cas de figure rien ne t’empêche de publier ton logiciel sous une licence libre pour ceux qui veulent prendre la peine de le déployer on-premise et proposer une version SaaS afin d’avoir une source de revenue.

2 J'aime

En fait j’avais raté ma selection pour la citation, ce qui me dérangeait c’était ta phrase :

Dans le cas de Google et de Microsoft, ils publient aussi des outils open source indépendants de leur logiciels privateurs.

Oui techniquement libérer son code c’est simple, je suis d’accord.

Oui c’est aussi à ça que je pensais lorsque je parlais d’animer la communauté.
Si on ne prend pas le temps d’étudier les contributions ou d’aider les autres à utiliser notre produit, ils passeront à un autre.

Autant ne pas libérer son code si ce n’est pas pour s’occuper de sa communauté.
Sinon, elle mourra d’elle-même.

Il suffit d’un seul contributeur pour provoquer des problèmes.
Il suffit qu’il mette le doigt sur une faille de sécurité en auditant le code pour qu’on doive patcher en urgence une 60aine de projets client, tous utilisant des révisions différentes du Framework/CMS.
On n’est pas prêt à ça.

Surtout qu’on n’a pas (encore) automatiser nos déploiements, ni pleins d’autres bonnes pratiques que l’on peut trouver dans ce forum et la culture DevOps.
C’est d’ailleurs en partie pour cela que je traîne ici.
Je pense qu’on a intérêt à développer cela en priorité plutôt que de rendre notre code open-source.

Et je suis d’accord qu’il existe déjà pléthore de CMS et Framework PHP.
La plupart sont certainement meilleurs que le notre.
Mais le nôtre, existait bien avant la plupart des frameworks existant actuellement.
Et il n’est pas simple de migrer un projet d’un framework à un autre; déjà entre 2 versions d’un même framework, c’est pas simple non plus parfois !
Et beaucoup de nos clients refusent de faire des mises à jour “car ça marche bien comme ça”.
Et on le maîtrise à 100%, ce qui nous permet d’être rapide au niveau du dév.

2 J'aime

Le modèle de GitLab est en effet open-core.

Par contre il faut bien avoir à l’esprit deux chose :

  • GitLab-CE est un Logiciel Libre

  • GitLab-EE est un logiciel open-source dont l’utilisation est soumise à une licence payante

C’est le même dépôt GitLab qui hégerge les deux versions. GitLab partage d’ailleur pourquoi ils ont fait ce chois.

En fait GitLab est l’exemple même, pour moi, de ce qu’il faut faire quand on fait de l’open-core. Car l’intégralité de son code est auditable. Ils acceptent les contributions, y compris sur la version EE. Et d’ailleurs régulièrement ils basculent des fonctionnalités de la version EE à la version CE, suite aux suggestions de leurs utilisateurs sous licence. En même temps en sortant une version tous les mois il ne risque pas grand-chose, car ils ajoutent des tonnes de fonctionnalités que ce soit dans la version CE ou dans la version EE.

Je ne vais pas vous cachez que j’aime beaucoup cette philosophie.

3 J'aime

Peut-être que cette excuse à une autre raison que l’ignorance ou la malhonnêteté ? Techniquement, c’est vrai : pour publier du code en open source, il suffit de donner une licence et de publier. La question c’est « pourquoi publier du code en open source ? » A mon avis c’est à travers cette question que tu comprends la raison.

Déjà, c’est quoi de l’animation ? Pour moi, c’est tout le travail d’interaction avec des contributeurs que tu dois faire en réactif ou en proactif. Cela va comprendre la lecture de pull-request, la réponse à des pull-requests, la publication d’un coding style, la publication d’une charte de contribution, le choix d’une licence, le travail de release de ton soft car lorsque le projet a pour vocation à être utilisé, tu ne publies pas de la même manière que quand tu es le seul user, un site de présentation du projet, et même choisir un nom au projet, …

Sans cette animation, un code publié en open source tombe dans l’oubli. En 2020, GitHub propose ~100M de repositories. Combien d’entre eux sont des projets actifs et utilisés ? Un projet qui n’est pas animé est un projet qui tombe dans l’oubli, ou comme tu le souligne qui se fait forker par quelqu’un qui a le temps de l’animer.

Je ne peux pas m’exprimer pour @BugsByte, mais pour ma part, si je publie du code en open source c’est pour que la communauté propose des nouvelles idées, des améliorations et contribue au code. Tu imagines bien que je ne vais pas libérer plusieurs mois de travail pour les jeter directement dans le néant d’Internet. Donc, au vu de mon objectif, il n’est pas judicieux de libérer du code sans avoir le temps de gérer l’animation qui va autour.

Pour ma part c’est donc un calcul économique : est-ce que le temps que je vais consacrer à l’animation sera rentabilisé par la consolidation du soft via ses utilisateur et contributeurs ? Ou la question peut être posée différemment : Dans l’intérêt de ma société, mon temps étant limité, ou est-il investi le mieux ?

Je dirais donc que le temps nécessairement consacré à l’animation du projet est une excellente excuse pour ne pas publier du code en open source.

Avec un soft open source « classique », lorsque tu soumets un patch, le mainteneur reste libre de l’intégrer ou non. Généralement, si ton patch est très lié à ton business, il sera rejeté car il n’apporte rien au projet. Si ton patch apporte une fonctionnalité utile, tu peux le défendre et il aura de bonnes chances d’être adopté. Si tu soumet un patch a un projet open core, tu as un autre élément qui fixe le choix : est-ce que cette fonctionnalité n’est pas prévue dans la roadmap EE ?

Il est juste de faire remarquer que tu peux forker un projet open core (enfin, il faut tout de même valider cela en lisant la licence), et qu’il prendra si tu apportes plus de valeur que l’original. Je considère que c’est pour cela qu’il faut être vigilant. Tu prends un soft open core, tes équipes montent en compétences. Il est déployé partout, les fonctionnalités core te suffisent et tu as calculé ton coût de fonctionnement en te basant sur cet état de fait.

Un jour tu as besoin d’une fonctionnalité. Tu fais ta contribution qui est rejetée car cela fait partie de la version EE. Alors :

  • soit tu payes et ça plombe ton coût de fonctionnement,
  • soit tu maintiens ton patch, et ça plombe ton coût de fonctionnement,
  • soit tu fork en espérant un jour avoir des contributeurs qui maintiennent le projet à ta place et ça ne prend pas pour les raisons que tu évoques.

Ce que je veux montrer par-là, c’est que le choix open core peut avoir des coûts inattendus. Perso, lors d’un choix de soft open core, je pars du principe que si l’on n’a pas les moyens de prendre une licence, on n’utilise pas du tout le soft.

C’est juste. C’est amusant car ce modèle peut coller aux deux premiers modèles que j’évoque en fonction de l’ordre des choses. Dans le cas d’Elasticsearch, c’est le second : Le logiciel est d’abord publié en open source, puis suite à sa forte adoption, un business SaaS est créé autour du soft. Cela peut aussi correspondre au premier modèle : tu te donnes une mission pour laquelle tu fabrique un logiciel que tu publies par la suite en open source.

3 J'aime

Le cas de Microsoft est un peu problématique. Si je prend l’exempble de VScode sont code source est publié sous licence MIT, donc Libre. Par contre il n’y a pas de release sur le projet GitHub, l’aviez-vous remarqué ? Pour obtenir le binaire de VSCode il faut le télécharger sur le site..

Le site dit explicitement :

By using VS Code, you agree to its license and privacy statement.

Microsoft nous fait un tour de passe en privatisant son binaire.

C’est pour cela que Chez Lydra on utilise VSCodium qui lui est un binaire Libre construit à partir des sources Libre.

3 J'aime

C’est l’exemple le plus emblématique chez Microsoft en effet @cchaudier

Pour Google il y a Android : ASOP est open-source, mais pas la version dans ton smartphone qui embarque des surcouche fermées.

Le prochain projet toxique à mon sens est au niveau des navigateur : Chromium est open-source dans lequel Google et Microsoft sont associé afin de proposer leurs ajouts fermés qui donnent naissance à Chrome & Edge.

1 J'aime

Je suis à 100% d’accord avec tes propos.
C’est ce que j’ai voulu expliquer mais tu l’as fait bien mieux que moi, merci.

On est d’accord mais ils sont aussi à l’origine de projet tel que Kubernetes, donc ce n’est pas leur unique approche.

Pour Microsoft, on est d’accord c’est plus flagrant.

Et ne pas oublier le plus sournois de tous : Amazon via AWS :slight_smile:

2 J'aime

Merci à tous pour vos interventions, c’est vraiment un sujet passionnant.

Toutes vos interventions sont pertinentes et présente chacune des points de vue très intéressants.

C’est grâce à ce genre de sujet que je suis content d’avoir créé cette communauté et d’avoir mis en place un forum et non un chat qui n’aurai pas donné des discussions aussi organisées et pointus.

2 J'aime

Je ne connais pas assez Kubernetes, mais en effet, du côté outillage, Google a très vite compris que l’open-source leur permettrait de mutualiser du dev et créer des standards. En faire un business n’est pas dans le plan de départ. Ça me semble plutôt vertueux comme pratique, mais je reste méfiant do’nt be evil :smiling_imp:

  1. On crée un outil qui répond à nos besoins mais sans trop de spécificités pour attirer des utilisateurs;
  2. On ouvre le code pour mutualiser le dev, mais on garde la main sur la roadmap;
  3. On a assez d’utilisateurs/contributeurs tiers pour arrêter de supporter pleinement le projet, l’historique nous garanti une roadmap sans avoir besoin de garder les commandes : le standard est effectif, changer radicalement la direction d’un train est improbable.

Pour Android, c’est autre chose. C’est un business à la base : Déployer massivement un collecteur de données et/ou du travail distribué. Pour ça il faut proposer un service suffisament intéressant à l’utilisateur sans contre partie financière et on se paye ensuite.
C’est le plan initial des produits publiques : le moteur de recherche, Gmail , (re-)Captcha, etc.

1 J'aime

Et dans ce business model ouvrir ses sources n’est pas du tout une bonne idée :smiling_imp:

Avec Google on à donc à faire à une entreprise très agile et sachant utiliser des moyens et méthodes très variées.

1 J'aime

Je suis d’accord avec toi sur les possibles dérives liés à l’ouverture de projets. Néanmoins, c’est très peu probable pour ne pas dire impossible dans le cas cité de Kubernetes, celui-ci a été offert il y a déjà plus de 5 ans à la Linux Foundation.

Après on peut émettre des spéculations autour de cette fondation qui est composée d’acteurs économiques majeurs. Néanmoins, il faut admettre que ces entreprises sont indispensables à la pérennité de beaucoup de projets libres.

Personnellement je trouve dommage que le monde du libre devienne un monde bipolaire partagé entre pragmatiques et extrémistes.