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 à de fins humanistes ? » C’est la question que le vous propose qu’on 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 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 permet vous 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 « aller, 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 rappelez de l’une de vos premières contributions, pourquoi avez-vous fait cette contribution ? Qu’est-ce que 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 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 ç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 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 », eh 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 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 dan 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. Cest 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 pour lesquelles 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. 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 j’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 est basé 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 le 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 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 de 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 elles.

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 en 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, c’est du machine learning. Est-ce que je vais recoder ma propre librairy de machine learning ? Est-ce que je vais recoder ça ? Non. Il y a des dizaines des centaines de librairies 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 librairy open source pour construire mon application, à partir du moment où j’utilise cette librairy 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 librairy, 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 librairy 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êtes 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 librairy, 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 librairy é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 : 4pour 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 librairy 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