Nous arrivons bientôt au terme de notre traduction semaine après semaine de l’ouvrage Des routes et des ponts de Nadia Eghbal (version originale en PDF). Pour remonter vers les épisodes précédents il suffit de cliquer sur ce lien.

Aujourd’hui nous vous proposons un chapitre qui recense les moyens dont les institutions et entreprises pourraient contribuer au développement et à la pérennité des projets open source qui constituent la colonne vertébrale de l’infrastructure numérique.

Traduction Framalang : Penguin, lyn, goofy, Opsylac, xXx

Une esquisse du tableau

Il est trop tôt pour dire à quoi devrait ressembler le soutien institutionnel à long terme d’un point de vue prospectif, mais il y a plusieurs domaines de travail critiques qui peuvent nous aider à le déterminer. Les propositions suivantes sont rattachées à trois domaines :

• Traiter les infrastructures numériques comme un bien commun essentiel et les élever au rang d’acteur intersectoriel clé ;
• Travailler avec des projets pour améliorer les standards, la sécurité et les flux de production ;
• Augmenter la taille du groupe de contributeurs de manière à ce que davantage de personnes, et davantage de personnes de types différents, puissent élaborer et soutenir ensemble les logiciels publics.

Conscientiser et éduquer les acteurs clés

Comme nous l’avons relevé dans ce rapport, beaucoup d’acteurs clés — dont les startups, les gouvernements, et les sociétés de capital risque — pensent à tort que les logiciels publics « fonctionnent, tout simplement » et ne requiert pas de maintenance supplémentaire. Pour entretenir correctement l’écosystème de nos infrastructures numériques, ces populations devraient être les premières à être informées du problème. Les infrastructures numériques ont besoin de porte-paroles qui soient affranchis de toute contrainte politique ou commerciale et qui puissent comprendre et communiquer les besoins de l’écosystème.

Traiter les infrastructures numériques comme des biens publics essentiels pourrait également motiver l’investissement direct dans la construction de meilleurs systèmes à partir de zéro. Par exemple, aux États-Unis, les autoroutes inter-états et le réseau de bibliothèques publiques furent dès l’origine conçus comme des ressources publiques. Les unes et les autres ont eu leur champion (respectivement le Président Dwight Eisenhower et le philanthrope Andrew Carnegie) qui ont clairement argumenté en faveur du bénéfice social et financier qui résulterait de tels projets.

Un réseau national d’autoroutes ne sert pas uniquement à nous relier en tant qu’individus, en facilitant les déplacements d’un endroit à un autre, mais il apporte aussi la prospérité financière dans tous les coins du pays, grâce à l’usage commercial des voies rapides pour acheminer les marchandises. Dans les bibliothèques Andrew Carnegie, publiques et gratuites, les livres étaient accessibles et non stockés en magasin, pour permettre aux gens de les feuilleter et d’y trouver eux-mêmes l’information sans avoir recours à un⋅e bibliothécaire. Cette pratique a aidé à démocratiser l’information et à donner aux gens les moyens de s’éduquer eux-mêmes.

Une meilleure éducation et une meilleure prise de conscience pourraient s’étendre jusqu’aux gouvernements, dont certains ont rendu, par la loi, les infrastructures numériques difficiles à soutenir et qui ne sont peut-être pas familiers des normes culturelles et de l’histoire de l’open source. Aux USA, l’IRS [NdT : Internal Revenue Service – organisme qui collecte l’impôt] a une définition très restrictive des activités caritatives, et comme l’open source est mal comprise, son impact positif sur la société demeure ignoré. Cela complique l’institutionnalisation de plus gros projets à travers une fondation ou une association professionnelle.

Mesurer l’utilisation et l’impact de l’infrastructure numérique

L’impact de l’infrastructure numérique est encore très difficile à mesurer. Les indicateurs habituels sont soit très imprécis, soit simplement indisponibles. Ce n’est pas un problème facile à résoudre. Mais sans données relatives aux outils utilisés et à notre dépendance vis-à-vis d’eux, il est difficile de se faire une idée nette de ce qui manque de financement.

Avec de meilleurs indicateurs, nous pourrions décrire l’impact économique de l’infrastructure numérique, identifier les projets essentiels qui manquent de financement, et comprendre les dépendances entre les projets et entre les personnes. Pour le moment, il est impossible de dire qui utilise un projet open source à moins que l’utilisateur, individu ou entreprise, ne le révèle. Pour déterminer quel projet a besoin de plus de soutien, nous ne disposons que d’informations anecdotiques.

De meilleures statistiques pourraient également nous aider à identifier les « contributeurs clé de voûte ». En biologie environnementale, une « espèce clé » est une espèce animale qui a un impact disproportionné sur son environnement au regard de ses effectifs. Dans la même idée, un « contributeur clé » pourrait être un développeur qui contribue à plusieurs projets essentiels, qui est le seul responsable d’un projet crucial, ou qui est généralement perçu comme influent et digne de confiance. Les « contributeurs clés » sont des défenseurs essentiels, les valoriser en leur fournissant les ressources dont ils ont besoin pourrait améliorer le système dans son ensemble. Comprendre les relations entre les communautés open source et les « contributeurs clés » pourrait aider à identifier rapidement les secteurs qui auront besoin de soutien supplémentaire.

On dispose également de peu de données sur les contributeurs eux-mêmes : qui contribue à l’open source, quelles conditions leur permettent de le faire, et quelles sont les contributions effectuées. Les femmes, les non-anglophones, et les nouveaux contributeurs à l’open source sont des exemples de population qui devraient être suivies dans le temps, en particulier pour mesurer l’impact des programmes de soutien.

Les seules statistiques disponibles sur les dépôts GitHub sont le nombre de personnes ayant étoilé (action semblable à liker), vu (c’est-à-dire qu’elles reçoivent des nouvelles du projet) ou « forké » un projet. Ces chiffres permettent de fournir des indicateurs concernant la popularité, mais ils peuvent être trompeurs. Beaucoup de personnes peuvent étoiler un projet, parce qu’il a une conception intéressante par exemple, sans toutefois l’intégrer à leur propre code.

Certains gestionnaires de paquets tels npm (qui est celui de Node.js) suivent les téléchargements. Le « popularity contest » de Debian piste les téléchargements du système d’exploitation libre Debian. Néanmoins, chaque gestionnaire de paquets est limité à un écosystème particulier, et aucun de ces gestionnaires ne peut donner une image du système dans son ensemble. Plusieurs projets ne sont pas inclus dans un gestionnaire de paquets et ne sont pas suivis. Libraries.io, un site web créé par Andrew Nesbitt, est une tentative pour agréger des données des projets open source en fonction de leur usage, il piste environ 1,3 millions de bibliothèques open source sur 32 gestionnaires de paquets.

Travailler avec les projets pour moderniser l’organisation de travail

Beaucoup de projets sont en difficulté et pas seulement à cause d’un manque de financement, mais aussi parce qu’il est difficile d’y contribuer, ou encore parce qu’il existe un goulot d’étranglement au niveau des mainteneurs qui traitent les demandes de modification (pull requests) de la communauté. C’est vrai, en particulier, pour les plus anciens projets qui ont été bâtis avec des outils de développement, des langages et des processus qui ne sont plus populaires (ceux qui par exemple utilisent un système de contrôle de version autre que Git, dont la popularité croît chez les développeurs).

On peut faire beaucoup de choses pour faciliter la contribution à un projet, depuis la migration vers un flux de travail (workflow) plus moderne, le nettoyage du code, la fermeture des pull request délaissées, jusqu’à la mise en place d’une politique claire pour les contributions. Certains projets expérimentent pour rendre les contributions plus simples. Le développeur Felix Geisendörfer, par exemple, a suggéré que chaque personne qui soumet une modification du code devrait avoir une permission de commit afin de réduire l’engorgement au niveau de l’unique mainteneur vérifiant et approuvant ces changements. Felix a estimé que « cette approche est un fantastique moyen d’éviter que le projet ne se ratatine en transformant le projet d’un seul homme en celui d’une communauté. »

Le règlement de contribution de Node.js, qui peut être adopté par les autres projets Node, met l’accent sur l’augmentation du nombre de contributeurs et sur leur autonomisation dans la prise de décision, plutôt que de désigner les mainteneurs comme seule autorité approbatrice. Leurs règles de contribution expliquent comment soumettre et valider des pull requests, comment consigner des bugs, etc. Les mainteneurs Node.js ont constaté qu’adopter de meilleures règles les avait aidés à gérer leur charge de travail et à faire évoluer leur communauté vers un projet plus sain et actif.

Dans un premier temps, il y a des recherches à faire pour déterminer quels projets doivent avancer. Autrement dit, à quoi ressemble un « projet à succès », aussi bien en termes de financement et de modèles de gouvernance, que dans l’équilibre à trouver entre mainteneurs, contributeurs et usagers ! La réponse peut varier en fonction des différents types de projets et de leur ampleur.

Encourager les standards communs dans les projets open source

Bien que GitHub soit en train de devenir une plateforme standard pour la collaboration sur le code, de nombreux aspects des projets open source ne sont pas encore standardisés, notamment l’ampleur et la richesse de la documentation, des licences et des guides de contribution, ainsi que le style de code et le formatage.
Encourager l’adoption de standards de projets pourrait faciliter, pour les mainteneurs, la gestion des contributions, tout en réduisant pour les contributeurs les obstacles à la participation.

Parmi les exemples de standardisation croissante, on trouve le code de conduite, qui est un règlement détaillant les attentes en termes d’attitude et de communication.
Ces dernières années, des codes de conduite ont été adoptés par un nombre croissant de communautés de projets, notamment Node.js, Django et Ruby. Bien que le processus d’adoption ait pu donner lieu à d’intenses débats au sein de certaines communautés, leur prolifération révèle un intérêt croissant pour la responsabilisation du comportement des communautés.

Augmenter le nombre de contributeurs et contributrices open source

Comme nous l’avons évoqué dans un chapitre précédent de ce rapport, l’industrie du logiciel est florissante, avec un nombre croissant de nouveaux développeurs mais aussi d’autres talents variés : il y a du travail à faire pour encourager ces nouveaux arrivants à contribuer à l’open source. Augmenter le nombre de contributeurs permet aux projets open source d’être plus durables, car davantage de personnes participent à leur développement. Permettre à davantage de personnes de contribuer à l’open source accroît également l’empathie et la communication entre les « utilisateurs » de l’open source et les projets dont ils dépendent.

« Your First PR » (« votre première PR », PR pour Pull Request, NdT) est un exemple d’initiative, développée par la programmeuse Charlotte Spencer, qui aide les nouveaux venus à effectuer leur première contribution à l’open source. « First Timers Only » (Réservé aux débutants) et « Make a Pull Request » (Faites une pull request) sont deux autres exemples de ressources populaires qui introduisent les nouveaux venus à l’open source. Certains projets open source utilisent également des étiquettes telles que « first bug » ou « contributor friendly » pour signaler les problèmes susceptibles d’être résolus par des contributeurs moins expérimentés. Il serait également bénéfique d’encourager les contributions à l’open source autres que le code, comme la rédaction de documentation technique, la gestion des tâches et des flux de travail, ou la création d’un site internet pour le projet.

En plus de l’augmentation de la proportion de techniciens talentueux contribuant à l’open source existe la possibilité de puiser dans un groupe de contributeurs plus large. Faire en sorte que les non-anglophones se sentent bienvenus dans les communautés open source, par exemple, pourrait rendre la technologie plus accessible à travers le monde. Et comme beaucoup de recruteurs utilisent les travaux open source comme un portfolio au moment d’embaucher un développeur, une communauté open source plus diverse encouragerait l’apparition d’un personnel technique globalement plus inclusif.

Améliorer les relations entre projets et acteurs extérieurs

Les entreprises sont une pièce incontournable de l’écosystème open source, et leur rôle ne fait que gagner en importance à mesure que davantage d’entre elles adoptent les logiciels open source. Faciliter la collaboration entre entreprises et projets, ainsi qu’aider les entreprises à comprendre les besoins des communautés open source, pourrait débloquer le soutien des entreprises susceptibles de devenir mécènes ou promoteurs de l’open source.

Selon l’étude annuelle des entreprises open source réalisée par Black Duck, seulement 27 % des entreprises ont un règlement formel concernant les contributions de leurs employés à l’open source. Clarifier la possibilité ou non pour les employés de contribuer à l’open source sur leur temps de travail, et les encourager à le faire, pourrait grandement améliorer le soutien des entreprises aux projets open source.

En 2014, un groupement d’entreprises a fondé le TODO Group, pour partager les bonnes pratiques autour de la participation corporative à l’open source. Parmi les membres de ce groupe, on trouve Box, Facebook, Dropbox, Twitter et Stripe. En mars 2016, le TODO Group a annoncé qu’il serait hébergé par la Fondation Linux en tant que projet collaboratif.

Les entreprises peuvent également fournir un soutien financier aux projets, mais il est parfois difficile pour elles de trouver comment formaliser leur mécénat. Créer des budgets dédiés au mécénat en direction des équipes d’ingénieurs ou des employés, ou encore créer des documents permettant aux projets de « facturer » plus facilement leurs services aux entreprises, sont autant d’initiatives qui pourraient augmenter les contributions financières à l’open source.

Poul-Henning Kamp, par exemple, travaille sur un projet open source nommé Varnish, utilisé par un dixième des sites les plus visités d’internet, notamment Facebook, Twitter, Tumblr, The New York Times et The Guardian. Pour financer ce travail, il a créé la Varnish Moral License pour faciliter la sponsorisation du projet par les entreprises.

Même si en pratique la relation est un mécénat, Poul Henning utilise une terminologie familière aux entreprises, avec des termes tels que « facturation » et « licences », pour réduire les obstacles à la participation.

Augmenter le soutien aux compétences diverses et aux fonctions hors-codage

Dans un passé pas si lointain, les startups de logiciels étaient fortement centrées sur les compétences techniques. Les autres rôles, comme le marketing et le design, étaient considérés comme secondaires par rapport au code. Aujourd’hui, avec la création et la consommation rapide de logiciels, cette conception ne tient plus. Les startups sont en concurrence pour capter l’attention de leurs clients. L’identité de la marque est devenue l’un des principaux facteurs de différenciation.

Ces cinq dernières années ont été celles de l’essor du développeur full stack (polyvalent) : des développeurs plus généralistes que spécialisés, capables de travailler sur plusieurs domaines d’un logiciel complexe, et qui sont susceptibles d’avoir des compétences dans la conception et la production. Les équipes de développement sont plus soudées, elles utilisent les méthodes agiles avec des approches de conception d’architecture logicielle (où le livrable est élaboré en faisant des navettes entre les équipes de techniciens, designers et commerciaux), plutôt qu’une approche en cascade (où chaque équipe apporte sa pièce à l’édifice avant de la transmettre au groupe de travail suivant).

Les projets open source ont connu peu d’évolutions de ce genre, malgré notre dépendance croissante à leurs logiciels. On comprend aisément que le code soit au cœur d’un projet open source, il est en quelque sorte le « produit final » ou le livrable. Les fonctions relatives à la gestion de la communauté, à la documentation, ou à la promotion du projet, qui sont la marque d’une organisation saine et durable, sont moins valorisées. Il en découle que les projets sont déséquilibrés. Beaucoup de choses pourraient être entreprises pour financer et soutenir les contributions autres que le code, des dons en nature pour payer les serveurs par exemple, ou des avantages comme une assurance maladie. Disposer de soutiens de ce type permettrait de réduire notablement la charge des développeurs.

Aujourd’hui menu allégé (après les agapes), avec un bref chapitre de Des routes et des ponts par Nadia Eghbal, ouvrage dont tous les chapitres précédents sont là.
Il s’agit cette fois-ci de dresser la liste des principes qui devraient gouverner le soutien durable aux projets et infrastructures open source.

Traduction Framalang :  Penguin, goofy, xi, Lumi, xXx, Mika

Élaborer des stratégies d’assistance efficaces

Même si les gens sont de plus en plus intéressés par les efforts pour soutenir les infrastructures numériques, les initiatives actuelles sont encore récentes, faites pour des cas particuliers ou fournissent seulement un support partiel (comme le partage d’avantages fiscaux par des organisations à but non lucratif avec des groupes extérieurs à celles-ci).

Le développement de stratégies de soutien efficaces demande une compréhension fine de la culture open source qui caractérise une très grande partie de notre infrastructure numérique, mais aussi de reconnaître que beaucoup de choses ont changé dans les cinq dernières années, y compris la définition même de l’open source.

L’argent seul ne suffira pas à répondre aux problèmes d’un projet d’infrastructure en difficulté, parce que l’open source s’épanouit grâce aux ressources humaines et non financières. Il existe beaucoup de façons d’accroître les ressources humaines, comme distribuer la charge de travail parmi davantage de contributeurs ou encourager les entreprises à faire publier en open source une partie du travail de leurs employés. Une stratégie de soutien efficace doit inclure plusieurs façons de générer du temps et des ressources au-delà du financement direct du développement. Elle doit partir du principe que l’approche open source n’est pas défectueuse en elle-même, mais manque simplement de ressources.

Soutenir les infrastructures nécessite d’intégrer le concept d’intendance en lieu et place du concept de contrôle. Comme nous l’avons vu, les infrastructures numériques ne ressemblent pas aux infrastructures physiques. Elles sont réparties entre de multiples acteurs et organisations, avec des projets de toute forme et de toute taille, et il est difficile de prédire quels projets deviendront un succès ou qui y contribuera sur le long terme.

Avec cela en tête, voici quelques clés pour élaborer une stratégie d’assistance efficace :

Adopter la décentralisation, plutôt que s’y opposer

Les ressources de l’open source sont destinées à être partagées, c’est en partie ce qui leur donne autant d’impact.
Utiliser la force que donne l’aspect communautaire comme un levier, plutôt que de recentraliser l’autorité.

Travailler étroitement avec les communautés informatiques existantes.

Les communautés informatiques sont actives, soudées et savent se faire entendre. Faites appel à elles plutôt que de prendre une décision en aparté. Les voix les plus sonores des communautés agissent comme un signal de danger quand un problème nécessite d’être soulevé.

Envisager une approche globale du soutien aux projets

Les projets ont besoin de bien plus que du code ou de l’argent, parfois même ils n’ont besoin ni de l’un ni de l’autre. Le soutien sur le long terme est davantage une question de temps accordé que d’argent. La revue de code, la documentation technique, les tests de code, la soutien de la communauté, et la promotion du projet constituent un ensemble de ressources importantes.

Aider les mainteneurs de projets à anticiper

Aujourd’hui, les efforts pour soutenir l’infrastructure numérique ont tendance a être uniquement de la réactivité liée aux circonstances ponctuelles. En plus des projets existants, il existe sûrement de nouveau projets qui ont besoin d’être lancés et accompagnés.
Pour les projets existants, les mainteneurs trouveront un grand avantage à pouvoir planifier en vue des trois à cinq ans à venir, et pas seulement pour six mois ou un an.

Voir les opportunités, pas seulement les risques

Soutenir l’open source de nos jours, cela ne consiste pas uniquement à éviter les scénarios catastrophes (par exemple les failles de sécurité), mais plutôt à donner les moyens à davantage de personnes de réaliser davantage de choses. Ce concept est une caractéristique essentielle de la culture open source actuelle, et permet aussi de mettre en place un soutien pérenne. Tenez compte dans votre stratégie de la façon dont vous pourriez accueillir davantage de personnes d’horizons, de compétences et de talents différents, plutôt que de limiter l’activité pour favoriser les personnes qui participent déjà.

David Heinemeier Hansson, le créateur de Ruby on Rails, compare l’open source à un récif de corail :

« C’est un milieu plus fragile que vous ne le pensez, et il est difficile de sous-estimer la beauté qui est involontairement en jeu. Marchez avec précaution. »

Aujourd’hui nous ouvrons avec plaisir nos colonnes à Véronique Bonnet, membre du C.A de l’April, qui évoque avec ferveur l’histoire et l’esprit de cette association amie dont nous partageons les combats et des valeurs.

L’April vient d’avoir 20 ans

par Véronique Bonnet

Ces jours-ci, l’April a eu 20 ans. Et toutes ses dents. Pas les dents de l’amer GAFAM, crocs avides des requins du Web et autres loups. Des dents, plutôt, qui ne mâchent pas leurs mots pour dénoncer l’inventivité souriante, glaçante, de firmes qui veulent continuer à dominer. Pour dire ce qu’un partenariat entre un ministère chargé d’éduquer à l’autonomie et Microsoft a de troublant. Pour s’étonner de l’open bar opaque de la Défense.

Alors même que le projet de loi pour une république numérique faisait miroiter de vertueux principes. Sur ce qui devait être transparent, interopérable et communicable, dans l’espace public. Sur ce qui devait rester inviolable et inaliénable dans l’espace privé. Loi tronquée, l’April l’a dit. C’est sa manière à elle de décliner la loi de Stallman :

« Tant que les grandes entreprises domineront la société et écriront les lois, chaque avancée ou chaque changement de la technologie sera pour elles une bonne occasion d’imposer des restrictions ou des nuisances supplémentaires à ses utilisateurs. »

La naissance de l’April, dès novembre 1996, avant le dépôt des statuts, a eu lieu au Bocal, cœur du laboratoire informatique de Paris 8 Saint-Denis. Des étudiants, dont notre actuel délégué général, Frédéric Couchet, fondent alors l’APRIL« Association pour la Promotion et la Recherche en Informatique Libre », devenue l’April « Association francophone de promotion et défense du logiciel libre ». Cette association relaie ainsi en France la FSF (Free Software Foundation) constituée par Richard Stallman en octobre 1985 : « une fondation sans but lucratif avec la mission cosmopolitique de promouvoir la liberté des utilisateurs d’ordinateurs et de défendre les droits de tous les utilisateurs du Free Software ». Dès novembre 1998, l’April accueillait RMS en conférence, à l’université Paris 8. Inspirée par l’indignation d’un utilisateur empêché d’utiliser son informatique comme il le voulait, l’April a été, elle aussi, inspirante. Quand on aime le Libre, on ne compte pas en rester là, on essaime.

Et il le faut, pour faire face ensemble, jamais dans l’entre-soi, à des évolutions empoisonnées qui se donnent des aspects riants, innocents. Que l’on touche à nos libertés, et l’April se met en colère. Avec la Quadrature du net. Framasoft. La FFDN. On n’est jamais trop pour se répartir la tâche de discerner, sous des angles divers, les faux semblants des rapaces de tout poil.

Marguerite Yourcenar, dans les Mémoires d’Hadrien, met dans la bouche de son empereur romain des conjectures à propos de certaines manœuvres dilatoires :

« Je doute que toute la philosophie du monde parvienne à supprimer l’esclavage, on en changera tout au plus le nom. Je suis capable d’imaginer des formes de servitude pires que les nôtres parce que plus insidieuses. Soit qu’on réussisse à transformer les hommes en machines stupides et satisfaites qui se croient libres alors qu’elles sont asservies, soit qu’on développe chez eux un goût du travail aussi forcené que la passion de la guerre […] »

La réduction des individus au machinal leur fait adopter des gestuelles dont ils ne saisissent plus les tenants et aboutissants. Et va même jusqu’à faire du travail, théoriquement émancipateur, une suite d’enchaînements sans signification. Cybernétique étrange, dont les acteurs ne seraient plus que des agents dociles de mécanismes qui n’auraient de sens que pour d’autres et qui ne serviraient qu’à d’autres. Comme si la vocation humaine à faire de sa vie une histoire, s’essayer à des tournants, tenter une élaboration symbolique intime, partagée ou non, n’avait plus cours.

Dans son Discours de la servitude volontaire, La Boétie, lui, se référait à Cyrus qui avait mis les Lydiens durablement sous sa coupe en ouvrant « des bordels, des tavernes et des jeux publics ». Pour que ceux qu’il avait vaincus, subjugués par la prégnance des sensations, laissent en sommeil leurs compétences à percevoir et analyser. Stratégie de l’amollissement de l’esprit critique que Jules César pour les Romains, avait réitérée : « … car son humanité même, que l’on prêche tant, fut plus dommageable que la cruauté du plus sauvage tyran qui fût oncques, pour ce qu’à la vérité ce fut cette sienne venimeuse douceur qui, envers le peuple romain, sucra la servitude ». Tibère et Néron se hâtèrent de lui emboîter le pas.

Débusquer alors la subordination derrière des activités qui occupent l’esprit en le réduisant à une instantanéité sans recul ? La servitude s’avance masquée. Les cookies, c’est confortable, c’est cool, ça anticipe même les désirs. Les menottes numériques, c’est indolore, et ça facilite la navigation. Le nuage, on n’en cause même pas. Tu n’as plus à t’occuper de rien. Le Saas, c’est aussi la nasse. Mais pourquoi pas, puisque ça habitue à déléguer. Former ? Autant formater. Futur usager, apprends à t’en remettre à des logiciels qui simplifient la vie. On ne voit plus les verrous qui les sous-tendent, ni le profilage qu’ils effectuent, ni le dépeçage de données qu’ils opèrent.

L’April, qui promeut et défend le logiciel libre, ne va pas prendre le thé n’importe où. Elle se méfie des belles pommes rouges, regarde où elle met les pieds, et fait son possible pour signaler les sables mouvants d’une informatique douce-amère. Elle alerte sur des outils apparemment conviviaux qui, mine de rien, privent de tout. Elle sensibilise à ce qui emprisonne et empoisonne, imperceptiblement.

L’April est un bon contre-poison. Dans les événements festifs qui ponctuent ses 20 ans, qu’ils aient déjà eu lieu, à Lyon, Toulouse, Marseille, Lille, Sarrebourg, Valenciennes, Digne, Nantes… ou qu’ils aient lieu après Newtonmas, Brest, le 6 janvier, Saint Denis le 11, Paris le 26… pas de sirop frelaté, ni de bouillon d’onze heures.

Ces jours-ci, l’April a eu 20 ans. Bon anniversaire l’April !

Pour en savoir plus :

• Le site web de l’April
  • ses objectifs et actions
  • pourquoi adhérer

Au cours des deux derniers chapitres (si vous avez manqué des chapitres, c’est par ici) Nadia Eghbal nous a décrit les solutions existantes pour financer les projets open source et leurs contributeurs : mécénat, crowdfunding, utilisation payante d’un logiciel ou d’un service ; elle a également montré les difficultés et les limites de chaque mode de financement.

Dans ce bref chapitre, l’autrice poursuit sa recherche sur les financements en faisant un point synthétique sur les causes systémiques des difficultés de financement des projets open source.

Traduction Framalang : Sphinx, Penguin, Opsylac, Luc, dominix, lyn., goofy

Pourquoi ces projets sont-ils si difficiles à financer ?

Aujourd’hui, le travail sur les infrastructures numériques est effectué par des développeurs freelance ou ayant un « job alimentaire », leur temps libre est consacré aux projets open source mais le reste du temps ils font un travail rémunéré sans rapport avec ces projets. Même si c’est un moyen réaliste pour financer son quotidien, cela ne permet pas d’apprécier à sa juste valeur l’apport social de ces projets.

Étonnamment, bien que tout le monde soit d’accord pour reconnaître qu’il y a un problème (qu’on le qualifie de « burnout du bénévole », de mauvaise gestion de la communauté ou de manque de financement suffisant), la discussion ne dépasse pas le stade de maigres solutions à court-terme comme les « pourboires » ou le crowdfunding.

Discutez avec des développeurs qui ont trouvé un moyen de gagner leur vie, et vous entendrez le mot « chanceux » à tout bout de champ : chanceux d’avoir été embauché par une entreprise, chanceux d’avoir eu de la notoriété et des dons, chanceux d’être tombé sur un modèle économique viable, chanceux de ne pas avoir une famille ou un prêt dont s’inquiéter. Tout le monde peut être chanceux. Mais la chance dure quelques mois, peut-être un an ou deux, et puis elle s’épuise.

Pourquoi est-il si difficile de financer les infrastructures numériques ?

Fondamentalement, l’infrastructure numérique a un problème de passagers clandestins. Les ressources sont disponibles gratuitement, et tout le monde les utilise (qu’il s’agisse de développeurs individuels ou de grandes entreprises de logiciels), mais personne n’est encouragé à contribuer en retour, chacun s’imaginant qu’un autre finira par le faire. S’il est laissé à l’abandon, ce problème mènera à une tragédie des communs.
En plus de l’enjeu macroéconomique des communs, il y a plusieurs raisons pour lesquelles le financement des infrastructures numériques est particulièrement compliqué. Ces raisons ont déjà été abordées au cours de cette étude, mais sont toutes résumées ici.

On croit à tort qu’il s’agit d’un « problème résolu ».

Même parmi les acteurs du secteur comme les entreprises de logiciels, la croyance est très répandue que l’open source est déjà correctement financée, ce qui rend d’autant plus difficile la levée de fonds. Certains projets d’infrastructure fonctionnent durablement, soit parce qu’ils disposent d’un modèle économique viable ou de mécènes, soit parce que les coûts de maintenance sont limités. Un public novice pourra également faire le lien entre l’open source et des entreprises telles que Red Hat ou Docker et penser que le problème a été résolu. Mais il faut garder à l’esprit que ces cas sont l’exception et non la règle.

Il manque une prise de conscience et une compréhension culturelle de ce problème.

En dehors de la communauté open source, tout le monde, ou presque, ignore les problèmes de financement de ces projets d’infrastructure, et le sujet est perçu comme plutôt aride et technique. Les développeurs qui ont besoin de soutien ont tendance à se concentrer principalement sur la technique et sont mal à l’aise lorsqu’il s’agit de défendre l’aspect financier de leur travail. Au bout du compte, on ne parvient pas à trouver l’élan qui pourrait modifier cette situation en panne.

Les infrastructures numériques sont enracinées dans l’open source, dont la culture du bénévolat n’encourage pas à parler d’argent.

Même si cette attitude a fait de l’open source ce qu’elle est aujourd’hui, elle crée également un tabou qui rend difficile pour les développeurs l’évocation de leurs besoins, car ils se sentent coupables ou ont peur de passer pour des personnes qui n’auraient pas l’esprit d’équipe. La nature hautement décentralisée et démocratique de l’Open source rend également difficile la coordination et le financement d’acteurs institutionnels qui pourraient défendre leurs intérêts.

Les infrastructures numériques sont hautement décentralisées, contrairement aux infrastructures physiques.

Contrairement à un projet de construction de pont, il n’est pas toujours évident de savoir quels projets seront utiles avant qu’ils n’aient déjà décollé. Ils ne peuvent pas être planifiés à l’avance par un organisme centralisé. Et à l’autre bout du cycle de vie, certains projets sont destinés à tomber en désuétude à mesure que d’autres solutions, meilleures, prendront leur place. L’infrastructure numérique est constituée de centaines de projets, grands ou petits, réalisés par des individus, des groupes ou des entreprises ; en faire l’inventaire serait un travail de titan.

« Il est difficile de trouver des financements… pour le développeur moyen (comme moi), certains sont totalement hors de portée. [Kickstarter] ne marche que si tu deviens viral, ou si tu embauches quelqu’un pour faire tout ce qui est marketing/design/promotion… Transformer un projet en entreprise c’est génial aussi mais… ce sont des choses qui t’éloignent du développement (qui est la partie qui m’intéresse). Si je voulais obtenir une subvention, je ne saurais même pas par où commencer. »

– Kyle Kemp, développeur freelance et contributeur open source.

Dans notre projet de traduction de l’ouvrage de Nadia Eghbal Roads and Bridges (tous les épisodes déjà traduits), nous abordons aujourd’hui une section importante consacrée aux modes de financement de ce qu’elle appelle l’infrastructure numérique et qui est comme l’épine dorsale de du monde informatique.

Elle donne ici un aperçu avec quelques exemples significatifs des trois principales voies explorées avec des succès variables par les développeurs et les entreprises : l’incitation par des récompenses, la monétisation par des services et le recours à des licences open source hybrides, en partie payantes…

Des modèles économiques pour les infrastructures numériques

Traduction Framalang : Piup, xi, Penguin, Bidouille, Lumibd, Opsylac, goofy

Certains aspects des infrastructures numériques peuvent fonctionner dans un contexte concurrentiel. Les bases de données et les services d’hébergement, par exemple, sont souvent des affaires profitables, bien financées, parce qu’elles peuvent faire payer l’accès. Tout comme l’accès à l’eau ou à l’électricité, l’accès à un serveur ou à une base de données peut être mesuré, facturé, et fermé si les honoraires ne sont pas réglés.

Heroku (mentionné au début de ce rapport) et Amazon Web Services sont deux exemples notables de plateformes qui vendent des services d’infrastructure numérique à des développeurs logiciels contre une redevance (à noter qu’aucun des deux n’est un projet open source). Des projets open source similaires, à ce niveau d’infrastructure, tels que OpenStack (une plate-forme concurrente d’Amazon Web Services) ou MySQL (une base de données), ont trouvé leurs assises dans des entreprises. OpenStack est financé par un consortium d’entreprises, et MySQL a été racheté par Oracle.

Une partie de ce qui rend ces services financièrement attractifs, c’est l’absence de « bruit ». Pour un seul logiciel, un développeur utilise parfois 20 bibliothèques différentes, avec chacune des fonctions différentes, mais il n’a besoin que d’une seule base de données. En conséquence, les projets à succès ont plus de chances d’obtenir l’attention et le soin dont ils ont besoin.

Il existe une autre façon utile de cerner les infrastructures que l’on peut facturer : s’il y a un risque immédiat de défaillance, alors il y a probablement un modèle économique. En d’autres termes, un serveur peut subir des interruptions de service inattendues, tout comme l’électricité peut sauter à l’improviste, mais un langage de programmation ne « casse » ni n’a des périodes d’indisponibilités de cette même façon, parce qu’il s’agit d’un système d’information.

Pour ce genre de projets open source, le modèle économique a tendance à se focaliser sur la recherche de services ou d’assistance facturables. Cela fonctionne pour les projets qui bénéficient d’un usage significatif par les entreprises, en particulier quand il s’agit d’un problème techniquement complexe, ou lorsqu’une entreprise a besoin qu’une fonction soit développée.

Récompenses

À petite échelle, des gens ou des entreprises promettent parfois des « récompenses » d’ordre pécuniaire pour l’atteinte de certains objectifs de développement.
Par exemple, IBM demande régulièrement de nouvelles fonctionnalités pour divers projets par le biais d’un site web appelé Bountysource, offrant jusqu’à 5 000 $ par tâche. Bountysource est une plateforme populaire pour trouver et proposer des récompenses ; elle compte plus de 26 000 membres. 120 récompenses aident à régler les problèmes précédemment mentionnés liés aux simples dons à un projet. Comme les récompenses sont clairement liées à un résultat, l’argent va être utilisé. En revanche, les récompenses peuvent avoir des effets pervers pour l’incitation à contribuer à un projet.
Les récompenses peuvent dicter quel travail sera ou ne sera pas effectué, et parfois ce travail n’est pas en phase avec les priorités d’un projet. Il peut aussi introduire du bruit dans le système : par exemple, une entreprise peut offrir une forte récompense pour une fonctionnalité que les propriétaires du projet ne considèrent pas comme importante.

Du côté des contributeurs, des personnes extérieures sans connaissances sur un projet peuvent y participer seulement pour obtenir la récompense, puis le quitter. Ou bien elles peuvent bâcler le travail requis, parce qu’elles essaient d’obtenir des récompenses. Enfin, les récompenses peuvent être une façon appropriée de financer de nouvelles fonctionnalités ou des problèmes importants, mais sont moins pratiques lorsqu’il s’agit de financer des opérations continues, comme le service client ou la maintenance.

Jeff Atwood, le créateur de Stack Overflow, a remarqué les problèmes suivants avec les programmes de récompenses, en particulier en ce qui concerne la sécurité :

L’un des effets pervers de cette tendance à attribuer des récompenses pour les rapports de bugs est que cela n’attire pas seulement de véritables programmeurs intéressés par la sécurité, mais aussi tous les gens intéressés par l’argent facile. Nous avons reçu trop de rapports de bugs de sécurité « sérieux » qui n’avaient qu’une importance très faible. Et nous devons les traiter, parce qu’ils sont « sérieux », n’est-ce pas ? Malheureusement, beaucoup d’entre eux ne représentent qu’un gaspillage de temps… Ce genre d’incitation me semble mauvais. Même si je sais que la sécurité est extrêmement importante, je vois ces interactions avec de plus en plus d’inquiétude parce qu’elles me créent beaucoup de travail et que le retour sur investissement est très faible.

Services

À une plus vaste échelle, un des exemples bien connus et les plus souvent cités de modèle économique open source, c’est Red Hat, l’entreprise dont nous avons déjà parlé, qui propose une assistance, des sessions de formation et autres services à des entreprises qui utilisent Linux. Red Hat a été fondée en 1993, il s’agit d’une entreprise cotée en bourse avec un chiffre d’affaires déclaré de 2 milliards de dollars par an.

Bien que Red Hat ait connu un succès fantastique d’un point de vue financier, nombreux sont ceux qui soulignent qu’il s’agit d’une anomalie qui n’aura pas de lendemains. Red Hat a bénéficié de l’avantage du premier arrivé dans son domaine technologique. Matt Asay, un journaliste spécialisé en open source, a remarqué que Red Hat utilise un ensemble unique de licences et brevets pour protéger ses parts de marché. Asay, qui auparavant était un fervent défenseur des entreprises open source, est maintenant persuadé que certaines licences propriétaires sont nécessaires pour faire sérieusement des affaires. Matthew Aslet du 451 Group, un organisme de recherche, a découvert lui aussi que la plupart des entreprises open source qui réussissent utilisent en fait un type ou un autre de licence commerciale.

Docker, déjà mentionné plus haut, est un projet open source qui aide les applications à fonctionner efficacement. C’est l’exemple le plus récent d’entreprise qui s’inspire de ce modèle. Docker a levé 180 millions de dollars en capital-risque auprès d’investisseurs, avec une valorisation d’un milliard de dollars de la part d’investisseurs privés. Comme sa part de marché s’est accrue, Docker a commencé à proposer des services d’assistance au niveau des entreprises. Mais sans solides revenus, Docker pourrait n’être qu’un exemple de plus de capital-risque qui fait un investissement dans une entreprise d’infrastructure leader sur son marché, mais qui réalise des pertes.

À petite échelle, beaucoup de développeurs proposent des services de consultants pour pouvoir financer leur travail. Hoodie est un framework poids plume qui repose sur Node et qui a réussi dans les services de consultants.

Hoodie lui-même est un projet open source. Plusieurs mainteneurs gagnent leur vie grâce à la boutique de l’entreprise, Neighbourhoodie, qui propose des services de développement logiciel. Bien que Neighbourhoodie se spécialise dans le framework de Hoodie, ce dernier est encore un projet plutôt jeune, de sorte que certaines parties de son travail proviennent de pojets qui ne sont pas lié à Hoodie. Dans le cas de Hoodie, le modèle de services choisi est censé payer le salaire de plusieurs mainteneurs, plutôt que de viser une stratégie d’entreprise de l’échelle de Red Hat.

Le conseil est une option viable pour les développeurs indépendants, s’il y a suffisamment de gens qui utilisent le projet qui sont d’accord et ont assez d’argent pour payer de l’aide supplémentaire. Mais à petite échelle, cela peut aussi les empêcher d’améliorer le projet lui-même, puisque les deux personnes au plus qui le maintiennent passent désormais leur temps à développer leur affaire et à fournir des services qui peuvent ou non être en accord avec les besoins du projet en termes de maintenance.

Aspirer à une activité de consultant peut aussi entrer en contradiction avec l’objectif de rendre le produit facile à utiliser et à appréhender, ce qui est bien dans l’esprit de l’open source. Twisted, la bibliothèque Python déjà citée, a mentionné un témoignage plein d’humour de l’un de ses utilisateurs, une entreprise nommée Mailman : « Les gars, vous avez un gros problème, parce que c’était vraiment trop facile ! Comment vous comptez vous faire un paquet d’argent juste avec du conseil ? 🙂 »

En fin de compte, le « modèle économique » pour un projet open source n’est pas très différent du simple travail indépendant.

Licences payantes

Certains développeurs ont l’impression que mettre les projets sous licence serait une solution au moins partielle aux problèmes de financement de l’open source. Si les projets open source sont fortement utilisés, pourquoi ne pas les facturer ? Ces « licences payantes » ne sont techniquement pas des licences open source, selon la définition de l’open source Initiative. Il s’agit plutôt d’initiatives qui tentent d’apporter un équilibre entre le besoin très concret de travail rémunéré et le désir de rendre le code accessible au public. Ce type de code peut être appelé « à source visible » ou «  à source disponible ». Fair Source, par exemple, se décrit lui-même comme «  [offrant] certains des avantages de l’open source tout en préservant la possibilité de faire payer pour le logiciel. »

La licence Fair Source fut créée en novembre 2015 par une entreprise appelée Sourcegraph pour répondre au besoin de licence payante. Les termes de la licence ont été rédigés par Heather Meeker, un juriste qui a également travaillé dans l’équipe principale de la Mozilla Public License v2.0. Avec la licence Fair Source, on peut librement consulter, télécharger, exécuter et modifier le code, jusqu’à un certain nombre d’utilisateurs par organisation. Une fois cette limite dépassée, l’organisation doit payer un forfait de licence, dont le montant est déterminé par l’éditeur. En d’autres termes, le code Fair Source est gratuit pour un usage personnel et pour les PME, mais fournit une base légale pour facturer les cas de plus gros usages commerciaux.

L’annonce par Sourcegraph de la création de la licence Fair Source, qu’ils utilisent maintenant eux-mêmes, a provoqué un débat animé sur la monétisation de l’open source. (Il est à noter qu’un mouvement similaire autour du « shareware », logiciel propriétaire gratuit, avait émergé avec un certain succès populaire dans les années 1980).
Mike Perham, l’un des mainteneurs de Sidekiq, un outil populaire pour le développement en Ruby, a aussi récemment suggéré aux contributeurs et contributrices open source d’utiliser une «  licence duale » pour monétiser leur travail, faisant payer les entreprises l’accès à une licence MIT permissive plutôt qu’une licence AGPL plus restrictive qui impose l’attribution. Sa théorie est qu’en faisant d’AGPL la licence par défaut, « les entreprises vont payer pour l’éviter. »
Pour justifier cette idée, Perham a rappelé à son public :

«  Souvenez-vous : logiciel open source ne signifie pas logiciel gratuit. Ce n’est pas parce que l’on peut consulter la source sur GitHub que tout le monde peut l’utiliser et en faire n’importe quoi. Il n’y a aucune raison pour laquelle vous ne pourriez pas donner l’accès à votre code mais aussi faire payer pour son utilisation. Tant que vous possédez le code, vous avez le droit d’y attribuer la licence que vous voulez.
…[La] réalité, c’est que la plupart des petits projets open source dépendent d’une seule personne qui fait 95 % du travail. Si c’est votre cas, soyez reconnaissants envers les gens qui vous aident gratuitement mais ne vous sentez pas coupable de garder 100 % du revenu. »

Faire payer les entreprises offre une autre possibilité aux développeurs et développeuses qui souhaitent poursuivre leur travail, en particulier s’il n’y a qu’une ou deux personnes pour maintenir un projet actif. Cependant, tous les projets ne peuvent pas faire payer pour le travail fourni, en particulier les projets plus vieux, ou les projets d’infrastructure qui ressemblent plus à des biens publics qu’à des produits de consommation, comme les langages de programmation.

Même si les licences payantes peuvent fonctionner pour certains scénarios, ce modèle est aussi pour beaucoup en opposition avec l’énorme valeur sociale offerte par l’open source, qui suggère que lorsque le logiciel est libre, l’innovation suit.

L’objectif ne devrait pas être le retour à une société qui repose sur les logiciels fermés, où le progrès et la créativité sont limités, mais de soutenir de façon durable un écosystème public dans lequel le logiciel peut être créé et distribué librement.

Cet article vise à clarifier la position de Framasoft, sollicitée à plusieurs reprises par le Ministère de l’Éducation Nationale ces derniers mois. Malgré notre indignation, il ne s’agit pas de claquer la porte, mais au contraire d’en ouvrir d’autres vers des acteurs qui nous semblent plus sincères dans leur choix du libre et ne souhaitent pas se cacher derrière une « neutralité et égalité de traitement » complètement biaisée par l’entrisme de Google, Apple ou Microsoft au sein de l’institution.

Pour commencer

Une technologie n’est pas neutre, et encore moins celui ou celle qui fait des choix technologiques. Contrairement à l’affirmation de la Ministre de l’Éducation Mme Najat Vallaud-Belkacem, une institution publique ne peut pas être « neutre technologiquement », ou alors elle assume son incompétence technique (ce qui serait grave). En fait, la position de la ministre est un sophisme déjà bien ancien ; c’est celui du Gorgias de Platon qui explique que la rhétorique étant une technique, il n’y en a pas de bon ou de mauvais usage, elle ne serait qu’un moyen.

Or, lui oppose Socrate, aucune technique n’est neutre : le principe d’efficacité suppose déjà d’opérer des choix, y compris économiques, pour utiliser une technique plutôt qu’une autre ; la possession d’une technique est déjà en soi une position de pouvoir ; enfin, rappelons l’analyse qu’en faisait Jacques Ellul : la technique est un système autonome qui impose des usages à l’homme qui en retour en devient addict. Même s’il est consternant de rappeler de tels fondamentaux à ceux qui nous gouvernent, tout choix technologique suppose donc une forme d’aliénation. En matière de logiciels, censés servir de supports dans l’Éducation Nationale pour la diffusion et la production de connaissances pour les enfants, il est donc plus qu’évident que choisir un système plutôt qu’un autre relève d’une stratégie réfléchie et partisane.

Un système d’exploitation n’est pas semblable à un autre, il suffit pour cela de comparer les deux ou trois principaux OS du marché (privateur) et les milliers de distributions GNU/Linux, pour comprendre de quel côté s’affichent la créativité et l’innovation. Pour les logiciels en général, le constat est le même : choisir entre des logiciels libres et des logiciels privateurs implique une position claire qui devrait être expliquée. Or, au moins depuis 1997, l’entrisme de Microsoft dans les organes de l’Éducation Nationale a abouti à des partenariats et des accords-cadres qui finirent par imposer les produits de cette firme dans les moindres recoins, comme s’il était naturel d’utiliser des solutions privatrices pour conditionner les pratiques d’enseignement, les apprentissages et in fine tous les usages numériques. Et ne parlons pas des coûts que ces marchés publics engendrent, même si les solutions retenues le sont souvent, au moins pour commencer, à « prix cassé ».

Depuis quelque temps, au moins depuis le lancement de la première vague de son projet Degooglisons Internet, Framasoft a fait un choix stratégique important : se tourner vers l’éducation populaire, avec non seulement ses principes, mais aussi ses dynamiques propres, ses structures solidaires et les valeurs qu’elle partage. Nous ne pensions pas que ce choix pouvait nous éloigner, même conceptuellement, des structures de l’Éducation Nationale pour qui, comme chacun le sait, nous avons un attachement historique. Et pourtant si… Une rétrospective succincte sur les relations entre Microsoft et l’Éducation Nationale nous a non seulement donné le tournis mais a aussi occasionné un éclair de lucidité : si, malgré treize années d’(h)activisme, l’Éducation Nationale n’a pas bougé d’un iota sa préférence pour les solutions privatrices et a même radicalisé sa position récemment en signant un énième partenariat avec Microsoft, alors nous utiliserions une partie des dons, de notre énergie et du temps bénévole et salarié en pure perte dans l’espoir qu’il y ait enfin une position officielle et des actes concrets en faveur des logiciels libres. Finalement, nous en sommes à la fois indignés et confortés dans nos choix.

L’Éducation Nationale et Microsoft, une (trop) longue histoire

En France, les rapports qu’entretient le secteur de l’enseignement public avec Microsoft sont assez anciens. On peut remonter à la fin des années 1990 où eurent lieu les premiers atermoiements à l’heure des choix entre des solutions toutes faites, clés en main, vendues par la société Microsoft, et des solutions de logiciels libres, nécessitant certes des efforts de développement mais offrant à n’en pas douter, des possibilités créatrices et une autonomie du service public face aux monopoles économiques. Une succession de choix délétères nous conduisent aujourd’hui à dresser un tableau bien négatif.

Dans un article paru dans Le Monde du 01/10/1997, quelques mois après la réception médiatisée de Bill Gates par René Monory, alors président du Sénat, des chercheurs de l’Inria et une professeure au CNAM dénonçaient la mainmise de Microsoft sur les solutions logicielles retenues par l’Éducation Nationale au détriment des logiciels libres censés constituer autant d’alternatives fiables au profit de l’autonomie de l’État face aux monopoles américains. Les mots ne sont pas tendres :

(…) Microsoft n’est pas la seule solution, ni la meilleure, ni la moins chère. La communauté internationale des informaticiens développe depuis longtemps des logiciels, dits libres, qui sont gratuits, de grande qualité, à la disposition de tous, et certainement beaucoup mieux adaptés aux objectifs, aux besoins et aux ressources de l’école. Ces logiciels sont largement préférés par les chercheurs, qui les utilisent couramment dans les contextes les plus divers, et jusque dans la navette spatiale. (…) On peut d’ailleurs, de façon plus générale, s’étonner de ce que l’administration, et en particulier l’Éducation Nationale, préfère acheter (et imposer à ses partenaires) des logiciels américains, plutôt que d’utiliser des logiciels d’origine largement européenne, gratuits et de meilleure qualité, qui préserveraient notre indépendance technologique.

L’année suivante, en octobre 1998, le Ministère de l’Éducation Nationale signe avec l’AFUL un accord-cadre pour l’exploitation, le développement et l’expertise de solutions libres dans les établissements. Le Ministère organise même en juillet 1999 une Université d’été « La contribution des logiciels et ressources libres à l’amélioration de l’environnement de travail des enseignants et des élèves sur les réseaux ».

D’autres témoignages mettent en lumière des tensions entre logiciels libres et logiciels privateurs dans les décisions d’équipement et dans les intentions stratégiques de l’Éducation Nationale au tout début des années 2000. En revanche, en décembre 2003, l’accord-cadre¹ Microsoft et le Ministère de l’Éducation Nationale change radicalement la donne et propose des solutions clés en main intégrant trois aspects :

• tous les établissements de l’Éducation Nationale sont concernés, des écoles primaires à l’enseignement supérieur ;
• le développement des solutions porte à la fois sur les systèmes d’exploitation et la bureautique, c’est-à-dire l’essentiel des usages ;
• la vente des logiciels se fait avec plus de 50% de remise, c’est-à-dire avec des prix résolument tirés vers le bas.

Depuis lors, des avenants à cet accord-cadre sont régulièrement signés. Comme si cela ne suffisait pas, certaines institutions exercent leur autonomie et établissent de leur côté des partenariats « en surplus », comme l’Université Paris Descartes le 9 juillet 2009, ou encore les Villes, comme Mulhouse qui signe un partenariat Microsoft dans le cadre de « plans numériques pour l’école », même si le budget est assez faible comparé au marché du Ministère de l’Éducation.

Il serait faux de prétendre que la société civile ne s’est pas insurgée face à ces accords et à l’entrisme de la société Microsoft dans l’enseignement. On ne compte plus les communiqués de l’April (souvent conjoints avec d’autres associations du Libre) dénonçant ces pratiques. Bien que des efforts financiers (discutables) aient été faits en faveur des logiciels libres dans l’Éducation Nationale, il n’en demeure pas moins que les pratiques d’enseignement et l’environnement logiciel des enfants et des étudiants sont soumis à la microsoftisation des esprits, voire une Gafamisation car la firme Microsoft n’est pas la seule à signer des partenariats dans ce secteur. Le problème ? Il réside surtout dans le coût cognitif des outils logiciels qui, sous couvert d’apprentissage numérique, enferme les pratiques dans des modèles privateurs : « Les enfants qui ont grandi avec Microsoft, utiliseront Microsoft ».

On ne saurait achever ce tableau sans mentionner le plus récent partenariat Microsoft-EN signé en novembre 2015 et vécu comme une véritable trahison par, entre autres, beaucoup d’acteurs du libre. Il a en effet été signé juste après la grande consultation nationale pour le Projet de Loi Numérique porté par la ministre Axelle Lemaire. La consultation a fait ressortir un véritable plébiscite en faveur du logiciel libre dans les administrations publiques et des amendements ont été discutés dans ce sens, même si le Sénat a finalement enterré l’idée. Il n’en demeure pas moins que les défenseurs du logiciel libre ont cru déceler chez nombre d’élus une oreille attentive, surtout du point de vue de la souveraineté numérique de l’État. Pourtant, la ministre Najat Vallaud-Belkacem a finalement décidé de montrer à quel point l’Éducation Nationale ne saurait être réceptive à l’usage des logiciels libre en signant ce partenariat, qui constitue, selon l’analyse par l’April des termes de l’accord, une « mise sous tutelle de l’informatique à l’école » par Microsoft.

Entre libre-washing et méthodes douteuses

Pour être complète, l’analyse doit cependant rester honnête : il existe, dans les institutions de l’Éducation Nationale des projets de production de ressources libres. On peut citer par exemple le projet EOLE (Ensemble Ouvert Libre Évolutif), une distribution GNU/Linux basée sur Ubuntu, issue du Pôle de compétence logiciel libre, une équipe du Ministère de l’Éducation Nationale située au rectorat de l’académie de Dijon. On peut mentionner le projet Open Sankoré, un projet de développement de tableau interactif au départ destiné à la coopération auprès de la Délégation Interministérielle à l’Éducation Numérique en Afrique (DIENA), repris par la nouvelle Direction du numérique pour l’éducation (DNE) du Ministère de l’EN, créée en 2014. En ce qui concerne l’information et la formation des personnels, on peut souligner certaines initiatives locales comme le site Logiciels libres et enseignement de la DANE (Délégation Académique au Numérique Éducatif) de l’académie de Versailles. D’autres projets sont parfois maladroits comme la liste de « logiciels libres et gratuits » de l’académie de Strasbourg, qui mélange allègrement des logiciels libres et des logiciels privateurs… pourvus qu’ils soient gratuits.

Les initiatives comme celles que nous venons de recenser se comptent néanmoins sur les doigts des deux mains. En pratique, l’environnement des salles informatiques des lycées et collèges reste aux couleurs Microsoft et les tablettes (réputées inutiles) distribuées çà et là par villes et départements, sont en majorité produites par la firme à la pomme². Les enseignants, eux, n’ayant que très rarement voix au chapitre, s’épuisent souvent à des initiatives en classe fréquemment isolées bien que créatives et efficaces. Au contraire, les inspecteurs de l’Éducation Nationale sont depuis longtemps amenés à faire la promotion des logiciels privateurs quand ils ne sont pas carrément convoqués chez Microsoft.

L’interprétation balance entre deux possibilités. Soit l’Éducation Nationale est composée exclusivement de personnels incohérents prêts à promouvoir le logiciel libre partout mais ne faisant qu’utiliser des suites Microsoft. Soit des projets libristes au sein de l’Éducation Nationale persistent à exister, composés de personnels volontaires et motivés, mais ne s’affichent que pour mieux mettre en tension les solutions libres et les solutions propriétaires. Dès lors, comme on peut s’attendre à ce que le seul projet EOLE ne puisse assurer toute une migration de tous les postes de l’EN à un système d’exploitation libre, il est logique de voir débouler Microsoft et autres sociétés affiliées présentant des solutions clés en main et économiques. Qu’a-t-on besoin désormais de conserver des développeurs dans la fonction publique puisque tout est pris en charge en externalisant les compétences et les connaissances ? Pour que cela ne se voie pas trop, on peut effectivement s’empresser de mettre en avant les quelques deniers concédés pour des solutions libres, parfois portées par des sociétés à qui on ne laisse finalement aucune chance, telle RyXéo qui proposait la suite Abulédu.

Finalement, on peut en effet se poser la question : le libre ne serait-il pas devenu un alibi, voire une caution bien mal payée et soutenue au plus juste, pour légitimer des solutions privatrices aux coûts exorbitants ? Les décideurs, DSI et autres experts, ne préfèrent-ils pas se reposer sur un contrat Microsoft plutôt que sur le management de développeurs et de projets créatifs ? Les solutions les plus chères sont surtout les plus faciles.

Plus faciles, mais aussi plus douteuses ! On pourra en effet se pencher à l’envi sur les relations discutables entre certains cadres de Microsoft France et leurs postes occupés aux plus hautes fonctions de l’État, comme le montrait le Canard Enchaîné du 30 décembre 2015. Framasoft se fait depuis longtemps l’écho des manœuvres de Microsoft sans que cela ne soulève la moindre indignation chez les décideurs successifs au Ministère³. On peut citer, pêle-mêle :

• la stratégie sournoise d’introduction des produits à l’école, selon la technique « embrace and extend », ce qui flirte dangereusement avec les règlements en vigueur, à commencer par le droit des marchés publics (opposé régulièrement pour contrecarrer la préférence donnée au Libre dans les appels d’offres) ;
• les accointances institutionnelles et le mélange des genres savamment orchestré ;
• les frontières imprécises entre promotion marketing et innovation pédagogique, voilant à peine les intentions réelles de Microsoft…

Du temps et de l’énergie en pure perte

« Vous n’avez qu’à proposer », c’est en substance la réponse balourde par touittes interposés de Najat Vallaud-Belkacem aux libristes qui dénonçaient le récent accord-cadre signé entre Microsoft et le Ministère. Car effectivement, c’est bien la stratégie à l’œuvre : alors que le logiciel libre suppose non seulement une implication forte des décideurs publics pour en adopter les usages, son efficience repose également sur le partage et la contribution. Tant qu’on réfléchit en termes de pure consommation et de fournisseur de services, le logiciel libre n’a aucune chance. Il ne saurait être adopté par une administration qui n’est pas prête à développer elle-même (ou à faire développer) pour ses besoins des logiciels libres et pertinents, pas plus qu’à accompagner leur déploiement dans des milieux qui ne sont plus habitués qu’à des produits privateurs prêts à consommer.

Au lieu de cela, les décideurs s’efforcent d’oublier les contreparties du logiciel libre, caricaturent les désavantages organisationnels des solutions libres et légitiment la Microsoft-providence pour qui la seule contrepartie à l’usage de ses logiciels et leur « adaptation », c’est de l’argent… public. Les conséquences en termes de hausses de tarifs des mises à jour, de sécurité, de souveraineté numérique et de fiabilité, par contre, sont des sujets laissés vulgairement aux « informaticiens », réduits à un débat de spécialistes dont les décideurs ne font visiblement pas partie, à l’instar du Ministère de la défense lui aussi aux prises avec Microsoft.

Comme habituellement il manque tout de même une expertise d’ordre éthique, et pour peu que des compétences libristes soient nécessaires pour participer au libre-washing institutionnel, c’est vers les associations que certains membres de l’Éducation Nationale se tournent. Framasoft a bien souvent été démarchée soit au niveau local pour intervenir dans des écoles / collèges / lycées afin d’y sensibiliser au Libre, soit pour collaborer à des projets très pertinents, parfois même avec des possibilités de financement à la clé. Ceci depuis les débuts de l’association qui se présente elle-même comme issue du milieu éducatif.

Depuis plus de dix ans Framasoft intervient sur des projets concrets et montre par l’exemple que les libristes sont depuis longtemps à la fois forces de proposition et acteurs de terrain, et n’ont rien à prouver à ceux qui leur reprocheraient de se contenter de dénoncer sans agir. Depuis deux décennies des associations comme l’April ont impulsé des actions, pas seulement revendicatrices mais aussi des conseils argumentés, de même que l’AFUL (mentionnée plus haut). Las… le constat est sans appel : l’Éducation Nationale a non seulement continué à multiplier les relations contractuelles avec des firmes comme Microsoft, barrant la route aux solutions libres, mais elle a radicalisé sa position en novembre 2015 en un ultime pied de nez à ces impertinentes communautés libristes.

Nous ne serons pas revanchards, mais il faut tout de même souligner que lorsque des institutions publiques démarchent des associations composées de membres bénévoles, les tâches demandées sont littéralement considérées comme un dû, voire avec des obligations de rendement. Cette tendance à amalgamer la soi-disant gratuité du logiciel libre et la soi-disant gratuité du temps bénévole des libristes, qu’il s’agisse de développement ou d’organisation, est particulièrement détestable.

Discuter au lieu de faire

À quelles demandes avons-nous le plus souvent répondu ? Pour l’essentiel, il s’agit surtout de réunions, de demandes d’expertises dont les résultats apparaissent dans des rapports, de participation plus ou moins convaincante (quand il s’agit parfois de figurer comme caution) à des comités divers, des conférences… On peut discuter de la pertinence de certaines de ces sollicitations tant les temporalités de la réflexion et des discours n’ont jamais été en phase avec les usages et l’évolution des pratiques numériques.

Le discours de Framasoft a évolué en même temps que grandissait la déception face au décalage entre de timides engagements en faveur du logiciel libre et des faits attestant qu’à l’évidence le marché logiciel de l’Éducation Nationale était structuré au bénéfice des logiques privatrices. Nous en sommes venus à considérer que…

• si, en treize ans de sensibilisation des enseignants et des décideurs, aucune décision publique n’a jamais assumé de préférence pour le logiciel libre ;
• si, en treize ans, le discours institutionnel s’est même radicalisé en défaveur du Libre : en 2003, le libre n’est « pas souhaitable » ; en 2013 le libre et les formats ouverts pourraient causer des « difficultés juridiques » ; en 2016, le libre ne pourra jamais être prioritaire malgré le plébiscite populaire⁴…

…une association comme Framasoft ne peut raisonnablement continuer à utiliser l’argent de ses donateurs pour dépenser du temps bénévole et salarié dans des projets dont les objectifs ne correspondent pas aux siens, à savoir la promotion et la diffusion du Libre.

L’éducation populaire : pas de promesses, des actes

Framasoft s’est engagée depuis quelque temps déjà dans une stratégie d’éducation populaire. Elle repose sur les piliers suivants :

• social : le mouvement du logiciel libre est un mouvement populaire où tout utilisateur est créateur (de code, de valeur, de connaissance…) ;
• technique : par le logiciel libre et son développement communautaire, le peuple peut retrouver son autonomie numérique et retrouver savoirs et compétences qui lui permettront de s’émanciper ;
• solidaire : le logiciel libre se partage, mais aussi les compétences, les connaissances et même les ressources. Le projet CHATONS démontre bien qu’il est possible de renouer avec des chaînes de confiance en mobilisant des structures au plus proche des utilisateurs, surtout si ces derniers manquent de compétences et/ou d’infrastructures.

Quelles que soient les positions institutionnelles, nous sommes persuadés qu’en collaborant avec de petites ou grandes structures de l’économie sociale et solidaire (ESS), avec le monde culturel en général, nous touchons bien plus d’individus. Cela sera également bien plus efficace qu’en participant à des projets avec le Ministère de l’Éducation Nationale, qui se révèlent n’avoir au final qu’une portée limitée. Par ailleurs, nous sommes aussi convaincus que c’est là le meilleur moyen de toucher une grande variété de publics, ceux-là mêmes qui s’indigneront des pratiques privatrices de l’Éducation Nationale.

Néanmoins, il est vraiment temps d’agir, car même le secteur de l’ESS commence à se faire « libre-washer » et noyauter par Microsoft : par exemple la SocialGoodWeek a pour partenaires MS et Facebook ; ou ADB Solidatech qui équipe des milliers d’ordinateurs pour associations avec des produits MS à prix cassés.

Ce positionnement du « faire, faire sans eux, faire malgré eux » nous a naturellement amenés à développer notre projet Degooglisons Internet. Mais au-delà, nous préférons effectivement entrer en relation directe avec des enseignants éclairés qui, plutôt que de perdre de l’énergie à convaincre la pyramide hiérarchique kafkaïenne, s’efforcent de créer des projets concrets dans leurs (minces) espaces de libertés. Et pour cela aussi le projet Degooglisons Internet fait mouche.

Nous continuerons d’entretenir des relations de proximité et peut-être même d’établir des projets communs avec les associations qui, déjà, font un travail formidable dans le secteur de l’Éducation Nationale, y compris avec ses institutions, telles AbulEdu, Sésamath et bien d’autres. Il s’agit là de relations naturelles, logiques et même souhaitables pour l’avancement du Libre. Fermons-nous définitivement la porte à l’Éducation Nationale ? Non… nous inversons simplement les rôles.

Pour autant, il est évident que nous imposons implicitement des conditions : les instances de l’Éducation Nationale doivent considérer que le logiciel libre n’est pas un produit mais que l’adopter, en plus de garantir une souveraineté numérique, implique d’en structurer les usages, de participer à son développement et de généraliser les compétences en logiciels libres. Dans un système déjà noyauté (y compris financièrement) par les produits Microsoft, la tâche sera rude, très rude, car le coût cognitif est déjà cher payé, dissimulé derrière le paravent brumeux du droit des marchés publics (même si en la matière des procédures négociées peuvent très bien être adaptées au logiciel libre). Ce n’est pas (plus) notre rôle de redresser la barre ou de cautionner malgré nous plus d’une décennie de mauvaises décisions pernicieuses.

Si l’Éducation Nationale décide finalement et officiellement de prendre le bon chemin, avec force décrets et positions de principe, alors, ni partisans ni vindicatifs, nous l’accueillerons volontiers à nos côtés car « la route est longue, mais la voie est libre… ».

— L’association Framasoft

Dans ce onzième chapitre de son ouvrage Des routes et des ponts que l’équipe Framalang vous traduit semaine après semaine (si vous avez raté le début), Nadia Eghbal aborde le problème endémique des infrastructures numériques open source, leur manque de ressources humaines pérennes : entre ceux qui s’y consacrent à corps perdu et s’arrêtent au bord du burnout, les entreprises qui profitent des ressources sans jamais contribuer en retour, ceux qui se lancent ingénument dans le développement sans notion bien nette de sécurité, ceux qui ne peuvent contribuer que sur un temps libre limité… Des témoignages sur ces situations et d’autres encore ont été recueillis dans ce chapitre.

Comme le souligne l’autrice, cette situation bancale a pour conséquence un coût important en termes d’argent et de sécurité pour l’ensemble de l’industrie numérique qui puise abondamment dans l’infrastructure numérique open source.

Négliger les infrastructures a un coût caché

Traduction Framalang : Piup, jums, Penguin, serici, xi, Asta, Diane, glissière de sécurité, Luc, goofy, lyn

Comme nous l’avons vu, l’infrastructure numérique est un constituant essentiel du monde actuel. Notre société repose sur les logiciels, et ces logiciels s’appuient de plus en plus sur une infrastructure qui utilise des méthodologies open source. Dans la mesure où nous prenons peu d’initiatives pour comprendre et pérenniser notre infrastructure numérique, que mettons-nous en péril ?
Ne pas réinvestir dans l’infrastructure numérique présente des dangers que l’on peut classer en deux catégories : les coûts directs et les coûts indirects.

Les coûts directs

Les coûts directs sont les bogues non détectés et les vulnérabilités de sécurité qui peuvent être exploitées à des fins malveillantes, ou qui mènent à des interruptions imprévues dans le fonctionnement des logiciels. Ces coûts sont fortement ressentis et causent des problèmes qui doivent être résolus immédiatement.

Les coûts indirects

Les coûts indirects se traduisent par exemple par la perte de main-d’œuvre qualifiée, ainsi qu’une croissance faible et peu d’innovation. Même si ces coûts ne sont pas immédiatement perceptibles, ils représentent une valeur sociale difficile à évaluer.

Bogues, failles de sécurité et interruptions du service

L’introduction de ce rapport relatait les détails de la faille de sécurité Heartbleed, qui a été découverte en avril 2014 dans une bibliothèque logicielle appelée OpenSSL. Du fait de son usage généralisé, notamment pour le fonctionnement de nombreux sites web majeurs, Heartbleed a largement attiré l’attention du public sur le problème des failles de sécurité des logiciels.

En septembre 2014, une autre faille majeure a été découverte dans un autre outil essentiel appelé Bash. Bash est inclus dans des systèmes d’exploitation populaires tels que Linux et Mac OS, ce qui fait qu’il est installé sur 70 % des machines connectées à internet.

L’ensemble de bugs de sécurité, surnommés « ShellShock », peuvent être exploités pour permettre un accès non autorisé à un système informatique. Les vulnérabilités étaient restées non-détectées pendant au moins une décennie. Bash a été créé à l’origine par un développeur appelé Brian Fox en 1987, mais depuis 1992 il est maintenu par un seul développeur, Chet Ramey, qui travaille comme architecte technique senior à la Case Western University dans l’Ohio.

Un autre projet, OpenSSH, fournit une suite d’outils de sécurité dont l’usage est largement répandu sur internet. Des développeurs ont trouvé de multiples failles dans son code qui ont pu être prises en charge et corrigées, y compris celle de juillet 2015, qui permettait aux attaquants de dépasser le nombre maximal d’essais sur les mots de passe, et celle de janvier 2016, qui laissait fuiter les clefs de sécurité privées.

L’un des aspects du problème est que beaucoup de projets sont des outils anciens, développés au départ par un ou plusieurs développeurs passionnés, qui ont par la suite manqué de ressources pour gérer le succès de leur projet. Avec le temps, les contributions diminuent et les acteurs restants se lassent et s’en vont, mais pour autant le projet est toujours activement utilisé, avec seulement une ou deux personnes tâchant de le maintenir en vie.

Un autre problème croissant dans le paysage des logiciels actuel, où l’on voit tant de jeunes développeurs inexpérimentés, c’est que les concepts de sécurisation ne sont pas enseignés ou pas considérés comme prioritaires. Les nouveaux développeurs veulent simplement écrire du code qui marche. Ils ne savent pas faire un logiciel sécurisé, ou pensent à tort que le code public qu’ils utilisent dans la sécurité de leurs programmes a été vérifiée. Même les bonnes pratiques de divulgation sécurisée ou de gestion des failles ne sont généralement pas enseignées ni comprises. La sécurité ne devient un enjeu que lorsque le code d’un développeur a été compromis.

Christopher Allen a coécrit la première version du protocole de transfert sécurisé TLS (Transport Layer Security), dont les versions successives sont devenues un standard utilisé quasiment universellement en ligne, y compris sur des sites comme Google, Facebook ou YouTube. Bien que le protocole soit devenu un standard, Christophe parle ainsi de ses origines :

« En tant que co-auteur de TLS, je n’aurais pas prédit que 15 ans plus tard la moitié d’Internet utiliserait une implémentation de TLS maintenue par un ingénieur à quart-temps. C’est ce manque de maintenance qui a conduit au bug tristement célèbre de Heartbleed. Je raconte aujourd’hui cette anecdote à mes collègues qui travaillent sur les crypto-monnaies pour les avertir que leur chiffrage, ultra moderne aujourd’hui, pourrait  être ’dépassé’ dans 10 ans et subir le même sort, le projet n’étant plus aussi passionnant, et leur travail acharné risquerait d’être compromis. »

En définitive, la stabilité de nos logiciels repose sur la bonne volonté et la coopération de centaines de développeurs, ce qui représente un risque significatif. La fragilité de notre infrastructure numérique a récemment été démontrée par un développeur nommé Azer Koçulu.
Azer, un développeur Node.js, hébergeait un certain nombre de bibliothèques sur un gestionnaire de paquets nommé npm. Après un conflit avec npm sur la propriété intellectuelle d’un de ses projets, Azer, mécontent de l’issue du conflit, décida de supprimer toutes les publications qu’il avait pu faire sur npm.

L’une de ces bibliothèques, left-pad, avait été réutilisée dans des centaines d’autres projets. Même s’il ne s’agissait que de quelques lignes de code, en supprimant le projet left-pad, Azer a « cassé » les algorithmes d’innombrables protocoles logiciels développés par d’autres. La décision d’Azer a provoqué tant de problèmes que npm a pris la décision sans précédent de republier sa bibliothèque, contre la volonté d’Azer, afin de restaurer les fonctionnalités offertes par le reste de l’écosystème.

Npm a aussi revu sa politique pour qu’il soit plus difficile pour les développeurs de retirer leurs bibliothèques sans avertissement, reconnaissant ainsi que les actions d’un individu peuvent en affecter négativement beaucoup d’autres.

Les logiciels ne reçoivent pas la maintenance nécessaire dont ils ont besoin

Construire une infrastructure numérique de façon désorganisée implique que tout logiciel sera construit plus lentement et moins efficacement. L’histoire de l’infrastructure Python en fournit un bon exemple.

L’un des importants projets d’infrastructure pour les développeurs Python se nomme Setuptools. Setuptools fournit un ensemble d’outils qui rendent le développement en Python plus simple et plus standardisé.
Setuptools a été écrit en 2004, par le développeur PJ Eby. Pendant les quatre années qui ont suivi, l’outil a été largement adopté. Néanmoins, Setuptools était difficile à installer et à utiliser, et Eby était très peu réceptif aux contributions et aux corrections apportées par d’autres, car il voulait, en tant que concepteur, avoir le dernier mot sur Setuptools. En 2008, un groupe de développeurs conduits par Tarek Ziade a décidé de forker le projet pour obliger Eby à faire des améliorations. Ils ont appelé le nouveau projet « Distribute ». En 2013, les deux projets ont fusionné dans Setuptools.
Ce long désaccord a néanmoins souligné à la fois l’état douteux des outils de l’infrastructure de Python, et la difficulté de mettre en œuvre des améliorations, notamment parce que personne ne se consacrait aux problèmes de la communauté ni ne désirait s’en occuper.

Les outils de Python ont commencé à s’améliorer quand le groupe de travail Python Packaging Authority (PyPA) s’est formé pour se consacrer spécifiquement à définir de meilleurs standards pour le paquetage. Un développeur, Donald Stufft, fit des outils de paquetage Python le cœur de son travail et fut engagé par HP (devenu HPE) en mai 2015 pour poursuivre son travail (son parcours sera évoqué plus tard dans ce rapport).

Un autre exemple intéressant est celui de RubyGems.org, un site web utilisé par la plupart des développeurs Ruby pour héberger leurs bibliothèques Ruby. Ruby a été utilisé pour bâtir des sites web majeurs comme Twitter, AirBnB, YellowPages et GitHub lui-même. En 2013, une faille de sécurité de RubyGems.org a été découverte, mais elle ne fut pas réparée avant plusieurs jours, parce que RubyGems.org était entièrement maintenue par des bénévoles. Les bénévoles pensaient régler le problème le week-end, mais pendant ce temps, quelqu’un d’autre a découvert la faille et a piraté le serveur de RubyGems.org. Après l’attaque, les serveurs ont dû être entièrement reconfigurés. Plusieurs bénévoles ont pris sur leur temps de travail, et certains ont même pris des jours de congé, afin de remettre RubyGems.org en état de marche le plus vite possible.

Comme RubyGems.org est un élément d’infrastructure critique, la faille de sécurité affectait par rebond beaucoup de développeurs et d’entreprises. L’incident a mis en lumière le fait qu’un travail fondé uniquement sur la base du volontariat limitait les garanties de sécurité et de fiabilité que l’on pouvait offrir sur une infrastructure logicielle importante. Des dizaines de développeurs se mobilisèrent de façon « bénévole » pendant l’incident parce que le problème affectait directement leur emploi salarié.

Malheureusement, aucun d’entre eux n’avait l’expérience requise pour être utile, et aucun d’entre eux n’a continué à offrir son aide une fois les serveurs réparés. En 2015, une organisation nommée Ruby Together a été formée pour aider à financer la maintenance et le développement de l’infrastructure Ruby, entre autres RubyGems.org, en sollicitant des entreprises comme sponsors.

La perte de main-d’œuvre qualifiée

Comme dans beaucoup de communautés de bénévoles, le « burnout » est commun parmi les contributeurs open source, qui se retrouvent à répondre aux requêtes d’utilisateurs individuels ou d’entreprises, pour un travail sans compensation. Beaucoup de développeurs ont des anecdotes où des entreprises les sollicitaient pour du travail gratuit. Daniel Roy Greenfield, développeur Django et Python, a écrit :

« J’ai personnellement eu des demandes pour du travail non-payé (les discussions pour payer le travail n’aboutissent jamais) par des entreprises à haut profit, grandes ou petites, pour [mes projets]. Si je ne réponds pas dans les temps convenus, si je n’accepte pas une pull request merdique, on va me mettre une étiquette de connard. Il n’y a rien de pire que d’être face à des développeurs du noyau Python/PyPA travaillant pour Redhat [sic], qui exigent de toi un travail non payé tout en critiquant ce qu’ils considèrent comme les insuffisances de ton projet, pour te pourrir ta journée et plomber ta foi en l’open source. »

(Red Hat est une multinationale du logiciel avec un revenu annuel excédant les 2 milliards d’euros, qui vend des logiciels open source à des clients d’entreprise. Du fait de la nature de leur entreprise, les employés de Red Hat utilisent et contribuent à de nombreux projets open source : en un sens, Red Hat est devenu la tête d’affiche de l’open source dans le monde de l’entreprise. Nous reparlerons de son succès financier plus tard dans ce rapport).

Read the Docs, service d’hébergement de documentation technique précédemment mentionné, annonce explicitement sur son site qu’il ne s’occupe pas de l’installation personnalisée dans les entreprises ou chez les particuliers.

L’un des mainteneurs, Eric Holscher, va jusqu’à faire ce commentaire :
« Je suis à peu près sûr que Read the Docs n’a aucun intérêt à être open source, vu que les utilisateurs privés ne contribuent jamais en retour, et se contentent de demander une assistance gratuite. »
Maquess, le contributeur OpenSSL, a tenu un discours acerbe à propos des requêtes récurrentes sur ses posts qui parlent de financement :

« C’est à vous que je pense, entreprises du Fortune 1000. Vous qui incluez OpenSSL dans vos firewall/dispositifs/cloud/produits financiers ou de sécurité, tous ces produits que vous vendez à profit, ou que vous utilisez pour vos infrastructures et communications internes. Vous qui n’avez pas besoin de financer une équipe interne de programmeurs pour se débattre avec du code crypté, puis qui nous harcelez pour obtenir une assistance gratuite quand vous réalisez que vous êtes incapables de l’utiliser. Vous qui n’avez jamais levé le petit doigt pour contribuer à la communauté open source qui vous a fait ce cadeau. Les concernés se reconnaîtront. Certains développeurs choisissent d’arrêter de maintenir leurs projets parce qu’ils n’ont plus assez de temps à y consacrer, et espèrent que quelqu’un d’autre prendra le relais. Pendant ce temps, les entreprises, les gouvernements et les individus dépendent de ces bibliothèques pour leur bon fonctionnement, inconscients des enjeux sous-jacents. »

David Michael Ross, ingénieur manager dans une agence web, a écrit au sujet de son expérience :

« Pour moi, c’est là que le bât blesse.  […] On sait qu’on a créé quelque chose gratuitement, par passion, et on voit ce flux infini de personnes qui crient « plus ! encore plus ! » et qui se mettent en colère quand on ne traite pas leur cas particulier.
Il y avait mon numéro de téléphone sur l’un de mes sites personnels pour que mes amis puissent me joindre. Je l’ai enlevé au bout d’une semaine parce que des gens m’appelaient à toute heure de la journée pour de l’assistance sur les plugins, alors qu’il y a un forum consacré à ça. Il n’y a rien de fondamentalement méchant là-dedans, c’est juste que c’est usant. On se met à avoir peur de vérifier ses mails ou de répondre au téléphone. »

Ryan Bigg, qui écrit de la documentation technique pour le framework Ruby on Rails, a annoncé en novembre 2015 qu’il renonçait à tout travail open source :

« Je n’ai plus le temps ni l’énergie de m’investir dans l’open source. Je ne retire strictement aucun revenu de mon travail open source, ce qui veut dire que le travail que je fais là, c’est du temps que je pourrais consacrer à des activités perso, ou à écrire. Ce n’est pas justifié d’attendre de moi que je travaille encore, en dehors de mon emploi salarié, sans que je sois honnêtement rétribué pour ça (en temps ou en argent). C’est aussi une recette qui a de bonnes chances de me conduire au burnout ou de me rendre juste globalement aigri.

Par ailleurs, la perte de main-d’œuvre qualifiée dans l’open source, ce n’est pas seulement les contributeurs qui démissionnent, c’est aussi ceux qui n’ont jamais contribué du tout. »

Il existe très peu de statistiques sur la démographie des contributeurs open source, ce qui est déjà révélateur en soi. Une analyse récente de GitHub a révélé que seulement 5,4% des contributeurs open source étaient des femmes, qui occupent pourtant environ 15 à 20% des postes techniques dans l’ensemble des entreprises de logiciels.

L’une des raisons qui font que les contributeurs open source sont un groupe remarquablement plus homogène que le secteur de la technologie dans son ensemble, c’est qu’ils ont besoin de temps et d’argent pour apporter dans un premier temps des contributions significatives. Ces contraintes empêchent des contributeurs par ailleurs qualifiés d’entrer dans cet espace.
David Maclver, créateur de Hypothésis, une bibliothèque Python qui sert à tester des applications logicielles, explique pourquoi il a pu passer autant de temps sur le projet :

« J’ai pu le faire seulement parce que j’avais le temps et l’argent pour le faire. J’avais le temps parce que j’étais obsessionnel, je n’avais personne à charge, et je n’avais pas d’emploi. Je pouvais me permettre de ne pas avoir d’emploi parce que j’avais de l’argent. J’avais de l’argent parce que pendant la dernière moitié de l’année passée, je touchais un salaire deux fois plus élevé que d’habitude, en dépensant deux fois moins que d’habitude, et je traversais une dépression qui me rendait trop borderline pour avoir envie de dépenser mon argent dans quoi que ce soit d’intéressant. Ce ne sont pas des conditions qu’on peut raisonnablement exiger de quelqu’un. […] Est-ce qu’on pourrait produire un logiciel de qualité en moins de temps que ça, en ne travaillant que sur du temps libre ? J’en doute. »

Cory Benfield, un développeur pour les fonctions de base de Python, écrit :

« De manière générale, les personnes qui ne sont pas des hommes cisgenres, hétérosexuels, blancs, de classe moyenne, et anglophones sont moins susceptibles de pouvoir assumer les risques financiers accrus associés à l’absence d’emploi stable. Cela signifie que ces personnes ont vraiment besoin d’un salaire régulier pour pouvoir contribuer le plus efficacement possible. Et nous avons besoin de leur contribution : des équipes diversifiées font un meilleur travail que des équipes homogènes. »

Charlotte Spencer, qui contribue au framework logiciel Hoodie et au système de bases de données PouchDB, fait écho à cette opinion :

« Toutes mes contributions sont purement bénévoles. Je n’en retire pas d’argent, même si j’aimerais beaucoup pouvoir. J’ai demandé à des vétérans de l’open source s’ils étaient payés et ce n’est pas le cas, ce qui m’a découragé d’essayer quoi que ce soit (si ces gens-là ne sont pas payés, pourquoi le serais-je ?). J’y consacre la plus grande partie de mon temps libre, mais j’essaie d’en faire moins parce que ça envahissait trop ma vie. »

Jessica Lord, développeuse, a contribué activement à l’open source tout en travaillant à Code for America, une organisation à but non-lucratif qui soutient la technologie dans le secteur public. Urbaniste de formation, elle insiste sur le fait qu’elle n’avait « pas de diplôme en informatique, pas d’expérience formelle en programmation, mais un portfolio GitHub ».

Ses contributions régulières attirèrent l’attention de la plate-forme GitHub elle-même, pour qui elle travaille désormais. Cependant, Jessica note qu’elle a pu contribuer à l’open source grâce à un concours de circonstances « particulier » : elle a accepté une baisse de salaire pour travailler à Code for America, utilisé toutes ses économies, travaillé « presque non-stop » sur des projets open source, et bénéficié d’une communauté de soutiens.

À propos du manque de diversité dans l’open source, Jessica écrit:

« La valeur des savoirs communs ne peut être surestimée. Nous devons faire mieux. Nous avons besoin des idées de tout le monde. C’est le but que nous devrions chercher à atteindre. Il est nécessaire que l’open source soit ouvert à tous. Pas seulement aux privilégiés ou même aux seuls développeurs. »

Ce dernier point soulevé par Jessica Lord est révélateur : permettre à des profils plus divers de participer à l’open source peut aider à pérenniser l’open source en elle-même. D’un point de vue fonctionnel, la grande majorité des contributeurs open source sont des développeurs, mais beaucoup d’autres rôles sont nécessaires pour gérer les projets d’ampleur, comme la rédaction, la gestion de projet ou la communication. Les projets open source ne sont pas différents des autres types d’organisations, y compris les startups où l’on a besoin de personnes se chargeant de l’administration, du marketing, du design, etc., qui sont autant de fonctions nécessaires au fonctionnement de base d’une structure. C’est en partie parce que la culture open source repose principalement sur les développeurs que la pérennité financière est si rarement l’objet de discussions et d’actions concrètes.

Enfin, l’homogénéité des contributeurs open source impacte les efforts en faveur de la diversité dans le monde de la technologie au sens large, puisque l’open source est étroitement lié à l’embauche. En effet, comme nous l’avons remarqué plus haut, beaucoup d’employeurs utilisent les contributions open source, notamment les profils GitHub, pour découvrir leurs futurs employés potentiels ou pour vérifier les qualifications d’un candidat. Les employeurs qui se fient ainsi essentiellement aux preuves de contributions open source ne recrutent que parmi un vivier de candidats extrêmement restreint.

Ashe Dryden, dans un essai important intitulé L’Éthique du travail non payé et la Communauté OSS, expliquait :

« Juger que quelqu’un est un bon programmeur en se basant uniquement sur le code qu’il rend disponible publiquement, c’est exclure bien plus que les gens marginaux. C’est aussi exclure quiconque n’est pas autorisé à publier son code publiquement pour des raisons de licence ou de sécurité. Cela concerne également un grand nombre de travailleurs freelance ou de contractuels qui, pour des raisons légales, n’ont pas le droit de revendiquer publiquement leur participation à un projet (par exemple s’ils ont signé un accord de confidentialité). Dans une industrie où on lutte pour dénicher assez de talents, pourquoi limitons-nous artificiellement le spectre des candidats ? » (source)

Comment atténuer ou éviter certains des coûts qui s’imposent aux personnes qui participent à l’élaboration d’infrastructures numériques aujourd’hui ? Pour commencer, nous analyserons comment les projets d’infrastructure sont actuellement financés.

Une question épineuse pour les projets libres et open source est leur maintenance à long terme, et bien évidemment les ressources, tant financières qu’humaines, que l’on peut y consacrer. Tel est le sujet qu’aborde ce nouveau chapitre de l’ouvrage de Nadia Eghbal Des routes et des ponts que le groupe Framalang vous traduit semaine après semaine (si vous avez raté les épisodes précédents)

Elle examine ici une série de cas de figures en fonction de l’origine de l’origine projet.

Comment les projets d’infrastructure numérique sont-ils gérés et maintenus ?

TraductionFramalang : Diane, Penguin, Asta, Rozmador, Lumibd, jum-s, goofy, salade, AFS, Théo

Nous avons établi que les infrastructures numériques sont aussi nécessaires à la société moderne que le sont les infrastructures physiques. Bien qu’elles ne soient pas sujettes aux coûts élevés et aux obstacles politiques auxquels sont confrontées ces dernières, leur nature décentralisée les rend cependant plus difficiles à cerner. Sans une autorité centrale, comment les projets open source trouvent-ils les ressources dont ils ont besoin ?

En un mot, la réponse est différente pour chaque projet. Cependant, on peut identifier plusieurs lieux d’où ces projets peuvent  émaner : au sein d’une entreprise, via une startup, de développeurs individuels ou collaborant en communauté.

Au sein d’une entreprise

Parfois, le projet commence au sein d’une entreprise. Voici quelques exemples qui illustrent par quels moyens variés un projet open source peut être soutenu par les ressources d’une entreprise :

Go, le nouveau langage de programmation évoqué précédemment, a été développé au sein de Google en 2007 par les ingénieurs Robert Griesemer, Rob Pike, et Ken Thompson, pour qui la création de Go était une expérimentation. Go est open source et accepte les contributions de la communauté dans son ensemble. Cependant, ses principaux mainteneurs sont employés à plein temps par Google pour travailler sur le langage.

React est une nouvelle bibliothèque JavaScript dont la popularité grandit de jour en jour.
React a été créée par Jordan Walke, ingénieur logiciel chez Facebook, pour un usage interne sur le fil d’actualités Facebook. Un employé d’Instagram (qui est une filiale de Facebook) a également souhaité utiliser React, et finalement, React a été placée en open source, deux ans après son développement initial.
Facebook a dédié une équipe d’ingénieurs à la maintenance du projet, mais React accepte aussi les contributions de la communauté publique des développeurs.

Swift, le langage de programmation utilisé pour iOS, OS X et les autres projets d’Apple, est un exemple de projet qui n’a été placé en open source que récemment. Swift a été développé par Apple en interne pendant quatre ans et publié en tant que langage propriétaire en 2014. Les développeurs pouvaient utiliser Swift pour écrire des programmes pour les appareils d’Apple, mais ne pouvaient pas contribuer au développement du cœur du langage. En 2015, Swift a été rendu open source sous la licence Apache 2.0.

Pour une entreprise, les incitations à maintenir un projet open source sont nombreuses. Ouvrir un projet au public peut signifier moins de travail pour l’entreprise, grâce essentiellement aux améliorations de la collaboration de masse.
Cela stimule la bonne volonté et l’intérêt des développeurs, qui peuvent alors être incités à utiliser d’autres ressources de l’entreprise pour construire leurs projets.

Disposer d’une communauté active de programmeurs crée un vivier de talents à recruter. Et parfois, l’ouverture du code d’un projet aide une entreprise à renforcer sa base d’utilisateurs et sa marque, ou même à l’emporter sur la concurrence. Plus une entreprise peut capter de parts de marché, même à travers des outils qu’elle distribue gratuitement, plus elle devient influente. Ce n’est pas très différent du concept commercial de « produit d’appel ».

Même quand un projet est créé en interne, s’il est open source, alors il peut être librement utilisé ou modifié selon les termes d’une licence libre, et n’est pas considéré comme relevant de la propriété intellectuelle de l’entreprise au sens traditionnel du terme. De nombreux projets d’entreprise utilisent des licences libres standard qui sont considérées comme acceptables par la communauté des développeurs telles que les licences Apache 2.0 ou BSD. Cependant, dans certains cas, les entreprises ajoutent leurs propres clauses. La licence de React, par exemple, comporte une clause additionnelle qui pourrait potentiellement créer des conflits de revendications de brevet avec les utilisateurs de React.

En conséquence, certaines entreprises et individus sont réticents à utiliser React, et cette décision est fréquemment décrite comme un exemple de conflit avec les principes de l’open source.

Via une startup

Certains projets d’infrastructures empruntent la voie traditionnelle de la startup, ce qui inclut des financements en capital-risque. Voici quelques exemples :
Docker, qui est peut-être l’exemple contemporain le plus connu, aide les applications logicielles à fonctionner à l’intérieur d’un conteneur. (Les conteneurs procurent un environnement propre et ordonné pour les applications logicielles, ce qui permet de les faire fonctionner plus facilement partout). Docker est né en tant que projet interne chez dotCloud, une société de Plate-forme en tant que service (ou PaaS, pour  platform as a service en anglais), mais le projet est devenu si populaire que ses fondateurs ont décidé d’en faire la principale activité de l’entreprise. Le projet Docker a été placé en open source en 2013. Docker a collecté 180 millions de dollars, avec une valeur estimée à plus d’1 milliard de dollars.

Leur modèle économique repose sur du support technique, des projets privés et des services. Les revenus de Docker pour l’année 2014 ne dépassaient pas 10 millions de dollars.

Npm est un gestionnaire de paquets sorti en 2010 pour aider les développeurs de Node.js à partager et à gérer leurs projets. Npm a collecté près de 11 millions de dollars de financements depuis 2014 de la part de True Ventures et de Bessemer Ventures, entre autres. Leur modèle économique se concentre sur des fonctionnalités payantes en faveur de la vie privée et de la sécurité.

Meteor est un framework JavaScript publié pour la première fois en 2012. Il a bénéficié d’un programme d’incubation au sein de Y Combinator, un prestigieux accélérateur de startups qui a également été l’incubateur d’entreprises comme AirBnB et Dropbox. À ce jour, Meteor a reçu plus de 30 millions de dollars de financements de la part de firmes comme Andreessen Horowitz ou Matrix Partners. Le modèle économique de Meteor se base sur une plateforme d’entreprise nommée Galaxy, sortie en Octobre 2015, qui permet de faire fonctionner et de gérer les applications Meteor.

L’approche basée sur le capital-risque est relativement nouvelle, et se développe rapidement.
Lightspeed Venture Partners a constaté qu’entre 2010 et 2015, les sociétés de capital-risque ont investi plus de 4 milliards de dollars dans des entreprises open source, soit dix fois plus que sur les cinq années précédentes.

Le recours aux fonds de capital-risque pour soutenir les projets open source a été accueilli avec scepticisme par les développeurs (et même par certains acteurs du capital-risque eux-mêmes), du fait de l’absence de modèles économiques ou de revenus prévisibles pour justifier les estimations. Steve Klabnik, un mainteneur du langage Rust, explique le soudain intérêt des capital-risqueurs pour le financement de l’open source :

« Je suis un investisseur en capital-risque. J’ai besoin qu’un grand nombre d’entreprises existent pour gagner de l’argent… J’ai besoin que les coûts soient bas et les profits élevés. Pour cela, il me faut un écosystème de logiciels open source en bonne santé. Donc je fais quoi? … Les investisseurs en capital-risque sont en train de prendre conscience de tout ça, et ils commencent à investir dans les infrastructures. […]
Par bien des aspects, le matériel open source est un produit d’appel, pour que tu deviennes accro…puis tu l’utilises pour tout, même pour ton code propriétaire. C’est une très bonne stratégie commerciale, mais cela place GitHub au centre de ce nouvel univers. Donc pour des raisons similaires, a16z a besoin que GitHub soit génial, pour servir de tremplin à chacun des écosystèmes open source qui existeront à l’avenir… Et a16z a suffisamment d’argent pour en «gaspiller » en finançant un projet sur lequel ils ne récupéreront pas de bénéfices directs, parce qu’ils sont suffisamment intelligents pour investir une partie de leurs fonds dans le développement de l’écosystème. »

GitHub, créé en 2008, est une plateforme de partage/stockage de code, disponible en mode public ou privé, doté d’un environnement ergonomique. Il héberge de nombreux projets open source populaires et, surtout, il est devenu l’épicentre culturel de la croissance explosive de l’open source (dont nous parlerons plus loin dans ce rapport).
GitHub n’a reçu aucun capital-risque avant 2012, quatre ans après sa création. Avant cette date, GitHub était une entreprise rentable. Depuis 2012, GitHub a reçu au total 350 millions de dollars de financements en capital-risque.

Andreessen Horowitz (alias a16z), la firme d’investissement aux 4 millards de dollars qui a fourni l’essentiel du capital de leur première levée de fonds de 100 millions de dollars, a déclaré qu’il s’agissait là de l’investissement le plus important qu’elle ait jamais fait jusqu’alors.
En d’autres termes, la théorie de Steve Klabnik est que les sociétés de capital-risque qui investissent dans les infrastructures open source promeuvent ces plateformes en tant que « produit d’appel », même quand il n’y a pas de modèle économique viable ou de rentabilité à en tirer, parce que cela permet de faire croître l’ensemble de l’écosystème. Plus GitHub a de ressources, plus l’open source est florissant. Plus l’open source est florissant, et mieux se portent les startups. À lui seul, l’intérêt que portent les sociétés d’investissement à l’open source, particulièrement quand on considère l’absence de véritable retour financier, est une preuve du rôle-clé que joue l’open source dans l’écosystème plus large des startups.
Par ailleurs, il est important de noter que la plateforme GitHub en elle-même n’est pas un projet open source, et n’est donc pas un exemple de capital-risque finançant directement l’open source. GitHub est une plateforme à code propriétaire qui héberge des projets open source. C’est un sujet controversé pour certains contributeurs open source.

Par des personnes ou un groupe de personnes

Enfin, de nombreux projets d’infrastructures numériques sont intégralement développés et maintenus par des développeurs indépendants ou des communautés de développeurs. Voici quelques exemples :

Python, un langage de programmation, a été développé et publié par un informaticien, Guido van Rossum, en 1991.
Van Rossum déclarait qu’il « était à la recherche d’un projet de programmation « passe-temps », qui [le] tiendrait occupé pendant la semaine de Noël. »
Le projet a décollé, et Python est désormais considéré comme l’un des langages de programmation les plus populaires de nos jours.

Van Rossum reste le principal auteur de Python (aussi connu parmi les développeurs sous le nom de « dictateur bienveillant à vie » et il est actuellement employé par Dropbox, dont les logiciels reposent fortement sur Python.

Python est en partie géré par la Python Software Foundation (NdT: Fondation du logiciel Python), créée en 2001, qui bénéficie de nombreux sponsors commerciaux, parmi lesquel Intel, HP et Google.

RubyGems est un gestionnaire de paquets qui facilite la distribution de programmes et de bibliothèques associés au langage de programmation Ruby.
C’est une pièce essentielle de l’infrastructure pour tout développeur Ruby. Parmi les sites web utilisant Ruby, on peut citer par exemple Hulu, AirBnB et Bloomberg. RubyGems a été créé en 2003 et est géré par une communauté de développeurs. Certains travaux de développement sont financés par Ruby Together, une fondation qui accepte les dons d’entreprises et de particuliers.

Twisted, une bibliothèque Python, fut créée en 2002 par un programmeur nommé Glyph Lefkowitz. Depuis lors,  son usage s’est largement répandu auprès d’individus et d’organisations, parmi lesquelles Lucasfilm et la NASA.
Twisted continue d’être géré par un groupe de volontaires. Le projet est soutenu par des dons corporatifs/commerciaux et individuels ; Lefkowitz en reste l’architecte principal et gagne sa vie en proposant ses services de consultant.

Comme le montrent tous ces exemples, les projets open source peuvent provenir de pratiquement n’importe où. Ce qui est en général considéré comme une bonne chose. Cela signifie que les projets utiles ont le plus de chances de réussir, car ils évitent d’une part les effets de mode futiles inhérents aux startups, et d’autre part la bureaucratie propre aux gouvernements. La nature décentralisée de l’infrastructure numérique renforce également les valeurs de démocratie et d’ouverture d’Internet, qui permet en principe à chacun de créer le prochain super projet, qu’il soit une entreprise ou un individu.
D’un autre côté, un grand nombre de projets utiles proviendront de développeurs indépendants qui se trouveront tout à coup à la tête d’un projet à succès, et qui devront prendre des décisions cruciales pour son avenir. Une étude de 2015 menée par l’Université fédérale de Minas Gerai au Brésil a examiné 133 des projets les plus activement utilisés sur Github, parmi les langages de programmation, et a découvert que 64 % d’entre eux, presque les deux tiers, dépendaient pour leur survie d’un ou deux développeurs seulement.

Bien qu’il puisse y avoir une longue traîne de contributeurs occasionnels ou ponctuels pour de nombreux projets, les responsabilités principales de la gestion du projet ne reposent que sur un très petit nombre d’individus.

Coordonner des communautés internationales de contributeurs aux avis arrêtés, tout en gérant les attentes d’entreprises classées au Fortune 500 qui utilisent votre projet, voilà des tâches qui seraient des défis pour n’importe qui. Il est impressionnant de constater combien de projets ont déjà été accomplis de cette manière. Ces tâches sont particulièrement difficiles dans un contexte où les développeurs manquent de modèles clairement établis, mais aussi de soutien institutionnel pour mener ce travail à bien. Au cours d’interviews menées pour ce rapport, beaucoup de développeurs se sont plaints en privé qu’ils n’avaient aucune idée de qui ils pouvaient solliciter pour avoir de l’aide, et qu’ils préféreraient « juste coder ».

Pourquoi continuent-ils à le faire ? La suite de ce rapport se concentrera sur pourquoi et comment les contributeurs de l’open source maintiennent des projets à grande échelle, et sur les raisons pour lesquelles c’est important pour nous tous.