La gestion d’une communauté de développeurs d’un projet open source est assez délicate. Le langage de programmation Rust, conçu et développé de façon ouverte au sein de Mozilla depuis une bonne dizaine d’années, fait largement appel à sa communauté dans sa structure et son mode de développement.

Son originalité par rapport au management de projet en entreprise apparaît de façon intéressante dans le témoignage et les réflexions de Mara Bos, une jeune développeuse impliquée dans le projet dont Framalang a traduit ci-dessous les propos.

Article original sur le blog de l’autrice : Rust is not a company

Traduction Framalang : Fabrice, Côme, goofy

Rust n’est pas une entreprise

par Mara Bos

L’année dernière, en tant que contributrice occasionnelle au projet Rust, je n’ai pas trop réfléchi à la structure organisationnelle de l’équipe derrière le projet. J’ai vu une hiérarchie d’équipes et de groupes, de chefs d’équipe, etc. Tout comme n’importe quelle autre organisation. Cette année, après m’être davantage impliquée, et devenue membre de l’équipe Library ¹ puis cheffe d’équipe, j’ai pris le temps de me demander pourquoi nous avons cette structure et à quoi servent ces équipes.

Pas une entreprise

Dans la plupart des entreprises, on trouve des directeurs et des actionnaires et autres trucs dans le genre en haut de la hiérarchie, qui définissent les buts de l’entreprise. Objectifs, jalons, dates limites, et autres choses qui vont sûrement mener l’entreprise vers le but final quel qu’il soit ; généralement l’argent.

Ensuite il existe plusieurs niveaux de management répartis en départements et en équipes pour diviser la charge de travail. Chaque niveau prend en charge une part des objectifs et s’assure que sa part est faite, en assignant des tâches aux employés en bas de la hiérarchie, tous travaillant d’une manière ou d’une autre à atteindre l’objectif principal commun.

Alors que la structure derrière un gros projet open source comme Rust peut sembler similaire, vue de loin, c’est souvent complètement l’inverse. Dans un tel projet, les objectifs et buts ne sont pas ceux des équipes d’en haut, mais effectivement ceux des contributeurs.

En tant qu’équipe library, nous pourrions par exemple essayer de décider que le mécanisme de formatage (std::fmt) devrait être réécrit pour être plus petit et plus efficace. Mais prendre cette décision ne provoque pas la réécriture. Et nous n’avons pas d’employés à qui assigner les tâches. Ce n’est pas comme ça que ça fonctionne.

Au lieu de cela, un contributeur passionné d’algorithmes de formatage pourrait se manifester, et commencer à travailler sur le problème. Notre travail en tant qu’équipe library est de faire en sorte que cette personne puisse travailler. S’assurer que son projet est en accord avec le reste de la bibliothèque standard, relire son travail et fournir un retour utile et constructif. Si davantage de personnes interviennent pour collaborer sur ce projet, mettre en place un groupe de travail pour aider à tout organiser, etc.

Les entreprises ne font pas travailler le premier venu sur quelque chose. C’est ce qui fait que l’open source est particulier et si génial, si on s’y prend bien.

Objectifs personnels

Idéalement, l’objectif d’un projet open source comme Rust est simplement la combinaison des buts personnels de toutes les personnes travaillant dessus. Et là est la difficulté. Parce que quand une nouvelle personne arrive, on ne lui assigne pas une tâche qui correspond à nos objectifs. Cette personne arrive plutôt avec ses propres objectifs et ses propres idées, les ajoutant à un ensemble déjà assez varié d’objectifs potentiellement conflictuels.

Et c’est pourquoi un projet open source piloté par des bénévoles a besoin d’une structure de management. On ne peut pas juste mettre ensemble une centaine de personnes avec chacune ses propres buts et espérer que tout se passe bien.

Donc ce que fait le management, c’est prendre en considération tous les buts personnels de toutes les personnes travaillant sur un sujet, et essayer de les guider de manière à ce que les choses fonctionnent. Ça peut impliquer le fait de dire non à des idées quand elles seraient incompatibles avec d’autres idées, ou ça peut impliquer beaucoup de discussions pour harmoniser les idées afin qu’elles soient compatibles. C’est exactement l’opposé de la manière dont fonctionne une entreprise typique, où les objectifs viennent d’en haut, et où le management décide de la manière de les répartir et les assigner aux personnes qui effectuent le travail technique.

Alors que beaucoup de projets open source, dont Rust, ont un cap ou un plan d’action, ces derniers doivent reposer sur les objectifs des contributeurs individuels du projet pour que ça fonctionne. Dire « notre objectif principal en 2021 est d’améliorer les mécanismes de formatage dans la bibliothèque standard » devrait faciliter le travail des personnes travaillant déjà dessus, et attirer les personnes qui voulaient déjà travailler sur quelque chose de ce genre. Ça devrait les aider parce que nous priorisons toutes les décisions de management et les révisions de code dont ils ont besoin. Ça devrait permettre aux personnes de se concentrer et d’avancer davantage. Mais sans ces contributeurs, mettre en place de tels objectifs n’a pas de sens. Contrairement à une entreprise, nous n’avons pas à choisir ce sur quoi les personnes passent leur temps, et nous n’employons pas de personnes auxquelles assigner des tâches.

Et c’est une bonne chose.

C’est la raison pour laquelle les gens veulent travailler sur Rust.

Je ne prétends pas qu’un langage de programmation ne pourrait pas être géré « d’en haut » comme une entreprise le ferait. Beaucoup de langages de programmation ont été et sont développés de cette manière avec beaucoup d’efficacité. Ce que je dis, cependant, c’est que personnellement je ne veux pas que le projet Rust fonctionne de cette manière.

Je ne veux pas gérer le département library de l’entreprise Rust. Je veux aider les personnes qui veulent améliorer les bibliothèques du langage Rust.

Un espace pour s’épanouir

Différents contributeurs ont des objectifs très différents, travaillent avec des méthodes très variées, et ont des besoins très différents des structures de management.

Pour certains d’entre eux, nous avons des processus en place destinés à leur rendre le travail plus facile. Une personne qui veut travailler sur une nouvelle fonctionnalité du langage peut soumettre ses idées via une RFC ² et prendre part dans une discussion avec l’équipe library pour des conseils et de l’aide. Quelqu’un qui veut améliorer une grande partie du code du compilateur ³ peut soumettre une proposition de changement majeur (MCP) et en discuter avec l’équipe du compilateur. Et quelqu’un qui veut résoudre un problème dans la bibliothèque standard peut soumettre une proposition de modification et la voir relue et évaluée par des personnes qui connaissent le contexte.

En d’autres termes, nous avons créé un espace pour ces types de contributeurs. De l’espace pour faire leur travail, de l’espace pour obtenir des retours, de l’espace pour obtenir de l’aide, de l’espace pour obtenir une reconnaissance, tout l’espace dont ils ont besoin pour réussir.

Cependant, il existe malheureusement beaucoup de types de contributeurs pour lesquels nous n’avons pas créé un espace, ou pas le bon espace.

Jusqu’à une époque récente, l’équipe library était principalement concentrée sur la conception de l’API. Les problèmes critiques d’implémentation étaient gérés par l’équipe du compilateur par nécessité. Les modifications de code plus modestes étaient relus et évalués par des relecteurs individuels de l’équipe library. Mais il n’y avait pas de gestion prévue pour de plus gros changements de code. Ça signifiait qu’il n’y avait pas d’espace pour une personne qui aurait voulu remettre à neuf le code de std::fmt. Il n’y avait pas d’équipe qu’elle aurait plus rejoindre pour travailler là-dessus, rendant beaucoup plus difficile, voire impossible, d’atteindre son but.

C’est pourquoi j’ai lancé la nouvelle équipe Library.

Faire de la place pour quelque chose peut souvent amener à (accidentellement) retirer de la place pour autre chose. Une personne qui n’est pas très impliquée dans le code mais qui veut appliquer son expérience dans la conception d’API et qui se soucie beaucoup de l’interface de la bibliothèque standard ne s’épanouirait pas dans une équipe qui aime avoir des réunions hebdomadaires à propos des problèmes de correction du code et de la manière avec laquelle résoudre ces problèmes avant la prochaine version publique.

Voilà pourquoi nous avons à présent l’équipe Library API

Nous avons maintenant aussi une équipe de « Contributeurs à Library ». Un endroit pour les personnes qui sont plus impliquées dans le projet que les contributeurs occasionnels, mais qui ne font pas partie des équipes qui prennent les décisions finales. Ça fait de l’espace pour les personnes qui veulent, par exemple, travailler sur seulement un aspect particulier de la bibliothèque, ou aider à relire les modifications proposées. Jusqu’à il y a environ un an, il n’y avait pas d’espace particulier pour qu’une personne relise les changements ou qu’elle s’implique davantage d’autres manières, sans faire directement partie d’une équipe avec beaucoup plus de responsabilités.

J’ai réussi à effectuer ces changements de structure d’équipe avec l’aide des membres des équipes Core et Library, qui m’ont mise en capacité de le faire. En retour, ces changements vont, je l’espère, permettre à des membres de ces nouvelles équipes de s’épanouir, et ainsi permettre à encore plus de personnes de contribuer, pour que finalement cela soit bénéfique pour tous les utilisateurs et utilisatrices du langage.

Continuer à changer

Je n’ai pas l’impression que nous ayons maintenant un espace pour toute personne souhaitant contribuer. Mais une fois que la poussière de la réorganisation se sera dispersée, je pense que le résultat sera une amélioration par rapport à ce que nous avions auparavant, et que ça correspond mieux au projet tel qu’il est aujourd’hui.

« Aujourd’hui » est le mot important ici. Ces équipes sont faites autour des membres actuels et des personnes qui, je pense, pourraient devenir des membres dans un futur proche. Mais ce groupe de personnes et leurs besoins changent, parfois à une vitesse surprenante. Et dans un projet qui est entièrement défini par les personnes qui y contribuent, ça change le projet en lui-même et la structure dont il a besoin, tout aussi rapidement.

En 2018, l’équipe Library était très impliquée dans l’aide aux auteurs des bibliothèques ⁴ populaires de l’écosystème. L’équipe a publié un ensemble de guides, et va réviser les bibliothèques et travailler conjointement avec leurs auteurs pour les implémenter. Tout cela pour améliorer la cohérence et la qualité de l’écosystème de librairies Rust.

Il y a quelques jours encore, c’était toujours techniquement une partie des buts affichés de l’équipe, même si en pratique ça n’était plus vraiment le cas ; particulièrement depuis qu’Ashley Mannix a quitté le projet il y a un moment. Sans les personnes qui ont pour but personnel de faire que des choses se produisent, les choses ne se produisent pas.

Et c’est très bien comme ça.

Tout le monde a une longue liste de vœux pour Rust, de choses qui ne se font pas parce que personne ne travaille dessus. Nous ne sommes pas une entreprise avec des dates limites et des jalons qu’il nous faut absolument atteindre. Nous sommes un groupe, divers et fluctuant, de personnes qui essaient de gérer tout ça avec passion, en s’efforçant de faire en sorte que tous les efforts aboutissent harmonieusement.

Il y a beaucoup de choses pour lesquelles nous devrions avoir de l’espace, mais pour lesquelles nous n’avons encore de place. Mais si nous continuons à essayer, si nous continuons à effectuer de petites améliorations. À nous adapter. À prendre en compte les personnes autour de nous qui veulent contribuer elles aussi ; si nous continuons à réfléchir à la façon dont nous pouvons les aider, eux et tous les autres. Alors chaque pas sera un pas dans la bonne direction, ainsi Rust prospérera et toutes les nombreuses personnes qui travaillent sur Rust et avec Rust s’épanouiront.

Photo « Rusty but pretty »  par Jeanne à vélo, licence CC-BY-SA

Attention, cet article va parler d’un sujet qui a été tellement polarisé qu’il transforme de nombreuses personnes en troll·e·s : l’écriture inclusive. Mais en fait on ne va pas du tout parler de ça. On va parler de Liberté et de libertés, tiens !

Premièrement : vous avez raison

On va mettre tout le monde d’accord d’un coup (quitte à vous mettre d’accord pour nous taper dessus)… quoi que vous pensiez sur l’écriture inclusive : vous avez raison.

Vous pensez que cela va changer les esprits et permettre de réduire les inégalités ? Vous avez raison. Vous pensez que c’est inefficace et inutile ? Vous avez raison.

Vous pensez que c’est une mode ? Vous avez raison. Vous pensez que c’est une évolution ? Vous avez raison.

Vous pensez que c’est un juste contrepoids à une masculinisation de notre langue par l’académie française lors de sa création au XVIIe siècle ? Vous avez raison. Vous pensez que l’académie française actuelle l’ayant officiellement comparée à un péril mortel, il ne faut pas l’utiliser ? Vous avez raison.

Vous vous en foutez royalement, tyranniquement ou démocratiquement…?

Vous. Avez. Raison.

Vous avez raison parce que vous avez vos raisons (ou même vos absences de raisons, pour les personnes qui s’en cognent). Vos opinions sur l’écriture inclusive peuvent être étayées par des faits, des autorités, des réflexions et de fait vous semblent parfaitement valides, mais elles restent cela : des opinions (ou absences d’opinions, n’oublions pas le droit de s’en foutre).

Car nos manières de pratiquer une langue vivante restent des choix : personnels, collectifs, politiques, poétiques… Mais des choix subjectifs. Ou des absences de choix, parce que saperlipopette, on a aussi le droit de se laisser porter !

Deuxièmement : nous aussi

Chez Framasoft, cela fait plus de trois ans que ce choix est fait.

Le 27 février 2015, on pouvait lire dans cet article du Framablog :

On le sait, les libristes s’ennuient durant les week-end, tant ils croulent sous le temps libre, tant elles n’ont rien d’autre à faire que jouer à SuperTuxKart.

Quelques jours avant, c’est le mot « les rêveureuses » qui s’y affiche , quand on n’y parle pas carrément des « barbu-e-s » (déc. 2015) afin de désigner les informaticiennes et informaticiens libristes (pour tirer la langue à cette expression communautaire excluant, de fait, les visages glabres).

Quant à notre newsletter, suivie par plus de 95 000 inscrit·e·s, c’est pas mieux : dès 2015 les « ils et elles » y fleurissent, on y évoque « nos salarié-e-s » en 2016, ou on y imagine carrément les « chef-fe-s » du petit village libriste !

En fait, nos usages et manières ont progressé au fil de nos réflexions, et ce n’est que le 22 février 2017 que, suite à de rares commentaires ici ou là, notre comité communication décide d’ajouter cette réponse dans notre foire aux questions, afin de répondre par avance à toute interrogation, et d’expliquer pourquoi nous laissons des graphies novatrices s’exprimer dans nos communications.

Troisièmement : ça pique un peu au début…

Alors oui, on le sait, lire de tels bidouillages de la langue française, ça perturbe. Nous le savons parce que nous aussi nous l’avons vécu. On est là, installé·e·s pépères dans une utilisation d’une langue que l’on s’est fait ch#£§ à apprendre durant de longues années, quand soudain des graphies nous rappellent que mémère existe aussi. Sans compter que, derrière tout cela, y’a une question -presque une accusation- qui vient se chuchoter dans nos pensées…

Aurais-je été sexiste tout ce temps, sans le savoir, juste en faisant des phrases…?

Alors là, c’est non : notre esprit se défend et sort les griffes… C’est normal, hein : il fait son boulot d’esprit. La neuro-biologie nous apprend que, lorsque nous sommes confronté·e·s à quelque chose qui remet en questions nos croyances les plus profondes, notre cerveau réagit comme si nous étions physiquement agressé·e·s.

Or les croyances « je ne suis pas sexiste » ou « je sais comment s’écrit le bon Français » sont souvent chères à nos esprits : elles sont identitaires. Nos esprits se défendent donc avec de multiples objections bien connues : « c’est moche », « c’est illisible », « c’est pas français », « c’est la novlangue de la pensée unique », « c’est excluant », etc. C’est un mécanisme de défense que les libristes connaissent bien. Qui n’a jamais entendu un « Je n’ai rien à cacher » après avoir remis en question la croyance « mes pratiques numériques sont saines »…?

Chez Framasoft, nombre de nos membres ont vécu ces objections : nous les connaissons intimement. Nous en avons discuté, débattu, argumenté (la question de l’accessibilité, par exemple, mérite que l’on se penche dessus, donc nous l’avons fait). Nous en avons déterminé qu’il ne s’agissait pas de nous, mais de Liberté.

Quatrièmement : …mais après ça passe

Parce qu’en fait, si on parvient à mettre en sourdine le « scrogneugneu, mais c’est pas comme ça que ça s’écrit » qui crie très fort en nous… eh bien on s’habitue ! Ne sous-estimons pas nos cerveaux : ils ont une capacité de résilience qui peut nous surprendre nous-mêmes…

D’expérience (et qui vaut ce qu’elle vaut, hein, z’avez le droit de ne pas être d’accord), on peut très vite s’habituer, ne plus trébucher mentalement sur des nouveautés linguistiques. De nos jours, écrire ou dire que « c’est relou », ne choque plus les esprits (sauf dans un contexte où on doit parler soutenu), mais à une époque pas si lointaine, lorsque l’on craignait les « loubards » en blousons noirs, le verlan était socialement choquant…

Car la seule chose qui nous empêche de nous habituer à des graphies novatrices : c’est nous.

C’est quand on ne veut pas, qu’on en a pas envie. Et pourquoi pas : vous avez le droit de refuser de voir votre langue, un outil profondément lié à nos identités, écrite de manière X ou Y. Vous pouvez ne pas en avoir envie…

Comme nous, dans notre association, nous pouvons avoir envie d’user de points médians (ou de smileys :p… ). Car, dans un cas comme dans l’autre, nous faisons un choix personnel, nous usons de notre Liberté.

Cinquièmement : pourquoi maintenant ?

Au-delà de ce débat qui, pour nous, se résume en une phrase (nous ne transigerons pas sur les libertés), il y a une question à se poser. Depuis plus de trois ans que nous expérimentons avec la langue (tout en faisant des efforts typographiques, orthographiques, et grammaticaux que personne ne vient saluer, snif !), les remarques et commentaires trollesques ne pleuvent que depuis environ neuf mois.

En novembre 2017, il y a eu un débat soulevé dans les médias de masse. Depuis, nous voyons quotidiennement combien il n’est plus possible de discuter paisiblement.

C’est comme s’il y avait une guerre, qu’il fallait choisir son camp, et pis si t’es pas avec nous t’es contre nous… La question s’est polarisée au point de caricaturer les pires personnages de jeux de baston :

HystéroFémiNazie VS FachoMascuMacho,
Round 1,
FIGHT !

Vous trouvez pas qu’on s’est un peu fait embourber nos esprits dans une ambiance de merde…? Combien de personnes, aujourd’hui, revendiquent le droit d’en avoir rien à foutre du point médian, de s’en cogner de la double flexion, et de n’avoir aucun avis sur la règle de proximité ? Qui pense encore, dans ce débat, au fait que dire « chacun et chacune » (la double flexion, donc) est tout autant une marque du langage inclusif que « chacun·e »…?

Mais surtout : où étaient nos critiques littéraires ces trois dernières années ? Que faisaient ces personnes, et pourquoi ne veillaient-elles pas à notre salut linguistique auparavant ? Il peut être bon de se demander, chacun et chacune (tiens !) en son for intérieur, pourquoi est-ce que l’on a commencé à avoir un avis sur la question (en novembre dernier)… plutôt que de bidouiller avec, juste pour voir comment ça fait, pour voir ce que ça change.

Finalement : la liberté n’est pas négociable

Chez Framasoft, nous sommes attentifves : croyez-le ou non, mais nous veillons à rester intelligibles. Si nous publions un texte de telle ou telle manière, c’est que nous avons estimé, collégialement et dans notre entière subjectivité, qu’il est intelligible.

Intelligible ne signifie pas confortable, hein. Utiliser les dissonances cognitives que provoquent les expressions inhabituelles peut être un outil pour communiquer ce que l’on souhaite transmettre. C’est un choix dans la méthode, qui peut sembler approprié à l’auteur·rice d’un texte, et aux personnes qui relisent.

La Liberté, chez Framasoft, c’est pas négociable. Nous en avons parlé lors de notre dernière assemblée générale : nous faire aimer/apprécier/bien voir, vouloir séduire/éduquer/convertir les gens à la cause du libre, cela ne se fera pas à tout prix. Ce serait chercher une universalité quasi-impossible, et qui (à nos yeux) mène sur le chemin du plus petit dénominateur commun, celui des idiocraties googlesques qui nous rebutent. Bref, on va pas se renier, pas au prix de nos libertés ni de nos convictions.

Et les libertés des personnes qui, volontairement, refusent de supporter le langage épicène, les pauvres …?

Nous avons fait en sorte que vous ayez le droit de reprendre nos publications (sous licence CC-By-SA, sauf mention contraire) et les traduire en langage traditionaliste (comme d’autres les traduisent en italien, en anglais, et merci !). Nous avons fait en sorte de n’obliger aucun·e membre, aucune personne qui contribue à nos actions, à utiliser telles ou telles règles (d’ailleurs, nombre de nos textes sont aussi en langage traditionnel, et c’est OK pour nous).

Nous savons les internets assez grands pour que chacun·e (tiens !) puisse y trouver son bonheur… Sans forcément aller faire les gros n’yeux aux autres parce que « ielles ne font pas comme il faut, c’est à dire comme moi je veux ! ». On peut même renvoyer les ronchonchons aux conditions générales d’utilisations de nos services (dont le blog, la newsletter, etc. font partie), clause « si ça vous va pas, vous êtes libres d’aller voir ailleurs » (allez lire, ça prend 3mn et c’est bel et bien écrit dedans).

Offrons-nous la paix

C’est un peu violent, comme conclusion, non…? Il faut dire que le cumul des remarques trollesques et de mauvaise foi que nous essuyons depuis des mois est franchement frustrant, et cette accumulation, nous la vivons comme une violence… Il est temps de briser ce cercle vicieux.

Là où nous sommes d’accord avec nos détracteurices (soyons fous… et folles : hop, un mot-valise !), c’est que les questions de genre et de linguistique ne sont pas le but premier de Framasoft… Alors pourquoi venir les commenter ? Pourquoi détourner l’attention de ce que nous faisons en faisant remarquer quelques pauvres signes de ponctuation…?

Ne pourrait-on pas vivre, et laisser vivre…?

Peut-on passer à autre chose…?

Nous l’espérons, et vous faisons confiance.

Après l’introduction du livre Des routes et des ponts de Nadia Eghbal (si vous avez raté le début…) que le groupe Framalang vous traduit au fil des semaines, voici un aperçu tout simple des composants de base d’un logiciel.

Nos lecteurs les plus au courant n’y trouveront rien qu’ils ne sachent déjà, mais l’intérêt de cette présentation c’est justement qu’elle rend abordables et compréhensibles au grand public des objets techniques qui peuvent s’avérer très complexes à comprendre (…et maîtriser !). On peut dire que la démarche choisie ici, pragmatique et imagée, ne manque pas de pédagogie.
Merci à nos lecteurs soucieux des valeurs du libre de noter que l’auteur n’introduit les notions que progressivement : c’est seulement dans quelques chapitres qu’elle établira clairement une distinction claire qui nous est chère.

Vous souhaitez participer à la traduction hebdomadaire ? Rejoignez Framalang ou rendez-vous sur un pad dont l’adresse sera donnée sur Framasphère chaque mardi à 19h… mais si vous passez après vous êtes les bienvenu.e.s aussi !

De quoi sont faits les logiciels

par Nadia Eghbal

Traduction framalang : Luc, woof, Diane, xi, serici, Lumibd, goofy, alien spoon, flo, salade, AFS, lyn., anthony

Tous les sites web ou les applications mobiles que nous utilisons, même les plus simples, sont constitués de multiples composants plus petits, tout comme un immeuble est fait de briques et de ciment.

Imaginez par exemple que vous désiriez poster une photo sur Facebook. Vous ouvrez votre appli mobile Facebook, ce qui déclenche le logiciel de Facebook pour vous afficher votre fil d’actualités.

Vous téléchargez une photo depuis votre téléphone, ajoutez un commentaire, puis vous cliquez sur « Envoyer ». Une autre partie du logiciel de Facebook, en charge du stockage des données, se souvient de votre identité et poste la photo sur votre profil. Finalement, une troisième partie de ce logiciel prend le message que vous avez saisi sur votre téléphone et le montre à tous vos amis à travers le monde.

Bien que ces opérations aient lieu sur Facebook, en réalité, ce n’est pas Facebook qui a développé toutes les briques nécessaires pour vous permettre de publier sur son application. Ses développeurs ont plutôt utilisé du code libre, public, mis à disposition de tous sur Internet par des bénévoles. Facebook ne publie pas la liste des projets qu’ils utilisent, mais une de ses filiales, Instagram, le fait et remercie certains de ces projets sur sa page d’accueil et dans son application mobile

Utiliser du code public est plus efficace pour des entreprises comme Facebook ou Instagram que de développer à nouveau tous les composants par elles-mêmes. Développer un logiciel est comparable à la construction d’un immeuble. Une entreprise du bâtiment ne produit pas ses marteaux et ses perceuses, et n’ira pas non plus chercher du bois pour découper les troncs en planches.

Elle préférera les acheter à un fournisseur et se fournir en bois auprès d’une scierie pour finir le travail plus rapidement.

Grâce aux licences permissives, les sociétés telles que Facebook ou Instagram ne sont pas obligées de payer pour ce code, mais sont libres d’en profiter grassement. Ce n’est pas différent d’une entreprise de transport (Instagram) qui utilise les infrastructures routières publiques (code public) pour acheminer ses produits à des fins commerciales (application Instagram).

Mike Krieger, un des co-fondateurs d’Instagram, a insisté sur ce point en 2013 et encouragé d’autres entrepreneurs à :

emprunter plutôt que construire à chaque fois que c’est possible. Il existe des centaines d’excellents outils qui peuvent vous faire gagner du temps et vous permettre de véritablement vous concentrer sur le développement de votre produit. (source)

Voici quelques-uns des outils utilisés par une entreprise de logiciels :

Frameworks (environnements de développement)

Les framewoks offrent une base, une sorte d’échafaudage, une structure. Imaginez cela comme un schéma pour toute une application. Comme un plan, un framework définit la manière dont l’application se comportera sur mobile, ou comment ses données seront sauvegardées dans une base de données. Par exemple Rails et Django sont des frameworks.

Langages

Les langages de programmation constituent l’épine dorsale de la communication des logiciels, comme la langue anglaise (NdT : aux USA bien sûr) qu’emploient les ouvriers du bâtiment sur un chantier pour se comprendre. Les langages de programmation permettent aux divers composants du logiciel d’agir et de communiquer entre eux. Si par exemple vous créez un compte sur un site internet et que vous cliquez sur « S’enregistrer », cette application peut utiliser des langages comme le JavaScript ou le Ruby pour sauvegarder vos informations dans une base de données.

Parmi les langages de programmation les plus populaires on peut mentionner le Python, le JavaScript et le C.

Bibliothèques

Les bibliothèques sont des fonctions pré-fabriqués qui accélèrent l’écriture du code d’un logiciel, tout comme une entreprise du bâtiment achète des fenêtres préfabriquées au lieu de les assembler à partir des composants de base. Par exemple, au lieu de développer leur propre système d’identification pour les utilisateurs de leur application, les développeurs et développeuses peuvent utiliser une bibliothèque appelée OAuth. Au lieu d’écrire leur propre code pour visualiser des données sur une page web, ils ou elles peuvent utiliser une bibliothèque appelée d3.

Bases de données

Les bases de données stockent des informations (profils d’utilisateurs, adresses électroniques ou codes de cartes bancaires par exemple) qui peuvent être utilisées par l’application. À chaque fois qu’une application a besoin de se souvenir d’une information qui vous concerne, l’application la stocke dans la base de données. Parmi les systèmes de gestion de bases de données (SGBD) les plus populaires on trouve notamment MySQL et PostgreSQL.

Serveurs web et d’applications

Ces serveurs gèrent certaines requêtes envoyées par les utilisateurs sur Internet : on peut les voir comme des centrales téléphoniques qui répartissent les appels. Par exemple, si vous saisissez une URL dans la barre d’adresse de votre navigateur, un serveur web vous répondra en vous envoyant la page concernée. Si vous envoyez un message à un ami sur Facebook, le message sera d’abord envoyé à un serveur d’applications qui déterminera qui vous essayez de contacter puis transmettra votre message au compte de votre ami.

Parmi les serveurs web très répandus, citons Apache et Nginx.

Certains de ces outils, comme les serveurs et les bases de données, sont coûteux, surtout à l’échelle d’une entreprise, ce qui les rend plus faciles à monétiser. Par exemple, Heroku, une plate-forme sur le cloud (sur un serveur distant) qui fournit des solutions d’hébergement et de bases de données, propose une offre de base gratuite, mais il faut payer pour avoir accès à plus de données ou de bande passante. De grands sites reposent sur Heroku comme ceux de Toyota ou de Macy, et l’entreprise a été rachetée en 2010 par Salesforce.com pour 212 millions de dollars.

Il est plus difficile de faire payer d’autres types d’outils de développement, tel que les frameworks, de nombreuses bibliothèques et langages de programmation, qui sont souvent créés et maintenus par des bénévoles.

Ce type d’outils ressemble plus à des ressources qu’à des services qui peuvent être activés ou désactivés : les rendre payants limiterait fortement leur adoption. C’est pourquoi n’importe qui, que ce soit une entreprise milliardaire ou un adolescent apprenti développeur, peut utiliser gratuitement ces composants pour créer ses propres logiciels.

Par exemple, selon la page d’accueil d’Instagram, l’une des bibliothèques utilisées par l’entreprise est Appirater. Il s’agit d’une bibliothèque qui facilite les fonctions de rappels automatiques pour l’évaluation d’une application, à destination des utilisateurs d’iPhone. Elle a été créée en 2009 par Arash Payan, un développeur indépendant basé à Los Angeles. Le projet n’apporte aucun revenu à Payan.

C’est comme si des scieries, des centrales à béton et des magasins de matériel donnaient leurs matériaux de base à une entreprise du bâtiment, puis continuaient à approvisionner cette entreprise.