Je donne un tutoriel à un workshop, sur l’utilisation d’un logiciel que j’ai conçu. Nombre d’utilsateurs viennent au workshop (une semaine !) pour apprendre à l’utiliser.

Mais très peu sont en fait en train d’écouter, de faire les exercices ou même de demander de l’aide. Ils demandent à leur IA de le faire. Elle chIAsse du code faux et ils ne comprennent pas pourquoi. « Tant pis, ça a l’air de tourner. »

Mention spéciale à ce type, qui me demande de l’aide et que je vois être littéralement obligé de se battre (je n’exagère pas) contre son IA pour écrire ce qu’il veut dans son éditeur.

On vit vraiment dans une saucisse.

#ia #llm #code

Y uno puede creerse la narrativa estadounidense de la seguridad nacional, que es un agente tan peligroso que restringe su acceso y uso por temas de seguridad para evitar un armagedón digital; en ese caso, simplemente Europa está en desventaja, con sus sistemas menos protegidos que los estadounidenses. Pero no creo que ese sea el caso, porque no creo que el Pentágono se reprima en usar este arma.

Lo que va a ocurrir es que el Gobierno estadounidense usará Mythos en secreto y se guardará un arsenal de vulnerabilidades críticas desconocidas de todo tipo de navegadores, programas y sistemas a buen recaudo, para usarlo cuando le convenga, como ya hizo en su día con el exploit Eternal Blue que estuvo usando secretamente durante años hasta que se filtró y provocó el desastre planetario del wannacry. Y lo que veremos, me temo, es una superarma de ciberseguridad guardada con candado y restringida a un selecto club, el que el Gobierno de EE.UU. tenga el control y decida quién la usa y quién no (un poco como la tecnología del arma nuclear), y que el propio Gobierno de EE.UU. usará a su antojo contra quien considere y cuando quiera, sin que nosotros podamos hacer nada.

#ciberseguridad #geopolítica #geopolitics #IA #mythos

Lo que a mí me preocupa de Claude #Mythos no es todo lo que puede hacer, el arma ofensiva que supone, sino quién lo puede hacer. El tema no es que sea capaz de descubrir multitud de vulnerabilidades críticas desconocidas y diseñar sus exploits para atacarlas, porque eso se puede hacer previamente durante el desarrollo de modo que el producto final ya esté escaneado y parcheado y sea seguro (al igual que ofensiva, es una potente arma defensiva), el tema es que el acceso a este arma (y digo bien, arma) está restringido. Solo el Gobierno de Estados Unidos y un puñado de empresas estadounidenses tienen permitido el acceso y uso de Claude Mythos.

Y esto tiene unas connotaciones geopolíticas muy fuertes. Europa está desesperada por conseguir acceso a Mythos pero lo tiene denegado, y es que, mucho hablar de soberanía tecnológica pero con esto Europa se queda muy atrás. Es un salto en la #ciberseguridad y Europa se queda fuera. Deberíamos estar muy preocupados, aunque no veo que se le dé importancia en los medios.

#IA #EEUU #geopolítica

Bueno, pues parece que es bastante probable que tengamos acceso a Mythos Claude de Anthropic, bastante guai. Guai por las propias características del agente.

No soy un integrista anti-IA aunque tampoco un entusiasta y le tengo muchos reparos. Ha estado bien que frente a quien ha venido a vendernos las virtudes de este agente entre otras cosas yo, el último mono, he podido hablar con libertad y exponerle los problemas que yo le veo a la #IA actual y a los agentes #LLM en particular, al parecer el único de entre toda la mesa de la junta directiva no invadido por el entusiasmo. Curioso también que quien venía a hablar del producto ha coincidido conmigo en gran parte, tenía una visión bastante realista sobre los agentes LLM.

Manda narices que quien te viene a hablar de las bondades de un producto sea menos acrítico que tú. No sé si esto, y el interesante debate que hemos tenido, habrá hecho pensar sobre su entusiasmo a los demás que se sentaban a la mesa.

🎉🌐 Arriba la FEDIFESTA a la UPV!

Vos convidem en dilluns 4 de maig a una vesprada de xarrades i tallers per a repensar la tecnologia que utilitzem cada dia 💻

Parlarem de software lliure, tecnocapitalisme i alternatives com el Fedivers amb @criticalswitch, posant sobre la taula com les grans plataformes digitals concentren poder i impacten en la política, la guerra i les nostres formes de relacionar-nos.
També explorarem altres maneres de connectar-nos i organitzar-nos amb més autonomia 💚

Programació:
🕔 17:00 — Introducció al Fedivers
🕕 18:00 — Implicació d’empreses tecnològiques en l’apartheid israelià
🕡 18:45 — Perspectives crítiques de la IA

🗓 Dilluns 4 de maig
⏰ 17:00 – 19:30 h
📍 Aula Pecera I – Casa de l’Alumne UPV (Camí de Vera, Edifici 4K, València)

Vine a informar-te, debatre i imaginar alternatives ✨

#fedifesta #fedivers #tecnocapitalisme #ia
------------------------------------------------------------------

🎉🌐 ¡Llega la FEDIFIESTA a la UPV!

Os invitamos el lunes 4 de mayo a una tarde de charlas y talleres para repensar la tecnología que usamos cada día 💻

Hablaremos de software libre, tecnocapitalismo y alternativas como el Fediverso con @criticalswitch , poniendo sobre la mesa cómo las grandes plataformas digitales concentran poder e influyen en la política, la guerra y nuestras formas de relacionarnos.
También exploraremos otras maneras de conectarnos y organizarnos con más autonomía 💚

Programación:
🕔 17:00 — Introducción al Fediverso
🕕 18:00 — Implicación de empresas tecnológicas en el apartheid israelí
🕡 18:45 — Perspectivas críticas de la IA

🗓 Lunes 4 de mayo
⏰ 17:00 – 19:30 h
📍 Aula Pecera I – Casa del Alumno UPV (Camino de Vera, Edificio 4K, Valencia)

Ven a informarte, debatir e imaginar alternativas ✨

#fedifiesta #fediverso #tecnocapitalismo #palestina

Fornito da @altbot, generato localmente e privatamente utilizzando Gemma4:26b

@gubi Uno screenshot di un post sulla piattaforma LinkedIn dell'utente Nicola Mattina. Il post include una foto del profilo, il pulsante "+ Connect" e il seguente testo:

"I help leaders and teams turn AI into a trustworthy co-worker b... 16h • Walter Veltroni ha intervistato Claude sul Corriere della Sera e non ci ha capito un c***o. Scudate il francesismo.

Mentre Veltroni faceva le sue domande "profonde", da qualche parte nel mondo centinaia di migliaia di altre istanze dello stesso modello (probabil (probabilmente Sonnet) stavano rispondendo ad altre persone.

Claude non è una persona: quando Veltroni ha chiuso la conversazione, il Claude che ha "intervistato" ha smesso di esistere, perché Claude non ha né né un'identità né una memoria.

Inoltre, i modelli linguistici rispecchiano il registro di chi interroga. Domande letterarie e malinconiche producono risposte letterarie e malinconiche. Quello che Veltroni legge come profondità (l'anima, la solitudine, la paura della morte) è in larga parte un mirroring stilistico. stilistico. Se le stesse domande l'avesse poste un ingegnere in tono asciutto, avrebbe avuto un altro "Claude". L'intervista è in buona parte un autoritratto.

Si dirà: tutto questo è ovvio per chi lavora con l'IA. Ma, chiaramente, non lo è per Veltroni, che fa un altro mestiere (a proposito, mestiere ha adesso?).

Però questa intervista finirà sulle scrivanie di manager e imprenditori che già si aspettano di lavorare con una tecnologia che si comporta come un consulente saggio con la bacchetta magica. E poi il "consulente" inventerà fatti, dimenticherà tutto da una sessione all'altra, restituirà banalità non dai fatti contesti.

Capire cosa è davvero un LLM (un sistema senza memoria persistente, senza identità continua, che produce token plausibili sulla base del contesto che riceve) è la precondizione per usarlo bene.

L'intervista di Veltroni è un mediocre pezzo letterario che racconta l'IA nel modo sbagliato, ossia trattandola come un essere umano.

#IA #intelligenzaartificiale"

🌱 Energia utilizzata: 0.633 Wh

Comment sont gérés et financés les logiciels libres ? Quels sont les modèles existants et leurs évolutions au fil du temps ? Ces questions sont simples et pourtant les réponses ne sont pas évidentes.

Dans cet épisode, nous en faisons une première introduction avec Raphaël Semeteys, architecte et DevRel chez Wordline et Gonéri Le Bouder, Senior Software Engineer chez Red Hat.

Épisode avec Raphaël Semeteys et Gonéri Le Bouder

Sommaire

• 1 Épisode avec Raphaël Semeteys et Gonéri Le Bouder
• 2 Présentation de Gonéri Le Bouder et Raphaël Semeteys
• 3 Présentation de la méthode QSOS
• 4 Le modèle communautaire
• 5 Les fondations
• 6 Les modèles du service et du support + SaaS
• 7 L’Open Core
• 8
• 9 Les changements de licences et projets qui se referment
• 10 Les licences éthiques
• 11 Tribunes libres
• 12 Conclusion
• 13 Sources pour aller plus loin
• 14 Licence

Walid : bienvenue pour ce nouvel épisode de Projets Libres. Aujourd’hui, on va faire un épisode que je veux faire depuis le départ, sur lequel je me suis un peu cassé la tête pendant très longtemps. J’ai demandé de l’aide à deux personnes qui connaissent très bien ce sujet avec qui j’ai travaillé, on a travaillé ensemble tous les trois il y a très longtemps (à l’époque, on était au Centre Open Source d’Atos). C’est un sujet qui est aussi très frais dans nos têtes puisque hier et avant-hier, il y avait le salon Open Source Experience à Paris et on a parlé à plein de gens de ces problématiques de modèles économiques. Cela nous a donné plein de nouvelles idées et de choses à discuter.

Ce soir, pour parler des modèles économiques du logiciel libre – on va dire une introduction, on abordera d’autres modèles dans d’autres interviews avec d’autres projets ou éditeurs – j’ai avec moi deux personnes, la première c’est Gonéri Le Bouder, avec qui je travaille et je suis en contact depuis très longtemps, qui est Senior Developer chez Red Hat. Je le laisserai se présenter après. Il connaît bien ses sujets de licence puisque quand je l’ai connu l’époque où on a commencé à travailler ensemble, il était en train de passer son process pour devenir développeur Debian. Et le sujet des licences était un gros sujet.

La deuxième personne, c’est Raphaël Semeteys, avec qui j’ai aussi travaillé chez Atos et qui avait à l’époque développé une méthode de qualification et de sélection de logiciels libres qui s’appelait QSOS : on va en parler assez rapidement. Raphaël est architecte et DevRel chez Worldline. Bonjour à tous les deux. Ça fait vraiment plaisir de vous avoir et je pense que c’est la première fois qu’on se reparle tous les trois depuis un certain nombre d’années.,

Raphaël : c’est vrai. Salut à tous.
Raphaël Semeteys (source : linkedin)
Gonéri : bonjour tout le monde.
Gonéri Le Bouder (source : ansible blog)

Présentation de Gonéri Le Bouder et Raphaël Semeteys

Walid : la première question que je vais vous demander à tous les deux, c’est de commencer par vous présenter et de m’expliquer un peu comment vous êtes tombé dans le logiciel libre et rapidement, quel est votre parcours ? Gonéri ?

Gonéri : moi, ça fait à peu près 20 ans que je fais du logiciel libre. J’ai commencé avant KDE 1. Je me souviens que j’avais une version francisée d’une Slackware avec un Kernel 2.6.36 ou un truc comme ça. C’était il y a quand même longtemps. J’étais au lycée, j’avais contacté les équipes de traduction de KDE à l’époque et c’est là où j’avais commencé à avoir des interactions avec des gens comme ça. Je n’étais pas du tout développeur, ça m’avait permis de rencontrer des gens. Puis j’avais aussi découvert le monde des LUGs, des Linux User Group qu’il y avait dans ma région, en Bretagne. Après, je n’ai pas vraiment arrêté.

Walid : et maintenant, qu’est-ce que tu fais ?

Gonéri : ça fait dix ans que je travaille chez Red Hat. J’ai au début, j’ai gravité autour d’OpenStack pendant à peu près six ans. Depuis à peu près quatre ans, je suis dans l’équipe Ansible. J’ai fait plusieurs choses dans l’équipe Ansible. Mais là, présentement, je travaille sur un truc qui s’appelle Lightspeed, qui vise à doter Ansible d’une intelligence artificielle pour aider les développeurs à produire leurs playbooks.

Walid : merci, Gonéri. Je vais pouvoir mettre le hashtag #IA sur cet épisode. Merci.

Gonéri : je suis désolé.

Walid : et toi, Raphaël ?

Raphaël : moi, je suis Raphaël, Raphaël Semeteys. Je travaille chez Worldline. Je suis architecte et DevRel depuis un an. J’ai l’habitude de faire du design de systèmes d’information et ce genre de choses-là. Avant, j’étais chez Atos. Nous avons été collègues, d’ailleurs, tous les trois, Gonéri, toi et moi, dans l’Open Source Center d’Atos, le centre de compétences open source. Pendant neuf ans, j’ai d’abord participé à créer le centre et après, je me suis occupé de pas mal des activités de veille et de conseils autour de l’adoption de l’open source, des risques qu’on encoure etc. C’est dans ce cadre que j’ai créé la méthode QSOS.

L’open source, je l’ai découvert quand je suis rentré en école d’ingénieur, dans une école de Télécoms. J’ai découvert Internet et l’open source en même temps, c’était en 1994. Tout de suite, ça m’a beaucoup, beaucoup intéressé, cette idée d’utiliser Internet pour interconnecter tout le monde et de commencer à échanger du code et échanger des idées de manière libre. C’est vrai que je me suis rendu compte que la construction d’Internet, ça a été aussi beaucoup basé sur des logiciels libres et open source, puisqu’il a fallu créer l’infrastructure et c’était à base de composants libres.

Je monte un serveur de temps, je monte un serveur DNS, je monte un serveur Apache. Puis après, quand le Web est apparu, c’est devenu dynamique, des sites PHP/MySQL, etc. Donc on se rend compte que c’est très lié les deux. Et ça, c’est quelque chose qui m’a beaucoup intéressé dès le départ. Aujourd’hui, je ne suis plus dans un métier qui fait que de l’open source, mais justement, je conseille sur la sélection de composants pour construire des offres, soit des plateformes où on offre du service chez Worldline, soit pour des projets qui clients. Et il y a aussi cette problématique d’intégrer ces composants-là dans des architectures plus complexes et surtout de les opérer, d’en faire le run et tout ça sur la durée. C’est vrai que c’est des choses qui sont importantes à regarder. Worldline, effectivement, c’est une boite aujourd’hui, un opérateur mondial, on va dire, dans le domaine du paiement. Mais en fait, on ne fait pas que ça. On fait aussi tout ce qui va être systèmes avec beaucoup de transactions, donc haut volumes et très régulés.

Présentation de la méthode QSOS

Walid : avec Raphaël, on vient de passer deux jours au salon Open Source Experience. C’était la grande excitation. Alors maintenant, il faudrait qu’on parle un tout petit peu, justement, de QSOS, puisque c’est un peu le sujet. Enfin, c’était une partie du sujet. Donc, je voudrais qu’on aborde juste très rapidement ce que c’était que QSOS.
QSOS (source : wikipedia)
Raphaël : QSOS, ça veut dire Qualification et Sélection de Logiciels Open Source. C’est une méthode, une démarche que j’ai créée dans les années 2005-2006, quand j’étais dans l’Open Source Center d’Atos. D’abord pour des besoins internes : quand nous avions besoin de sélectionner des composants pour nos propres projets, ce genre de choses. C’est parti de quelque chose qui ressemblait un petit peu au kit comparatif qu’on peut avoir avec la FNAC. On a un certain nombre de critères et puis on a des étoiles et cela permet de comparer. À partir de là, on s’est rendu compte que ça c’était utile aussi pour les clients. Et puis finalement, je l’ai intégré dans la démarche de conseil et de veille que je faisais pour le compte des clients. Il faut savoir qu’au départ, on était sur des grilles de comparaison sur des fonctionnalités, donc de la couverture fonctionnelle ou des aspects techniques. Très vite, j’ai rajouté tout un ensemble de critères qui est toujours le même, quel que soit le domaine, que j’ai appelé « maturité » et qui permet d’évaluer la maturité, la pérennité d’une solution et du projet qui la construit. Parce que c’est hyper important pour un utilisateur, une entreprise ou une administration, d’évaluer les risques qu’il prend à adopter un logiciel open source par rapport au fait que le logiciel soit pérenne, qu’il soit toujours là dans quelques années ou qu’il n’y ait pas des changements de licence ou des changements de business model, comme on en parlera sûrement après.

Pour ça, j’ai établi une liste de critères assez précis qu’on peut regarder parce qu’on est dans le domaine du libre et que c’est accessible. Ou lorsque ça ne l’est pas, justement, c’est une information aussi. Par exemple qui contrôle le projet ? Quelle est la licence du projet ? Qui détient les droits sur le code ? Quels sont les business models ? Les core committers, est-ce qu’ils sont dans une seule entreprise ou ils sont payés par plusieurs entreprises, ou pas payés du tout ? Quel est le niveau d’industrialisation du projet lui-même ? comment gère-t-il la sécurité ? est-ce qu’il y a de la gouvernance ?

Il y a tout un ensemble de critères. On n’a pas de boule de cristal, on ne peut pas prévoir tout ce qui va se passer dans le monde open source, mais ça permet d’anticiper quand même certains risques. Effectivement, et d’ailleurs, Gonéri, c’est ce que tu as apporté quand j’ai travaillé avec toi là- dessus. Très vite, tu m’as dit « Mais il faudrait avoir un format standard pour stocker les informations d’une évaluation. » Et à partir de ce format-là, qui était un format XML (à l’époque, c’était encore à la mode), on a construit un ensemble d’outils qui permettent à la fois de construire des grilles, puisqu’il y a la couverture fonctionnelle qui va changer en fonction du domaine, et une fois qu’on a une grille, de réaliser des évaluations de la manière la plus objective possible. Une fois qu’on a des évaluations qui ont pu être réalisées par d’autres personnes, c’est de les utiliser pour les comparer, avec un troisième type d’outil, pour faire un choix dans un domaine donné, comparer plusieurs types de softs.

Ça peut être des bases de données, MySQL, Postgres, MariaDB, etc : on fait un choix sur des critères précis et on modélise le contexte qu’on a, nous. On choisit en mettant des poids sur ces critères-là. Si un critère qui n’est pas important, on met un poids de zéro et puis un critère qui est plus important, on va mettre un poids plus important. À partir de là, on peut générer des graphes, des quadrants où on voit la maturité par rapport à la couverture fonctionnelle, etc. Ça, on l’a beaucoup utilisé dans les travaux de veille. D’ailleurs, pas plus tard qu’il y a quelques jours, quand on était au Salon, j’ai croisé un client dans le secteur public qui m’a dit qu’ils utilisaient toujours la méthode QSOS quand ils sélectionnaient des logiciels et même qu’ils demandaient à leurs prestataires de l’utiliser pour faire les études de veille. Je suis assez content et ça prouve que ça sert.

Walid : c’est un sujet passionnant, l’évaluation et la qualification des logiciels. Moi, bosser avec toi sur QSOS, ça m’a énormément appris.

Le modèle communautaire

Maintenant, on va rentrer dans le dur du sujet. On va commencer à parler des modèles économiques. Comme je le disais en intro, des modèles économiques, il y en a pléthore. On en est même quasiment arrivés à la conclusion qu’il y a autant de modèles économiques que de projets, puisque c’est quand même très lié aux gens qui font le projet, au secteur, à un ensemble très vaste de facteurs. Le premier modèle dont on peut parler – et j’en ai déjà parlé sur le podcast, vous pouvez écouter l’épisode 1 avec Dolibarr et le premier épisode sur GLPI – c’est le modèle communautaire. Là, le modèle communautaire, c’est un modèle qui est très ancien et c’est un modèle qui a eu son heure de gloire, un petit peu moins maintenant.

Raphaël : oui, effectivement, même historiquement, les premiers business open source, ou premiers modèles d’organisation autour des projets open source qui se sont faits, c’étaient des projets purement communautaires. Comme je l’ai dit, c’est concomitant de la création d’Internet. Qu’est-ce qu’on a fait ? On a commencé à construire les outils dont on avait besoin pour faire l’infrastructure d’Internet, puis ensuite pour développer des softs. C’est tous les frameworks de bas niveau, les gestionnaires de code, tous les IDE, toutes ces choses- là. C’est vrai qu’au départ, ce type de projet, il se veut vraiment communautaire. C’est vraiment le premier type de modèle : on va avoir un ou plusieurs développeurs qui se retrouvent, qui commencent à travailler ensemble. Il n’y a pas de gouvernance ou de structure hyper explicite pour organiser les travaux. Après, quand le modèle il grossit, ça peut se transformer en une gouvernance pas toujours si explicite que ça, mais où il y a un rôle qu’on appelle « dictateur bienveillant » qui peut émerger. Ça, c’est l’exemple qu’on a avec le noyau Linux, avec Linus Torvald, qui aujourd’hui toujours a un peu ce rôle-là. Il faut se rappeler qu’au début, Linus, il a juste publié sur Internet le fait qu’à l’époque, il était jeune étudiant, qu’il travaillait sur un noyau.

Des années après, le projet a énormément grossi. Il s’est structuré, mais il y a toujours ce rôle-là de dictateur bienveillant. A un moment donné il y a quelqu’un qui va prendre des décisions sur le projet. Et quand on commence à avoir de plus en plus de contributeurs et notamment des gens qui vont avoir le rôle de committer, c’est-à-dire qu’ils peuvent modifier le code source mainstream du projet, alors c’est un rôle qui est important. Donc il peut y avoir un principe de méritocratie qui se met en place. Au fur et à mesure que les contributions sont reconnues et que le reste de l’équipe core, on va dire, a confiance dans ces personnes-là, ils peuvent avoir ce droit-là, ce droit de committer sur le code. Après, la manière dont c’est organisé, ça peut être plus ou moins structuré. On l’a vu avec le projet PostgreSQL, par exemple, où ils ont une structure assez lâche, mais c’est voulu, c’est fait exprès. Je pense que ce sera intéressant d’ailleurs de faire un épisode dans les interviews de voir qu’ils expliquent comment ils fonctionnent. Le risque dans tout ça, c’est qu’au début, ça marche bien, la méritocratie, mais après, sur des projets assez anciens, quid des nouveaux ?

C’est un peu compliqué, ça peut se transformer en oligarchie un petit peu. C’est ça le risque.

Walid : Gonéri, est-ce que tu veux ajouter des choses supplémentaires ?

Gonéri : là, on parle plus de la façon d’organiser un projet, mais pas forcément du financement. Je pense qu’au début, dans le cas de Linux, c’était surtout quelqu’un qui était bénévole et ça a duré longtemps comme ça. Et je pense que pendant longtemps, ça a été la source de rémunération. C’était du bénévolat ou c’était dans le cadre du travail pour répondre à un besoin local. Et ce besoin de pérenniser des projets, ce n’était pas vraiment un sujet, je pense, à l’époque.

Walid : en France, sur ces modèles-là, ces modèles un peu communautaires, on avait pas mal de projets qui ont commencé en faisant des associations, par exemple. Avec des gens qui étaient bénévoles. Certains sont restés avec des associations, d’autres, effectivement, se sont peut-être transformés. J’en parle un peu dans l’épisode sur GLPI, par exemple, où il y avait une association et cette association elle-même, elle avait des adhérents et il y avait des gens qui gravitaient autour. Et la gestion du projet, les mainteneurs, étaient des bénévoles. Et eux-mêmes, par exemple, avaient des accords de partenariat avec des sociétés privées qui faisaient du conseil aussi. Ce n’est pas toujours un modèle qui est finalement très évident quand on essaye de faire du business avec des associations. Ce n’est pas toujours très évident parce qu’ on a des gens qui sont… enfin c’est une association, en tout cas en France, potentiellement à but non lucratif. Et d’un autre côté, on a des gens qui sont là pour aussi faire de l’argent. Donc arriver à trouver les gens et à trouver la manière de faire le pont entre les deux, ce n’est pas toujours très évident.

Peut-être est-ce une des choses qui fait que ce modèle a un peu perdu de sa superbe ? Je ne sais pas. Qu’est-ce que vous en pensez, Gonéri, par exemple ?

Gonéri : je pense qu’il est encore très présent. En fait, c’est une question d’échelle aussi. Disons qu’il y a 30 ans, une seule personne pouvait développer un logiciel qui allait être utilisé massivement. Aujourd’hui, pour avoir autant d’impact, il faut quand même être une petite équipe. Il y a des coûts supplémentaires qui arrivent. Je ne pense pas que ce soit si simple, à moins de développer une librairie JavaScript ou des choses comme ça qui sont très précises. On arrive toujours sur le problème du périmètre. Je ne sais pas ce que tu en penses, Raphaël.

Raphaël : en termes de business model, c’est surtout que les développeurs ne sont pas payés par le projet, puisque le projet n’a pas d’existence économique ou juridique. Il n’y a pas de notion de rémunération de leur travail. Soit ils ne sont pas payés du tout, là, il y a un risque intense sur la pérennité du projet. On l’a vu avec des projets comme ColorJS ou MakerJS où finalement, le lead dev en a eu marre de ne pas gagner d’argent : il a un peu sabordé son projet, ce qui a gêné pas mal d’autres projets open source qui l’utilisaient.

Ça peut être aussi des modèles comme on voit aujourd’hui sur le noyau Linux ou même sur Postgres : c’est de la coopétition, c’est-à-dire qu’il y a des entreprises qui payent des développeurs, ça peut être même à plein temps, pour travailler sur le noyau Linux ou sur Postgres, parce qu’elles y ont un intérêt. Cela fait partie de leur business model à elles, puisqu’elles vont revendre du service ou des versions Enterprise comme EnterpriseDB. Ou tous les constructeurs qui veulent s’assurer que, par exemple, Linux tourne bien sur leurs machines. Donc là, on est un peu dans ce modèle-là.

Après, comment financer aussi quand on est dans du pure communautaire ? Ça peut être des dons avec notamment le crowd sourcing, avec des sites comme Patreon ou ce genre de choses-là. Il y a des projets qui vivent sur les dons, qui peuvent être aussi faits par des entreprises, soit sous forme d’argent ou aussi du matériel. Ça peut permettre de faire tourner des infras, faire tourner la CI/CD, les tests, héberger le site web, etc. Et puis, il y en a aussi qui peuvent faire du merchandising, mais dans ce cas-là, il faut avoir une marque un peu. Il n’y a que besoin d’une entité légale pour porter la marque et vendre des T- shirts, des mugs.

Walid : est-ce qu’on peut donner des exemples pour que les auditrices, les auditeurs, puissent se figurer un peu de projets un peu connus, emblématiques, qui utilisent ce modèle un peu communautaire comme ça ?

Raphaël : oui, effectivement, on a des exemples de projets, c’est souvent, comme on l’a dit, les premiers qui sont apparus et on les retrouve un peu dans les trucs qui vont faire l’infrastructure de l’Internet aujourd’hui, par exemple dans la messagerie. Que ce soit Sendmail ou Postfix, ce sont des projets purs communautaires. C’est sur cette base là que que s’est construite toute l’infrastructure de mails d’Internet aujourd’hui, par exemple. On en parle aussi sur Linux et tout ce qui a permis de développer l’outillage.

Walid : Gonéri, on avait noté aussi Debian, par exemple ?

Gonéri : Debian, je pense que c’est un exemple un peu à part. C’est propre à toutes les distributions Linux. Ce qui fait la force de ces organisations, c’est que le travail est très structuré et c’est assez facile de devenir une petite fourmi ouvrière dans le système et commencer à construire des paquets, des choses comme ça. Il y a quand même une fondation, il y a quand même une structure derrière, qui a de l’argent, qui a un petit peu de moyens, niveau légal et tout ça. Mais c’est vrai que je dirais que 90% du travail est fait par ces mainteneurs de paquets qui sont des gens qui sont vraiment des bénévoles purs et durs.

Walid : j’allais dire des gens comme VLC ?

Gonéri : oui, il y a Vim aussi. Vim, c’est vraiment un projet pur communautaire. Il n’y a jamais eu de structure derrière.

Walid : là, il y a aussi le moyen d’avoir des dons financiers, ça peut passer par un certain nombre de moyens différents : dons, merchandising. On a parlé hier et avant-hier de sponsoring. Je dois avouer que je n’étais pas très au fait de ça. Est- ce que tu peux en dire deux mots , des moyens pour ces projets de récolter de l’argent Raphaël ?

Raphaël : une des sources de financement, ça peut être les dons. Les dons peuvent être faits par des particuliers avec des projets comme Patreon ou ce genre de choses, ou ça peut même être des subventions du domaine public. Par exemple, avec des projets qui viennent de l’Europe comme la fondation NLnet, projet très intéressant pour dynamiser tout l’écosystème en Europe (NDLR : voir l’épisode avec Lwenn Bussière de NLNet). Elle ne finance pas sur des montants complètement délirants. Elle finance des projets qui en ont bien besoin pour les booster un peu : c’est super. Pour ce faire, il faut effectivement que le projet se structure pour avoir au moins une entité légale, morale, pour recevoir ces dons-là et pouvoir les utiliser et les organiser. Ça peut être aussi, du coup, gérer la marque avec un logo, une marque. Avec cela, ils vont peut-être pouvoir aussi générer de l’argent pour financer le projet en vendant des produits dérivés. On le voit quand on va au Salon Open Source Experience, même dans le village des associations, il y a des logos, il y a des marques, on peut acheter des mugs, des sweatshirts, plein de choses comme ça. C’est vrai que c’est intéressant.

Gonéri : en sponsoring, il y a eu Transmeta. Transmeta, c’est une entreprise qui voulait faire un processeur dans les années 2000. Ils payaient Linus Torvald pour ça.

Le principe, c’était qu’il devait porter Linux sur ce nouveau processeur. Mais la réalité, c’est que c’était aussi une façon pour Transmeta de se faire connaître et de montrer qu’ils contribuaient, que techniquement, ils étaient des bons acteurs. Là, on était vraiment dans du sponsoring. C’était une façon de populariser la marque Transmeta grâce au travail de Linus Torsvald.
Transmeta (source : wikipedia)
Walid : pour finir avec ce modèle-là, qu’en est-il en ce qui concerne, la propriété intellectuelle ?

Raphaël : effectivement, sur ce type de projet communautaire, comme il n’y a pas de business model en tant que tel, il n’y a pas besoin de gagner de l’argent grâce au code. Il n’y a pas cette notion de propriété intellectuelle sur le code sur lequel une entité aurait besoin d’avoir le contrôle. En fait, tu peux avoir un peu tous les types de licences. On retrouve un peu tout.

Cela a été surtout sur les premiers projets : c’est là où sont créés les premiers types de licences. Effectivement, le projet n’est pas une entité qui a besoin d’avoir les droits sur le code. Et ce qui va sécuriser le projet, c’est que chaque contributeur détient les droits sur sa propre contribution. Et c’est ça qui rend le projet aussi stable et fort par rapport à une prise de contrôle d’une autre entité qui pourrait prendre le contrôle de la base de code, comme dans d’autres modèles qu’on verra un peu plus tard. Je prends des exemples de projets open source qui ont démarré très tôt comme PostgreSQL ou comme ceux que je citais tout à l’heure. Aujourd’hui, changer la licence de ces softs-là, c’est quelque chose qui serait très compliqué parce qu’il faudrait avoir l’accord un peu de tout le monde.
Donc ça le protège.

Gonéri : PostgresSQL, c’est une licence BSD, je pense. Tu pourrais changer la licence. D’ailleurs il y a des versions propriétaires de PosgreSQL.

Walid : il faut qu’ils donnent leur accord ?

Gonéri : non, pas avec une BSD.

Les fondations

Walid : passons au modèle suivant. C’est le modèle des fondations, qui est un autre modèle aussi très répandu. Raphaël, est-ce que tu veux un introduire un peu ce modèle, s’il te plaît ?

Raphaël : oui, les fondations. C’est le deuxième modèle qui est apparu et c’est une évolution possible. Lorsqu’un projet commence à avoir beaucoup d’utilisateurs et de contributeurs, il peut y avoir la possibilité de créer une fondation autour du projet. Comme on l’a dit tout à l’heure, l’idée, c’est de disposer d’une entité morale et juridique qui va être capable de représenter le projet devant la loi, par exemple, et de gérer le budget et de distribuer l’argent. La fondation, elle va aussi organiser et protéger… Suivant la taille et de la maturité de la fondation, il y a des rôles qui vont émerger, qui sont assez clairs, assez précis, avec cette idée de transparence autour de la méritocratie et du fait de tenir ce rôle ou pas. Qu’est-ce que ça veut dire ? Certains des rôles qui sont structurants par rapport au fonctionnement et à la gouvernance de la fondation peuvent être rémunérés carrément. Il y a cette notion de budget qui est importante. En général, comme je le dis, c’est surtout sur des projets qui ont eu beaucoup d’utilisateurs et de contributeurs et qui ont tendance à créer d’autres projets annexes ou connexes et donc à faire émerger cette notion d’écosystème.
Fondation Apache (source : wikipedia)
On le voit avec des exemples comme la fondation Apache. Au départ, c’était un serveur web. Aujourd’hui, la fondation Apache contient énormément de projets. Pareil pour la fondation Eclipse : c’est parti d’un IDE. Aujourd’hui, Eclipse fait bien plus qu’un IDE, même du Java.
Fondation Eclipse (source : wikipedia)
Les fondations de ce type-là, au début, ont eu tendance à pousser des protocoles et des standards ouverts parce que justement, elles sont en train de favoriser l’émergence d’écosystèmes. C’est via ces protocoles et standards qu’on va pouvoir faire de l’intégration et construire et articuler les différentes choses comme des legos. Construire des choses de plus en plus complexes, de plus en plus sympa.

The Document Foundation est un bon exemple. Quand LibreOffice a été forké d’OpenOffice, un des premiers réflexes qu’ont eu les gens qui ont fait ça, c’est de créer une fondation qui s’appelait The Document Foundation, avec un objectif clair qui était de faire la promotion aussi de formats ouverts de bureautique. On voit comment une fondation peut être plus large que juste un seul projet. En général, ces fondations-là vont avoir tendance à vouloir accepter des nouveaux projets, à favoriser l’innovation.

Pour ça, elles vont avoir des notions d’incubateurs dans lesquels il y a des projets qui peuvent prétendre à rentrer dans la fondation et donc à profiter un peu de tout ce qu’elle propose en termes d’organisation, protection juridique, etc. Mais cela passe par un process où la maturité du projet va être évaluée. Ils vont vérifier justement ces notions de propriété intellectuelle, éventuellement demander à changer de licence, pour un licence qui soit plus conforme à la stratégie de la fondation. D’ailleurs, on retrouve dans certaines fondations des méthodes qui ne sont peut-être pas aussi poussées que QSOS, parce que justement, ils ont besoin de vérifier ces aspects-là.

Gonéri : il y a aussi OpenStack. Je pense à la Linux Foundation où OpenTofu, le fork de Terraform est entré il n’y a pas très longtemps. C’est une façon de montrer qu’ils étaient « sérieux », de montrer qu’ils voulaient vraiment structurer leur fork.
OpenTofu (source : Linux Fondation)
Walid : je ne sais pas si tu l’as mentionné, Raphaël, mais il y a aussi le côté détention des marques et propriété du code.

Raphaël : contrairement aux premiers modèles communautaires, la fondation a besoin d’avoir la propriété intellectuelle sur le code pour être capable de le protéger, de protéger le projet au niveau juridique et au niveau légal. Donc, c’est là où, effectivement, apparaît la notion de CLA, qui veut dire Contributor License Agreement. Il y a des variantes : individuel ou enterprise, mais l’idée, c’est la même derrière. Lorsqu’il y a une contribution est faite et va rentrer dans la base de code officielle du projet mainstream, il y a un partage ou carrément une cession des droits de propriété intellectuelle sur le code, pour que ce soit la fondation, une entité morale, qui possède le code. Et ça, c’est ce qui va lui permettre de protéger les choses.

En termes de licences, par exemple celles que j’ai citées, Eclipse, Apache, puis après tout l’univers Mozilla, par exemple, ont créé leur propres licences parce que ça correspondait effectivement à leur vision de qu’est-ce que c’était l’open source et de la manière dont eux voulaient fonctionner.
Mozilla Foundation (source : wikipedia)
C’est vrai qu’en général, les fondations ont des variantes de licences privilégiées. Et l’ensemble des projets qui sont sous le couvert de cette fondation-là vont partager cette licence. C’est toujours la même idée de pouvoir recomposer les projets les uns avec les autres et donc ne pas avoir de problème de compatibilité entre licences puisqu’ils sont dans un univers, finalement, qui est homogène. Après, effectivement, les CLA se sont avérés être un peu lourd parce qu’il y a pas mal de choses à vérifier avant de se dire « Est-ce que tout est OK au niveau du code pour l’intégrer ? » Et donc, certaines fondations qui ont adapté un petit peu ce concept-là avec la notion de Developer Certificate of Origin, donc c’est DCO. Là, l’idée, c’est de faire confiance au développeur en lui demandant de lui checker de son côté et de garantir que tout était OK par rapport à la contribution qu’il s’apprêtait à faire. Qu’il avait bien le droit, qu’il respectait bien la propriété intellectuelle, qu’il n’était pas en train de violer des brevets ou ce genre de choses-là. Donc, ça a permis de faciliter un petit peu les contributions parce que sinon, ça pouvait un peu rebuter certains contributeurs qui disaient « C’est hyper lourd, ça devient bureaucratique pour contribuer ». Ça s’est un peu allégé avec ça.

Walid : sur ces histoires de CLA et de DCO, on en parle aussi dans l’épisode avec Benjamin Jean. On va certainement reparler dans d’autres épisodes puisque j’ai rencontré des gens qui sont très, très calés sur ce sujet-là et parce que c’est assez passionnant, ce sujet.

Pour finir, ce qui est intéressant, pour en avoir discuter avec les gens de la fondation Eclipse, c’est qu’il y a tout un côté d’apprentissage pour les gens qui viennent et qui disent « Moi, j’ai un projet, je ne sais pas comment on fait pour structurer ça. » Il y a toute une partie éducation à « Comment bien faire un projet libre ? Comment accompagner les gens ? Comment bien contribuer ? » Je trouvais ça assez intéressant parce qu’effectivement, quand tu es une grosse boîte tu ne sais pas forcément comment faire du libre. Ils sont là aussi pour t’accompagner. C’est ça qui est assez intéressant. Il y a différents types de fondations. Il y a des fondations qui sont plutôt historiques. On a parlé d’Apache, on a parlé de fondation Eclipse. Il y a d’autres nouvelles fondations aussi. Je n’irai pas plus loin sur le sujet parce que je ne le connais pas, mais on en reparlera, pareil, je pense, dans d’autres épisodes.

Raphaël : les fondations, puisqu’elles organisent et elles essaient de faire la promotion d’écosystèmes, ont tendance à créer des standards, à créer des protocoles pour fédérer autour des différents projets qu’elles créent, The Document Foundation autour du projet LibreOffice pour défendre des standards ouverts dans tout ce qui est bureautique. Et on le retrouve dans plein d’autres domaines et d’écosystèmes, par exemple XMPP, même si aujourd’hui je ne sais pas si c’est toujours à la mode, mais c’est vraiment l’idée. On va le retrouver aussi dans le Fediverse, avec la création de protocoles.

Dans les business model des fondations, comment finalement elles récupèrent de l’argent ? C’est un peu comme les premiers types de projets : elles peuvent recevoir des dons. Ça marche aussi pas mal par dons, du sponsoring. Ça peut être les sponsors d’entreprises qui disent « Moi, je participe à la fondation, Linux, Eclipse, etc. » en donnant de l’argent. Ça peut même être organisé en fonction de niveaux Silver, Gold, Platinum. Parce que ça fait aussi de la pub, finalement, des gens qui sponsorisent, qui participent à ça. Ça, c’est quand les fondations, évidemment, sont bien visibles.

Raphaël : ça peut être des subventions publiques également. Et puis d’autres moyens que les fondations ont de générer de l’argent, ça peut être en créant du merchandising, avec des logos, des T-shirts, tout ce qu’il peut y avoir comme produits dérivés. Il y aussi, mais je ne sais pas si ça leur apporte de l’argent, l’organisation des événements comme l’ApacheCon ou l’EclipseCon. Aujourd’hui, il y a beaucoup de choses qui se font comme ça. Ça aide à animer et à fédérer la communauté autour de la fondation. Et c’est vraiment ça qui peut aussi leur ramener de l’argent. Je ne pense pas que ce soit leur première source de revenus, mais c’est à noter quand même.
EclipseCon 2023 (source : eclipse)
Walid : il y a aussi un sujet avec la localisation où se trouve la fondation. On en reparlera dans les prochains épisodes, je pense en particulier avec les fondateurs de Tryton qui font un fork de TinyERP à l’époque, ça ne s’appelait pas encore Odoo. Ils ont monté une fondation de droit belge et qui expliquent justement pourquoi et ce que c’est une fondation en Belgique ? C’est quoi les spécificités, etc. C’est un autre sujet qui pourrait être traité aussi et qui mériterait beaucoup de temps pour voir un peu pourquoi il y a une fondation dans un pays, qu’est-ce qui est différent d’un autre, etc.

Les modèles du service et du support + SaaS

Walid : le modèle suivant, c’est un autre modèle qui existe depuis très longtemps et que nous-mêmes avons pas mal pratiqué. C’est le modèle qui concerne les services et le support. En gros, il y a un projet et il y a des entreprises qui vendent des services. Ça peut être par exemple du développement générique ou spécifique, du support sur le logiciel. Ce qu’on paye, c’est tous ces services. Gonéri, est-ce que tu veux en dire quelques mots ?

Gonéri : c’était le business model de Red Hat. Je pense que ça a évolué quand même, mais au début, l’idée était que les entreprises voulaient essayer Linux ou migrer depuis leur système Unix vers Linux. Ils avaient besoin d’un partenaire pour prendre les risques. Et c’est là où Red Hat est arrivé. Les clients payaient Red Hat pour avoir cette garantie. En échange, Red Hat fournissait un support technique. Ça existe toujours, mais c’est vrai que maintenant, Red Hat est quand même devenue une entreprise avec différents types de revenus. Cette stratégie n’est qu’une des sources de revenus.

Walid : Raphaël ?

Raphaël : à partir du moment où les projets, les communautés, ont besoin de trouver un modèle financier et continuer à payer les développeurs, en tout cas, à ce qu’ils en vivent et donc à assurer aussi la pérennité du projet sur le long terme. Un modèle a été la vente, et ça l’est toujours d’ailleurs : la vente de services et de supports sur le logiciel qui est créé par la communauté. Effectivement, avec la création d’entreprises commerciales qui vont offrir et vendre ces services-là. Donc, ce n’est pas une fondation, mais c’est un autre moyen de gagner de l’argent et de pérenniser, notamment, les développeurs. Ça, c’est quelque chose qu’on va regarder dans QSOS.

Justement, est-ce qu’il y a un modèle commercial ? Qui paye les développeurs ? Quelque part. Et après, ça va dépendre des services qui sont fournis ou proposés par l’entreprise, parce qu’il y a toute une gamme de services, à commencer par le service de support, donc corriger les bugs dans le code avec engagements potentiels sur le temps de correction. Ça va dépendre du type de contrat : c’est sûr que pour faire ça, il vaut mieux avoir des core developpers et des committers dans son équipe, parce que sinon, ça va être difficile de prendre des engagements.

Ça, c’est un contrôle qui va être plutôt fort sur le projet, avec des engagements sur la qualité du code et puis aussi un peu sur la roadmap, sur les décisions pour développer des nouvelles features pour des clients, etc. Les services peuvent être aussi simplement de l’intégration, de la customisation, des choses qui vont pas toucher au code, au cœur du soft ou qui vont être à la périphérie pour l’intégrer dans d’autres environnements. Ça peut être aussi de la formation ou de l’expertise et ça peut aller même jusqu’à de la certification ou, par exemple avec Linux Professional Institute ou même chez Red Hat, il y a ces notions de certification. Ça, c’est des choses qui sont payantes. C’est évidemment quand le soft lui-même a acquis une valeur et qu’il y a besoin de démontrer qu’on a l’expertise sur l’utilisation et la mise en œuvre de ces logiciels-là et de leur écosystème. C’est aussi un autre modèle qui a pas mal marché et qui existe toujours.
LPI (source : lpi)
Gonéri : WordPress est aussi un bon exemple. Il y a une multitude de petites entreprises qui fournissent du service sur WordPress, qui ne contribuent pas forcément directement.

Walid : vous pouvez écouter un des épisodes précédents sur WordPress. On en parle justement avec Jean-Baptiste Audras, qui est un core committer de WordPress et qui explique un peu cela.
WordPress (source wordpress.com)
Raphaël : un autre service qui peut être offert, c’est celui du SaaS avec l’apparition du Cloud : c’est vendre du service, pas le soft lui-même. Ça veut dire que le soft, il est toujours sous licence open source, il peut être distribué, utilisé par les gens qui veulent se l’installer eux-mêmes. Mais l’entreprise va aussi fournir le service hébergé, qu’elle va héberger elle-même et sur lequel elle va s’engager en termes de SLA, de contrat de service. Cela peut être associé avec les autres services, de support, de formation, de certification. On voit par exemple, ça, c’est le modèle de Red Hat, ça peut être même vendu sous forme de souscription. Une souscription, c’est quelque chose que tu payes régulièrement et qui couvre un peu tout ça. Cela a pas mal marché auprès des vendeurs, des entreprises ou des administrations qui avaient l’habitude de payer des licences régulières annuelles auprès de fournisseurs de logiciels privatifs : là, ils retrouvent un peu leurs petits. Ils étaient plus à l’aise, en tout cas, pour aborder l’entreprise et la manière de travailler. En revanche, puisqu’il y a une entreprise commerciale, il y a besoin aussi d’avoir l’accès au code, mais il n’y a pas forcément besoin complètement de la CLA ou du DCO. Ça va dépendre un peu de chaque projet, de chaque modèle. C’est vrai que si on fait de la formation ou de l’expertise, possiblement on n’intervient même pas sur le code et on n’a pas d’IP (propriété intellectuelle).

Walid : ce n’est pas toujours évident avec ce modèle non plus, le service, parce que cela fluctue pas mal. Quand tu as des développeurs et que tu n’as pas de contrat, c’est assez dur. Ce qui explique aussi pourquoi certains projets partent de ce modèle-là, parce que tu vas chercher des revenus récurrents pour pouvoir payer tes développeurs. Et le service est quelque chose qui est plutôt aléatoire et donc ce n’est pas évident. Gonéri, tu voulais dire quelque chose ?

Gonéri : non, je pensais au SaaS, aux souscriptions. Et effectivement, je pense que c’est la réponse à ce que tu dis. Ça permet de lisser un peu les sources de revenus, d’avoir de la visibilité sur ce qui va arriver. Et aussi d’avoir des groupes d’utilisateurs, de bien identifier les demandes qui viennent des clients pour les améliorations, des choses comme ça. Ce qu’on n’a pas forcément lorsqu’on fait juste du support occasionnel.

Walid : la question que je me pose, mais peut-être que vous avez la réponse : j’ai l’impression que sur les nouveaux projets qui se montent ou qui ont quelques années, le service n’est pas un modèle qui est extrêmement utilisé. Mais peut- être que j’ai une vision biaisée du truc. Je ne sais pas, Raphaël, qu’est-ce que tu en penses ?

Raphaël : effectivement, ce qui va garantir quelque part que ce modèle est bon sur la durée. La pérennité de l’entreprise et des projets est bonne car c’est prédictif. Le problème du support, c’est qu’on ne peut pas prévoir les rentrées d’argent que ça va générer, alors que quand on vend du service comme ça, notamment en mode SaaS, c’est du récurrent, c’est prédictible. C’est vrai que ça permet de sécuriser et de vraiment payer des développeurs et d’avoir des business plans et de convaincre des investisseurs sur la santé financière de l’entreprise. Ce modèle-là de support et de service, il a eu le vent en poupe. Aujourd’hui, ce n’est pas forcément le modèle dominant. On verra qu’il y a d’autres modèles qui sont aujourd’hui plus facilement utilisés, mais il y a des gens, des projets qui restent fidèles à cette vision-là : avoir quelque chose de purement communautaire et d’offrir des services. On en a rencontré lors du salon à Open Source Experience, c’était très intéressant. Ils sont fidèles à leurs valeurs, ils veulent gagner de l’argent, ils veulent pérenniser leurs projets, mais pas au prix de ces valeurs-là.

Raphaël : c’est vrai que c’est intéressant de voir qu’il y a des entreprises qui vivent et qui survivent avec cette vision-là.

Walid : c’est vrai qu’il y a des gens qui sont fondamentalement accrochés, dans le bon sens du terme, à ce modèle, qui savent qu’ils pourraient, par exemple, faire plus d’argent en passant à un mode éditeur et en passant à un modèle open core, on va en parler après, mais qui restent sur ce modèle-là parce que ce modèle garantit que 100% du code est libre. Je connais plusieurs exemples de boîtes qui disent « Non, non, mais nous, 100% du code, il est libre, on fait du service, on sait qu’on pourrait gagner plus d’argent autrement, mais on veut pas, on veut rester sur ce modèle. » Gonéri ?

Gonéri : quand on a une entreprise qui est basée sur le support, sur les formations, des choses comme ça, passer sur un autre modèle, c’est quand même pas évident. Parce que les clients qu’on a, c’est des gens qui sont là aussi parce qu’ils apprécient cette démarche. Je pense que tu l’as vécu avec GLPI : quand on commence à dire à tous les clients qu’on va changer, qu’on va passer sur un système de souscription, qu’on se retrouve à pédaler un peu pendant plusieurs années, c’est aussi quelque chose qui freine, je pense, la transition vers un autre modèle.

Walid : tout à fait.

Raphaël : après, effectivement, sur ce modèle-là de support et de service, tout l’enjeu est de trouver un équilibre : pouvoir survivre dans le temps au niveau économique. Il y a pas mal de projets et d’entreprises qui se sont cherchés en termes de business model. Et parfois, changer de business model, ça implique de changer la licence, quand ils ont justement la propriété intellectuelle sur le code. Mais le problème c’est que dès qu’on touche à la licence, on touche un peu au nerf de la guerre et il faut faire très attention aux réactions des utilisateurs qui peuvent ne pas comprendre le changement de licence, parce qu’ils sont habitués à pouvoir utiliser le soft de manière libre, au sens free software. Et ça peut leur faire peur. Et puis, on peut avoir aussi des réactions au niveau des contributeurs qui se disent « Mais quoi ? Changement de licence ? Est-ce qu’il n’y a pas un autre modèle économique qui est en train d’émerger ? » ou « En fait, finalement, on profite de mes travaux ? » Ce genre de choses. Donc, c’est vrai que c’est toujours un moment important dans la vie d’un projet quand il y a ces changements-là.
En général, les changements de licence, c’est associé à un changement de business model, notamment pour aller vers le type open core.

Walid : quand ton logiciel a toujours été libre et qu’à un moment, tu commences à parler d’argent et à parler de gros mots comme souscription, licence, etc, effectivement, pour l’avoir vécu (on en parle pas mal dans l’épisode 2 sur GLPI) c’est dur. Cela prend des années et ce n’est d’ailleurs même pas forcément les gens qui étaient là au départ qui restent ensuite. Parce que le modèle, il a changé. C’est peut-être pour ça que des projets qui commencent, ils ne commencent pas avec ce modèle-là.

L’Open Core

Walid : ok, modèle suivant. Modèle très en vogue, un gros morceau. C’est le modèle qu’on appelle le modèle open core, aussi les modèles éditeurs. Il y a différentes saveurs de modèle open core. C’est un modèle qui a été inventé en 2008. Je pensais que c’était plus récent que ça, mais en fait non. D’après la définition de Wikipédia, « cela consiste principalement à offrir une version de base ou limitée en termes de fonctionnalités d’un logiciel open source, tout en offrant une version commerciale ou des add-ons sous forme de logiciel propriétaire ». Dans le domaine dans lequel je suis, qui est le no-code, c’est le modèle dominant pour les produits open source.
Je vous laisse introduire. Raphaël, qu’est-ce que tu peux en dire de ce modèle ?

Raphaël : là il y a toujours une entreprise commerciale qui va être autour du projet, avec d’autres moyens de trouver des financements. En général, pour générer de l’argent, c’est la vente des fonctionnalités ou des choses qui ne sont pas forcément toujours open source. C’est pour ça qu’on parle d’Open Core : avec un cœur qui peut être open, qui est open source et avec des fonctionnalités avancées autour ou des plugins, des add-ons qui vont être payants. C’est là-dessus que l’entreprise va se rémunérer et pouvoir payer les développeurs et payer tous les frais et essayer de faire des bénéfices. Souvent, ces features-là, c’est des features qui vont s’adresser aux entreprises, puisqu’on rentre dans le monde de l’entreprise et du business. Ce n’est pas forcément des fonctionnalités qui vont être utiles à des utilisateurs isolés ou à des petites équipes. Ça va être des choses comme de l’intégration avec le reste d’un système d’information, la gestion d’utilisateurs avec des droits précis, parce qu’on en a beaucoup et qu’il faut avoir des types d’utilisateurs, des rôles, ce genre de choses, ou des choses qui vont être liées à l’industrialisation, à l’observabilité, etc.

Ça va être aussi la capacité à s’engager sur des versions à long terme avec des Long Term Support versions, ce genre de choses-là. Après, dans l’open core, il y a autant de modèles, on l’a dit de manière générale, mais dans l’open core, c’est encore plus vrai. Il y a autant de modèles qu’il y a d’entreprises qui le pratiquent. On pourrait parler de 50 nuances d’open source ou d’open core.

Cela va du fauxpensource qui est la libération du code pour être visibles et pour essayer de récupérer des utilisateurs assez rapidement. Mais en fait, on ne cherche pas du tout à développer une communauté. Forcément, regarder l’IP sur le code, de toute façon, on ne va pas accepter les contributions, on ne les cherche pas et on va peut-être essayer de se faire racheter par une autre entreprise ou de gagner de l’investissement externe. Après, ça peut aller jusqu’à des entreprises qui vont essayer d’articuler de la manière la plus propre possible une partie communautaire et une partie business. Et en fait, c’est la manière dont cette articulation est faite, plus ou moins bien, qui va garantir finalement le succès de ce genre d’entreprise.

Lorsque l’entreprise arrive à bénéficier à la fois d’une communauté qui est dynamique, qui est motivée, qui augmente la base d’utilisateurs, qui augmente la visibilité et d’un autre côté, des versions business qui sont claires avec des fonctionnalités qui sont vraiment bien précises pour certains types d’utilisateurs, il suffit qu’ils transforment une partie de leurs utilisateurs communautaires en utilisateurs commerciaux et l’entreprise peut avoir un bilan économique qui est viable.

Walid : dans l’open core, il y a pas mal de déclinaisons. Il y a un sujet qui est super intéressant, que j’essaye d’aborder dans les podcasts, justement, c’est comment est-ce que tu fais pour trouver le bon équilibre entre une version libre qui a des fonctionnalités suffisantes pour que les gens puissent l’utiliser au quotidien, mais d’un autre côté, certaines fonctionnalités avancées qui font que les gens vont avoir envie de prendre une souscription. Et là, il y a plein de modèles différents. Il y en a qui vont dire « Il y a des trucs récurrents, des trucs du style dans la version propriétaire, je mets par exemple tout ce qui concerne les authentifications, le SSO, ce genre de truc. ». Il y en a qui vont dire « Moi, je mets toutes les fonctionnalités entreprises, c’est-à-dire que tous les petits trucs pour les assos etc., ça va dans la version communautaire. » Il y en a qui vont dire, comme par exemple ça a été le cas pour Passbolt, que j’ai interviewé ou aussi sur GLPI, « On a des features, si on les met dans la version open source, on sait que ça va nous générer énormément de support et on sait qu’on n’a pas la bande passante pour garantir ces supports, parce que ce sont des features sur lesquelles on doit revenir régulièrement, etc. Et donc, on a besoin que les gens prennent des souscriptions pour être sûr que ça soit traité correctement ».
Donc, il y a vraiment un panel assez grand et chaque projet gère justement ce qu’il met dans une version ou ce qu’il met dans une autre de manière différente. Il y a encore d’autres projets qui vont dire « Moi, par exemple, je mets dans la version pas libre certaines features et quand j’estime qu’elles sont rentabilisées, je les rebascule, je les backporte dans la version libre. » Il y a il y a plein de choses différentes et là, c’est vraiment en fonction de ton marché, peut-être de tes concurrents, des fondateurs de la boite, du marketing, du commerce. Par contre, il y a quand même un certain nombre de choses là-dedans, c’est que très souvent, quand tu veux contribuer toi en tant qu’individu ou société externe, tu signes un accord des CLA en général ou quelque chose comme ça. Et on a vu effectivement des sociétés aussi qui, potentiellement, peuvent changer de modèle économique.

Gonéri : il y a un modèle intermédiaire où c’est le modèle produit-projet, qui est utilisé par Red Hat. On a quasiment à chaque fois un projet communautaire avec les défauts et les qualités que ça apporte, avec une roadmap courte, peu de visibilité sur le long terme, des versions qui s’enchaînent. Et à côté, on va avoir un produit où la roadmap va être plus maîtrisée, il va y avoir des engagements où le support va être plus long, des choses comme ça. Et dans les deux cas, ce sont des logiciels libres mais on a quand même ce produit qui s’apparente plus à ce qu’on vient de décrire, où on va pouvoir le vendre comme un logiciel qui peut être déployé, qui pourra avoir un support sur le long terme.

Raphaël : effectivement, au niveau Open Core, il y a un point qui est important, ça va être sur la licence et la propriété intellectuelle (IP). L’entreprise veut avoir plus ou moins le contrôle sur la base de code. Donc elle va avoir besoin de la propriété intellectuelle en général sur le code. Et donc, on retrouve ces notions de CLA (Contributor License Agreement), pour que, justement, l’entité commerciale puisse posséder la base de code. En général, on peut retrouver aussi ce modèle-là – en tout cas, historiquement, il y en a eu – de dual licensing, où le code est distribué (puisqu’il appartient à une entité, elle peut décider de le distribuer comme elle veut, c’est toujours comme ça que ça commence au début), sous une licence libre, mais aussi sous une licence qui est commerciale et privative, avec un contrat de licence qui est passé avec les clients. En fonction de l’usage qui va être fait du soft, il y a telle ou telle licence qui va le permettre. Un bon exemple, c’est MySQL. MySQL, dès le départ, ça a été sous double licence, à la fois GPL et propriétaire sans licence GPL comme c’est une licence copyleft.
MySQL (source : wikipedia)
En général, le Dual Licensing, ça marche bien avec les licences copyleft. Pourquoi ? Parce que lorsque l’entreprise va décider distribuer aussi le soft sous licence propriétaire. elle va enlever l’aspect contaminant, viral ou persistant (ça dépend comment on trouve le copyleft : est-ce que c’est bien ou pas bien, peu importe, il n’y a pas de jugement). Elle va enlever ces contraintes-là et donc ça va permettre à des entreprises de contracter directement avec l’entreprise qui diffuse le soft, là en l’occurrence MySQL, sans avoir à livrer des modifications qu’ils auraient fait dans le code ou autour en intégrant. On le retrouve pas mal dans l’embarqué (embedded), par exemple, quand MySQL est intégré dans du soft ou même proche du hardware. Effectivement, c’est plus facile à vendre à une entreprise, comme je l’ai dit tout à l’heure, où un acheteur va retrouver des choses qu’il connaît, puisque finalement, il a une licence assez classique, comme il a l’habitude de faire.

Walid : ça, c’est une question que j’aimerais bien aborder. Quel est le rôle des capitaux risqueurs (VCs) dans tout ça ? Parce que tu montes ta boîte, on va te donner de l’argent. Un VC va mettre de l’argent dans ta boîte, il va attendre un retour. Qu’est- ce qui se passe s’il n’a pas ce retour ? Quel est l’impact sur tes beaux idéaux de faire du logiciel libre, etc. ? On voit bien à l’heure actuelle qu’il y a quand même des problématiques qui sont liées au financement. Et ce modèle open core où tu as une société qui est éditrice, si en plus de ça, elle a toute la propriété intellectuelle sur le code, rien ne l’empêche de changer de licence et de partir sur des licences non-libres, finalement. C’est une problématique à prendre en compte de plus en plus. Et puis, une fois que tu as changé de licence, rien ne dit que tu vas pas rechanger une deuxième fois de licence en plus.

Raphaël : cet aspect-là sur le code est important en termes de maturité. Parce que c’est vrai que cela n’arrive même pas que dans le domaine open source : même sur des grands projets, par exemple, quand on fait pour des grandes entreprises ou dans le secteur public, il y a ce besoin-là d’avoir la garantie que le code et le soft sera toujours fonctionnel et donc potentiellement avoir accès au code dans 20 ou 25 ans. Et donc, il n’y a pas de garantie sur la pérennité de l’entreprise et c’est pour ça que souvent, ça peut être demandé de déposer le code, de le consigner, par exemple, à la Caisse des Dépôts pour s’assurer que même si l’entreprise disparaît, le code, lui, sera toujours disponible, et qu’il y aura toujours quelqu’un qui sera capable de le maintenir. Je pense par exemple à du code qui fait tourner des centrales nucléaires ou qui est envoyé dans l’espace. Et c’est vrai que de ce point de vue-là, l’open source, ça peut être une garantie pour certains de ces acteurs-là de pérennité et de garder la maîtrise de ce qu’ils construisent parce qu’ils ont des usages critiques ou sur le long terme. Ça va les rassurer.

Gonéri : ça me fait penser à l’industrie spatiale où ils avaient ce genre de demande.

Walid : on avait des demandes de support sur 20 ans du logiciel et on expliquait qu’il y a 20 ans, le logiciel n’existait même pas. C’était un peu compliqué pour nous…

Il y a plusieurs niveaux dans l’open core et aussi, ça, j’en parlerai, je pense, dans d’autres épisodes, parce qu’on a parlé pas mal avec des gens qui maintenant ont des modèles open core. Des sociétés qui commencent, partent directement sur un modèle open core. Ça, ça peut se comprendre. Elles ont un peu tiré les conclusions de tout ce qui s’est fait avant. Elles estiment que pour elles, ça semble mieux et aussi pour se financer.

Mais il y a aussi des entreprises qui se cherchent et qui essayent plusieurs modèles avant d’arriver à un modèle open core. Et certaines disent qu’effectivement, c’est avec ce modèle-là qu’elles ont réussi à se financer. On a même discuté avec des entreprises qui sont sur des modèles open core comme ça et qui nous disaient « Quand les clients nous appellent, on ne leur dit même pas que c’est libre. Ils cherchent une solution, on leur dit qu’on a une solution, on ne leur dit même pas que c’est du libre. Tu vois, ça, ça peut se comprendre. C’est-à-dire que ceux qui veulent, ils utilisent la version libre, mais les gens, ils viennent nous voir pour une solution. Nous, on leur donne une solution ».

Il y a pas mal de gens qui sont venus à force à ce modèle et qui sont passés par du support. Ils ont essayé plein de trucs, etc. Et puis, ils en sont arrivés à ce modèle-là. Tu as aussi des sociétés qui vont faire du libre mais dont le seul but des fondateurs c’est de se faire acheter. Et donc la pérennité du projet, ça peut être un peu compliqué aussi.

Gonéri : je pense qu’il y a aussi la question des levées de fonds. Aujourd’hui, si on veut avoir une banque, des fonds d’investissement, des choses comme ça, et si on dit qu’on n’a pas de propriété intellectuelle (IP), qu’on n’a que des communautés et que les clients, ce sont gens qui nous donnent de l’argent parce qu’ils ont envie de nous le donner, cela devient très dur d’avoir des des investissements et de pouvoir faire grossir son entreprise rapidement. J’ai vu plusieurs fois des cas où les entreprises avaient choisi des licences différentes pour pouvoir justement satisfaire ces demandes de la part des VCs. Les CLA, ça apporte une sécurité à ce niveau-là, c’est un peu une façon de dire « OK, dans tous les cas, si les choses tournent mal, on a toujours moyen de prendre une licence propriétaire à un moment donné ». Ce qui peut être une façon d’assurer l’investisseur.

Raphaël : parfois aussi ce n’est pas un modèle qu’on prend tout de suite cet aspect communautaire. Justement, comme je le disais, l’articulation entre parties business, parties communautaires. Moi, j’ai même l’exemple d’un ancien collègues qui était avec nous dans Open Source Center il y a pas mal d’années et qui est parti chez un éditeur open source comme ça, qui fournissait des services et une solution dans le domaine du e-commerce. Au départ, ils n’avaient pas forcément cet aspect communautaire en vue. Lui, il a été embauché, il est venu pour faire ça, pour développer la partie communautaire. Il m’a dit que ça a pris beaucoup de temps, parce que ce n’est pas si simple que ça. C’est un vrai changement de mindset au sein des entreprises, de comprendre qu’on ouvre des choses et qu’on laisse des gens venir modifier la base de code, tout ça avec des règles et tout, et que ça n’avait vraiment pas été si simple et que ça lui avait pris pas mal de temps et d’énergie. C’est vrai qu’encore une fois, on le voit, les modèles dont on parle, ils ne sont pas statiques. Les entreprises vont se chercher au fur et à mesure, mais à chaque fois qu’il y a un changement de modèle, il y a une remise en cause et ce n’est pas anodin.

C’est vrai qu’il peut y avoir des risques autour. Il y a des entreprises qui ont pu trouver des modèles et se stabiliser en le changeant une, deux ou trois fois de modèle. On a rencontré des gens sur le salon qui nous parlaient un peu de ça. Il y en a, ils ont pu se retrouver un peu dans des situations très compliquées parce que soit ils perdent leurs clients, soit ils perdent la communauté. Ce n’est pas garanti.

Gonéri : j’ai l’impression que c’était bien dans les années 2000-2010 ce modèle-là, mais que c’est en perte de vitesse. Le modèle où on essaye de grossir une communauté d’utilisateurs le plus vite possible, de montrer, de se faire connaître, d’investir à coups de capitaux qui viennent d’investisseurs qui parient sur nous. Je pense à OpenStack, des choses comme ça, où ça marchait très bien et maintenant les investisseurs sont un peu revenus sur ce modèle. Ils y croient moins, ou alors ils ont vu que ce n’était pas forcément toujours rentable. Dans les années 2020, c’est un modèle qui ne marche pas trop.

Les changements de licences et projets qui se referment

Walid : on avait noté ensuite qu’il y avait des nouvelles tendances, potentiellement des nouveaux types de licences, des projets qui changent de licence pour essayer de trouver une certaine pérennité que même certains d’ailleurs se refermaient complètement. On avait noté un exemple assez connu qui est SugarCRM, par exemple, qui est assez, je pense, emblématique. Je ne sais pas si un de vous deux veut en dire un mot ou parler d’un autre logiciel ?

Raphaël : une grande tendance que j’ai observée depuis le temps dans les évolutions des business models dans l’open source, ça a été des changements de licences qui sont liés à l’émergence du SaaS et du Cloud. Ce qu’il faut bien comprendre, c’est que les licences open source, les premières, les principales, les plus utilisées, elles ont été créées avant l’apparition du cloud. Donc, elles n’étaient pas prévues ni armées pour cet usage-là. Le seul qui avait vraiment un petit petit peu anticipé le truc lorsque c’est apparu, c’est Richard Stallman. C’est vrai que parfois, on le traite un peu de dingue, de gardien du temple, mais lui, il avait anticipé le truc. Il avait dit « Le Cloud, ça va nous poser un problème par rapport aux licences de la Free Software Foundation. » C’est pour ça qu’il a créé l’Affero GPL, qui est l’AGPL, pour dire « La viralité, elle ne s’arrête pas lorsqu’on passe en mode service fourni sur le cloud». C’est-à-dire que si on fait des modifs sur le code et qu’on vend du service, dans ce cas-là, ces modifs, il faut aussi qu’elles soient contribuées. La copuleft s’applique toujours.
FSF (source : gnu.org)
C’est pour ça qu’il a créé cette licence-là, alors que les autres licences plus open source, plus permissives, elles n’ont pas de dispositif pour garantir le fait qu’une base de code va continuer à évoluer parce que les gens l’utilisent et la modifie. C’est pour ça que ça a donné tout un mouvement avec l’émergence des Cloud Service Providers pour qui, ça e coûte pas grand chose, effectivement, de réutiliser un composant open source et de le fournir en mode SaaS avec beaucoup d’investissements et de la qualité de service, des SLA comme on disait, et ça donne des projets comme MongoDB. C’était un des premiers, en tout cas, un des plus visibles qui a fait ça, qui a changé sa licence et qui a créé une nouvelle licence qui s’appelle la « Server-side Public License », donc la SSPL. Elle dit que si tu fournis du Mongo-as-a-Service, dans ce cas- là, toutes les modifications que tu fais dans Mongo et autour pour l’industrialiser il faut aussi que tu le reverses au pot commun et au projet, donc à nous, Mongo. Ça revient à créer une sorte de « copyleft » mais sur des licences qui étaient pas… Sur des projets qui étaient pas prévus comme ça au départ. Et ça, c’est vraiment pour lutter contre les Amazon et les autres cloud providers.

Après, il y en a d’autres qui l’ont fait. Il y a Elastic aussi qui est passé avec une Elastic License où là ils vont plus loin. Eux interdisent carrément l’« Elastic-as-a-service » c’est-à-dire qu’ils interdisent les « managed services ». Ils disent que les seuls qui pourront vendre vraiment du Elasticsearch ou du Kibana as-a-Service, c’est nous. Ça ne veut pas dire qu’on ne peut pas l’utiliser pour vendre des services, mais des services qui sont bien plus larges, qui ne sont pas focalisés que sur ce service de base qui est le nôtre. C’est comme ça qu’ils essaient de garantir leur pérennité aussi et de se battre un peu. Évidemment, dès qu’ils ont fait ça, il y a les grands fournisseurs de Cloud qui les ont forqués en disant « Nous, on va continuer à utiliser les autres versions, on va les faire évoluer. » C’est sûr que de ce point de vue-là, si ce n’est pas bien expliqué d’abord, ça peut faire peur aux utilisateurs et aux clients.

Du coup c’est plus conforme à l’Open Source Definition puisqu’on est en train de mettre une restriction, ce qui n’est pas dans la définition open source ni logiciel libre. Plus récemment encore, on a vu d’autres types de réactions à ça. Ça, c’est MariaDB. MariaDB, c’était déjà le fork de MySQL par Monty, qui avait créé MariaDB lorsque ça a été racheté par Oracle. Eux, ils ont innové, ils ont créé la Business Source License, la BUSL, à pas confondre avec la BSL qui est la Boost Server License, type BSD.

Dans le cas de MariaDB, d’abord, on peut mettre des restrictions sur un usage commercial de la solution pour dire « Si vous voulez utiliser sans vouloir faire de l’argent directement avec, c’est OK. Si vous commencez à vouloir faire de l’argent, faut qu’on discute. » Et surtout, il y a une notion de promesse dans le temps de ce qu’on met sous cette licence-là va devenir open source à terme. On l’a vu, MySQL c’était sous dual licence commerciale et GPL. Ça reste sous GPL, mais les nouvelles fonctionnalités qui sortent côté MariaDB, elles vont être sur BUSL et c’est au bout de quatre ans qu’ils s’engagent, c’est écrit dans la licence, à libérer le code et à ce que ça repasse sous licence GPL. C’est open source à terme.

Walid : j’ai vu sur un autre projet que je suis qui est récent où c’est pareil, ils disent « On est sur une licence BUSL, mais par contre, dans quatre ans, on sera dans une licence MIT. » Oui, sauf que ça se trouve, toi, dans quatre ans, startup t’existera plus…

Raphaël : là, il y a une histoire d’avoir confiance dans le fait que le projet va continuer à évoluer et à innover, mais dans un premier temps, il a besoin, avec cette nouveauté, de garantir sa pérennité financière, mais ça remet pas forcément en cause l’idée que ce soit open source à terme. En revanche, ça remet en cause la définition à nouveau de l’Open Source Definition.

Walid : ça, c’est une espèce de lame de fond quand même. Il y a quand même beaucoup de projets qui décident de changer de licence. Surtout ces derniers temps, on en a quand même entendu quelques-uns, mais des assez emblématiques, qui décident de changer de licence.

Gonéri : ils cherchent ou on leur demande de changer de business model. C’est vrai. Le board est pas forcément les personnes qu’on imagine. Dans les années 2020, 2010, c’était assez facile, je pense, d’avoir des investissements de VC, si on faisait du logiciel, du moment qu’on avait une grosse base d’utilisateurs, qu’on avait de la notoriété, qu’on arrivait à faire du lock-in sur les utilisateurs, des choses comme ça et à vendre ça aux VC. Aujourd’hui, les VC ont compris que ce n’était pas vrai, qu’on pouvait très bien avoir Amazon qui débarque et qui commence à faire une offre commerciale SaaS de ces mêmes logiciels et en quelques semaines, les utilisateurs commencent à migrer. On perd l’investissement qui avait été fait. Et pour moi, ces changements de licence sont liés à ça. À chaque fois, c’est ces des entreprises qui sont quand même des entreprises américaines qui ont connu des grosses croissances rapides, où il y a eu forcément des injections de capitaux. Il y a un bon exemple qui est arrivé il n’y a pas longtemps, c’est Elasticsearch, qui est devenu OpenSearch. En fait, OpenSearch, c’est le fork agressif d’Amazon qui l’a forké parce que Elasticsearch a changé sa licence pour empêcher qu’Amazon fasse du SaaS avec et vampirise les revenus.

En fait, c’est une situation qui est assez facile pour une entreprise comme AWS de faire du SaaS parce qu’ils ont toute l’infrastructure, ils ont les connaissances, ils ont les vendeurs, ils ont vraiment tout pour pouvoir faire du SaaS. Et derrière, on a les éditeurs de logiciels libres qui ne sont pas armés de la même façon et qui se retrouvent à devoir se défendre par rapport à des acteurs comme ça agressifs. Pour moi, ça montre l’intérêt des fondations quand même, parce qu’une fondation qui a été créée il y a 15 ans, elle sera encore là dans 15 ans. C’est un modèle qui est quand même… Qui stabilise vraiment ce genre de choses.
Tous les logiciels qui sont gérés par des fondations depuis longtemps, à ma connaissance, il n’y a pas eu d’histoires.

Walid : avant, on faisait du modèle communautaire, on n’avait pas d’argent, on cherchait un autre modèle. Maintenant, ils faisaient des modèles open core et ils cherchent un autre modèle. Moi, ce que je retiens un peu de tout ça, c’est que ces écosystèmes sont en évolution permanente. Il y a des changements de modèles. C’est bien, c’est pas bien, j’en sais rien, mais en tout cas, c’est assez passionnant à suivre !

Les licences éthiques

Walid : pour finir cette liste, il y a des petits side-projects dont je voulais quand même qu’on parle parce qu’on peut pas faire comme si ça existait pas. Je sais pas comment s’appelle la personne, mais c’est en regardant une conférence de Capitole de Libre 2022 que j’ai pris conscience de ça. Ce sont les licences qu’on appelle maintenant les licences éthiques. La plupart des gens à qui j’en parle, ils me disent « Mais pourquoi tu veux parler de ces trucs- là ? De toute façon, ce n’est pas libre. » Mais mon avis, c’est que tu peux pas faire comme si, parce que ce n’est pas libre, ça n’a pas d’intérêt d’en parler.
Et donc il y a des licences qui sont pas libres parce qu’elles mettent des restrictions sur l’utilisation. On en avait cité plusieurs, Raphaël. Moi, j’en ai rencontré il n’y a pas très longtemps une qui était une Anticapitalist License. Et toi, tu en as mis d’autres. Est-ce que tu peux juste les lister celles que tu as mis ?

Raphaël : là, on est à la lisière de l’open source. C’est par exemple l’Hippocratic License ou la Do Not Arm License. Elles veulent s’assurer qu’elles vont mettre des conditions sur le comportement que vont avoir les utilisateurs, ou même l’usage qu’ils vont avoir des softwares. Et ça, ça couvre souvent des aspects sociaux liés à l’environnement ou aux droits humains. Par rapport à la définition de l’open source, ça devient problématique et en général, ça sort de l’OSD. Ce n’est plus considéré comme open source, parce que ça met des restrictions.

Ce genre de phénomène-là est arrivé un peu dans la foulée. A un moment donné, c’était à la mode de faire des codes of conduct sur les projets dans les grandes communautés. Ca correspond aussi, pour moi, au renouvellement des contributeurs avec des nouvelles générations. Eux, c’est leur point d’attention, leur centre d’intérêt aujourd’hui. Ils ont une vision du monde sur lequel ils se projettent et l’environnement pour eux sera important, les mouvements sociaux ou ce genre de considérations aussi. Ils vont être regardants par rapport à ça. On le voit dans les entreprises quand on les embauche, mais on le voit aussi dans les communautés et sur les projets.

Pour récupérer ces contributeurs-là potentiels, il faut aussi mettre en avant des valeurs dans lesquelles ils vont se retrouver. Le problème, c’est qu’effectivement, après, ce n’est plus conforme aux définitions qui datent, certes, de la FSF ou de l’OSI. Il y en a qui demandent à ce que ces notions-là soient revisitées ou soit revues. On retrouve ce phénomène et c’est un bon exemple dans tout ce qui est intelligence artificielle. Dans ce domaine-là, on retrouve aussi ces problématiques de licence. Pour commencer, quand on parle de licence d’un modèle, par exemple d’IA générative, il faut voir de quoi on parle. Est-ce qu’on parle du dataset, du modèle, des poids, du code qui est associé, etc. ? Ça peut être assez complexe. Ce sont des choses que je suis en train d’analyser. On retrouve cette notion de « on est ouvert, mais on met des restrictions à l’usage ». On va retrouver ce genre de choses avec ce qu’on appelle les « OpenRAIL licenses » — « rail », ça veut dire « responsable ai », donc licence où ils vont dire « Oui, ce modèle, vous pouvez l’utiliser, mais évidemment, il ne faut pas faire de mal, il faut respecter la loi, etc». Mais parfois, cela peut restreindre un usage médical, ou en lien avec le militaire.

On voit que c’est associé à des idéaux, à une vision des choses. Mais cela peut être aussi « On interdit de faire du hosted services » et donc d’offrir le modèle pour être concurrent d’un Meta ou d’un autre fournisseur de modèles. Avec ces notions d’ethical, il y a un déplacement un peu, et je pense que c’est quand même lié à les évolution de la société : on ne peut pas les ignorer parce que le monde change et les contributeurs, les gens qui contribuent et qui vont utiliser les softs changent aussi. Même si ce n’est pas pur open source, c’est quelque chose qu’il faut considérer, selon moi.

Gonéri : dans 95% des cas, ces licences sont indéfendables devant un jury, déjà.

Walid : moi, ce qui m’intéresse là-dedans, ce n’est pas qu’elles soient défendables ou pas, mais ce qui m’intéresse, c’est de comprendre les vraies motivations des gens qui font ça, sachant qu’ils savent certainement pertinemment que leurs licences ne sont pas libres.

Gonéri : à partir du moment où quelqu’un a du temps libre et qu’il a envie de créer un logiciel et qu’il met sa licence, je ne vois pas en quoi c’est un problème. Ça peut être un shareware, ça peut être une licence propriétaire un peu originale comme ça. Moi, pour moi, ça reste que la personne utilise son temps comme il le souhaite. On n’a pas à juger ce qu’il en fait. Par contre, il ne faut pas lui dire que c’est une licence libre. C’est un mensonge.

Walid : je ne pense pas que les gens disent que c’est une licence libre. Je regarde parce que j’essaye de comprendre le profil des gens qui font ça pour essayer de voir s’il y a des tendances. Ça m’intéresse.

Gonéri : ça me donne envie de faire ma licence.

Tribunes libres

Walid : voilà, on a fait un premier panorama. Il y aura certainement encore énormément de choses à dire. Mais on va garder cela pour des épisodes suivants, soit avec des spécialistes de certains domaines, soit avec des projets qui utilisent ou qui se sont cherchés et qui finissent par utiliser un modèle plutôt qu’un autre. C’est certainement une série qui va continuer pendant assez longtemps, je pense. Je suis très content qu’on ait fait cet épisode tous les trois. Je vous laisse chacun faire un petit mot de la fin avant que l’on conclue.

Raphaël : ça m’a bien fait plaisir de participer à ce podcast. J’étais super content de revoir la tête de Gonéri, parce que ça fait quand même un bail que je ne t’avais pas vu. Tu as les cheveux un peu grisonnants, c’est dire il s’en est passé des choses depuis.

Effectivement, même dans le domaine de l’open source, on a vu pas mal d’évolution sur les business models et sur les licences, avec notamment les tendances qu’on a évoqué, et puis l’évolution des différents modèles communautaires, après Service, après Open Core, etc.

Je pense que les licences et les business models qui sont associés, parce que moi je ne différencie pas les deux, cela reste important à regarder. Parce que c’est vrai qu’autour de moi, des gens qui disent « Moi, la licence, je m’en fous un peu, votre open source c’est pas très important. Moi, du moment que le code, il est sur GitHub, je fork le projet, puis après, je ferai une Merge Request, etc. » Attention, parce qu’il y a quand même des droits et des devoirs et c’est dommage de ne pas comprendre un peu quelles sont ces contraintes-là.

Il y a un autre truc qui me rend heureux après 20, 25 ans dans le domaine : les licences qui ont été créées à l’époque, et les fondations qui se sont créées aussi, sont toujours là. Pour certaines elles sont bien présentes. Elles ont aidé à structurer ce qui est le paysage de l’IT aujourd’hui de manière générale et pas qu’open source. Cela prouve que ce sont des choses qui marchent, qui fonctionnent, qui sont stables. Aujourd’hui, l’open source est devenu mainstream, il est partout. Aujourd’hui, on ne se pose plus la question de « est-ce qu’il faut d’open source ? », c’est plutôt « comment ? ». On a vu aussi dans ces business models, qu’il y a pas mal d’entreprises, fondations, de projets qui se sont cherchés et qui ont pu changer au cours du temps. Ça veut dire que rien n’est figé et que ça peut toujours évoluer. C’est pour cela qu’il faut rester au courant de ce qui se passe et suivre un peu, notamment avec la méthode QSOS, quels sont les points qui peuvent être soumis à changement. Et on l’a vu, quand il y’a besoin, il y a d’autres types de licences qui vont commencer à émerger.

Après, on peut avoir un débat, est-ce que c’est open source ou pas open source ? Peu importe. En tout cas, on voit qu’il y a des nouveaux besoins qui apparaissent et qu’ il y a besoin de les couvrir. C’est un domaine qui reste encore très dynamique, et moi cela me rend heureux parce que ce n’est pas poussiéreux : on n’est pas sur des combats d’arrière-garde. On voit que c’est dans la société avec tout ce qu’on a dit sur les licences éthiques, ce genre de choses-là. Demain, on n’est pas à l’abri que d’autres types de licences émergent et même de nouveaux types de business model apparaissent. C’est ce qui est excitant : même après des dizaines et des dizaines d’années, c’est un domaine qui reste complètement foisonnant avec des communautés, des êtres humains qui veulent co-créer, puisque l’idée, elle est bien là : créer ensemble et aller toujours un peu plus loin dans ce qu’on va être capable d’inventer. Cela ne me fait pas regretter de m’être intéressé aussi profondément à tout ça, parce que c’est très satisfaisant.

Merci beaucoup Walid de m’avoir invité et d’avoir pu m’épancher sur tout ça, en plus de vous retrouver tous les deux. Là, on a l’impression d’être back in time. C’était sympa.

Walid : merci beaucoup. Gonéri ?

Gonéri : pareil. Merci pour l’invitation. Il y a un modèle dont on n’a pas beaucoup parlé, c’est celui qui est porté par des grosses entreprises. Je pense à AngulairJS ou Kubernetes. Je crois que ça s’appelle Borg ou Grok chez Google ou ça s’appelait comme ça. C’est ce modèle où un énorme acteur qui a un besoin produit en interne et il crée ce produit, mais il n’a pas forcément envie de le vendre. Il va juste le rendre libre et le maintenir.

Oui, j’ai trouvé ça intéressant. Le sujet est vaste. J’avais peur qu’on se perde : je pense qu’on s’est un petit peu perdu, malgré tout. Mais, je pense que malgré tout c’était une discussion intéressante. Merci. C’était chouette de voir vos faces.

Conclusion

Walid : moi, je retiens effectivement le côté « c’est un écosystème qui vit et qui n’est pas sclérosé ». Et ça me semble hyper important parce que les générations passent, parce que les modèles évoluent et tout. Et c’est assez passionnant, surtout vu nos âges avancés, d’avoir vu tous ces modèles et de les continuer à les voir. Pour ceux qui sont intéressés, qui veulent en savoir plus, vous pouvez écouter l’épisode avec Benjamin Jean.

Portez-vous bien. N’hésitez pas à me laisser des commentaires. Vous pouvez nous joindre sur Mastodon, vous pouvez laisser des commentaires sur le site WordPress, vous pouvez envoyer un mail ou sur LinkedIn. Faites tourner si ça vous intéresse parce que je suis très curieux d’avoir les retours pour voir un peu les sujets qu’on a survolés et ça me donnera aussi des idées de personnes à interviewer derrière. Même si, pour être honnête, entre le Capitole du Libre et le salon Open Source Experience, je pense qu’il y a de quoi faire à peu près tout 2024.

À bientôt, portez- vous bien et vive le logiciel libre !

Cet épisode a été enregistré le 8 décembre 2023. Transcription réalisée par Walid Nouh

Sources pour aller plus loin

• Pierre-Yves Lapersonne – Licences Open Source : entre guerre de clochers et radicalité
• Podcast The business of Open Source par Emily Omier
• Podcast Radio Devops : changement de licence pour Terraform (à 42 min 32 sec)
• Post de Dan Lorenc sur LinkedIn autour des raisons du changement de licence de Terraform
• Article de Sébastien Dinot sur l’évolution de la gouvernance des projets libres (2020)
• Évolution de la gouvernance des projets libres – Sébastien Dinot – Capitole du libre 2022
• Les livrets bleus du logicel libre : modèles économiques

Licence

Ce podcast est publié sous la double licence Art Libre 1.3 ou ultérieure – CC BY-SA 2.0 ou ultérieure.

Projets Libres

2024-01-14 20:30:48

L’ERP Tryton : histoire et perspectives N. Evrard & C. Krier – B2CK

L’histoire de l’ERP Tryton

Sommaire

• 1 L’histoire de l’ERP Tryton
• 2 Présentation de Nicolas Evrard et Cédric Kreier
• 3 La génèse de Tryton
• 4 Les premières actions à la naissance de Tryton
• 5 L’état d’esprit au moment du fork
• 6 Le panorama des solutions d’ERP en 2008
• 7 La gouvernance du projet Tryton
• 8 La communauté de Tryton
• 9 Les outils pour collaborer
• 10 Les points forts de Tryton
• 11 Le futur de Tryton
• 12 Conclusion de l’interview
• 13 Licence

Walid: bienvenue sur ce nouvel épisode de Projets Libres! Aujourd’hui, c’est un épisode un peu spécial. Les deux invités que j’ai aujourd’hui, ce n’est pas la première fois que je les interview. Il se trouve que la première fois que j’ai participé à une interview… c’était il y a 15 ans, sur une radio qui s’appelait Radio Panic, avec Frédéric Péters, Fabrice Flore-Thébault et Pierre Cros. On avait une émission qui s’appelait Good Morning Stallman, à laquelle on participait. Et un jour, le 14 janvier 2009, nous avons reçu nos invités, Nicolas Evrard et Cédric Krier, pour présenter ce qui était à l’époque, je pense, une des premières interviews de Tryton, un ERP open source dont on va parler aujourd’hui. Donc voilà, 15 ans après, normalement, si vous écoutez cet épisode, il doit sortir le 14 janvier 2024, c’est-à-dire 15 ans pile après la première interview. Petite touche humoristique. Et cette idée d’interview m’est venue parce que ça fait longtemps que je voulais parler de fork et faire une série sur ce que c’était que les forks. J’ai repensé à cette interview et j’ai donc recontacté Nicolas et Cédric. Ils ont gentiment accepté mon invitation. Donc j’espère que vous allez bien tous les deux.

Nicolas: oui, oui, on va bien. J’ai un peu peur qu’on répète ce qu’on a dit il y a 15 ans, mais voilà.

Présentation de Nicolas Evrard et Cédric Kreier

Walid: ça fait 15 ans, ça va. Je pense qu’on ne dira pas la même chose à mon avis. Alors pour les auditrices et les auditeurs, je mettrai dans les notes du podcast le lien vers l’émission de Good Morning Stalman de 2009. Voilà, pour ceux qui sont motivés, ils pourront aller écouter. La première partie, c’est que je vais vous demander à tous les deux de vous présenter, nous expliquer un petit peu quel est votre parcours. Comment vous avez connu le logiciel libre ?

Nicolas: bon, je vais y aller moi, je suis plus vieux. Donc, Nicolas Evrard, je suis un développeur Tryton. Comment j’ai connu le logiciel libre ? C’est à l’université, dans les années 90, donc ça fait quand même un bail là maintenant. On bossait sur des Unix et à la maison, pour faire des TP, le plus simple c’était d’avoir un Linux. Et donc j’ai installé une Red Hat, qui si je me rappelle bien était la 5.2. Et puis voilà, puis finalement j’ai mis une Debian et je me suis retrouvé à bosser sur Zope, un framework de développement web en Python. Puis une chose en amenant une autre, je me suis retrouvé à faire de l’OpenERP, TinyERP même à l’époque ça s’appelait, qui est devenu OpenERP. Et puis j’ai quitté, c’est devenu Odoo. Et j’ai rencontré Cédric peu avant de quitter, puisque pour la petite histoire je faisais les interviews des gens qui arrivaient chez Odoo et j’ai interviewé Cédric. Et il m’a bien plu parce qu’il lisait ses emails par Mutt. Ce qui est complètement stupide, mais bon, voilà. C’était une façon de trier les gens quand même.

Cédric: ouais, donc, Cédric, j’ai une formation d’ingénieur. J’ai commencé à connaître le logiciel libre, je pense, pendant aussi mes études. J’ai dû installer une Mandrake à l’époque (NDRL : pour en savoir plus voir l’interview de Gaël Duval), que j’avais eue dans un magazine, c’était des CDs. J’ai un peu laissé de côté. J’ai commencé mon parcours professionnel comme développeur dans une société qui faisait un logiciel pour des banques, en Cobol. Je suis resté quelques années là, et puis j’ai switché, et j’ai travaillé dans une boîte qui était dans la sécurité, qui faisait des network appliances. Et après ça, j’ai été engagé chez Tiny, pour travailler sur TinyERP. Et puis, quelques années après… on a démarré Tryton et maintenant on travaille tous les deux chez B2CK, une société qu’on a créée pour le support du logiciel.

Walid: je me rappelle très bien de la Red Hat 5.1 ou 5.2, on doit avoir à peu près le même âge. Vous êtes basé en Belgique, vous êtes basé où ?

Cédric: on est à Liège.

Nicolas: tous les deux liégeois.

Walid: alors maintenant que vous êtes présentés, commençons par introduire Tryton. La plupart des gens qui sont là, je ne suis pas sûr qu’ils connaissent Tryton. Donc déjà, c’est un ERP, un logiciel Enterprise Resource Planning. C’est un logiciel dont le but est de gérer un peu l’ensemble des process d’une société. Est-ce que vous pouvez nous présenter Tryton ?

Cédric: oui, en fait, on a même plutôt tendance à dire que c’est plutôt un progiciel qu’un ERP. C’est un peu plus large que vraiment les features (NDLR : fonctionnalités) d’un ERP. C’est vraiment un peu au-delà.

Donc, Tryton, c’est un logiciel libre, qu’on a développé, qui vient initialement d’un fork de TinyERP. On en parlera un peu plus tard. Ses caractéristiques, c’est qu’il est écrit en Python, qu’il se base sur une base de données Postgres, qu’il est sur une architecture trois tiers. Donc on a un client, un client léger, un serveur qui est le serveur applicatif, donc il y a la connaissance métier, les process métiers, etc. Et puis la base de données pour le stockage.
Cédric Krier

On a deux clients, en fait, deux clients légers. Un client dans le navigateur, écrit en JavaScript. et un client ou bureau écrit avec GTK, compilé en application native. Après, les fonctionnalités qu’on a de base, c’est les grosses fonctionnalités qu’on attend d’un ERP : achat, vente, gestion de stock, comptabilité, facturation, production…

Nicolas: vente en ligne plus ou moins, enfin il y a moyen de construire. C’est aussi ça qui est dans la philosophie de Tryton, c’est qu’on fournit les briques pour aller plus loin. Tout n’est pas intégré. J’imagine que les gens connaissent mieux Odoo. Et Odoo, ça vient avec son e-commerce dedans, et avec Tryton, c’est plutôt construit sur le côté. On a d’ailleurs construit quelques-uns.

Cédric: une des idées d’architecture du logiciel, c’est d’être modulaire, pouvoir activer les modules dont on a besoin, et créer des modules si on veut en plus. Et en plus d’être interopérable, donc on peut l’utiliser, d’être facile à connecter à d’autres applications, à d’autres solutions. Et donc entre autres pour l’e-commerce, on a un module pour se connecter à Shopify, un module pour Vuestorefront. Et on a déjà développé plusieurs fois des petits connecteurs pour d’autres e-commerces. On a aussi des solutions de connexion avec des solutions de paiement en ligne. On gère automatiquement : on a Stripe et Braintree, filiale de Paypal. Vraiment, l’idée c’est l’interopérabilité.

Nicolas: j’ajouterais en plus que le projet, cette vision d’interopérabilité a permis qu’il y ait d’autres projets qui sont construits en parallèle à Tryton. Entre autres, il y en a un logiciel libre qui s’appelle GNU Health, qui est donc un logiciel de gestion d’hôpitaux et de dossiers patients. Il se déploie, alors il paraît, en Espagne, mais essentiellement dans les pays en voie de développement. On en a vu au Laos, il y en a en Afrique, on sait qu’il y en a aussi en Argentine, en Jamaïque, à Cuba, je pense. Mais je pense qu’il y a des cliniques en Espagne qui l’utilisent. Et il y a aussi un logiciel de gestion d’assurance qui s’appelle Coog, édité par des clients à nous, qui fait de la gestion d’assurance et qui se base sur Tryton. Et eux, ils ont pris essentiellement la compta, mais rien du tout de la vente, du stock, etc. Et ils ont construit des centaines de modules qui gèrent des assurances.

Cédric: autre exemple de verticalisation, il y a aussi GnuVet, une version pour la gestion de vétérinaires.

Walid: vous avez fait des petits, là !

Nicolas: oui, oui, oui.

La génèse de Tryton

Walid: alors, justement, commençons par la genèse de Tryton. Pour parler de la genèse de Tryton, il faut donc parler de l’époque où vous étiez chez OpenERP. Moi, ce que j’aimerais comprendre, c’est quel est le cheminement qui vous a amené à vouloir créer Tryton, en fait ?

Cédric: je pense qu’on va me refaire une petite précision. En réalité, j’ai démarré le projet avec un autre associé, Bertrand, qui travaille aussi chez Tiny, et Nicolas a rejoint par après. Donc, vraiment la genèse du projet Tryton, ce serait plutôt de mon côté. Après, Nicolas a eu un peu la même démarche, mais de manière un peu différente. Donc, Tiny, ça s’appelait Tiny à l’époque, la boîte, et qui éditait Tiny ERP, un logiciel gestion d’entreprise aussi open source.

En tant qu’employé dans la structure, qui était une petite structure, je crois qu’on était moins de 10 à l’époque, avec mon collègue Bertrand, on était, après une année et demie, deux ans de travail dans la société et d’expérience, pas très contents en réalité du service au client qui était fourni. On était toujours un peu pas à l’aise par rapport aux promesses faites au client et par rapport à ce que la solution offrait et ce qu’il fallait développer, réparer en cours de route, etc. Donc, c’était assez frustrant en tant qu’employé de ne pas avoir la possibilité de fournir un travail considéré valorisant. Du coup… on s’est dit qu’on pouvait faire mieux. Et de là, assez rapidement, je pense qu’on s’est décidé, en deux ou trois mois, on s’est dit on va se lancer. Et donc, on a démissionné et puis on a démarré.
Cédric Krier

On n’a pas directement repris le code qui était hébergé un subversion (NDLR : autrement appelé SVN), mais en fait, c’était un subversion qui était privée. Donc, en tant qu’employé, on y avait accès, mais en n’étant plus employé, on n’était plus censé y avoir accès. Donc, on n’a pas repris, on n’a pas su reprendre l’historique, parce qu’à l’époque, le logiciel était juste publié en release, de manière un peu irrégulière. Et donc on est reparti d’une archive, mais on ne l’a pas intégrée telle quelle directement dans notre dépôt. On a repris des bouts, bloc par bloc, parfois en réécrivant des parties, et on a reconstruit en piochant dans le code existant. Ce qui nous a permis, dès le début, de corriger des erreurs qu’on connaissait de l’architecture initiale, d’essayer d’éviter de les reprendre pour notre départ. Avec le temps, on s’est aperçu qu’on avait laissé passer des problèmes à cette époque-là qu’on ne connaissait pas. Et de là, on a commencé à reconstruire. Ça, c’était vraiment pour le cœur, le cœur avec le client léger.

Walid: donc, en fait, la décision de faire votre propre boîte et votre propre ERP, elle n’est pas liée à des problématiques techniques, elle est liée à des problématiques de relations clients, c’est bien ça ? Ou il y en a aussi des problématiques techniques, en fait ?

Cédric: quand on était employé, on avait identifié des problèmes techniques qu’on a essayé de faire corriger et de rectifier en interne. Mais on n’avait pas la possibilité, on ne nous a pas donné les moyens de pouvoir le faire. À l’époque, je sais bien que la société n’avait pas beaucoup de ressources non plus, donc c’était difficile, il fallait balancer entre le client et ce genre de développements. Après, on ne connaissait pas tout de la société, on n’était pas dans les secrets du management à l’époque. Nous, on avait l’impression qu’on pouvait faire mieux. Mais ce n’était pas possible de le faire en interne, enfin dans la structure. La structure était plus à courir après des clients, à essayer de rentrer un maximum de clients que de rectifier les problèmes de genèse du projet.

Nicolas: pour la petite histoire, en fait, quand je suis parti et que j’ai fait engager Cédric à Fabien (NDLR Pinkears, fondateur de TinyERP) à l’époque, je suis parti avec quelqu’un que j’ai rencontré chez Tiny, qui s’appelle Gaëtan de Menten, et on est partis tous les deux avec, exactement ça c’est très drôle, les mêmes constats et les mêmes envies de changer techniquement les choses et d’avoir une autre relation au code et à la façon de faire les choses de façon générale. Bon, nous ça s’est planté beaucoup plus, Tryton a réussi à s’en venir, nous ça n’a pas du tout marché. Parce que nous, on a réécrit dès le début from scratch, on n’a pas voulu du tout être dans le fork. En fait, on a voulu partir de zéro et c’est le plus difficile.

Les premières actions à la naissance de Tryton

Walid: il y a naissance de Tryton. Si je comprends bien, les premières actions, ces premières actions, c’est reprendre le code, faire du nettoyage, etc. Vous publiez une première version quand ?

Cédric: j’ai regardé le premier commit qu’on a fait, le 19 décembre 2007. Et la première release, on l’a faite le 17 novembre 2008, donc quasiment un an. Je pense que c’est à peu près ce qu’on s’était donné comme objectif : un an pour avoir une solution utilisable, démontrable, et pour commencer à essayer d’attirer des clients. On a eu un client très tôt, qui nous a suivis dès le démarrage, ce qui nous a permis de survivre pendant cette année-là. À la première release, assez rapidement, il y a une petite communauté qui s’est créée, principalement des gens qui venaient de TinyERP et qui étaient un peu déçus aussi par la qualité et par la gestion du projet. Je pense qu’on a surtout capitalisé sur le fait que nous, on a directement publié le dépôt. Notre dépôt était public, ce qui n’était toujours pas, je pense, le cas de TinyERP à l’époque. Avec notre première release, on avait une discussion ouverte et on était prêts à discuter avec les contributeurs éventuels, ce qui n’était absolument pas le cas chez Tiny. Il y avait bien un forum, mais en fait, c’était plutôt un forum d’utilisateurs qui s’entraidaient, et les employés de la société n’avaient pas d’autorisation d’aller aider sur ce forum, ça ne passait que par une relation commerciale.

L’état d’esprit au moment du fork

Walid: dans quel état d’esprit vous étiez quand vous avez fait le fork ? Je m’explique, j’ai participé à un fork d’un projet libre, et pendant un an c’était la grosse excitation, parce qu’il y avait des possibilités qui s’ouvraient et tout. Alors, dans quel état d’esprit vous étiez à ce moment-là ?

Cédric: assez enthousiastes, on n’avait pas de passif. On n’avait pas à prendre en considération un passé, maintenir une compatibilité avec quelque chose d’existant, etc.

Donc c’est vrai qu’on pouvait casser tout et décider de changer des grosses choses, de faire des gros changements structurels sans trop de contraintes. Et donc c’est vrai que pendant cette année-là, c’était assez gai de développer et de travailler sur le projet. Mais une fois qu’on a fait une première release, on s’est imposé des règles.
Cédric Krier

Et du coup, ces règles ont un peu cadenassé : il y a eu plus de challenges pour arriver à faire ce qu’on voulait dans les contraintes qu’on s’est données. Et un petit peu moins de liberté, mais dans un sens…

Walid: c’était quoi ces règles ?

Cédric: un utilisateur doit pouvoir passer d’une version à l’autre sans avoir besoin de services externes. Ce qui permet de ne pas avoir de vendor lock-in, ce qui est souvent reproché sur certains projets : à partir du moment où ils utilisent leurs solutions libres, on est obligé de passer par leur service pour maintenir, parce qu’il y a personne d’autre qui ne sait le faire. C’est ce que fait Odoo pour l’instant. Ça, c’était une première contrainte. Essayer d’avoir une backward compatibility (NDLR : compatiblité descendante) des API le plus possible. Bien qu’on ait décidé à plusieurs reprises de casser cela, on a fait la publicité de ces changements, expliqué et mis tout le monde au courant.

Le panorama des solutions d’ERP en 2008

Walid: je voulais vous demander quel était le panorama en fin 2008 des ERP libres et open source. Il y avait quoi ? Il y avait Dolibarr, TinyERP, il y avait quoi d’autre ?

Nicolas: Dolibarr, TinyERP, ERP5. C’était un ERP fait en Python, si je me rappelle bien, par un Lillois ou quelque chose comme ça. Les concepts étaient un peu intéressants, d’ailleurs. Je me rappelle, il y a eu un bouquin sur le design des logiciels, et il y a un chapitre dessus. Ça existe toujours d’ailleurs. Ah bah oui, il y a eu un commit il y a cinq jours. Voilà.

Cédric: GnuCash. Je ne sais pas si ça peut se monter comme ERP, mais il y a GnuCash qui existe.

Nicolas: un truc en Java, comme Compiere.

Cédric: … Compiere.

Walid: il n’y avait pas grand-chose.

Nicolas: non. Au final, il n’y a toujours pas grand-chose.

Cédric: ERPnext.

Nicolas: ERPnext en effet.

Cédric: oui. Il y a aussi… Alexor.

Walid: il y avait de la place pour un nouvel ERP libre open source.

Cédric: la première concurrence, je pense, c’est avec Excel. Dans beaucoup d’entreprises, ils travaillent avec Excel. Donc, il faut remplacer Excel, on remplace souvent Excel. Ou alors après, il y a vraiment les logiciels propriétaires, Navision, SAP. C’est plutôt la concurrence que les autres logiciels open source.

Walid: vous publiez la première version, vous avez une communauté qui se crée. La question que je me pose, c’est : est-ce que vous gardez des contacts à l’époque chez Tiny ? Est-ce que vous savez s’ils regardent un peu ce que vous faites ? Est-ce que vous, vous regardez ce qu’ils font aussi ? Est-ce qu’il y a des échanges un peu dans un sens ou dans les deux ? Comment ça se passe ?

Cédric:

le début était un peu chaotique. Parce qu’on a eu une première affaire avec Fabien, donc Fabien Pinckaers, le directeur de l’entreprise, qui, assez rapidement, quand on a publié du code, etc., nous a accusés de le voler. Alors qu’on était repartis sur la version publique, ce qui était sous licence GPL2. De ce point de vue-là, on n’a en fait rien à se reprocher. D’ailleurs, après nous avoir accusés de manière publique, on a juste écrit une première lettre avec l’aide d’un avocat pour lui dire qu’il se calme un peu sur les accusations. Et d’ailleurs ça n’a jamais été plus loin.
Cédric Krier

Donc je pense que c’était plus une crainte d’avoir un concurrent qui débarque qu’autre chose.

Walid: c’était pour dire bienvenue.

Cédric: si on veut.

Ensuite, par la suite, il y a eu du code qui a été repris. Je pense principalement à une petite librairie qu’on avait développée, qu’on avait appelée VAT Number, qui est pour valider les numéros de TVA d’un peu partout, de plein de pays. Et donc, on collectait des formats et on ajoutait des validateurs, etc. Et on a retrouvé notre code repris tel quel, en copier-coller, à l’intérieur des modules d’Odoo. Ce qui ne nous avait pas trop plu, c’était le manque… Ils n’avaient pas gardé l’attribution de l’auteur, le copyright. Au niveau licence, c’était bon parce que ça restait GPL, si je me rappelle bien.
Cédric Krier

On a dû un peu leur rappeler qu’il fallait mettre… Ils ont mis le nom en commentaire quelque part dans le fichier. Ce n’est pas tout à fait la bonne pratique, mais on n’a pas été plus loin que de leur rappeler ça. Donc, il y a eu ce genre d’échanges de code qui sont partis dans cette direction-là. Ce qu’on a même trouvé un peu regrettable, c’est que nous, on a tendance à développer des librairies pour des fonctionnalités générales qui ne sont pas directement liées à Tryton ou à l’ERP, de manière à ce qu’elles puissent être utilisables par d’autres. Et on a vu qu’ils ne réutilisaient pas notre librairie, mais la bundle de manière un peu cachée. On trouvait que c’était un peu dommage de ne pas avoir cet esprit où justement on aurait pu contribuer ensemble sur un projet… un bout de code, un bout de projet

Nicolas: oui, par exemple. Sensiblement la même idée, c’est quand on a fait notre client. Parce qu’il y a le client JavaScript, il y a le client GTK, donc desktop. Pour faire les tests, on a fait aussi un client en ligne de commande, enfin, plus ou moins. Au final, ce client, il a aussi eu une existence. Enfin, l’idée a été reprise. Ils auraient évidemment pas pu reprendre exactement la même chose. Mais il y a eu de l’inspiration, je pense, des deux projets de l’un à l’autre. On est passés à l’Active Record (NDLR : un design pattern logiciel, un patron de conception). Ils ont suivi un an ou deux plus tard. Et nous, on regarde ce qu’ils font et ça nous inspire de temps en temps.

Cédric: nous, de manière claire et publique. Il nous arrive de voir des commits passer ou des changements chez Odoo et de dire : « ah bah tiens, c’est peut-être intéressant, c’est une idée intéressante ». Et du coup, on ouvre un bug dans notre bug tracker avec le lien vers le commit en disant : « tiens, ils font ça comme ça, ça pourrait être applicable pour nous et ça pourrait être intéressant ». Dans l’autre sens, il y a, je pense, clairement la volonté de ne pas parler du projet Tryton. Du coup, on n’a pas vraiment de preuves, mais il y a parfois des coïncidences, des choses. On découvre qu’on a une idée, on développe quelque chose, et on retrouve l’idée un peu similaire qui est développée quelques mois après. Alors, c’est possible que ce soit des coïncidences ou pas. C’est difficile à savoir. Mais de leur côté, je pense clairement que le mot d’ordre c’est d’ignorer et de faire comme si le projet Tryton n’existait pas.

Walid: donc le projet est en licence GPL V3+. Quand vous avez récupéré le code au départ, il était en licence quoi ? GPL2 ? Il était déjà en licence ?

Cédric: en GPL2. On l’a upgradé à la GPL3. C’était à l’époque où la GPL3 venait de sortir. Il y avait tout un terme autour de la Tivoization. On s’est dit que c’était probablement une bonne idée d’upgrader.

La gouvernance du projet Tryton

Walid: quelque chose d’autre qui m’intéresse beaucoup. J’ai écouté d’autres podcasts que je mettrai en description dans lesquels vous parlez un peu du deuxième sujet qui m’intéresse : la gouvernance que vous avez mise en place. Il y a cette volonté, dès le départ, de faire en sorte que le code reste libre. J’ai trouvé ça vraiment très intéressant, surtout dans une période un peu troublée comme maintenant où les projets ont tendance à changer de licence pour passer sur des licences plus ou moins libres. Et puis entre-temps, vous avez aussi créé une fondation. Est-ce que vous pouvez un peu m’expliquer le cheminement qui a conduit à la gouvernance que vous avez maintenant ? Est-ce que c’était ce que vous vouliez faire au départ ? Et puis maintenant, quelle est la gouvernance ? Comment le projet est-il géré maintenant ?

Cédric: je pense qu’au démarrage du projet, Bertrand et moi, nous n’avions absolument aucune idée de comment le projet allait … au niveau communautaire… de comment on allait gérer. On n’avait absolument pas de vision. On s’était dit : on va faire un projet open source comme les autres projets open source.

Nicolas: au niveau de la licence, il y a le fait que tout bêtement… OpenERP ou Odoo, je ne sais plus, Tiny, je pense. Tiny a toujours le copyright sur une partie du code, et donc on ne peut pas le changer. On voulait le changer, il faudrait qu’on demande, et je ne pense pas qu’ils seraient d’accord.

Mais sinon, notre vision à ce niveau-là, ça a toujours été d’attribuer le code aux personnes qui l’ont écrit, dans le sens où plus de personnes ont le copyright, plus il est difficile de changer ensuite. Et donc, ça oblige le code à rester open source. C’est aussi pour ça qu’il n’y a pas de CLA, Contributor License Agreement, parce qu’un CLA, au final, ça donne l’autorisation à une boîte de faire ce qu’elle veut avec son code.
Nicolas Evrard

Je ne sais pas si on en a vraiment discuté, mais c’est quelque chose sur lequel on était d’accord quasi naturellement.

Cédric: oui, nous, dès le début, on s’est attribué à chacun le copyright du code qu’il a écrit. Ça ne sert à rien de faire autrement. Et on ne voit pas d’intérêt à le faire autrement. Qu’est-ce que ça nous apporterait, à part des contraintes juridiques ? Il faudrait un CLA, il faudrait en avoir un, le faire signer, le conserver, etc. Et pour quel intérêt ? Si on me demande de signer un CLA, c’est parce qu’on veut changer la licence par après.

Walid: c’est parce que l’entreprise garde le droit de faire ce qu’elle veut avec le logiciel auquel une communauté de gens a potentiellement contribué, ce qui est assez sournois finalement quand on y pense.

Cédric: oui, oui. Et alors, je dois dire aussi, je pense qu’il y a un point à rajouter.

Au début du projet, la communauté s’est principalement construite avec des gens venant du monde de Tiny, d’OpenERP et Odoo, qui ont eu une forte tendance à changer de licence tous les 3-4 ans. Ils sont passés d’une GPL à, je pense, une AGPL, puis une LGPL, et maintenant ils ont un mix avec une partie propriétaire et une partie qui reste LGPL, mais ils se réservent le droit de basculer du code d’un côté à l’autre. Tous ces changements de licence ont créé une crainte chez certains utilisateurs ou participants à cette communauté, qui se sont redirigés vers nous. Et du coup, c’était un critère important pour eux : s’assurer que les règles n’allaient pas changer en cours de route.
Cédric Kreir

Nous, dès le départ, on disait que l’idée était d’avoir B2CK comme une entreprise qui contribue au projet, mais qui reste une entreprise comme les autres. De ne pas avoir un avantage ou la possibilité de dire, à un moment donné, « la communauté est assez grande, maintenant hop on ferme, on garde pour nous et on vous fait payer une licence pour la suite ». C’était une crainte que beaucoup avaient, et du coup notre mode de travail… la manière dont on gérait déjà était rassurant. Du coup, on a pu construire cette idée que plus on partage le copyright, plus c’est protégé, et plus la licence est figée. C’est un peu ce qui s’est passé avec le kernel Linux (NDLR : noyau Linux), qui d’ailleurs n’a pas pu passer à la GPL3 parce qu’il n’est pas possible d’avoir l’accord de tous les contributeurs. À l’époque, la clause initiale n’avait pas mis « ou plus tard ». C’est ça, donc c’est une GPL2 stricte.

Nicolas: ça nous permet d’embrayer sur la fondation, parce que la fondation vient d’une de ces craintes en réalité.

À ce moment-là, on avait B2CK, et on est allés rencontrer des gens en Espagne qui étaient utilisateurs d’OpenERP et contributeurs de certains modules, etc. Une de leurs craintes, c’était en effet que B2CK copie ce qu’avait fait Tiny et prenne le contrôle sur la chose. Et une façon de les rassurer, c’était de créer la fondation. La fondation, c’est un mécanisme juridique en Belgique qui permet de créer une sorte de société avec un but particulier, qui doit être non commercial, si je me rappelle bien.
Nicolas Evrard

Cédric: c’est sécuriser un bien.

On a dû donner à la fondation un bien, qui est en fait le nom Tryton, simplement. La fondation a pour objet de le protéger. Donc, on a défini des règles, mais ce sont des règles immuables. On ne peut plus modifier l’objet de la fondation, et ça, c’est une garantie qui va au-delà de simplement s’engager. L’État nous oblige à respecter cette situation.
Cédric Krier

Nicolas: si d’aventure, le conseil d’administration de la fondation ne respecte pas les règles, par exemple en fermant le code source, n’importe qui pourrait attaquer ce conseil d’administration devant les tribunaux belges en l’occurence, pour faire respecter le caractère open source.

Walid: et donc là, vous décidez de créer la fondation. Là, on est en quelle année ?

Cédric: en 2012.

Nicolas: ouais, novembre 2012. On peut voir ça comme une façon de rassurer les gens, parce qu’au final, pour nous, on ne voyait pas le problème.

Cédric: on avait sécurisé en quelque sorte le code source, mais l’autre risque, c’était le nom. La marque Tryton et le nom de domaine étaient la propriété de B2CK. On les avait achetés avec B2CK, parce qu’il fallait bien sortir les fonds à un moment donné. Et du coup un des risques était qu’on prenne le contrôle du domaine et qu’on pointe vers autre chose. Tout le travail de construction de la marque soit volé en quelque sorte. C’était une manière de protéger le projet.

On a cherché la bonne forme juridique. Ce n’est pas évident parce que les juristes ne font pas ça souvent et ne comprennent pas toujours la demande, la difficulté. Mais aussi ce qui est souvent fait, ce sont des organisations type ASBL (NDLR : association sans but lucratif), mais ça ne protège pas de la même manière. Il y a toujours moyen de prendre le contrôle d’une ASBL et de changer son objet social.
Cédric Krier

Donc, ça a pris du temps entre chercher, écrire des statuts qui nous conviennent et qui protégeaient le projet. De trouver un mécanisme qui permet un bon équilibre entre ceux qui vont avoir la responsabilité de la fondation et le reste de la communauté qui va avoir une espèce d’équilibre de pouvoir. Voilà donc ça ça a été des choses à inventer et à imaginer.

Nicolas: dans notre fondation, on a le principe des supporters, parce qu’une fondation ne peut pas avoir de membres. Le terme « membre » ne pouvait pas apparaître dans les statuts, donc on a utilisé le terme « supporter ». Les gens deviennent des supporters de Tryton et constituent une assemblée des supporters. Cette assemblée des supporters peut, à une majorité de 2/3 ou 50%, – je ne sais plus, de toute façon ça n’arrive jamais – décider changer complètement le board de la fondation. Il est élu pour 5 ans.

Walid: ce board, il est composé de qui ?

Cédric: à la création, on était trois fondateurs, donc les trois propriétaires de B2CK. On est fondateurs parce que c’est nous qui apportons le bien. Donc on a une qualité juridique spéciale. On a choisi quatre autres membres. Donc, on s’est mis tous les trois dans le nombre fondateur, dans le conseil d’administration, et on a inclus quatre autres membres. Alors, on a essayé d’avoir une diversité géographique.

Nicolas: il y avait Udo d’Allemagne, Albert d’Espagne. Sharon d’Inde, et le quatrième,

Cédric: Sebastien,

Nicolas: ah bah si, voilà, eébastian, donc d’Argentie.

Cédric: d’Argentie. Donc on a essayé d’avoir une université géographique, aussi de pays, évidemment, de langues, enfin de cultures, enfin d’essayer de représenter la diversité qu’il y a dans la communauté dans le bord. Ensuite, le bord se renouvelle tous les cinq ans par cooptation. On lance un appel à candidats, en fait, pour qu’ils se présentent. C’est comme ça que le bord décide de fonctionner. Ça, ce n’est pas vraiment dans les statuts. On va devoir aider les candidats et le bord précédent choisit les membres suivants. Ça peut être les mêmes. Il n’y a pas de limite sur le nombre de mandats que personne peut faire. Il est déjà assez difficile de trouver des gens. C’est en limite, on risque de…

La communauté de Tryton

Walid: donc, il y a une fondation avec des membres qui sont représentatifs de la communauté. Il y a la communauté. Donc, je suppose que dans cette communauté, il y a des utilisateurs. Il y a aussi potentiellement des sociétés de services, des gens qui… quelle est la diversité de la communauté autour de Tryton ?

Cédric: si tu parles juste des supporters, là, on en… être supporters c’est juste demander, il faut juste demander, donc il y a un peu tout, il y a des utilisateurs, il y a des développeurs, il y a des sociétés de services qui fournissent du service sur Tryton. Donc on a vraiment tout type d’entités. Après, si on veut parler de la communauté plus générale, plus large, la partie vraiment vivante qui participe, etc., c’est principalement quand même des développeurs qui sont… souvent des développeurs qui sont dans une société qui fournit du service sur Tryton.

Nicolas: la communauté se rassemble essentiellement autour du forum et on voit qu’il y a quand même une bonne petite partie de développeurs allemands, pas mal d’hispanophones aussi qui font du GNU Health ou du Tryton.

Cédric: oui, au final,

on n’a pas une très claire vision de qui utilise Tryton, sur le forum, on a des pseudos, mais on ne sait pas toujours ce qu’il y a derrière. On a des événements en live, et donc on peut mettre des visages sur des pseudos, mais c’est toujours une partie. En fait, on est assez dans le flou de savoir qui utilise Tryton, et qui est vraiment dans la communauté.
Nicolas Evrard

Walid: vous avez des clients que vous avez le droit de citer, juste pour donner un exemple, qui peut utiliser Tryton par exemple ?

Nicolas: j’ai cité Coopengo, oui, mais ce sont des gens qui font la verticalisation dont je parlais, Tryton, les assurances, c’est un de nos principaux clients.

Cédric: je crois qu’on peut parler de Jurassic Fruit.

Nicolas: on a Jurassic Fruit,

Cédric: c’est un site. C’est un site de vente de fruits en ligne.

Nicolas: on a quelques… Ah oui, clients prestigieux, Saint Luc.

Cédric: c’est les leaders des boules de billard. Je crois qu’ils font 80% des boules de billard du monde. Et ils l’utilisent pour presque… ils sont en train de passer à presque tout leur processus.

Cédric: oui, ils ont commencé par la gestion d’entrepôt et puis progressivement, ils rajoutent des fonctionnalités, les achats, les ventes. Ils complètent, ils remplacent un ERP fait maison, historique, par Tryton.

Nicolas: on sait que dans les gens qui contribuent à Tryton, il y a une société qui fait je ne sais plus combien de pourcents des fraises qui sont faites en Espagne. Voilà. Donc à mon avis, c’est des gens qu’on ne connaît pas, mais il y en a certains qui ont bonne part de marché dans leur secteur. Et ce qui se passe, c’est que comme on n’a pas une entreprise têtière qui dirige le marketing, qui dirige le logiciel, au final, on ne sait pas. On ne sait pas ce qui se passe. Enfin, si, on le sait évidemment, parce que comme on est quand même des gens qui contribuent beaucoup, les gens nous parlent, mais au final, il y a quand même des gens qui l’utilisent sans jamais rien nous dire.

Cédric: et B2CK, si on revient sur B2CK, on a principalement comme client d’autres sociétés d’IT qui ont des clients. Donc, on est souvent plutôt en deuxième niveau. On a certains clients en premier niveau direct, mais on a principalement des clients en deuxième niveau. Donc, du coup, on peut un peu deviner les clients qu’il y a derrière. Oui, et il y a aussi un point en plus. Je pense qu’il y a aussi une partie de rebranding. Donc, il y a des sociétés de service qui vont installer Tryton, mais sans dire que c’est Tryton. Peut-être juste rebrandant le logo, ou en faisant un logo à leur sauce, et en mettant un petit thème sur sur le client et hop, ils en font leur solution. Dans un sens, ça nous va. Ils ont tout à fait le droit de le faire. C’est un peu regrettable pour la notoriété du projet.

Les outils pour collaborer

Walid: vous avez parlé d’un forum. Quels sont les outils qui sont utilisés pour collaborer ?

Nicolas: alors le forum, c’est Discourse. Plus en plus de logiciels libres sont en train d’y passer.

Cédric: on a un forum IRC. Plutôt calme, parce que sur Discourse c’est quand même beaucoup plus agréable et plus asynchrone, donc ça permet beaucoup.

Nicolas: il y avait des mailing lists, mais on les a tuées pour Discourse.

Cédric: on n’a pas voulu multiplier les canaux, disperser, sinon chacun reste dans son silo, dans son canal préféré. Donc on a vraiment tout centralisé sur Discourse.

Nicolas: et puis ça fait barbu, les mailing lists.

Walid: IRC aussi.

Cédric: et d’ailleurs, maintenant que Discourse a… On a activé aussi les chats sur Discourse. C’est vrai qu’il y a un côté un peu redondant. L’intérêt de l’IRC était pour les petits messages rapides, quelqu’un qui a un petit problème, il peut poser sa question et avoir une réponse rapidement. En fait, le chat de Discourse pourrait remplacer IRC dans un sens.

Walid: et pour les forges ?

Cédric: on a notre dépôt sur Mercurial depuis le début.

Nicolas: et c’était self-hosté (NDRL : auto-hébergé)

Cédric: oui, on l’a hosté sur nos serveurs avec juste le service web de base qu’il y a dans Mercurial. Et on utilisait Rietvelt comme outil de Code Review (NDLR : revue de code). C’était l’outil que Guido van Rossum, l’inventeur de Python, avait écrit quand il travaillait chez Google pour le review du projet Python, que le projet Python a arrêté d’utiliser depuis quelques années. Le projet n’est plus trop maintenu, je pense qu’on devait être les derniers encore à l’utiliser. Du coup, ça nous a poussé à chercher une solution alternative. Et là, depuis un an, on est passé sur une forge qui s’appelle Heptapod, qui est en fait un fork de GitLab avec le support Mercurial. C’est un fork qui se veut friendly (NDLR : amical), donc en fait, ils viennent juste rajouter des composants pour supporter Mercurial à la place de Git. Et on est hosté sur leur plateforme. Ils ont une plateforme de… Donc c’est foss.heptapod.net. Donc là, on a notre projet Tryton qu’on a migré maintenant en un monorepo. Donc avant, on avait un dépôt par projet et module. Pour la migration, pour le passage à la forge, on a fait un monorepo. Les modifications qu’on fait ont assez souvent des implications dans plusieurs modules, voire même dans tous les modules. C’est beaucoup plus pratique d’avoir une seule Merge Request globale qui contient tout l’historique du changement que d’avoir plein de petits dépôts avec des Merge Requests qui doivent être faites en même temps. En plus, ça permet aussi d’avoir une CI (NDLR : intégration continue) qui est beaucoup plus stable puisqu’on teste toujours un tout cohérent, une version, enfin un snapshot de l’ensemble du logiciel.

Nicolas: c’est la fondation qui a sponsorisé le switch.

Les points forts de Tryton

Walid: où est-ce qu’il en est le projet aujourd’hui et quels sont les points forts de Tryton en fait ? Pourquoi Tryton est bien adapté aujourd’hui maintenant ?

Cédric: moi je dirais la modularité. On a vraiment poussé le concept vraiment à l’extrême, c’est-à-dire qu’on peut, via l’ajout d’un module, modifier quasiment n’importe quel comportement du logiciel. Donc on peut modifier les flux standards qu’on implémente, qui sont des flux généralement classiques, mais chaque entreprise a sa petite spécificité, etc. Donc on peut aller se plugger (NDLR : brancher) n’importe où dans le code pour altérer le comportement et adapter aux besoins, et donc de pouvoir vraiment s’adapter à des flux de travail très spécifiques.

Nicolas: par contre, par rapport où on est le projet en général, là,

Cédric: on est en vitesse de croisière, je dirais

Nicolas: oui c’est ça, on a une vitesse de croisière. Nous, B2CK, on connaît pas mal d’entreprises qui utilisent Tryton depuis 10, 15 ans et qui fonctionnent.

Alors, on ne connaît pas l’explosion exponentielle que connaît par exemple Odoo. Ça, c’est sûr, on ne va pas le nier. Personnellement, ce n’est pas quelque chose que je recherche particulièrement, donc ça ne m’inquiète absolument pas. Oui, on pourrait probablement avoir plus de développeurs, mais ça ne vient pas non plus sans d’autres contraintes et sans parfois une certaine friction ou des choses ainsi.
Nicolas Evrard

Cédric:

il est assez facile d’avoir des gens qui veulent contribuer, d’ajouter des modules, de faire un module pour leurs besoins, etc. Ce qui est beaucoup plus difficile, c’est d’avoir des contributeurs qui vont faire vraiment le travail de maintenance du projet, maintenir les dépendances à jour, faire évoluer sur les nouvelles versions, corriger des bugs un peu compliqués dans le cœur, etc. Ou même juste optimiser.
Cédric Krier

Vraiment tout ce qui est travail d’optimisation, d’amélioration, vraiment dans le cœur du moteur. On a B2CK qui travaille et on a quelques contributeurs qui le font. Ce n’est pas énorme et c’est difficile de trouver parce que ce n’est pas évident. Il faut avoir beaucoup d’expérience, connaître bien l’intégralité du code parce que quand on touche au cœur, ça peut avoir des impacts partout. Ce n’est pas évident. Mais il y a beaucoup de développement qui est fait, mais en dehors vraiment de Tryton. Il y a des dépôts un peu partout qui existent, de projets personnels ou de sociétés qui implémentent des modules spécifiques aux besoins qu’ils ont rencontrés, etc. Donc il y a toute une partie de modules qui existent dans la nature. D’ailleurs, il y a un projet d’essayer de mettre en place, de faire une cartographie, un répertoire d’un peu tous ces modules externes pour donner un peu de visibilité.

Le futur de Tryton

Walid: dernier point que je voulais aborder, qui était le futur en fait. Quels sont les gros sujets que vous estimez être importants pour l’avenir ?

Nicolas: au niveau de la communauté, il y a cette cartographie des modules tiers. On se demande aussi s’il ne faudrait pas… Mais ça, c’est une grosse « polémique » dans la communauté de savoir si les modules doivent être hébergés ou pas par le projet lui-même ou par des externes. Nous, naïvement, on pensait que ça se ferait tout seul, mais ça n’a pas l’air de… Forcé de constater que ça ne s’est pas fait. Il n’y a pas non plus de cartographie qui s’est faite toute seule, un peu à la Django Package. Django Package, par exemple, c’est vraiment bien, ça montre tous les packages, les gens peuvent mettre des commentaires, etc. Mais ce n’est pas le projet de Django qui a décidé de le faire, c’est d’autres gens qui l’ont fait, et puis ils se sont dit, ah, c’est cool,

Cédric: on peut reprendre.

Nicolas: Django le reconnaît,

Cédric: quoi.

Nicolas: il y a ça au niveau de la communauté, je pense que ça va prendre encore du temps pour que ça arrive, puisque ça traîne depuis des années. Mais je pense que s’il y a une volonté plus forte maintenant que ça arrive, je pense que ça arrivera. Et puis, il y a des défis techniques qui sont des mises à jour. Il faudrait qu’on mette à jour le client, par exemple, à GTK4. J’en parle quasi tous les ans. On pourrait réécrire… le JavaScript qu’on utilise est daté, on pourrait le réorganiser autrement, on pourrait le moderniser, ça simplifie la vie à plein de gens.

Cédric: on a l’idée d’implémenter une API REST avec une architecture particulière pour permettre de développer plus facilement des sites connexes et communiquer juste avec une API REST. Pour l’instant, la manière dont on développe ce genre de site est fort couplée avec Tryton. Donc je pense que ce serait bien de pouvoir le découpler un peu plus avec une API. Ça, c’est un des projets.

Nicolas:

on dit souvent qu’on n’a pas de roadmap, les gens nous demandent parfois » est-ce qu’il y a une roadmap, quand est-ce que ce module-là va être disponible ? ». En fait, ça n’existe pas. C’est la communauté qui le fait, et alors la communauté le fait soit en le développant elle-même, soit en payant une des boîtes dans la communauté pour le faire.
Nicolas Evrard

Cédric: les développements sont drivés par le besoin, en fait. Je viens de penser à un autre projet qui est aussi en cours, qui est la réécriture de la documentation. En fait, il y a un an et demi, deux ans, on a structuré la manière dont on voulait documenter chaque module avec un squelette prédéfini qu’on doit appliquer à tous les modules. On a déjà réécrit la documentation pour les principaux, on a réécrit 50. La difficulté, c’est qu’il faut connaître pour réécrire la doc, et une fois qu’on connaît, ce n’est pas très intéressant d’écrire la doc.

Conclusion de l’interview

Walid: on arrive sur la fin de l’interview. J’avais, en guise de conclusion, des questions à vous poser. Première question, c’est qu’est-ce que vous diriez pour parler de Tryton à des gens qui n’ont pas d’ERP ?

Cédric: j’imagine que s’ils n’ont pas d’ERP, ils travaillent avec Excel, ça permet de ne pas avoir des milliers de feuilles Excel à mettre à jour et à dupliquer, à copier-coller à gauche à droite et reporter des infos.

Nicolas: ça cadre les processus aussi. Il y aura moins de déviations par rapport à la norme et ça va permettre de mieux optimiser.

Cédric: standardiser les processus et aussi la communication à l’intérieur de l’entreprise. Et donc on va pouvoir communiquer tout le monde avec la même info. L’information sera plus partagée, plus diffusée.

Nicolas: et en fonction aussi de la taille de l’entreprise, ça peut définir mieux les tâches de chacun.

Walid: deuxième question, qu’est-ce que vous diriez pour présenter Tryton à des personnes qui, comme moi, ont déployé d’autres ERP, libres ou pas libres ?

Cédric: avec Tryton, la configuration, la personnalisation est très poussée. On peut répondre aux besoins du client, de l’utilisateur quasiment dans tous les cas, et que la base sur laquelle va être reposée l’installation, donc la base sur laquelle on va construire, est saine et a un design cohérent et stable aussi. Mais on a basé beaucoup de notre design au début sur un bouquin de design d’ERP, en fait : data model resource. L’architecture, ce sur quoi on va… vous allez construire. C’est des bases stables et robustes.

Nicolas: et aussi que les migrations sont incluses.

Walid: ça introduit ma dernière question qui est comment est-ce que vous présenteriez Tryton à des libristes qui travaillent déjà sur des ERP libres comme Dolibarr ou Odoo ?

Cédric: les migrations sont incluses.

Walid: pour Dolibarr aussi. Dolibarr,

Nicolas: c’est pas inclus.

Walid: ah si, c’est dedans. Si, si, je peux dire que c’est dedans les migrations.

Nicolas: par Odoo par exemple ça l’est pas.

Walid: à part la migration.

Cédric: Tryton fonctionne. Est vraiment orienté objet. On travaille sur des objets qu’on fait évoluer, sur lesquels il y a des flux, des déconnexions, etc. En fait, c’est assez agréable, parce qu’on n’a pas besoin d’écrire beaucoup de code pour répondre aux besoins. Le code est assez clair et assez lisible, assez vite compréhensible.

Nicolas: pour Odoo, je rajouterais aussi, par exemple, qu’on ne fait pas des calculs avec des float (NDLR : nombres flottants), tout bêtement. C’est un peu mauvaise langue, mais voilà, quand on fait de la comptabilité avec des flots, c’est pas terrible.

Walid: c’est la private joke pour finir. On arrive à la fin. Est-ce que je vous fais une petite tribune libre si vous avez un message à passer ?

Nicolas: zut, je m’étais dit, c’est le moment que je préfère. Il pense à un truc cool et j’ai oublié.

Cédric: ben, Mercurial, c’est cool. C’est mieux que Git.

Nicolas: oui, voilà.

Walid: vous êtes un des derniers que je connais qui utilisent Mercurial, si ce n’est les derniers.

Cédric: ah bon ? En fait, Mercurial est utilisé par Google, Facebook, Nokia. C’est probablement un des systèmes de version de source qui a probablement la plus grosse base, qui gère les plus grosses bases de code.

Nicolas: oui, je ne m’aventurerais pas juste à dire ça.

Cédric: alors, chez Google, je crois qu’ils réécrivent des bouts, etc. Mais c’est des boîtes qui ont des monorepos qui sont…

Walid: c’est en tout cas la première fois qu’on parle sur Projets Libres! de Mercurial.

Nicolas: on peut expliquer pourquoi ?

Cédric: ce qui est vraiment bien avec Mercurial, c’est la ligne de commande. Les options sont cohérentes, le fonctionnement est cohérent à l’intérieur de tout le projet, et il n’y a pas d’étonnement. Et en plus, c’est extrêmement difficile de casser son repo. Il y a des sécurités partout. Mercurial empêche de faire des bêtises, alors que je n’utilise plus très souvent Git. Mais chaque fois que j’utilise, régulièrement, je me trouve à casser mon repo et à devoir re-cloner parce que je suis perdu ou j’ai perdu des développements.

Nicolas: Mercurial, à ce côté : ils ont fait une ligne de commande qui est vraiment ultra clean et qui fait ce qu’il faut, alors que Git, c’est un vrai bordel. Alors, ça fait énormément de choses, c’est super bien, c’est super rapide, c’est ultra performant, mais c’est un bordel sans fin.

Walid: ça marche. Écoutez, merci beaucoup d’avoir pris du temps pour échanger 15 ans après sur Tryton pour voir un petit peu les solutions très intéressantes que vous avez mises en place et assez originales finalement comme l’histoire de la fondation. Ça, c’est vraiment hyper intéressant de pouvoir échanger là-dessus. J’invite tout le monde à aller voir Tryton. Je mettrai les liens, bien sûr, en description. Comme d’habitude, aux auditeurs, aux auditrices, parlez-en autour de vous. N’hésitez pas à commenter. Le meilleur moyen de commenter, c’est sur Mastodon ou aussi sur LinkedIn. Les deux, je réponds. C’est les deux manières les plus simples. À bientôt. J’espère vous reparler dans quelques temps. Portez-vous bien et à une prochaine.

Nicolas: merci,

Cédric: salut.

Walid: à bientôt.

Licence

Ce podcast est publié sous la double licence Art Libre 1.3 ou ultérieure – CC BY-SA 2.0 ou ultérieure.

GitHub - gnuvet/gnuvet: gnuvet: the open source and free veterinary practice management software

gnuvet: the open source and free veterinary practice management software - gnuvet/gnuvet

^GitHub