podcast.projets-libres.org/@pr…

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

L’histoire de l’ERP Tryton

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.