Les contributions au logiciel libre sont-elles uniquement destinées à des fins humanistes

Titre : Les contributions au logiciel libre sont-elles uniquement destinées à des fins humanistes ?

Intervenant : Mathieu Ferment

Lieu : Paris - Salon Open Source Experience

Date : 7 décembre 2022

Durée : 47 min 11

Vidéo

Licence de la transcription : Verbatim

Illustration : À prévoir

NB : transcription réalisée par nos soins, fidèle aux propos des intervenant·e·s mais rendant le discours fluide.
Les positions exprimées sont celles des personnes qui interviennent et ne rejoignent pas nécessairement celles de l'April, qui ne sera en aucun cas tenue responsable de leurs propos.

Introduction

Au cours de cette présentation, nous mettrons en évidence la manière dont les entreprises de toutes tailles peuvent influencer un projet open source et y contribuer par le biais de leurs équipes, pour finalement apporter de la valeur, tant au projet qu’à l’entreprise contributrice.

Transcription

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 que je vous propose d'explorer 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 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. Du coup, quand j’ai rejoint PrestaShop en 2018, c'est comme ça 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 mets mes 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 WordPress.

Mathieu Ferment : Très bien. Du coup, j’aurais une question : si vous vous rappelez 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 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 ces traductions avec quelques corrections.

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, généralement quand ils veulent s’améliorer, 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 » : et bien, 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 ils vont vous dire si elle est bonne ou pas bonne, ce qu’on appelle la revue de code. C’est impressionnant si on y réfléchit : en vrai 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. Je suis aujourd’hui 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 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 contribution open source » et là votre frigo lâche. Je suis certain que s’il faut choisir entre réparer/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 boom !, on m’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 dire « OK, je fais 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, s’il y a le monsieur au fond qui a bientôt des développeurs et qui a bientôt une entreprise florissante, dit à son développeur salarié, lundi, « toute la journée tu fais de l’open source », peu importe si son frigo est cassé, peu importe s’il a d’autres priorités, là il est sponsorisé, il est missionné, il est payé pour faire ses contributions. Au moins ç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 il y a une entreprise qui paye cette personne 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 comme webcomic très connu par les 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 elle est vraie, je n’ai pas de données fiables là-dessus. Le fait que ça fait rire beaucoup de gens me laisse penser que beaucoup de gens pensent ça. Ça représente quoi ? Ç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, 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. C’était 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 les entreprises qui utilisent mon code 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 que je voulais des contributions des entreprises.

11’ 38

Du coup, 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. Ce que je veux dire par là c’est que, 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 et elle espère qu’avec toutes ces dépenses elle va 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 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.
Du coup, je vais essayer de montrer aux entrepreneurs qui sont présents aujourd’hui - et il y aura un replay qu’ils 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 : 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, c’est 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 comme entrepreneur parce que 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 ça 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.
Du coup, il y a un coût de maintenance qui vient. Vous devez en prendre soin. Vous devez imaginer que demain 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.
Du coup, 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 bugs fixés, pas de nouveaux correctifs, il n’y aura pas de nouvelles améliorations de performance. On va dire que cette library était en Rust et 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. C’est 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 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 que 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.

Du coup, 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 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 pour vous ce correctif logiciel, soit ce correctif logiciel, vous le contribuez 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 librairy 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 et 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. Et ça, pour un entrepreneur c’est génial. Ce sont d’autres gens qui vont maintenir pour vous le code que vous avez 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 [d’un 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 bests 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é, on a 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. Et, pour un entrepreneur, tout ça c’est aussi gratuit, ce n’est que du bonheur !

23’ 30

J’ai 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 Fourdry Foundation.
On va supposer que là tout le monde est très convaincu et je vais aussi opposer 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 à 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, on va se simplifier la vie, on va dire que dans chaque entreprise qui est 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 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 et, 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.

Si 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 les entreprises ne travaillent plus chacune sur ses chantiers, sur ce qu’elle veut [26 min 00] ; à la fin, elles mettent tout en commun dans un projet et chacune des entreprises 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, du coup, 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 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 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 si c’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 de bonnes contributions, ton code est de qualité, tu ne veux pas nous rejoindre côté mainteneur ? Tu ne peux 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.
Il est possible, si vous contribuez régulièrement à un projet open source, 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, en vrai, il y a 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 Eclypse 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 il fait 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, parce que 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 et 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 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 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 qu’on partage le fardeau de la maintenance, donc c’est littéralement de l’argent en moins à dépenser et on profite du processus de qualité. Tout le monde gagne, c’est pour moi la meilleure des raisons : quand on fait de l’open source, tout le monde met en commun son travail et, du coup, on participe un petit peu et on reçoit 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]

35’ 35

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 ??? et le fait d’avoir un compte GitHub. Je participe au nom de mon entreprise à un code open source. Mon entreprise décide que mon code sur GitHub appartient à l’entreprise. Derrière un recruteur voit mon profil, il voit plus mon profil public que mon profil entreprise. Dans ce cas-là, comment on gère les choses ? Est-ce qu’on peut pour finalement tout n’a pas été vu, parce que moi je fais aussi beaucoup dans mon entreprise plus qu’à titre personnel.

Mathieu Ferment : Je confirme qu’effectivement là c’est 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 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. Donc 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 : Il y a tout à fait 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. Si ça vous intéresse, par contre 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 les 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. Effectivement, les projets open source c'est un peu comme une OPA économiquement. Si vous avez une entreprise qui investit fortement et 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 et 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 alors que je suis employé dans une entreprise qui fait des contributions, avec le fait que je suis employé de cette entreprise qui 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 : C’est à discuter avec l’entreprise en question. Je ne peux 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 sont contractualisent ça parce qu’elles le prévoient à l’avance. Si rien n’est contractualisé j’imagine que ce serait possible. Du coup, si vous votez le contraire de ce que votre employeur veut, votre employeur va dire « pourquoi je te paye ? », ça va être 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 ils auront 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 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 exempl,e 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. 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, mais économiquement pour eux c’est important que le projet sur lequel ils ont fondé leur business continue à vivre.
Même nous, PrestaShop, nous proposons une solution aux gens qui permet 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 des 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, du coup 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]