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).
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 :
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).
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.
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é.
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.
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.
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.
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.
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..
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.
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.
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
On crée un outil qui répond à nos besoins mais sans trop de spécificités pour attirer des utilisateurs;
On ouvre le code pour mutualiser le dev, mais on garde la main sur la roadmap;
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.
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.
ils ont le mérite de publier des projets libres, est ce qu’on peut dire ça d’autres? Je ne suis pas salarié ou avocat de Google mais je pense qu’il faut avoir le bon angle de critique : anti-trust, souveraineté numérique, …etc. Les attaquer sur le plan du libre c’est à mon sens débile.
?