Merci beaucoup d’être venus à cette conférence : « Les contributions au logiciel libre sont-elles uniquement destinées à des fins humanistes ? ». C’est la question. Je vous propose qu’on l’explore ensemble aujourd’hui.

Avant de tout de suite se lancer dedans, peut-être que vous vous demandez qui est la personne qui parle devant vous. J’ai mis un petit slide à propos de moi.
Je m’appelle Mathieu Ferment. Je travaille depuis 2012. J’ai commencé comme développeur PHP et j’ai rejoint PrestaShop [1] en 2018. PrestaShop est une entreprise qui édite un logiciel de CMS e-commerce. Pour ceux qui sont déjà passés sur le stand, c’est un logiciel qui vous permet de construire une boutique en ligne, de vendre derrière et il est open source. C’est quand j’ai rejoint PrestaShop en 2018 que j’ai fait la découverte de l’open source. Avant je croyais que l’open source c’était mettre son code sur GitHub en accès libre, une vision un peu légère ! Depuis, j’ai quand même appris deux ou trois trucs en plus et c’est pour ça qu’aujourd’hui je suis capable de me présenter devant vous et de vous parler de deux ou trois trucs que je crois avoir compris.

Maintenant que vous me connaissez un peu mieux, le but c’est de savoir si on fait de l’open source uniquement pour des raisons humanistes, pour la beauté du geste ?

Avant de répondre à cette question précise on peut dézoomer un peu : pourquoi les gens font-ils des contributions open source ? Pourquoi les gens se lèvent-ils le matin en disant « allez, c’est parti, je fais des contributions en open source » ? Qu’est-ce qui les motive ?
Il y a peut-être une partie de la réponse dans la salle. Du coup, je voudrais savoir : si quelqu’un a déjà fait des contributions open source, est-ce qu’il peut lever la main ? Super ! Il y en a plein. Je ne peux en choisir qu’un parce que je n’aurai pas le temps de demander à tout le monde. Je vais demander au monsieur au pull rayé : vous avez fait beaucoup de contributions open source ?

Public : Non, pas beaucoup, en l’occurrence c’était chez WordPress.

Mathieu Ferment : Très bien. Du coup, j’aurais une question : si vous vous souvenez de l’une de vos premières contributions, pourquoi avez-vous fait cette contribution ? Qu’est-ce qui vous a amené à la faire ? Quelles étaient les raisons derrière ?

Public : C’était notamment pour de la traduction. Toutes mes contributions c’est de la traduction sur des gros plugins populaires liés à WordPress. C’était aussi l’idée d’ouvrir à un plus large public. En fait, certains plugins ne sont pas toujours très bien traduits, ou sont complexes à comprendre pour des personnes qui ne sont pas initiées, on va dire. J’avais fait ce travail de traduction avec quelques correctifs en plus.

Mathieu Ferment : C’est très bien. Déjà bravo. Du coup on est déjà un peu sur une raison humaniste. Vous n’avez pas fait ça pour gagner de l’argent ou par intérêt, c’était pour aider d’autres gens.

Public : Totalement. Oui c’était ça. À l’époque même moi je ne comprenais pas comment fonctionnaient certaines fonctionnalités du plugin, c’est la traduction qui m’avait aidé moi-même.

Mathieu Ferment : C’est très intéressant, je vais y revenir. Plutôt que de demander à tout le monde dans la salle, je ne me suis pas pris la tête, je suis allé sur Google et j’ai tapé « Pourquoi les gens font-ils des contributions open source ? ». Les trois réponses qui reviennent régulièrement ce sont celles-ci.
La première c’est qu’il y a plein de gens qui contribuent parce qu’ils se sentent redevables.
Je prends un exemple qui va parler aux étudiants ici présents. J’ai commencé en 2012 en tant que développeur PHP, PHP est un projet open source. PHP tourne généralement sur un web serveur, comme Apache, Apache est un projet open source ; ça tourne souvent avec une base de données MySQL, encore un projet open source ; ça tourne sur des serveurs sur lesquels il y a généralement une distribution Linux, encore de l’open source. Donc toute ma carrière est basée sur de l’open source. Pas d’open source, pas de carrière, pas d’argent.
Du coup, comme beaucoup de gens, je me sens redevable. Je me dis que grâce à l’open source j’ai une carrière, grâce à l’open source je gagne ma vie. Je me sens redevable, donc je fais des contributions open source, parce que j’ai l’impression de redonner un peu de ce que j’ai reçu et c’est ce qui motive beaucoup de gens. Là on est un peu sur des raisons humanistes, le côté « j’ai reçu beaucoup, je redonne un petit peu ».

Il y a d’autres raisons un peu plus égoïstes qui reviennent souvent.
La première va aussi intéresser nos amis étudiants, c’est que l’open source est une formidable opportunité pour apprendre. La plupart des projets open source c’est du code, c’est du logiciel. Du coup, les gens qui écrivent du code, quand ils veulent s’améliorer généralement ils écrivent du code : practice makes perfect, il n’y a rien de mieux qu’écrire du code pour s’améliorer en tant que développeur. Du coup, plein de gens contribuent à l’open source parce que c’est de l’entraînement, ils s’entraînent comme un sportif et ils font des contributions.

Il y a un deuxième élément beaucoup plus intéressant. Quand vous envoyez une contribution, vous dites « j’ai vu ce projet, je propose de changer ça ». Dans la plupart des projets open source, votre contribution est revue par des mainteneurs de ce projet et, généralement, ces mainteneurs sont des experts du projet. Les mainteneurs vont regarder votre contribution et vont vous dire si elle est bonne ou pas bonne, c’est ce qu’on appelle la revue de code. C’est impressionnant ! Si on y réfléchit : on a des experts qui regardent gratuitement le code que vous avez soumis et qui vous disent s’il est bon ou pas bon ; généralement ils ne se contentent pas de dire oui ou non, ils expliquent pourquoi. On est presque sur du consulting gratuit, on est presque sur des professeurs gratuits. Il y a vraiment des gens qui contribuent à l’open source parce que, quand ils envoient leur code à des projets, ils reçoivent du feed-back dessus, gratuitement, de la part d’experts. C’est donc une excellente manière d’apprendre.

Il y a un troisième élément, qui, pareil, va parler beaucoup à nos amis étudiants, c’est la réputation. Aujourd’hui je suis Tech Manager chez PrestaShop et je recrute des développeurs – je pense que tout le monde recrute dans cet événement, toutes les entreprises tech recrutent. Quand le département Ressources Humaines de PrestaShop me propose des CV, si je vois que la personne a un profil GitHub ou GitLab, je vais le voir tout de suite. Un profil GitHub ou GitLab me permet de voir deux choses : déjà si la personne connaît un peu l’open source, c‘est important pour PrestaShop ; je peux voir ce que la personne a échangé avec d’autres gens, sur GitHub on peut tout voir, tout est public ; je peux voir comment elle parle, je peux voir aussi comment elle écrit en anglais parce que c’est important chez PrestaShop et, surtout, je peux voir les contributions que la personne a faites, je peux voir son code, je peux évaluer la qualité du code de mon candidat, j’ai donc quelques éléments sur sa compétence de développeur. Pour moi c’est une mine d’or et, évidemment, plein de développeurs en sont conscients. Donc plein de développeurs qui se disent « OK, je suis dans cette entreprise et j’ai envie de partir », ils font des contributions parce qu’ils savent qu’elles vont être regardées par les gens qui vont potentiellement vouloir les recruter. Ils boostent eux-mêmes leur profil. Donc c’est de la réputation.

Ce sont les trois raisons qui revenaient le plus, en tout cas sur Google, pour contribuer à l’open source : le côté je me sens redevable, le côté ça me permet d’apprendre, ça me permet de très bien apprendre et le côté réputation, ça permet de booster sa réputation online.
J’aime bien ces trois raisons-là, mais je vais faire un peu la fine bouche, je trouve que ce ne sont pas les meilleures et je vous explique pourquoi.

Imaginez que là je vous ai bien convaincus, du coup, ce week-end, vous allez faire des contributions open source parce que vous voulez progresser sur le langage Python, donc la deuxième raison, pour apprendre. C’est prévu, vous vous êtes dit « samedi je me fais quatre heures de contributions open source » et là votre frigo lâche. Je suis certain que s’il faut choisir entre réparer ou acheter un autre frigo ou faire vos contributions, vous allez réparer le frigo parce que c’est plus prioritaire pour vous. Parce que, malheureusement, les trois raisons qui sont présentées là, c’est du best effort, c’est-à-dire que vous allez le faire si vous avez du temps, de la dispo, si vous n’êtes pas en galère, mais s’il y a un truc plus prioritaire à vos yeux, vous n’allez pas faire ça.
Je suis mainteneur sur le projet PrestaShop, je fais partie des gens qui valident les contributions qui viennent sur le projet. Quand je vois quelqu’un qui fait sa contribution un dimanche à 22 heures, je me doute que c’est quelqu’un qui fait ça sur son temps libre, le week-end, il n’a pas fait ça pour son entreprise. Cette personne a fait une contribution, elle n’est pas mal, mais je vois des changements à apporter pour qu’elle soit nickel, je me demande toujours « si je lui dis, est-ce qu’elle va avoir le temps de les traiter ? ». Si elle ne peut travailler que deux heures le week-end, quand elle a du temps, peut-être qu’elle va revenir dans un mois, deux mois, trois mois, peut-être qu’elle ne reviendra plus du tout, parce que, encore une fois, potentiellement les raisons qu’elle avait de contribuer, je ne vais pas dire qu’elles ne sont pas solides, en tout cas elles ne garantissent pas une certaine régularité de sa contribution. Une contribution c’est souvent un échange entre les mainteneurs du projet et les gens qui contribuent. Ce n’est pas on envoie quelque chose et boom !, c’est validé. Il y a souvent un échange, du coup il faut revenir plusieurs fois. Si la personne a juste deux heures un week-end et qu’après elle n’a plus de temps, ça ne marche pas. Donc je fais un peu la fine bouche.

Vous allez me dire « OK, vous faites la fine bouche ! », du coup, on va dire que les contributions des gens qui font ça sur leur temps libre, ce n’est pas forcément ce que je préfère. Du coup qu’est-ce que je préfère ?
Idéalement, ce que je préfère c’est quand ce sont les entreprises qui contribuent. Pourquoi ? Parce que lundi prochain, si le monsieur au fond qui a bientôt des développeurs, qui a bientôt une entreprise florissante, dit à son développeur salarié « toute la journée tu fais de l’open source », peu importe si son frigo est cassé, peu importe s’il a d’autres plans, etc., là il est missionné, il est sponsorisé, il est payé pour faire ses contributions. Ça m’assure que ça va être une contribution régulière dans le temps, sérieuse et qui va aller jusqu’au bout. Entre guillemets, « ça me rassure » de savoir que derrière cette personne il y a une entreprise qui la paye pour aller jusqu’au bout et que cette personne n’est pas sur son temps libre en bénévole.

Du coup je m’intéresse beaucoup aux contributions faites par les entreprises. Est-ce que les entreprises contribuent ?
Là normalement, dans le salon, vous avez vu pas mal d’entreprises qui contribuent, c’est le bon côté de venir à ce salon, mais il y a quand même un cliché qui circule sur les entreprises, qui va à l’encontre.
Je pense que je n’ai pas besoin de présenter XKCD [2], webcomic très connu des développeurs. J’ai récupéré cette image de XKCD qui illustre une situation quand même un peu triste, c’est un cliché. Je ne sais pas si c’est vrai, je n’ai pas de données fiables, mais le fait que ça a fait rire beaucoup de gens me laisse penser que beaucoup de gens pensent ce que ça représente. Ça représente un projet pharamineux, probablement une entreprise qui se fait des millions et qui gagne des millions grâce à ce projet, qui utilise tous les codes modernes et toutes les technologies modernes qui sont basées sur des composants logiciels, qui sont basés sur des composants logiciels, qui sont basés sur des composants logiciels, qui sont basés, tout en bas à droite, sur un composant logiciel qui est maintenu par quelqu’un, anonyme, dans le Nebraska, depuis 2003, qui fait ça sur son temps en bénévole. Cette image est un peu triste parce qu’elle représente ce que beaucoup de gens pensent : il y a beaucoup d’entreprises qui profitent de l’open source et se font des millions avec. Elles utilisent du code fait par des gens bénévolement, qui font ça sur leur temps libre et qui ne reçoivent rien du tout, donc il y a un sentiment d’injustice.

On entend régulièrement parler de ce sentiment d’injustice dans l’open source. J’ai mis un exemple tristement célèbre, une librairy qui s’appelait kaker.js. Le monsieur qui la maintenait, c’était le même cas, bénévole et tout, je crois que sa librairy était utilisée par Amazon et Microsoft, et, à un moment, il a dit « j’en ai marre parce que je fais ça bénévolement, je mets mon code sur GitHub, il est en accès libre et moi je galère à payer mon loyer. Ça m’énerve de savoir que des entreprises utilisent mon code, se font des millions avec, et moi je galère à payer mon loyer, c’est injuste ! ». Du coup, il est viré son code de GitHub et il a cassé plein de trucs. Je ne vous raconte pas la suite de l’histoire, il s’est passé des choses. C’est un élément qui me laisse penser qu’il y a beaucoup de gens qui pensent que beaucoup d’entreprises profitent de l’open source et ne redonnent pas à l’entreprise.
Du coup ça va un peu à l’encontre de ce que je disais quand je disais que je voulais des contributions des entreprises.

Je veux convaincre les entreprises de contribuer, puisque je pense que ça donne des contributions plus régulières, plus pérennes dans le temps, plus poussées.
Je pense qu’il ne faut pas venir voir les entreprises en disant « bonjour, c’est important de contribuer, c’est vraiment très important ». Je ne pense pas que ce soit un argument qui parle à beaucoup d’entreprises.
À mon avis, il faut parler à une entreprise en termes économiques. Si on schématise un peu, on va dire que le but d’une entreprise c’est quand même de gagner de l’argent. L’entreprise a des dépenses : elle paye des salaires, elle paye du matériel, elle paye des licences logicielles. Elle espère, avec toutes ces dépenses, pouvoir générer de la valeur ajoutée qu’elle va pouvoir revendre ou monétiser et, qu’à la fin du mois, elle aura gagné plus d’argent qu’elle n’en aura dépensé. Si elle a dépensé plus qu’elle n’a gagné, elle n’est pas rentable, elle va mourir. Pour vivre, l’entreprise a besoin de faire des bénéfices, elle a besoin de gagner plus d’argent que ce qu’elle a dépensé.

Mon but va être de démontrer à l’entreprise qu’en faisant de l’open source elle va gagner de l’argent et que ça va la motiver à contribuer.
Je vais essayer de montrer aux entrepreneurs qui sont présents aujourd’hui — et il y aura un replay que d’autres regarderont — que les contributions open source sont très intéressantes économiquement pour eux.

La première raison, selon moi, pour laquelle une entreprise devrait contribuer, c’est très simple : c’est que c’est son code.
Je vous explique. On va prendre un exemple.
On va imaginer que, demain, vous décidez de lancer une entreprise d’intelligence artificielle. Vous avez trouvé un super concept ce matin dans le train : le séchoir pour mettre les vêtements et qu’ils sèchent de manière optimale ; on va demander à une IA de répartir les vêtements sur le séchoir. Tout se fait, il y a des startups de fou, donc pourquoi pas ça !
Je fais mon entreprise qui est basée sur une IA que je vais vendre par abonnement et qui va dire aux gens comment mettre leurs vêtements sur le séchoir pour que ça sèche le mieux.
Je vais donc devoir, du coup, construire une intelligence artificielle, je vais utiliser du machine learning. Est-ce que je vais recoder ma propre library de machine learning ? Est-ce que je vais recoder ça ? Non. Il y a des dizaines, des centaines de libraries open source qui permettent de faire du machine learning, donc je vais en prendre une sur Internet. Et là je suis trop content en tant qu’entrepreneur ! Je me dis que j’aurais peut-être dû payer un développeur pendant huit mois pour me construire ce composant logiciel pour me faire une IA. Boom !, je l’ai pris sur GitHub, tac !, en une seconde c’est fait. J’ai économisé huit mois de salaire !
Mais c’est un peu une illusion. Pourquoi ? Pour y répondre j’ai mis une citation de Scott McNealy-Sun, Open source is free like a puppy is free. Je vous l’explique. C’est bientôt Noël. On va imaginer qu’à Noël vous allez recevoir un super cadeau, un petit chiot. Un petit chiot c’est mignon, c’est adorable, quand vous recevez le cadeau vous êtes trop content, il est trop content d’être avec vous et tout. Mais, si vous acceptez ce cadeau, vous allez devoir nourrir ce petit chiot, vous allez devoir le soigner, l’emmener chez le vétérinaire, vous allez devoir lui donner un endroit pour dormir, etc.. C’est donc un cadeau qui vient avec un coût de maintenance. Eh bien l’open source c’est pareil.
Si moi, l’entrepreneur qui ai construit ma solution d’intelligence artificielle, j’utilise une library open source pour construire mon application, à partir du moment où j’utilise cette library dans mon application, ça devient mon code, c’est à moi de m’en occuper. La plupart des projets open source sont gratuits, mais il n’y a pas de support. S’il y a un bug dedans c’est pour vous, c’est pour votre pomme, personne ne viendra le corriger pour vous. Du coup, à partir du moment où vous prenez du code open source et vous l’utilisez pour faire un business, vous devez traiter ce code open source, que vous n’avez pas écrit, comme si c’était votre propre code. Vous allez devoir le corriger, vous allez devoir le maintenir, vous allez devoir faire des montées de version. Il y a donc un coût de maintenance qui vient. Vous devez en prendre soin. Vous devez imaginer que, demain, peut-être, il y a aura un bug dans votre intelligence artificielle et, en analysant le bug, vous allez découvrir que le bug vient de la fameuse library, celle que vous n’avez pas écrite, celle que vous avez prise directement sur Internet. Si ce jour-là le bug est en train de vous faire perdre des dizaines de milliers d’euros chaque jour et que vous n’avez jamais regardé cette library auparavant, ça risque d’être embêtant pour le corriger très vite.

Mon conseil aux entreprises qui font ça, mon conseil aux entreprises qui utilisent de l’open source tous les jours, c’est de contribuer à ces projets open source. C’est comme ça que vous allez vous familiariser avec la base de code, que vous allez découvrir comment elle fonctionne, comment elle est conçue, comment elle est testée, comment on peut faire une nouvelle version et être prêts pour le jour J où vous aurez besoin d’intervenir dedans parce que personne d’autre ne va intervenir dedans, en tout cas gratuitement. Prenez soin de ce code comme si c’était le vôtre. De toute façon c’est le vôtre ! Il tourne dans votre application, c’est le vôtre.

Un deuxième élément aussi est important. On va reprendre mon exemple d’entreprise qui a fait l’intelligence artificielle. Ça marche trop bien, j’ai 10 000 clients, je suis content. Et là, je viens d’apprendre que la fameuse library que j’ai utilisée, était maintenue par une seule personne qui a décidé de passer à autre chose, elle arrête le projet. Zut ! Du coup il n’y aura pas de nouveaux bugfixes, de nouveaux correctifs, il n’y aura pas de nouvelles améliorations de performance. On va dire que cette library était faite en Rust, il n’y aura même pas la compatibilité avec les futures versions de Rust parce que le mainteneur est parti, le projet est mort et abandonné. En tant qu’entrepreneur, ce n’est pas une situation dans laquelle vous voulez vous trouver. Du coup, je recommande aux entrepreneurs : si vous utilisez du code open source qui est critique pour votre business, eh bien prenez-en soin et assurez sa survie. Et, pour assurer sa survie, il faut y contribuer, il faut que le projet soit actif, il faut qu’il y ait régulièrement des choses dessus. Tout simplement, prenez soin de ce code, parce que si vous en dépendez, vous avez besoin qu’il vive bien et vous avez besoin d’être prêt à intervenir dedans.
C’était ma première raison.

Ma deuxième raison. J’ai mis une très longue citation qui est tirée d’une étude de la Commission européenne. Je vous épargne la lecture. [« Étant donné que les contributions à l’OSS [open-source software]peuvent également être perçues comme une forme spécifique d’innovation, notre calcul prudent d’un rapport coûts-avantages de 1 à 4 pour l’UE est conforme aux deux études citées ».] Grosso modo, c’est une étude où l’Union européenne avait dit à des analystes « je voudrais m’intéresser à l’économie de l’open source en Europe. Quand une entreprise utilise de l’open source combien ça lui coûte ? Combien ça lui rapporte ? Quand une entité publique utilise de l’open source combien ça lui coûte ? Combien ça lui rapporte ? Etc. » Il y avait un volet sur la contribution open source qui disait : quand une entreprise fait une contribution open source, combien ça lui coûte ? Combien ça lui rapporte ?
L’étude prétend qu’il y a un rapport de 1 à 4 sur les contributions. Ça veut dire que si vous investissez 1 vous récupérez quatre fois plus. Un ROI [Retour sur investissement] fois 4. C’est beau ! Et encore, l’étude dit qu’un ROI fois 4 c’est un ROI prudent, certains éléments laissent penser à un ROI fois 10.
Là vous dites « il est sympa le monsieur en face de moi, il me dit un ROI fois 4, mais je n’ai que sa parole, je ne vais peut-être pas le croire sur parole ! »

Comment j’explique ce ROI fois 4 ? Je pense qu’il y a deux éléments principaux qui expliquent ce ROI fois 4.

Le premier, c’est ce que j’appelle le fardeau de la maintenance.
Je reprends l’exemple précédent. Votre entreprise, toujours la même, intelligence artificielle pour comment mettre des vêtements sur un séchoir. Elle marche bien, vous avez suivi mon conseil précédent, vous contribuez au projet open source, vous vous assurez qu’il survit, du coup votre business n’est pas en danger. Et là, arrive le cas que j’ai mentionné, il y a un bug. Il y a un bug dans l’application, vous perdez de l’argent, mais heureusement vous êtes familier avec la codebase, vous arrivez très vite à produire un correctif qui corrige le bug, vous arrêtez de perdre de l’argent. Super !
Maintenant vous avez deux scénarios devant vous : soit vous gardez ce correctif logiciel pour vous, soit vous contribuez ce correctif logiciel au projet initial.

Si je reprends ma vision un petit peu basique de l’entreprise avec les dépenses et les coûts, à priori ça paraît une mauvaise idée de donner ce correctif au projet. Peut-être, par exemple, que vous avez un concurrent qui utilise la même library open source. Du coup, si vous contribuez votre correctif, c’est comme si vous donniez à votre concurrent le correctif, vous lui donniez la valeur ajoutée que vous avez produite. Ça ne paraît pas une excellente stratégie d’un point de vue économique.
Oui mais ! Il faut considérer un autre cas.

On va supposer que vous dites « je garde mon correctif pour moi parce que ce sont mes ingénieurs qui l’ont développé, c’est mon argent que j’ai investi, je le garde pour moi, je garde cet avantage pour moi ». On va dire que la library open source que vous utilisiez était en version 5. Votre correctif marche très bien avec la version 5. Et là, la version 6 sort et votre correctif ne marche pas avec la version 6. Du coup, vous devez faire le travail de mettre à jour votre correctif pour qu’il soit compatible avec la version 6. Puis il y aura la version 7. Rebelote ! Vous allez devoir mettre à jour votre correctif potentiellement avec la version 7 parce qu’entre deux versions le code change, les correctifs doivent être adaptés.
Du coup, si vous continuez en gardant ce correctif pour vous, vous vous obligez à le maintenir dans le temps pour les futures versions. Vous vous donnez donc, à vous-même, un coût de maintenance. Alors que si, quand votre correctif était prêt, vous l’aviez contribué au projet open source, que le projet open source l’ait accepté, qui se serait tapé le coût de mettre à jour ce correctif pour les versions 6, 7, 8 ? Les gens du projet.
En fait, quand quelqu’un fait une contribution vers du logiciel libre et que cette contribution est acceptée par les mainteneurs du projet, les mainteneurs du projet, certes ils acceptent le changement de code, mais ils acceptent aussi le fardeau de maintenance qui vient avec et le fait de le maintenir dans le temps. C’est génial pour un entrepreneur. Ce sont d’autres gens qui vont maintenir, pour vous, le code que vous aviez pondu en échange de l’avoir donné au projet.
C’est le premier élément.

Le deuxième élément. La plupart des projets open source ont un processus qualité, c’est-à-dire que quand vous soumettez une contribution, elle n’est pas acceptée comme ça [Claquement de doigts, NdT]. Généralement il se passe au moins deux choses : tout un tas de tests automatisés sont lancés pour vérifier la validité et la qualité de votre contribution et les mainteneurs du projet vont également lire votre code, c’est la revue de code, ils vont vérifier si ça répond aux best practices, si ça répond à l’architecture du projet, etc. Ils vont vérifier que vous n’avez pas fait n’importe quoi. Et si tout cela est validé, votre contribution sera probablement acceptée.
Mine de rien, quand vous faites une contribution, le correctif que vous avez conçu passe devant un processus qualité que vous, dans votre entreprise, vous n’aviez peut-être pas. Du coup, quand vous contribuez des choses, vous avez un retour sur la qualité de ces choses grâce à ce processus de qualité, en faisant la contribution. Si vous l’aviez gardée pour vous, vous n’auriez jamais eu toutes ces infos. Peut-être que le processus de qualité va vous dire « très bien, le correctif que vous avez pondu marche très bien dans la plupart des cas, mais nous, grâce à notre processus qualité, nous avons détecté un cas problématique que vous n’aviez pas vu parce que vous étiez tout seul, qui aurait pu vous faire un bug dans deux semaines ». Comme vous avez contribué ce correctif au projet, que vous avez bénéficié de ce processus qualité, le bug a été détecté avant qu’il fasse mal, du coup il sera corrigé avant qu’il impacte vos clients finaux.

Du coup, quand vous contribuez, vous partagez le fardeau de la maintenance et vous bénéficiez du processus qualité de ce projet. Tout ça c’est gratuit, Pour un entrepreneur, ce n’est que du bonheur !

Il y a une troisième raison pour laquelle, selon moi, les entreprises devraient contribuer, celle-ci c’est ma préférée. J’ai mis aussi une petite citation pour expliquer : « Open source software is a positive-sum game », Sam Ramji - Cloud Foundry Foundation.
On va supposer que là tout le monde est très convaincu et que tout le monde ici est chef d’entreprise. Si, si ! Du coup, lundi prochain vous allez tous dire à vos équipes de développeurs « j’ai vu une super conférence mardi dernier, je suis convaincu, il faut faire de la contribution open source ». Toute la journée, tout ce lundi-là, les développeurs vont faire de la contribution open source.

On va faire des petits calculs. Pour se simplifier la vie, on va dire que dans chaque entreprise présente ici il y a dix développeurs.
Je prends l’entreprise A. Lundi elle dit à ses dix développeurs « aujourd’hui, toute la journée vous faites de l’open source ». Pour simplifier on va dire que les dix développeurs font chacun, en une journée, une contribution. Donc, le soir, on a réalisé dix contributions. Je ne pense pas que les développeurs vont faire n’importe quoi, ils vont sûrement faire des contributions qui bénéficient à l’entreprise ; ça va être des correctifs de bugs, ça va être des améliorations de performances, ça va être de nouvelles capacités, ils ne vont pas bosser sur n’importe quoi. Du coup, l’entreprise A va sûrement, au moins, déjà bénéficier de ces dix contributions. En fait, ils ont juste bossé comme d’habitude, ils ont amélioré la qualité du code qu’ils utilisent tous les jours.
Le soir, le chef d’entreprise fait ses comptes. Il dit « j’ai payé mes dix développeurs toute une journée et j’ai récupéré dix contributions, ce n’est pas mal ! »

À côté, l’entreprise B a fait pareil. Elle a demandé à ses dix développeurs de faire dix contributions. Le soir elle regarde et dit « j’ai dix contributions qui sont bonnes » ; l’entreprise C à côté pareil et l’entreprise D à côté pareil.

On va supposer, pour simplifier encore les calculs, qu’on a dix entreprises qui, tout le lundi, ont généré des contributions. Qu’est-ce qui se passe le soir ? Le soir toutes ces contributions sont envoyées aux différents projets open source qui en dépendaient et tout est fusionné ensemble, c’est le concept des projets open source : plein de gens bossent chacun de son côté et ils viennent tous ensemble fusionner leur travail dans un bien commun.

Je refais mes calculs. L’entreprise A a payé ses dix développeurs pour générer dix contributions – c’est ce qu’elle a produit, ce qu’elle a investi –, mais, en échange, elle a récupéré 100 contributions, parce qu’il y a toutes celles des autres entreprises.
Ce qui est très important avec l’open source, ce qui est absolument génial pour les entreprises, c’est que plusieurs entreprises travaillent chacune sur leurs chantiers, sur ce qu’elles veulent et, à la fin, elles mettent tout en commun dans un projet et chaque entreprise récupère l’intégralité du travail des autres. Du coup, il y a un démultiplicateur de fou ! Avec du logiciel propriétaire, ça ne marche pas. Si vous utilisez un logiciel propriétaire, vous pouvez faire tout ce que vous pouvez, vous ne pourrez jamais le partager avec les autres utilisateurs du logiciel et vice-versa ; vous ne pourrez pas récupérer ce que potentiellement les autres entreprises qui, comme vous, utilisent ce logiciel propriétaire, ont fait. Avec l’open source, c’est possible et ça permet des gains de fou.
Si vous y réfléchissez, chaque fois que vous utilisez une nouvelle version de Mozilla, de Chrome, de Linux, vous récupérez des centaines de millions d’euros d’investissement. Tout le travail fait dans chaque nouvelle version des projets open source arrive dans vos mains, gratuitement, parce que c’est partagé, parce que c’est donné à tous.
C’était la troisième raison pour laquelle, selon moi, les entreprises devraient contribuer et ce sont vraiment des raisons économiques, c’est économiquement intéressant pour elles. C’est économiquement intéressant pour une entreprise de vous payer, messieurs et mesdames, pour ceux qui sont ou seront salariés un jour comme développeur, à faire de l’open source.

J’ai une quatrième raison qui va un cran plus loin.
On va supposer qu’on est toujours dans l’exemple de l’entreprise qui fait de l’intelligence artificielle, toujours mon exemple. L’entreprise marche très bien. Du coup, je recommanderais à cette entreprise d’aller un cran plus loin.
Quand vous faites des contributions à un projet open source, vous en faites une, vous en faites deux, vous en faites cinq, vous en faites dix, vous en faites 20 ; vos contributions sont revues et validées par le processus qualité et par les mainteneurs du projet open source qui regardent votre code et vous disent s’il est bien ou pas bien. Au fur et à mesure que vous faites des contributions, des discussions se font, vous commencez à connaître les mainteneurs, les mainteneurs commencent à vous connaître, vous commencez aussi à connaître les autres utilisateurs du projet open source parce que vous interagissez, c’est une communauté.
Si vous contribuez très régulièrement, il est possible qu’au bout d’un moment les mainteneurs vous disent : « Salut, on voit que tu bosses bien, tu as fait des bonnes contributions, ton code est de qualité, tu ne veux pas nous rejoindre côté mainteneur ? Tu ne veux pas venir nous aider à valider les contributions des autres, parce qu’on a confiance ? ». C’est comme ça que ça se fait dans beaucoup de projets open source.
Aujourd’hui, je suis mainteneur sur le projet open source PrestaShop. On a un processus pour accepter de nouveaux mainteneurs, mais je vois aussi régulièrement des contributeurs qui sont investis, qui viennent régulièrement et, quand je vois qu’ils sont très investis, je leur dis « tu ne serais pas intéressé pour passer de l’autre côté de la barrière et nous aider à valider les contributions qui arrivent ? ». Le projet grandit, du coup on a besoin de faire grandir l’équipe des mainteneurs.
Si vous contribuez régulièrement à un projet open source, il est possible qu’au bout d’un moment vous deveniez mainteneur de ce projet open source. Et là, pour une entreprise, ça devient super intéressant. Pourquoi ? Parce qu’à la base c’est quoi un mainteneur ? C’est quand même la personne qui dit, devant une contribution, « ça rentre ou ça ne rentre pas ; c’est validé ou ce n’est pas validé ». Là, finalement, l’entreprise qui paye ce salarié vient d’acquérir une sorte de pouvoir d’influence sur ce qui rentre ou ce qui ne rentre pas sur le projet et c’est très important. Si ce projet open source est critique pour votre entreprise, vous avez envie d’être en capacité d’influencer son développement et la direction dans laquelle il va. Quand vous avez la capacité de dire oui ou non aux contributions qui arrivent, vous pouvez littéralement influencer le chemin de ce projet.

Dans la plupart des projets open source, il y a des mainteneurs, la plupart du temps il n’y a pas de relations contractuelles, ce ne sont pas des entreprises, c’est donc un ensemble de gens et, parfois, ces ensembles de gens doivent se mettre d’accord pour prendre des décisions communes : quand est-ce qu’on se lance dans la compatibilité avec la prochaine version de Rust ? Est-ce qu’on rajoute cette nouvelle feature ?, mais il y aura un impact. Est-ce qu’on arrête cette ancienne feature ?, dont on pense que plus personne ne l’utilise, mais il y a encore des gens qui l’utilisent. Ils doivent se mettre d’accord. Pour les petits groupes ça va. Pour les plus grands groupes il y a besoin de mettre en place une structure de décision, tout simplement, c’est ce qu’on appelle la gouvernance open source. Il y a des gouvernances de plein de types. J’ai mis un petit lien vers Red Hat, en bas, qui les présente un peu toutes.
Le grand classique c’est la gouvernance électorale. C’est tout simple, on fait un vote, chaque mainteneur a un droit de vote, c’est la majorité qui l’emporte.
Parfois, sur des projets beaucoup plus gros où faire un vote c’est un peu long, un peu fastidieux, il y a un comité de gouvernance ; parfois il y a carrément une fondation. Je pense que vous avez dû entendre parler, dans ce salon, de la fondation Eclipse [3], très connue. Parfois même, un quatrième exemple, la structure de décision c’est simple, c’est la personne qui a créé le projet initialement, donc le fondateur, qui décide tout et les autres doivent faire comme il veut. Il y a des projets pour lesquels c’est comme ça, il y a une sorte de dictateur absolu, c’est le premier qui a créé le projet, c’est lui qui dit oui ou non et les autres n’ont pas leur mot à dire ; c’est une manière de prendre des décisions. En tout cas il en faut une, quand le projet est grand il faut une manière de prendre des décisions. Si j’exclus celle du leader chef absolu, pour la plupart des projets open source, eh bien ce sont les mainteneurs qui participent à ces décisions.
Du coup, une entreprise, dont certains salariés sont mainteneurs d’un projet open source, a directement une capacité d’influence sur la décision de ce projet. Et, encore une fois c’est très important. Si votre entreprise dépend de manière critique de ce projet, c’est rassurant de savoir que vous avez une capacité d’influence pour au moins être sûr qu’ils ne vont pas faire n’importe quoi.
C’est la quatrième raison pour laquelle, selon moi, les entreprises devraient contribuer à l’open source.

Je vous fais un rappel parce que j’ai parlé longtemps, du coup j’ai parlé de beaucoup de choses.

Pourquoi est-ce que les individus ont tendance à contribuer à des projets open source, en tout cas d’après Google ?
D’une part pour apprendre, practice makes perfect, en tant que développeur il n’y a rien de mieux qu’écrire du code pour s’améliorer et, quand on envoie son code à un projet open source, ce code est souvent revu par des experts. Ce sont des gens qui vous forment gratuitement. C’est quand même génial !
Deuxième élément, pour la réputation. Les profils GitHub et GitLab sont très clairement regardés par les recruteurs. Pour nos amis étudiants SI, quand vous chercherez un boulot, faites des contributions open source pour montrer ce que vous valez à vos potentiels futurs employeurs. Dans vos contributions open source, montrez le meilleur de vous-même parce que c’est ça que votre potentiel employeur va regarder et c’est ça qu’il va utiliser potentiellement pour vous dire oui ou non.
Puisque, à la base, il y avait une question : est-ce qu’on fait de l’open source uniquement pour des buts humanistes ? Il y a aussi des buts humanistes : le fait qu’on a beaucoup reçu. Je pense que même ici, sans nous en rendre compte, nous avons tous beaucoup reçu de l’open source, beaucoup d’entre nous se sentent redevables, ont la sensation qu’il faut contribuer pour continuer à entretenir ce cycle de donnant-donnant.
Ça c’est pour les individus.

Pour les entreprises, je vous rappelle les quatre raisons pour lesquelles une entreprise devrait sponsoriser ses salariés à faire de l’open source.
Tout d’abord, vous utilisez du code open source, c’est votre code, ce n’est pas le code de quelqu’un d’autre, personne d’autre n’en prendra soin, du coup préparez-vous à en prendre soin et ne laissez pas ce projet critique pour votre business mourir, ce serait une très mauvaise idée.
D’après la Commission européenne, contribuer a un ROI, un retour sur investissement de fois 4, notamment parce que vous partagez le fardeau de la maintenance, c’est donc littéralement de l’argent en moins à dépenser et vous profitez du processus de qualité. Tout le monde gagne ! C’est vraiment, pour moi la meilleure des raisons : quand on fait de l’open source, tout le monde met en commun son travail et, du coup, vous participez un petit peu et vous recevez beaucoup. C’est vraiment génial, c’est la grande force de l’open source.
Le dernier élément c’est que, si vous contribuez régulièrement à un projet open source, potentiellement vous serez amené à devenir mainteneur et, du coup, vous obtiendrez une capacité d’influence sur les décisions et la vie de ce projet, tout simplement.

Merci beaucoup. On aura pas mal de temps pour les questions.

[Applaudissements]

Mathieu Ferment : Je crois qu’il y a un micro au milieu, je ne sais pas s’il marche, sinon nous sommes peu nombreux on peut parler un peu fort. Est-ce qu’il y a des mains levées pour des questions ?

Public : J’ai une question par rapport à ce que vous avez évoqué au début notamment sur le recrutement et le fait d’avoir un compte GitHub. Mettons que je participe au nom de mon entreprise à un code open source. Mon entreprise décide que j’utilise un compte sur GitHub pour l’entreprise. Derrière, un recruteur voit mon profil, à priori il voit plus mon profil public que mon profil entreprise. Dans ce cas-là, comment on gère les choses ? Est-ce que je dis au recruteur « attends, finalement tout n’a pas été vu, parce que je fais aussi via mon entreprise, plus qu’à titre personnel. »

Mathieu Ferment : Je confirme que là c’est effectivement un cas problématique. Chez PrestaShop, aujourd’hui, on ne demande pas d’avoir deux comptes dissociés, mais il y a effectivement des entreprises qui disent « vous allez contribuer sur GitHub, faites deux comptes dissociés » et on ne pourra pas le voir. C’est un choix de l’entreprise, on ne peut pas aller contre. Il me semble que quand on travaille dans une entreprise, la propriété intellectuelle de ce qu’on produit appartient à l’entreprise et pas à soi. C’est effectivement un cas problématique. Je sais que ça existe, je ne saurais pas dire si c’est une majorité ou une minorité d’entreprises qui obligent à ça, mais beaucoup de celles que je connais savent que, justement, les développeurs apprécient le fait de pouvoir montrer leur travail en public, donc les laissent utiliser un compte.
Chez PrestaShop, quand quelqu’un qui a déjà un compte GitHub nous rejoint, en fait dans GitHub on peut renseigner plusieurs adresses e-mail et il lie son adresse e-mail PrestaShop avec son compte GitHub, du coup tout est rassemblé. Quand la personne part, elle garde toutes ses contributions.
J’irais même plus loin, c’est aussi intéressant. Chez nous, les gens qui ont des droits auprès des projets, donc les mainteneurs, ce sont des droits qui sont liés au compte GitHub. Si, demain, je démissionne de PrestaShop à priori je reste chez mainteneur, même si je ne travaille plus pour PrestaShop, parce que c’est moi la personne, l’individu, qui suis mainteneur et non pas le salarié, du coup c’est intéressant pour moi.

Public : Est-ce que le fait de publier des correctifs en open source ne présente pas plus de failles de sécurité, plutôt que de les garder dans l’entreprise ?

Mathieu Ferment : C’est une question très intéressante. On fait un logiciel open source donc tout notre code est public, la question est effectivement posée régulièrement.
Dans un premier temps oui, on se dit « si mon code est public il est visible par tous, du coup c’est plus facile de trouver des failles dedans ». D’ailleurs, dans les projets open source de PresataShop, il y a régulièrement des failles qui sont publiées.
Ce qui de passe également c’est que quand votre code est public, certes il y a des attaquants qui le scannent en permanence pour trouver des failles, mais il y a aussi des gens qui le regardent en permanence pour colmater ces failles. Du coup, c’est un peu une course contre la montre. Il y a plein de gens qui regardent le code : il y a des gentils qui veulent trouver les failles et les corriger avant les autres ; il y a des méchants qui veulent trouver des failles et les exploiter avant les autres. On considère généralement dans l’open source que le nombre de gens gentils va dépasser le nombre de gens méchants et que vous êtes gagnant à la fin.
Certes, c’est une course contre la montre, mais, dans l’autre sens, un code propriétaire qui est inaccessible de l’expéditeur à part les gens d e l’entreprise personne ne peut le regarder, ne peut l’auditer.

Typiquement, chez PrestaShop, on a ce qu’on appelle un bug bounty : quand quelqu’un nous remonte des failles, on le rémunère dessus. C’est possible parce que c’est un projet open source, du coup n’importe qui peut aller voir le code et, s’il trouve une faille, on lui donne de l’argent pour ça. Je ne peux pas assurer que c’est vrai, mais aujourd’hui, dans la sécurité, on recommande plus le bug bounty que les audits de sécurité parce que le bug bounty c’est en permanence. Il y a en permanence de gens qui veulent gagner cet argent qu’on leur propose et qui cherchent ces failles. On suppose que rendre le code public, c’est plus avantageux pour la sécurité que le cacher. Est-ce que c’est certain ? Je ne suis pas sûr qu’on ait des données fiables là-dessus, en tout cas c’est l’approche qu’on a.

Public : Du coup, le bug bounty peut s’apparenter à un salaire pour certaines personnes.

Mathieu Ferment : Tout à fait. Il y a des gens qui vivent avec de leurs bug bounty ce sont les plus efficaces et les plus talentueux, mais il y a des gens qui ne vivent que de bug bounty. Ils passent leur vie à se balader sur des projets open source parce que le code est public. Il y a également des bug bounty privés pour lesquels on leur donne un accès, il faut qu’ils s’enregistrent, avant il faut qu’ils aient montré un peu leurs compétences, on ne donne pas accès à n’importe et ils vivent que de bug bounty. Comme, en plus, il y a un petit côté gamification, il y a des rankings, on voit qu’ils sont top 1, top 2, top 3, ça génère de la réputation qui fait qu’ils sont plus facilement éligibles pour être embauchés pour un audit de sécurité.
Il y a des gens qui vivent que de bug bounty. Par contre, si ça vous intéresse, il faut être très bon, il y a une belle concurrence.

Public : S’il y a des entreprises qui deviennent un petit peu mainteneur majeur dans des projets open source, est-ce qu’il n’y a pas un risque de dérive, qu’elles en fassent quelque chose de trop spécifique par rapport à leurs besoins et que ce ne soit plus assez bien pour les autres entreprises ?

Mathieu Ferment : C’est un risque complètement avéré. Je ne vais pas citer de nom aujourd’hui parce que c’est un concurrent, du coup je ne veux pas dire des choses comme ça sur une autre entreprise. Les projets open source c’est un peu comme une OPA économiquement. Si vous avez une entreprise qui investit fortement, si le processus de décision c’est un processus électoral à coups de votes, quand vous avez la majorité, vous avez le contrôle. Donc oui, mais c’est le jeu de l’open source. On considère que, certes, on se met en danger quand on propose aux gens et on dit « n’importe qui peut rejoindre le projet, devenir mainteneur », sous conditions bien sûr : si quelqu’un arrive à avoir une majorité de mainteneurs, il prend le contrôle. Mais, dans l’autre sens, on va aussi attirer d’autres acteurs. Une entreprise, demain, qui veut grossir, elle n’a pas beaucoup d’autres choix que soit embaucher, soit se faire racheter. Nous, on veut faire grossir le projet PrestaShop, on ne veut pas de ces deux options. On dit aux autres acteurs « venez participer au projet open source, investissez-vous, peut-être que vous aurez des mainteneurs, du coup vous acquerrez une capacité d’influence, en échange le projet va grossir, va aller plus vite, plus grand ».
Donc oui, c’est un risque avéré, mais qu’on accepte complètement parce qu’en échange il y a des gens qui viennent, qui s’investissent parce qu’ils savent qu’il y aura un retour sur investissement. Ils savent que s’ils s’investissent beaucoup dans le projet, ils vont récupérer quelque chose en échange, cette capacité d’influence, donc c’est intéressant pour eux, donc ça marche.

Il nous reste quatre minutes, s’il y a d’autres questions.

Public : Si un projet m’accepte en tant que contributeur, que je suis employé dans une entreprise qui fait des contributions, et cette entreprise m’accorde du temps pour faire ces contributions. C’est moi, en tant qu’individu, qui décide à qui je donne ma voix ? Si mon entreprise dit « il faut orienter le projet comme ça », je ne suis pas obligé d’être en accord avec cette orientation.

Mathieu Ferment : Ça va se discuter avec l’entreprise en question. Je ne peux pas parler pour toutes les entreprises. Il y a typiquement des entreprises qui peuvent contractualiser ça, qui vont dire « si tu deviens mainteneur on te demande de voter ce qu’on te dit de voter ». En France, dans le droit français, il me semble qu’il y a le principe de loyauté qui s’applique à tous les employés qui dit que sur le temps salarié il ne faut pas aller à l’encontre des intérêts de l’entreprise, quelque chose comme ça. Du coup, il y a des entreprises qui contractualisent ça parce qu’elles le prévoient à l’avance. Si rien n’est contractualisé j’imagine que ce serait possible. Mais, si vous votez le contraire de ce que votre employeur veut, votre employeur va dire « pourquoi je te paye ? », ça reste du donnant-donnant. Mais oui, en théorie ça pourrait marcher.
Il y a aussi des projets open source qui prennent en compte ceci et qui, du coup, proposent des sièges de mainteneur qui ne sont pas associés à des individus mais à des entreprises, qui disent : « Telle entreprise a investi deux millions d’euros, du coup elle aura cinq mainteneurs » ; ce sont des sièges attribués à l’entreprise. Quand les gens démissionnent ils sont remplacés par d’autres. C’est lié à l’entité et pas à l’individu et on se prémunit là-dessus. En tout cas, ce n’est pas le cas de la plupart des projets de petite taille.
Donc c’est vrai, tout est possible, tout est contractualisable, tout peut se mettre d’accord à l’avance, parce que ce sont des sujets trop importants, je pense, pour être laissés au hasard.

Je vais donner la parole à madame ou mademoiselle.

Public : Est-ce que ça ne risque pas de créer des problèmes au niveau des communautés de dire que la contribution peut être rémunérée ? Est-ce que ça ne risque pas de créer des tensions ?

Mathieu Ferment : Si, il y en a régulièrement. Je ne sais pas s’il y a Drupal [4] aujourd’hui chez nous, je pense que, pendant un moment, cette question s’était posée.
Si, bien sûr, parfois on se demande si les intérêts de l’entreprise vont dans le même sens que les intérêts des gens bénévoles ou non. C’est normal qu’il y ait parfois des petits conflits d’intérêt. L’important c’est de réussir à les résoudre, se mettre d’accord et avancer ensemble.
Oui, du coup, il peut y en avoir comme dans toute entreprise. En fait, un projet open source c’est un groupe d’humains qui bossent ensemble. Qu’ils soient là bénévolement ou pour des entreprises, il y aura toujours des désaccords. Il y a des projets open source où tout le monde est bénévole, il y a quand même des désaccords, il y a quand même des schismes, parce qu’il y en a qui veulent se concentrer sur le futur et abandonner les vieilles features, il y en a qui veulent beaucoup de stabilité, il y en a qui veulent faire cinq nouvelles versions par an, il y en a d’autres qui préfèrent une bien foutue. Donc oui, ce sont des gens qui bossent ensemble, il y a toujours des schismes, mais, pour moi, le jeu en vaut la chandelle, c’est-à-dire que les avantages et les intérêts de l’open source dépassent ces petits tracas, mais, en effet, ils existent.

Je pense que ce sera la dernière question.

Public : Quel est le ratio, à peu près, des entreprises qui contribuent à l’open source ?

Mathieu Ferment : Je suis désolé, je n’ai pas de données fiables là-dessus. Ce que je pourrais dire c’est que, par exemple sur les projets open source très grands, très matures, comme Eclipse, comme Linux, il y a énormément d’entreprises parce qu’il y a des enjeux énormes. Je pensais au grand classique Red Hat [5]. Red Hat est connue pour faire énormément de contributions ; là on est complètement dans une entreprise qui ne fait pas ça par bonté d’âme, mais parce que ça a vraiment un intérêt économique pour elle. Ils sont aussi très sympas. C’est économiquement important, pour eux, que le projet sur lequel ils ont fondé leur business continue à vivre.
Même nous, PrestaShop, nous proposons une solution qui permet aux gens de faire des boutiques, on a un intérêt direct à ce qu’il y ait un maximum d’utilisateurs parce que ce sont des gens à qui, après, on peut vendre des services ou des produits, donc plus il y en a, plus on a de clients potentiels.

Pour terminer, je voulais dire qu’on a effectivement intérêt à ce qu’un maximum de gens contribuent, donc d’entreprises qui contribuent, ça auto-alimente l’écosystème. Plus il y a d’entreprises qui contribuent, plus le projet grandit, du coup plus il y a de clients potentiels.
Ce qui se passe généralement sur un projet open source, c’est que les entreprises qui contribuent ne font pas ça seulement par bonté d’âme, souvent derrière elles vont vendre du service. Par exemple un truc tout bête : vous êtes une entreprise qui contribue énormément au projet Linux. En contribuant, vous faites du code, vous interagissez avec d’autres, peut-être que vous avez des mainteneurs, vous faites de la revue de code. Du coup, vous avez acquis une légitimité et une expertise que vous pouvez monétiser. Vous pouvez dire « je fais de la contribution à Linux depuis dix ans, je suis un expert », donc vous pouvez vous vendre beaucoup plus cher. C’est aussi intéressant pour les entreprises de contribuer juste pour dire « moi, je connais très bien le domaine, c’est pour ça que je demande deux fois plus cher que le voisin ».

On a un tout petit peu dépassé. On ne m’a rien dit, je pense qu’on va s’arrêter là. Si vous avez d’autres questions qui reviennent je serai sur le stand PrestaShop.
Je vous remercie beaucoup et je vous souhaite une très bonne journée.

[Applaudissements]