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. »

Voici le plus long des chapitres de Des routes et des ponts de Nadia Ehgbal que nous traduisons pour vous semaine après semaine (si vous avez raté les épisodes précédents). Il s’agit cette fois-ci des institutions (ici nord-américaines) qui par diverses formes de mécénat, contribuent au développement et au maintien des projets d’infrastructure numérique open source parce qu’elles y trouvent leur intérêt. Pas sûr qu’en Europe et en France ces passerelles et ces coopérations bien comprises entre entreprises et open source soient aussi habituelles…

Traduction Framalang :  Opsylac, Luc, jums, xi, serici, lyn, mika, AFS, Goofy

Les efforts institutionnels pour financer les infrastructures numériques

Il existe des institutions qui s’efforcent d’organiser collectivement les projets open source et aider à leur financement. Il peut s’agir de fondations indépendantes liées aux logiciels, ou d’entreprises de logiciels elles-mêmes qui apportent leur soutien.

Soutien administratif et mécénat financier

Plusieurs fondations fournissent un soutien organisationnel, comme le mécénat financier, aux projets open source : en d’autres termes, la prise en charge des tâches autres que le code, dont beaucoup de développeurs se passent volontiers. L’Apache Software Foundation, constituée en 1999, a été créée en partie pour soutenir le développement du serveur Apache HTTP, qui dessert environ 55 % de la totalité des sites internet dans le monde.

Depuis lors, la fondation Apache est devenue un foyer d’ancrage pour plus de 350 projets open source. Elle se structure comme une communauté décentralisée de développeurs, sans aucun employé à plein temps et avec presque 3000 bénévoles. Elle propose de multiples services aux projets qu’elle héberge, consistant principalement en un soutien organisationnel, juridique et de développement. En 2011, Apache avait un budget annuel de plus de 500 000 $, issu essentiellement de subventions et de donations.

Le Software Freedom Conservancy, fondée en 2006, fournit également des services administratifs non-lucratifs à plus de 30 projets libres et open source. Parmi les projets que cette fondation soutient, on retrouve notamment Git, le système de contrôle de versions dont nous avons parlé plus haut et sur lequel GitHub a bâti sa plateforme, et Twisted, une librairie Python déjà citée précédemment.

On trouve encore d’autres fondations fournissant un soutien organisationnel, par exemple The Eclipse Foundation et Software in the Public Interest. La Fondation Linux et la Fondation Mozilla soutiennent également des projets open source externes de diverses façons (dont nous parlerons plus loin dans ce chapitre), bien que ce ne soit pas le but principal de leur mission.

Il est important de noter que ces fondations fournissent une aide juridique et administrative, mais rarement financière. Ainsi, être sponsorisé par Apache ou par le Software Freedom Conservancy ne suffit pas en soi à financer un projet ; les fondations ne font que faciliter le traitement des dons et la gestion du projet.

Un autre point important à noter, c’est que ces initiatives soutiennent le logiciel libre et open source d’un point de vue philosophique, mais ne se concentrent pas spécifiquement sur ses infrastructures. Par exemple, OpenTripPlanner, projet soutenu par le Software Freedom Conservancy, est un logiciel pour planifier les voyages : même son code est open source, il s’agit d’une application destinée aux consommateurs, pas d’une infrastructure.

Créer une fondation pour aider un projet

Certains projets sont suffisamment importants pour être gérés à travers leurs propres fondations. Python, Node.js, Django et jQuery sont tous adossés à des fondations.

Il y a deux conditions fondamentales à remplir pour qu’une fondation fonctionne : accéder au statut d’exemption fiscale et trouver des financements.

Réussir à accéder au statut 501(c), la loi américaine qui définit les organismes sans but lucratif, peut s’avérer difficile pour ces projets, à cause du manque de sensibilisation autour de la technologie open source et de la tendance à voir l’open source comme une activité non-caritative. En 2013, une controverse a révélé que l’IRS (Internal Revenue Service, service des impôts américain) avait dressé une liste de groupes postulant au statut d’exemption fiscale qui nécessiteraient davantage de surveillance : l’open source en faisait partie. Malheureusement, ces contraintes ne facilitent pas l’institutionnalisation de ces projets.

Par exemple, Russell Keith-Magee, qui était jusqu’à une époque récente président de la Django Software Foundation, a expliqué que la fondation ne pouvait pas directement financer le développement logiciel de Django, sans prendre le risque de perdre son statut 501(c). La fondation soutient plutôt le développement via des activités communautaires.

En juin 2014, la Fondation Yorba, qui a créé des logiciels de productivité qui tournent sous Linux, s’est vu refuser le statut 501(c) après avoir attendu la décision pendant presque quatre ans et demi. Jim Nelson, son directeur exécutif, a été particulièrement inquiété par le raisonnement de l’IRS : parce que leur logiciel pouvait potentiellement être utilisé par des entités commerciales, le travail de Yorba ne pouvait pas être considéré comme caritatif. Une lettre de l’IRS explique :

« Se contenter de publier sous une licence open source tous usages ne signifie pas que les pauvres et les moins privilégiés utiliseront effectivement les outils. […] On ne peut pas savoir qui utilise les outils, et encore moins quel genre de contenus sont créés avec ces outils. »

Nelson a pointé les failles de ce raisonnement dans un billet de blog, comparant la situation à celle d’autres biens publics :

« Il y a une organisation caritative ici à San Francisco qui plante des arbres pour le bénéfice de tous. Si l’un de leurs arbres… rafraîchit les clients d’un café pendant qu’ils profitent de leur expresso, cela signifie-t-il que l’organisation qui plante des arbres n’est plus caritative ? »

Les projets qui accèdent au statut 501(c) ont tendance à insister sur l’importance de la communauté, comme la Python Software Foundation, dont l’objet est de « promouvoir, protéger et faire progresser le langage de programmation Python, ainsi que de soutenir et faciliter la croissance d’une communauté diversifiée et internationale de programmeurs Python ».

En parallèle, certains projets candidatent pour devenir une association de commerce au sens du statut 501(c)(6). La Fondation jQuery en est un exemple, se décrivant comme « une association de commerce à but non-lucratif pour développeurs web, financée par ses membres ». La Fondation Linux est également une association de commerce.

Le deuxième aspect de la formalisation de la gouvernance d’un projet à travers une fondation est la recherche de la source de financement adéquate. Certaines fondations sont financées par des donations individuelles, mais ont proportionnellement de petits budgets.

La Django Software Foundation, par exemple, gère Django, le plus populaire des frameworks web écrits en Python, utilisé par des entreprises comme Instagram et Pinterest. La Fondation est dirigée par des bénévoles, et reçoit moins de 60 000 $ de donations par an. L’année dernière, la Django Software Foundation a reçu une subvention ponctuelle de la part de la Fondation Mozilla.

Parmi les autres sources habituelles de financement on trouve les entreprises mécènes. En effet, les entreprises privées sont bien placées pour financer ces projets logiciels, puisqu’elles les utilisent elles-mêmes. La Fondation Linux est l’un de ces cas particuliers qui rencontrent le succès, et ce grâce la valeur fondamentale du noyau Linux pour les activités de quasiment toutes les entreprises. La Fondation Linux dispose de 30 millions de dollars d’un capital géré sur une base annuelle, alimenté par des entreprises privées comme IBM, Intel, Oracle et Samsung – et ce chiffre continue d’augmenter.

Créer une fondation pour soutenir un projet est une bonne idée pour les projets d’infrastructure très conséquents. Mais cette solution est moins appropriée pour de plus petits projets, en raison de la quantité de travail, des ressources, et du soutien constant des entreprises, nécessaires pour créer une organisation durable.

Node.js est un exemple récent d’utilisation réussie d’une fondation pour soutenir un gros projet. Node.js est un framework JavaScript, développé en 2009 par Ryan Dahl et différents autres développeurs employés par Joyent, une entreprise privée du secteur logiciel. Ce framework est devenu extrêmement populaire, mais a commencé à souffrir de contraintes de gouvernance liées à l’encadrement par Joyent, que certaines personnes estimaient incapable de représenter pleinement la communauté enthousiaste et en pleine croissance de Node.js.

En 2014, un groupe de contributeurs de Node.js menaça de forker le projet. Joyent essaya de gérer ces problèmes de gouvernance en créant un conseil d’administration pour le projet, mais la scission eut finalement lieu, le nouveau fork prenant le nom d’io.js. En février 2015 fut annoncée l’intention de créer une organisation 501(c) (6) en vue d’extraire Node.js de la mainmise de Joyent. Les communautés Node.js et io.js votèrent pour travailler ensemble sous l’égide de cette nouvelle entité, appelée la Fondation Node.js. La Fondation Node.js, structurée suivant les conseils de la Fondation Linux, dispose d’un certain nombre d’entreprises mécènes qui contribuent financièrement à son budget, notamment IBM, Microsoft et payPal. Ces sponsors pensent retirer une certaine influence de leur soutien au développement d’un projet logiciel populaire qui fait avancer le web, et ils ont des ressources à mettre à disposition.

Un autre exemple prometteur est Ruby Together, une organisation initiée par plusieurs développeurs Ruby pour soutenir des projets d’infrastructure Ruby. Ruby Together est structuré en tant qu’association commerciale, dans laquelle chaque donateur, entreprise ou individu, investit de l’argent pour financer le travail à temps plein de développeurs chargés d’améliorer le cœur de l’infrastructure Ruby. Les donateurs élisent un comité de direction bénévole, qui aide à décider chaque mois sur quels projets les membres de Ruby Together devraient travailler.

Ruby Together fut conçue par deux développeurs et finance leur travail de  : André Arko et David Radcliffe. Aujourd’hui, en avril 2016, est également rémunéré le travail de quatre autres mainteneurs d’infrastructure. Le budget mensuel en mars 2016 était d’un peu plus de 18 000 dollars par mois, couvert entièrement par des dons. La création de Ruby Together fut annoncée en mars 2015 et reste un projet récent, mais pourrait bien servir de base à un modèle davantage orienté vers la communauté pour financer la création d’autres projets d’infrastructure.

Programmes d’entreprises

Les éditeurs de logiciels soutiennent les projets d’infrastructure de différentes manières.

En tant que bénéficiaires des projets d’infrastructures, ils contribuent en faisant remonter des dysfonctionnements et des bugs, en proposant ou soumettant de nouvelles fonctionnalités ou par d’autres moyens. Certaines entreprises encouragent leurs employés à contribuer à des projets d’une importance critique sur leur temps de travail. De nombreux employés contribuent ainsi de manière significative à des projets open source extérieurs à l’entreprise. Pour certains employés, travailler sur de l’open source fait clairement partie de leur travail. L’allocation de temps de travail de leurs salariés est une des plus importantes façons de contribuer à l’open source pour les entreprises.

Les grandes entreprises comme Google ou Facebook adhèrent avec enthousiasme à l’open source, de façon à inspirer confiance et renforcer leur influence ; elles sont de fait les seuls acteurs institutionnels assez importants qui peuvent assumer son coût sans avoir besoin d’un retour financier sur investissement. Les projets open source aident à renforcer l’influence d’une entreprise, que ce soit en publiant son propre projet open source ou en embauchant des développeurs de premier plan pour qu’ils travaillent à plein temps sur un projet open source.

Ces pratiques ne sont pas limitées aux entreprises purement logicielles. Walmart, par exemple, qui est un soutien majeur de l’open source, a investi plus de deux millions de dollars dans un projet open source nommé hapi. Eran Hammer, développeur senior à Walmart Labs, s’est empressé de préciser que « l’open source, ce n’est pas du caritatif » et que les ressources d’ingénierie gratuites sont proportionnelles à la taille des entreprises qui utilisent hapi. Dion Almaer, l’ancien vice-président en ingénierie de Walmart Labs, a remarqué que leur engagement envers l’open source les aidait à recruter, à construire une solide culture d’entreprise, et à gagner « une série d’effets de levier ».

En termes de soutien direct au maintien du projet, il arrive que des entreprises embauchent une personne pour travailler à plein temps à la maintenance d’un projet open source. Les entreprises donnent aussi occasionnellement à des campagnes de financement participatif pour un projet particulier. Par exemple, récemment, une campagne sur Kickstarter pour financer un travail essentiel sur Django a reçu 32 650 £ (environ 40 000 €) ; Tom Christie, l’organisateur de la campagne, a déclaré que 80 % du total venait d’entreprises. Cependant, ces efforts sont toujours consacrés à des projets  spécifiques et les infrastructures numériques ne sont pas encore vues communément comme une question de responsabilité sociale par les entreprises de logiciel à but lucratif. Cela laisse encore beaucoup de marge aux actions de défense et promotion.

L’un des programmes d’entreprise les plus connus est le Summer of Code de Google (été de programmation, souvent nommé GSoC), déjà mentionné dans ce livre, qui offre de l’argent à des étudiant⋅e⋅s pour travailler sur des projets open source pendant un été. Les étudiant⋅e⋅s sont associé⋅e⋅s à des mentors qui vont les aider à se familiariser avec le projet. Le Summer of Code est maintenu par le bureau des programmes open source de Google, et il a financé des milliers d’étudiant⋅e⋅s.

Le but du Summer of Code est de donner à des étudiants la possibilité d’écrire du code pour des projets open source, non de financer les projets eux-mêmes.

L’an dernier, Stripe, une entreprise de traitement des paiements, a annoncé une « retraite  open source », offrant un salaire mensuel d’un maximum de 7500 dollars pour une session de trois mois dans les locaux de Stripe. À l’origine, l’entreprise voulait uniquement offrir deux bourses, mais après avoir reçu 120 candidatures, le programme a été ouvert à quatre bénéficiaires.

Ces derniers ont été enchantés par cette expérience. L’un d’entre eux, Andrey Petrov, continue de maintenir la bibliothèque Python urllib3 dont nous avons déjà parlé, et qui est largement utilisée dans l’écosystème Python.

À propos de cette expérience, Andrey a écrit :

« La publication et la contribution au code open source vont continuer que je sois payé pour ou non, mais le processus sera lent et non ciblé. Ce qui n’est pas un problème, car c’est ainsi que l’open source a toujours fonctionné. Mais on n’est pas obligé d’en rester là. […] 

Si vous êtes une entreprise liée à la technologie, allouez s’il vous plaît un budget pour du financement et des bourses dans le domaine de l’open source. Distribuez-le sur Gittip [Note : Gittip est maintenant dénommé Gratipay. Le produit a été quelque peu modifié depuis la publication originelle du billet d’Andrew] si vous voulez, ou faites ce qu’a fait Stripe et financez des sprints ambitieux pour atteindre des objectifs de haute valeur. 

Considérez ceci comme une demande solennelle  de parrainage : s’il vous plaît, aidez au financement du développement d’urllib3. »

La retraite open source de Stripe peut servir de modèle aux programmes de soutien. Stripe a décidé de reconduire le programme pour une deuxième année consécutive en 2015. Malgré la popularité de leur programme et la chaude réception qu’il a reçue chez les développeurs et développeuses, cette pratique n’est toujours pas répandue dans les autres entreprises.

Les entreprises montrent un intérêt croissant pour l’open source, et personne ne peut prédire au juste ce que cela donnera sur le long terme. Les entreprises pourraient régler le problème du manque de support à long terme en consacrant des ressources humaines et un budget aux projets open source. Des programmes de bourse formalisés pourraient permettre de mettre en contact des entreprises avec des développeurs open source ayant besoin d’un soutien à plein temps. Alors que les équipes de contributeurs à un projet étaient souvent composées d’une diversité de développeurs venant de partout, peut-être seront-elles bientôt composées par un groupe d’employés d’une même entreprise. Les infrastructures numériques deviendront peut-être une série de « jardins clos », chacun d’entre eux étant techniquement ouvert et bénéficiant d’un soutien solide, mais en réalité, grâce à ses ressources illimitées, une seule entreprise et de ses employés en assureront le soutien.

Mais si on pousse la logique jusqu’au bout, ce n’est pas de très bon augure pour l’innovation. Jeff Lindsay, un architecte logiciel qui a contribué à mettre en place l’équipe de Twilio, une entreprise  performante de solutions de communication dans le cloud, livrait  l’an dernier ses réflexions dans une émission :

« À Twilio, on est incité à améliorer le fonctionnement de Twilio, à Amazon on est incité à améliorer le fonctionnement d’Amazon. Mais qui est incité à mieux les faire fonctionner ensemble et à offrir plus de possibilités aux usagers en combinant les deux ? Il n’y a personne qui soit vraiment incité à faire ça. »

Timothy Fuzz, un ingénieur système, ajoute :

« Pour Bruce Schneier, cette situation tient du servage. Nous vivons dans un monde où Google est une cité-état, où Apple est une cité-état et… si je me contente de continuer à utiliser les produits Google, si je reste confiné dans l’environnement Google, tout me paraît bénéfique. Mais il est quasi impossible de vivre dans un monde où je change d’environnement : c’est très pénible, vous tombez sur des bugs, et aucune de ces entreprises ne cherche vraiment à vous aider. Nous sommes dans ce monde bizarre, mais si vous regardez du côté des cités-états, l’un des problèmes majeurs c’est le commerce inter-étatique : si on doit payer des droits de douane parce qu’on cherche à exporter quelque chose d’Austin pour le vendre à Dallas, ce n’est pas un bon modèle économique. On pâtit de l’absence d’innovation et de partage des idées. On en est là, aujourd’hui. »

Bien que l’argument du « servage » se réfère généralement aux produits d’une entreprise, comme l’addiction à l’iPhone ou à Android, il pourrait être tout aussi pertinent pour les projets open source parrainés. Les améliorations prioritaires seront toujours celles qui bénéficient directement à l’entreprise qui paie le développeur. Cette remarque ne relève pas de la malveillance ou de la conspiration : simplement, être payé par une entreprise pour travailler à un projet qui ne fait pas directement partie de ses affaires est une contrainte à prendre en compte.

Mais personne, pas plus Google que la Fondation Linux ou qu’un groupe de développeurs indépendants, ne peut contrôler l’origine d’un bon projet open source. Les nouveaux projets de valeur peuvent germer n’importe où, et quand ils rendent un service de qualité aux autres développeurs, ils sont largement adoptés. C’est une bonne chose et cela alimente l’innovation.

Aide spécifique de fondation

Deux fondations ont récemment fait part de leur décision de financer plus spécifiquement l’infrastructure numérique : la Fondation Linux et la Fondation Mozilla.

Après la découverte de la faille Heartbleed, la Fondation Linux a annoncé qu’elle mettait en place l’Initiative pour les infrastructures essentielles (Core Infrastructure Initiative, CII) pour éviter que ce genre de problème ne se reproduise. Jim Zemlin, le directeur-général de la Fondation Linux, a réuni près de 4 millions de dollars en promesses de dons provenant de treize entreprises privées, dont Amazon Web Services, IBM et Microsoft, pour financer des projets liés à la sécurité des infrastructures pour les trois ans à venir. La Fondation Linux s’occupe également d’obtenir des financements gouvernementaux, y compris de la Maison-Blanche.

La CII est officiellement un projet de la fondation Linux. Depuis sa création en avril 2014, la CII a sponsorisé du travail de développement d’un certain nombre de projets, dont OpenSSL, NTP, GnuPG (un système de chiffrement des communications) et OpenSSH (un ensemble de protocoles relatifs à la sécurité). La CII se concentre en priorité sur une partie de l’infrastructure numérique : les projets relatifs à la sécurité.

Au mois d’octobre 2015, Mitchell Baker, la présidente de la Fondation Mozilla, a annoncé la création du Programme de soutien à l’open source de Mozilla (Mozilla Open Source Support Program, MOSS) et a promis de consacrer un million de dollars au financement de logiciels libres et open source. Selon Baker, ce programme aura deux volets : un volet « rétribution » pour les projets qu’utilise Mozilla et un volet « contribution » pour les projets libres et open source en général. Grâce aux suggestions de la communauté, Mozilla a sélectionné neuf projets pour la première série de bourses. Ils se disent également prêts à financer des audits de sécurité pour les projets open source importants.

Enfin, certaines fondations contribuent ponctuellement à des projets de développement logiciel. Par exemple, la Python Software Foundation propose aux individus et aux associations des bourses modestes destinées pour la plupart aux actions pédagogiques et de sensibilisation.

Autres acteurs institutionnels

Il existe plusieurs autres acteurs qui apportent diverses formes de soutien aux infrastructures numériques : Github, le capital-risque et le monde universitaire. Si Facebook est un « utilitaire social » et Google un « utilitaire de recherche », tous deux régulant de facto les corps dans leur domaine respectif – alors Github a une chance de devenir « l’utilitaire open source ». Son modèle économique l’empêche de devenir un mastodonte financier (contrairement à Facebook ou Google dont le modèle est basé sur la publicité, alors que Github se monétise par l’hébergement de code pour les clients professionnels, et par l’hébergement individuel de code privé), mais Github est toujours un endroit où aujourd’hui encore l’open source est créée et maintenue.

Github s’est doté de grandes aspirations avec une levée de fonds de capital-risque de 350 millions de dollars, même si l’entreprise était déjà rentable. Si Github assume pleinement son rôle d’administrateur du code open source, l’organisation peut avoir une énorme influence sur le soutien apporté à ces projets. Par exemple, elle peut créer de meilleurs outils de gestion de projets open source, défendre certaines catégories de licences, ou aider les gestionnaires de projets à gérer efficacement leurs communautés.

Github a subi de grosses pressions venant des développeurs qui gèrent certains projets, ces pressions incluent une lettre ouverte collective intitulée « Cher Github », principalement issue de la communauté Javascript. Cette lettre explique : « Beaucoup sont frustrés. Certains parmi nous qui déploient des projets très populaires sur Github se sentent totalement ignoré par vous ». La lettre inclut une liste de requêtes pour l’amélioration de produits, qui pourrait les aider à gérer plus efficacement leurs projets.

Github se confronte de plus en plus à des difficultés largement documentées dans les médias. Auparavant, l’entreprise était connue pour sa hiérarchie horizontale, sans aucun manager ni directive venant d’en haut. Les employés de Github avaient aussi la liberté de choisir de travailler sur les projets qu’ils souhaitaient. Ces dernières années, tandis que Github s’est développée pour atteindre presque 500 employés, l’entreprise a réorienté sa stratégie vers une orientation plus commerciale en recrutant des équipes de vente et des dirigeants, insérés dans un système hiérarchique plus traditionnel. Cette transition d’une culture décentralisée vers plus de centralité s’est faite dans la douleur chez Github : au moins 10 dirigeants ont quitté l’organisation durant les quelques mois de l’hiver 2015-2016, ces départs incluant l’ingénieur en chef, le directeur des affaires financières, le directeur stratégique et le directeur des ressources humaines. En raison de ces conflits internes, Github n’a toujours pas pris position publiquement pour jouer un rôle de promoteur de l’open source et assumer un leadership à même de résoudre les questions pressantes autour de l’open source, mais le potentiel est bel et bien là.

Pour le capital-risque, abordé précédemment, il y a un enjeu particulier dans l’avenir des infrastructures numériques. Comme les outils des développeurs aident les entreprises du secteur technologique à créer plus rapidement et plus efficacement, meilleurs sont les outils, meilleures sont les startups, meilleure sera la rentabilité du capital-risque. Néanmoins, l’infrastructure, d’un point de vue capitaliste, n’est en rien limitée à l’open source mais plus largement focalisée sur les plateformes qui aident d’autres personnes à créer. C’est pour cela que les investissements dans Github ou npm, qui sont des plateformes qui aident à diffuser du code source, ont un sens, mais tout aussi bien les investissements dans Slack, une plateforme de travail collaboratif que les développeurs peuvent utiliser pour construire des applications en ligne de commande connectées à la plateforme (à ce propos, le capital-risque a constitué un fonds de 80 millions dédié au support de projets de développement qui utilisent Slack). Même si le capital-risque apprécie les mécaniques sous-jacentes de l’infrastructure, il est limité dans ses catégories d’actifs : un capitaliste ne peut pas investir dans un projet sans modèle économique.

Enfin, les institutions universitaires ont joué un rôle historique éminent dans le soutien aux infrastructures numériques, tout particulièrement le développement de nouveaux projets. Par exemple, LLVM, un projet de compilateur pour les langages C et C++, a démarré en tant que projet de recherche au sein de l’Université de l’Illinois, à Urbana-Champaign. Il est maintenant utilisé par les outils de développement de Mac OS X et iOS d’Apple, mais aussi dans le kit de développement de la Playstation 4 de Sony.

Un autre exemple, R, un langage de programmation répandu dans la statistique assistée par ordinateur et l’analyse de données, a été d’abord écrit par Robert Gentleman et Ross Ihaka à l’Université d’Auckland. R n’est pas uniquement utilisé par des entreprises logicielles comme Facebook ou Google, mais aussi par la Bank of America, l’Agence américaine des produits alimentaires et médicamenteux et le Service météorologique national américain, entre autres.

Quelques universités emploient également des programmeurs qui ont alors la liberté de travailler à des projets open source. Par exemple, le protocole d’heure réseau ou NTP (Network Time Protocol) utilisé pour synchroniser le temps via Intrenet, fut d’abord développé par David Mills, maintenant professeur émérite de l’université du Delaware — le projet continuant à être maintenu par un groupe de volontaires conduit par Harlan Stenn. Bash, l’outil de développement dont nous parlions dans un chapitre précédent, est actuellement maintenu par Chet Ramsay, qui est employé par le département des technologies de l’information de l’université Case Western.

Les institutions universitaires ont le potentiel pour jouer un rôle important dans le soutien de nouveaux projets, parce que cela coïncide avec leurs missions et types de donation, mais elles peuvent aussi manquer de la réactivité nécessaire pour attirer les nouveaux programmeurs open source. NumFOCUS est un exemple d’une fondation 501(c)(3) qui soutient les logiciels scientifiques open source à travers des donations et  parrainages financiers. Le modèle de la fondation externe peut aider à fournir le soutien dont les logiciels scientifiques ont besoin dans un contexte d’environnement universitaire. Les fondations Alfred P. Sloan et Gordon & Betty Moore expérimentent aussi des manières de connecter les institutions universitaires avec les mainteneurs de logiciels d’analyse des données, dans le but de soutenir un écosystème ouvert et durable.

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.

Chaque semaine, l’équipe Framalang vous propose la traduction d’un chapitre de Roads and Bridges de Nadia Eghbal, une enquête fouillée qui explore les problématiques des infrastructures numériques, et en particulier leur intrication avec l’écosystème open source.

Après avoir exploré dans le précédent chapitre différents types de modèles économiques adaptés aux projets open source (retrouvez ici tous les chapitres antérieurs), l’auteure examine ici les cas de projets s’appuyant sur les dons ou le mécénat : du financement participatif au soutien institutionnalisé d’une entreprise, elle analyse les avantages et les limites de chaque solution, et livre les témoignages de nombreux porteurs de projets ou contributeurs qui relatent leur expérience au cœur de projets aussi divers qu’OpenSSL, jQuery ou encore Node.js.

Traduction Framalang : goofy, dominix, Opsylac, Rozmador, lyn, Julien, Penguin, Luc, serici, pasquin, et 2 anonymes

La deuxième option pour financer des projets d’infrastructure numérique consiste à trouver des mécènes ou des donateurs. Il s’agit d’une pratique courante dans les cas de figure suivants :

• Il n’existe pas de demande client facturable pour les services proposés par le projet.
• Rendre l’accès payant empêcherait l’adoption (on ne pourrait pas, par exemple, faire payer l’utilisation d’un langage de programmation comme Python, car personne ne l’utiliserait ; ce serait comme si parler anglais étant payant).
• Le projet n’a pas les moyens de financer des emplois rémunérés, ou bien il n’y a pas de volonté de la part du développeur de s’occuper des questions commerciales.
• La neutralité et le refus de la commercialisation sont considérés comme des principes importants en termes de gouvernance.

Dans ce type de situation, un porteur de projet cherchera des mécènes qui croient en la valeur de son travail et qui sont disposés à le soutenir financièrement. À l’heure actuelle, il existe deux sources principales de financement : les entreprises de logiciel et les autres développeurs.

Le financement participatif

Certains travaux de développement obtiennent des fonds grâce à des campagnes de financement participatif (« crowdfunding ») via des plateformes telles que Kickstarter ou Indiegogo. Bountysource, le site de récompenses dont nous parlions dans un chapitre précédent, possède également une plateforme appelée Salt dédiée au financement participatif de projets open source.

Andrew Godwin, un développeur du noyau Django résidant à Londres, a ainsi réussi à récolter sur Kickstarter 17952£ (environ 21000€) de la part de 507 contributeurs, afin de financer des travaux de base de données pour Django. Le projet a été entièrement financé en moins de quatre heures.

Pour expliquer sa décision de lever des fonds pour un projet open source, Godwin écrit :

« Une quantité importante de code open source est écrit gratuitement. Cependant, mon temps libre est limité. Je dispose actuellement d’une seule journée libre par semaine pour travailler, et j’adorerais la consacrer à l’amélioration de Django, plutôt qu’à du conseil ou à de la sous-traitance.

L’objectif est double : d’une part, garantir au projet un temps de travail conséquent et au moins 80 heures environ de temps de codage ; et d’autre part prouver au monde que les logiciels open source peuvent réellement rémunérer le temps de travail des développeurs. »

À l’instar des récompenses, le financement participatif s’avère utile pour financer de nouvelles fonctionnalités, ou des développements aboutissant à un résultat clair et tangible. Par ailleurs, le financement participatif a moins d’effets pervers que les récompenses, notamment parce qu’organiser une campagne de financement demande plus d’efforts que de poster une offre de récompense, et parce que le succès du financement repose en grande partie sur la confiance qu’a le public dans la capacité du porteur de projet à réaliser le travail annoncé. Dans le cas de Godwin, il était l’un des principaux contributeurs au projet Django depuis six ans et était largement reconnu dans la communauté.

Toutefois, le financement participatif ne répond pas à la nécessité de financer les frais de fonctionnement et les frais généraux. Ce n’est pas une source de capital régulière. En outre, planifier et mettre en œuvre une campagne de financement participatif demande à chaque fois un investissement important en temps et en énergie. Enfin, les donateurs pour ces projets sont souvent eux-mêmes des développeurs ou des petites entreprises – et un porteur de projet ne peut pas éternellement aller toquer à la même porte pour financer ses projets.

Avec le recul, Godwin a commenté sa propre expérience :

« Je ne suis pas sûr que le financement participatif soit totalement compatible avec le développement open source en général ; non seulement c’est un apport ponctuel, mais en plus l’idée de rétribution est souvent inadéquate car elle nécessite de promettre quelque chose que l’on puisse garantir et décrire a priori.

S’en remettre uniquement à la bonne volonté du public, cela ne fonctionnera pas. On risque de finir par s’appuyer de manière disproportionnée sur des développeurs, indépendants ou non, à un niveau personnel – et je ne pense pas que ce soit viable. »

À côté des campagnes de financement participatif, plusieurs plateformes ont émergé pour encourager la pratique du « pourboire » (tipping en anglais) pour les contributeurs open source : cela consiste à verser une petite somme de revenu régulier à un contributeur, en signe de soutien à son travail. Deux plateformes populaires se distinguent : Patreon (qui ne se limite pas exclusivement aux contributeurs open source) et Gratipay (qui tend à fédérer une communauté plus technique).

L’idée d’un revenu régulier est alléchante, mais souffre de certains problèmes communs avec le financement participatif. On remarque notamment que les parrains (patrons ou tippers en anglais) sont souvent eux-mêmes des développeurs, avec une quantité limitée de capital à se promettre les uns aux autres. Les dons ont généralement la réputation de pouvoir financer une bière, mais pas un loyer. Gratipay rassemble 122 équipes sur sa plateforme, qui reçoivent collectivement 1000 $ par semaine, ce qui signifie qu’un projet touche en moyenne moins de 40$ par mois.

Même les très gros projets tels que OpenSSL ne généraient que 2000$ de dons annuels avant la faille Heartbleed. Comme expliqué précédemment, après Heartbleed, Steve Marquess, membre de l’équipe, a remarqué « un déferlement de soutien de la part de la base de la communauté OpenSSL » : la première vague de dons a rassemblé environ 200 donateurs pour un total de 9000$.

Marquess a remercié la communauté pour son soutien mais a également ajouté :

« Même si ces donations continuent à arriver au même rythme indéfiniment (ce ne sera pas le cas), et même si chaque centime de ces dons allait directement aux membres de l’équipe OpenSSL, nous serions encore loin de ce qu’il faudrait pour financer correctement le niveau de main-d’œuvre humaine nécessaire à la maintenance d’un projet aussi complexe et aussi crucial. Même s’il est vrai que le projet « appartient au peuple », il ne serait ni réaliste ni correct d’attendre de quelques centaines, ou même de quelques milliers d’individus seulement, qu’ils le financent à eux seuls. Ceux qui devraient apporter les vraies ressources, ce sont les entreprises lucratives et les gouvernements qui utilisent OpenSSL massivement et qui le considèrent comme un acquis. »

(À l’appui de l’argument de Marquess, les dons de la part des entreprises furent par la suite plus importants, les sociétés ayant davantage à donner que les particuliers. La plus grosse donation provint d’un fabricant de téléphone chinois, Smartisan, pour un montant de 160000$. Depuis, Smartisan a continué de faire des dons substantiels au projet OpenSSL.)

Au bout du compte, la réalité est la suivante : il y a trop de projets, tous qualitatifs ou cruciaux à leur manière, et pas assez de donateurs, pour que la communauté technique (entreprises ou individus) soit en mesure de prêter attention et de contribuer significativement à chacun d’eux.

Le mécénat d’entreprises pour les projets d’infrastructure

À plus grande échelle, dans certains cas, la valeur d’un projet devient si largement reconnue qu’une entreprise finit par recruter un contributeur pour travailler à plein temps à son développement.

John Resig est l’auteur de jQuery, une bibliothèque de programmation JavaScript qui est utilisée par près des 2/3 du million de sites web les plus visités au monde. John Resig a développé et publié jQuery en 2006, sous la forme d’un projet personnel. Il a rejoint Mozilla en 2007 en tant que développeur évangéliste, se spécialisant notamment dans les bibliothèques JavaScript.

La popularité de jQuery allant croissante, il est devenu clair qu’en plus des aspects liés au développement technique, il allait falloir formaliser certains aspects liés à la gouvernance du projet. Mozilla a alors proposé à John de travailler à plein temps sur jQuery entre 2009 et 2011, ce qu’il a fait.

À propos de cette expérience, John Resig a écrit :

« Pendant l’année et demi qui vient de s’écouler, Mozilla m’a permis de travailler à plein temps sur jQuery. Cela a abouti à la publication de 9 versions de jQuery… et à une amélioration drastique de l’organisation du projet (nous appartenons désormais à l’organisation à but non lucratif Software Freedom Conservancy, nous avons des réunions d’équipe régulières, des votes publics, fournissons des états des lieux publics et encourageons activement la participation au projet). Heureusement, le projet jQuery se poursuit sans encombre à l’heure actuelle, ce qui me permet de réduire mon implication à un niveau plus raisonnable et de participer à d’autres travaux de développement. »

Après avoir passé du temps chez Mozilla pour donner à jQuery le support organisationnel dont il avait besoin, John a annoncé qu’il rejoindrait la Khan Academy afin de se concentrer sur de nouveaux projets.

Cory Benfield, développeur Python, a suivi un chemin similaire. Après avoir contribué à plusieurs projets open source sur son temps libre, il est devenu un développeur-clé pour une bibliothèque essentielle de Python intitulée Requests. Cory Benfield note que :

« Cette bibliothèque a une importance comparable à celle de Django, dans la mesure où les deux sont des « infrastructures critiques » pour les développeurs Python. Et pourtant, avant que j’arrive sur le projet, elle était essentiellement maintenue par une seule personne. »

Benfield estime qu’il a travaillé bénévolement sur le projet environ 12 heures par semaine pendant presque quatre ans, en plus de son travail à plein temps. Personne n’était payé pour travailler sur Requests.

Pendant ce temps, HP embauchait un employé, Donald Stufft, pour se consacrer spécifiquement aux projets en rapport avec Python, un langage qu’il considère comme indispensable à ses logiciels. (Donald est le développeur cité précédemment qui est payé à plein temps pour travailler sur le packaging Python). Donald a alors convaincu son supérieur d’embaucher Cory pour qu’il travaille à temps plein sur des projets Python. Il y travaille toujours.

Les entreprises sont des acteurs tout désignés pour soutenir financièrement les projets bénévoles qu’elles considèrent comme indispensables à leurs activités, et quand des cas comme ceux de John Resig ou de Cory Benfield surviennent, ils sont chaleureusement accueillis. Cependant, il y a des complications.

Premièrement, aucune entreprise n’est obligée d’embaucher quelqu’un pour travailler sur des projets en demande de soutien ; ces embauches ont tendance à advenir par hasard de la part de mécènes bienveillants. Et même une fois qu’un employé est embauché, il y a toujours la possibilité de perdre ce financement, notamment parce que l’employé ne contribue pas directement au résultat net de l’entreprise. Une telle situation est particulièrement périlleuse si la viabilité d’un projet dépend entièrement d’un seul contributeur employé à plein temps. Dans le cas de Requests, Cory est le seul contributeur à plein temps (on compte deux autres contributeurs à temps partiel, Ian Cordasco et Kenneth Reitz).

Une telle situation s’est déjà produite dans le cas de « rvm », un composant critique de l’infrastructure Ruby. Michal Papis, son auteur principal, a été engagé par Engine Yard entre 2011 et 2013 pour soutenir le développement de rvm. Mais quand ce parrainage s’est terminé, Papis a dû lancer une campagne de financement participatif pour continuer de financer le développement de rvm.

Le problème, c’est que cela ne concernait pas seulement rvm. Engine Yard avait embauché plusieurs mainteneurs de projets d’infrastructure Ruby, qui travaillaient notamment sur JRuby, Ruby on Rails 3 et bundler. Quand les responsables d’Engine Yard ont été obligés de faire le choix réaliste qui s’imposait pour la viabilité de leur entreprise, c’est-à-dire réduire leur soutien financier, tous ces projets ont perdu leurs mainteneurs à temps plein, et presque tous en même temps.

L’une des autres craintes est qu’une entreprise unique finisse par avoir une influence disproportionnée sur un projet, puisqu’elle en est de facto le seul mécène. Cory Benfield note également que le contributeur ou la contributrice lui-même peut avoir une influence disproportionnée sur le projet, puisqu’il ou elle dispose de beaucoup plus de temps que les autres pour faire des contributions. De fait, une telle décision peut même être prise par une entreprise et un mainteneur, sans consulter le reste de la communauté du projet.

On peut en voir un exemple avec le cas d’Express.js, un framework important pour l’écosystème Node.js. Quand l’auteur du projet a décidé de passer à autre chose, il en a transféré les actifs (en particulier le dépôt du code source et le nom de domaine) à une société appelée StrongLoop dont les employés avaient accepté de continuer à maintenir le projet. Cependant StrongLoop n’a pas fourni le soutien qu’attendait la communauté, et comme les employés de StrongLoop étaient les seuls à avoir un accès administrateur, il est devenu difficile pour la communauté de faire des contributions. Doug Wilson, l’un des principaux mainteneurs (non-affilié à StrongLoop), disposait encore d’un accès commit et a continué de traiter la charge de travail du projet, essayant tant bien que mal de tout gérer à lui seul.

Après l’acquisition de StrongLoop par IBM, Doug déclara que StrongLoop avait bel et bien tué la communauté des contributeurs.

« Au moment où on est passé à StrongLoop, il y avait des membres actifs comme @Fishrock123 qui travaillaient à créer… de la documentation. Et puis tout à coup, je me suis retrouvé tout seul à faire ça sur mon temps libre alors que les demandes de support ne faisaient que se multiplier… et pendant tout ce temps, je me suis tué à la tâche, je me suis engagé pour le compte StrongLoop. Quoi qu’il arrive, jamais plus je ne contribuerai à aucun dépôt logiciel appartenant à StrongLoop. »

Finalement, le projet Express.js a été transféré de StrongLoop à la fondation Node.js, qui aide à piloter des projets appartenant à l’écosystème technologique Node.js.

En revanche, pour les projets open source qui ont davantage d’ampleur et de notoriété, il n’est pas rare d’embaucher des développeurs. La Fondation Linux a fait savoir, par exemple, que 80% du développement du noyau Linux est effectué par des développeurs rémunérés pour leur travail. La fondation Linux emploie également des Fellows [« compagnons » selon un titre consacré, NdT] payés pour travailler à plein temps sur les projets d’infrastructure, notamment Greg Kroah-Hartman, un développeur du noyau Linux, et Linus Torvalds lui-même, le créateur de Linux.

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.

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.

L’open source est de plus en plus populaire et répandu parmi les développeurs. Grâce à des plate-formes comme GitHub, qui ont standardisé la manière de contribuer à un projet, l’open source est devenu plus accessible, au point de devenir une norme. Mais cette nouvelle configuration n’est pas sans poser certains problèmes.

Dans ce nouveau chapitre de son ouvrage Des Routes et des ponts (traduit chapitre après chapitre par l’équipe Framalang), Nadia Eghbal s’intéresse aux enjeux de la standardisation et de la démocratisation de l’open source – notamment à l’inflation parfois anarchique du nombre de projets et de contributeurs : pour elle, l’enjeu est d’éviter que l’écosystème numérique ne se transforme en un fragile château de cartes.

Pourquoi les problèmes de support des infrastructures numériques sont de plus en plus pressants

Traduction Framalang : goudron, Penguin, serici, goofy, Rozmador, xi, Lumibd, teromene, xi, Opsylac, et 3 anonymes.

L’open source, grâce à ses points forts cités plus tôt dans ce rapport, est rapidement en train de devenir un standard pour les projets d’infrastructure numérique et dans le développement logiciel en général. Black Duck, une entreprise qui aide ses clients à gérer des programmes open source, dirige une enquête annuelle qui interroge les entreprises sur leur utilisation de l’open source. (Cette enquête est l’un des rares projets de banque de données qui existe sur le sujet.) Dans leur étude de 2015, 78% des 1300 entreprises interrogées déclarent que les logiciels qu’elles ont créés pour leurs clients sont construits grâce à l’open source, soit presque le double du chiffre de 2010.

L’open source a vu sa popularité s’accroître de manière impressionnante ces cinq dernières années, pas seulement grâce à ses avantages évidents pour les développeurs et les consommateurs, mais également grâce à de nouveaux outils qui rendent la collaboration plus facile. Pour comprendre pourquoi les infrastructures numériques rencontrent des problèmes de support grandissants, nous devons comprendre la manière dont le développement de logiciels open source prolifère.

Github, un espace standardisé pour collaborer sur du code

On n’insistera jamais trop sur le rôle clé de GitHub dans la diffusion de l’open source auprès d’une audience grand public. L’open source a beau exister depuis près de 30 ans, jusqu’en 2008, contribuer à des projets open source n’était pas si facile. Le développeur motivé devait d’abord découvrir qui était le mainteneur du projet, trouver une manière de le contacter, puis proposer ses changements en utilisant le format choisi par le mainteneur (par exemple une liste courriel ou un forum). GitHub a standardisé ces méthodes de communication : les mainteneurs sont listés de façon transparente sur la page du projet, et les discussions sur les changements proposés ont lieu sur la plate-forme GitHub.

GitHub a aussi créé un vocabulaire qui est désormais standard parmi les contributeurs à l’open source, tels que la « pull request » (où un développeur soumet à l’examen de ses pairs une modification à un projet), et changé le sens du terme « fork » (historiquement, créer une copie d’un projet et le modifier pour le transformer en un nouveau projet) [littéralement « fork » signifie « bifurcation », Ndt.]. Avant GitHub, forker un projet revenait à dire qu’il y avait un différend irréconciliable au sujet de la direction qu’un projet devrait prendre. Forker était considéré comme une action grave : si un groupe de développeurs décidait de forker un projet, cela signifiait qu’il se scindait en deux factions idéologiques. Forker était aussi utilisé pour développer un nouveau projet qui pouvait avoir une utilisation radicalement différente du projet initial.

Ce type de « fork de projet » existe toujours, mais GitHub a décidé d’utiliser le terme « fork » pour encourager à davantage d’activité sur sa plate-forme. Un fork GitHub, contrairement à un fork de projet, est une copie temporaire d’un projet sur laquelle on effectue des modifications, et qui est généralement re-fusionnée au projet. Le fork en tant que pratique quotidienne sur GitHub a ajouté une connotation positive, légère au terme : c’est l’idée de prendre l’idée de quelqu’un et de l’améliorer.

GitHub a aussi aidé à standardiser l’utilisation d’un système de contrôle de version appelé Git. Les systèmes de contrôle de versions sont un outil qui permet de garder une trace de chaque contribution apportée sur un morceau de code précis. Par exemple, si le Développeur 1 et le Développeur 2 corrigent différentes parties du même code en même temps, enregistrer chaque changement dans un système de contrôle de version permet de faire en sorte que leurs changements n’entrent pas en conflit. Il existe plusieurs systèmes de contrôle de versions, par exemple Apache Subversion et Concurrent Versions System (CVS). Avant GitHub, Git était un système de contrôle de version assez méconnu. En 2010, Subversion était utilisé dans 60% des projets logiciels, contre 11%pour Git.

C’est Linus Torvalds, le créateur de Linux, qui a conçu Git en 2005. Son intention était de mettre à disposition un outil à la fois plus efficace et plus rapide, qui permette de gérer de multiples contributions apportées par de nombreux participants. Git était vraiment différent des systèmes de contrôle de version précédents, et donc pas forcément facile à adopter, mais son workflow décentralisé a résolu un vrai problème pour les développeurs.

GitHub a fourni une interface utilisateur intuitive pour les projets open source qui utilisent Git, ce qui rend l’apprentissage plus facile pour les développeurs. Plus les développeurs utilisent GitHub, plus cela les incite à continuer d’utiliser Git. Aujourd’hui, en 2016, Git est utilisé par 38% des projets de logiciels, tandis que la part de Subversion est tombée à 47%. Bien que Subversion soit encore le système de contrôle de version le plus populaire, son usage décline. L’adoption généralisée de Git rend plus facile pour un développeur la démarche de se joindre à un projet sur GitHub, car la méthode pour faire des modifications et pour les communiquer est la même sur tous les projets. Apprendre à contribuer sur un seul des projets vous permet d’acquérir les compétences pour contribuer à des centaines d’autres. Ce n’était pas le cas avant GitHub, où des systèmes de contrôle de versions différents étaient utilisés pour chaque projet.

Enfin, GitHub a créé un espace sociabilité, qui permet de discuter et de tisser des liens au-delà de la stricte collaboration sur du code. La plate-forme est devenue de facto une sorte de communauté pour les développeurs, qui l’utilisent pour communiquer ensemble et exposer leur travail. Ils peuvent y démontrer leur influence et présenter un portfolio de leur travail comme jamais auparavant.

Les usages de GitHub sont un reflet de son ascension vertigineuse. En 2011 il n’y avait que 2 millions de dépôts (« repository »). Aujourd’hui, GitHub a 14 millions d’utilisateurs et plus de 35 millions de dépôts (ce qui inclut aussi les dépôts forkés, le compte des dépôts uniques est plutôt aux environs de 17 millions.) Brian Doll, de chez GitHub, a noté qu’il a fallu 4 ans pour atteindre le million de dépôts, mais que passer de neuf millions à dix millions n’a pris que 48 jours.

En comparaison, SourceForge, la plate-forme qui était la plus populaire pour héberger du code open source avant l’apparition de GitHub, avait 150 000 projets en 2008. Environ 18 000 projets étaient actifs.

Stack Overflow, un espace standard pour s’entraider sur du code

L’une des autres plate-formes importantes de l’open source est Stack Overflow, un site de question/réponse populaire parmi les développeurs, créé en 2008 par Jeff Atwood (développeur déjà mentionné précédemment) et par le blogueur Joel Spolsky. En Avril 2014, Stack Overflow avait plus de 4 millions d’utilisateurs enregistrés et plus de 11 millions de questions résolues (à noter qu’il n’est pas nécessaire de s’enregistrer pour voir les questions ou leurs réponses).

Stack Overflow est devenu de facto une plate-forme d’entraide pour les développeurs, qui peuvent poser des questions de programmation, trouver des réponses à des problèmes de code spécifiques, ou juste échanger des conseils sur la meilleure façon de créer un aspect précis d’un logiciel. On pourrait définir la plate-forme comme un « support client » participatif pour les développeurs à travers le monde. Même si Stack Overflow n’est pas un endroit où l’on écrit directement du code, c’est un outil de collaboration essentiel pour les développeurs individuels, qui facilite grandement la résolution de problèmes et permet de coder plus efficacement. Cela signifie qu’un développeur individuel est capable de produire plus, en moins de temps, ce qui améliore le rendement global. Stack Overflow a également permis à certains utilisateurs d’apprendre de nouveaux concepts de développement (ou même de s’initier au code tout court), et a rendu le codage plus facile et plus accessible à tous.

Tendances macro dans un paysage en mutation constante

La popularité hors-normes de l’open source a amené à des changements significatifs dans la manière dont les développeurs d’aujourd’hui parlent, pensent et collaborent sur des logiciels.

Premièrement, les attentes et exigences en termes de licences ont changé, reflétant un monde qui considère désormais l’open source comme une norme, et pas l’exception : un triomphe sur l’univers propriétaire des années 1980. Les politiques de GitHub et de Stack Overflow reflètent toutes deux cette réalité.

Dès le départ, Stack Overflow a choisi d’utiliser une licence Creative Commons appelée CC-BY-SA pour tous les contenus postés sur son site. La licence était cependant limitante, car elle requérait des utilisateurs qu’ils mentionnent l’auteur de chaque morceau de code qu’ils utilisaient, et qu’ils placent leurs propres contributions sous la même licence.

Beaucoup d’utilisateurs choisissaient d’ignorer la licence ou n’étaient même pas au courant de ses restrictions, mais pour les développeurs travaillant avec des contraintes plus strictes (par exemple dans le cadre d’une entreprise), elle rendait Stack Overflow compliqué à utiliser. S’ils postaient une question demandant de l’aide sur leur code, et qu’une personne extérieure réglait le problème, alors légalement, ils devaient attribuer le code à cette personne.

En conséquence, les dirigeants de Stack Overflow ont annoncé leur volonté de déplacer toutes les nouvelles contributions de code sous la Licence MIT, qui est une licence open source comportant moins de restrictions. En Avril 2016, ils débattent encore activement et sollicitent des retours de leur communauté pour déterminer le meilleur moyen de mettre en œuvre un système plus permissif. Cette démarche est un encouragement à la fois pour la popularité de Stack Overflow et pour la prolifération de l’open source en général. Qu’un développeur travaillant dans une grosse entreprise de logiciel puisse légalement inclure le code d’une personne complètement extérieure dans un produit pour lequel il est rémunéré est en effet un accomplissement pour l’open source.

A l’inverse, GitHub fit initialement le choix de ne pas attribuer de licence par défaut aux projets postés sur sa plateforme, peut-être par crainte que cela ne freine son adoption par les utilisateurs et sa croissance. Ainsi, les projets postés sur GitHub accordent le droit de consulter et de forker le projet, mais sont à part ça sous copyright, sauf si le développeur spécifie qu’il s’agit d’une licence open source.

En 2013, GitHub décida enfin de prendre davantage position sur la question des licences, avec notamment la création et la promotion d’un micro-site, choosealicense.com (« choisissez-une-licence »), pour aider les utilisateurs à choisir une licence pour leur projet. Ils encouragent aussi désormais leurs utilisateurs à choisir une licence parmi une liste d’options au moment de créer un nouveau « repository » (dépôt).

Ce qui est intéressant, cependant, c’est que la plupart des développeurs ne se préoccupaient pas de la question des licences : soit ignoraient que leurs projets « open source » n’étaient pas légalement protégés, soit ils s’en fichaient. Une étude informelle réalisée en 2013 par le Software Freedom Law Center (Centre du Droit de la Liberté des Logiciels) sur un échantillon de 1,6 million de dépôts GitHub révéla que seuls 15% d’entre eux avaient spécifié une licence. Aussi, les entretiens avec des développeurs réalisés pour ce rapport suggèrent que beaucoup se fichent de spécifier une licence, ou se disent que si quelqu’un demande, ils pourront toujours en ajouter une plus tard.

Ce manque d’intérêt pour les licences a amené James Governor, cofondateur de la firme d’analyse de développeurs Red Monk, à constater en 2012 que « les jeunes dévs aujourd’hui font du POSS – Post open source software. Envoie chier les licences et la gestion, contribue juste à GitHub » [en anglais « commit to GitHub » signifie littéralement « s’engager dans GitHub » mais fait également référence à la commande « commit » qui permet de valider les modifications apportées à un projet, NdT.]. En d’autres termes, faire de l’information ouverte par défaut est devenu une telle évidence culturelle aujourd’hui que les développeurs ne s’imaginent plus faire les choses autrement – un contexte bien différent de celui des rebelles politisés du logiciel libre des années 1980. Ce retournement des valeurs, quoi qu’inspirant au niveau global, peut cependant amener à des complications légales pour les individus quand leurs projets gagnent en popularité ou sont utilisés à des fins commerciales.

Mais, en rendant le travail collaboratif sur le code aussi facile et standardisé, l’open source se retrouve aux prises avec une série d’externalités perverses.

L’open source a rendu le codage plus facile et plus accessible au monde. Cette accessibilité accrue, à son tour, a engendré une nouvelle catégorie de développeurs, moins expérimentés, mais qui savent comment utiliser les composants préfabriqués par d’autres pour construire ce dont ils ont besoin.

En 2012, Jeff Atwood, cofondateur de Stack Overflow, rédigea un article de blog intitulé ironiquement « Pitié n’apprenez pas à coder », où il se plaint de la mode des stages et des écoles de code. Tout en se félicitant du désir des personnes non-techniciennes de comprendre le code d’un point de vue conceptuel, Atwood met en garde contre l’idée qu’« introduire parmi la main-d’œuvre ces codeurs naïfs, novices, voire même-pas-vraiment-sûrs-d’aimer-ce-truc-de-programmeur, ait vraiment des effets positifs pour le monde ».

Dans ces circonstances, le modèle de développement de l’open source change de visage. Avant l’ascension de GitHub, il y avait moins de projets open source. Les développeurs étaient donc un groupe plus petit, mais en moyenne plus expérimenté : ceux qui utilisaient du code partagé par d’autres étaient susceptibles d’être également ceux qui contribuent en retour.

Aujourd’hui, l’intense développement de l’éducation au code implique que de nombreux développeurs inexpérimentés inondent le marché. Cette dernière génération de développeurs novices emprunte du code libre pour écrire ce dont elle a besoin, mais elle est rarement capable, en retour, d’apporter des contributions substantielles aux projets. Beaucoup sont également habitués à se considérer comme des « utilisateurs » de projets open source, davantage que comme les membres d’une communauté. Les outils open source étant désormais plus standardisés et faciles à utiliser, il est bien plus simple aujourd’hui pour un néophyte de débarquer sur un forum GitHub et d’y faire un commentaire désobligeant ou une requête exigeante – ce qui épuise et exaspère les mainteneurs.

Cette évolution démographique a aussi conduit à un réseau de logiciels bien plus fragmenté, avec de nombreux développeurs qui publient de nouveaux projets et qui créent un réseau embrouillé d’interdépendances. Se qualifiant lui-même de « développeur-pie en rémission » [« pie » est un surnom pour les développeurs-opportunistes, d’après le nom de l’oiseau, la pie réputée voleuse, NdT], Drew Hamlett a écrit en janvier 2016 un post de blog devenu très populaire intitulé « Le triste état du développement web ». L’article traite de l’évolution du développement web, se référant spécifiquement à l’écosystème Node.js :

« Les gens qui sont restés dans la communauté Node ont sans aucun doute créé l’écosystème le plus techniquement compliqué [sic] qui ait jamais existé. Personne n’arrive à y créer une bibliothèque qui fasse quoi que ce soit. Chaque projet qui émerge est encore plus ambitieux que le précédent… mais personne ne construit rien qui fonctionne concrètement. Je ne comprends vraiment pas. La seule explication que j’ai trouvée, c’est que les gens sont juste continuellement en train d’écrire et de réécrire en boucle des applis Node.js. »

Aujourd’hui, il y a tellement de projets qui s’élaborent et se publient qu’il est tout simplement impossible pour chacun d’eux de développer une communauté suffisamment importante et viable, avec des contributeurs réguliers qui discuteraient avec passion des modifications à apporter lors de débats approfondis sur des listes courriels. Au lieu de cela, beaucoup de projets sont maintenus par une ou deux personnes seulement, alors même que la demande des utilisateurs pour ces projets peut excéder le travail nécessaire à leur simple maintenance.

GitHub a rendu simples la création et la contribution à de nouveaux projets. Cela a été une bénédiction pour l’écosystème open source, car les projets se développent plus rapidement. Mais cela peut aussi parfois tourner à la malédiction pour les mainteneurs de projets, car davantage de personnes peuvent facilement signaler des problèmes ou réclamer de nouvelles fonctionnalités, sans pour autant contribuer elles-mêmes en retour. Ces interactions superficielles ne font qu’alourdir la charge de travail des mainteneurs, dont on attend qu’ils répondent à une quantité croissante de requêtes.

Il ne serait pas déraisonnable d’affirmer qu’un monde « post-open source » implique une réflexion non seulement autour des licences, ainsi que James Governor l’exprimait dans son commentaire originel, mais aussi autour du processus de développement lui-même.

Noah Kantrowitz, développeur Python de longue date et membre de la Python Software Foundation, a résumé ce changement dans un post de blog souvent cité :

« Dans les débuts du mouvement open source, il y avait assez peu de projets, et en général, la plupart des gens qui utilisaient un projet y contribuaient en retour d’une façon ou d’une autre. Ces deux choses ont changé à un point difficilement mesurable.
[…] Alors même que nous allons de plus en plus vers des outils de niche, il devient difficile de justifier l’investissement en temps requis pour devenir contributeur. « Combler son propre besoin » est toujours une excellente motivation, mais il est difficile de construire un écosystème là-dessus.
L’autre problème est le déséquilibre de plus en plus important entre producteurs et consommateurs. Avant, cela s’équilibrait à peu près. Tout le monde investissait du temps et des efforts dans les Communs et tout le monde en récoltait les bénéfices. Ces temps-ci, très peu de personnes font cet effort et la grande majorité ne fait que bénéficier du travail de ceux qui s’impliquent.
Ce déséquilibre s’est tellement enraciné qu’il est presque impensable pour une entreprise de rendre (en temps ou en argent) ne serait-ce qu’une petite fraction de la valeur qu’elle dérive des Communs. »

Cela ne veut pas dire qu’il n’existe plus de grands projets open source avec des communautés de contributeurs fortes (Node.js, dont on parlera plus tard dans ce rapport, est un exemple de projet qui est parvenu à ce statut.) Cela signifie qu’à côté de ces réussites, il y a une nouvelle catégorie de projets qui est défavorisée par les normes et les attentes actuelles de l’open source, et que le comportement qui dérive de ces nouvelles normes affecte même des projets plus gros et plus anciens.

Hynek Schlawack, Fellow de la Python Software Foundation et contributeur sur des projets d’infrastructure Python, exprime ses craintes au sujet d’un futur où il y aurait une demande plus forte, mais seulement une poignée de contributeurs solides :

« Ce qui me frustre le plus, c’est que nous n’avons jamais eu autant de développeurs Python et aussi peu de contributions de haute qualité. […] Dès que des développeurs clefs comme Armin Ronacher ralentissent leur travail, la communauté toute entière le ressent aussitôt. Le jour où Paul Kehrer arrête de travailler sur PyCA, on est très mal. Si Hawkowl arrête son travail de portage, Twisted ne sera jamais sur Python 3 et Git.
La communauté est en train de se faire saigner par des personnes qui créent plus de travail qu’elles n’en fournissent. […] En ce moment, tout le monde bénéficie de ce qui a été construit mais la situation se détériore à cause du manque de financements et de contributions. Ça m’inquiète, parce Python est peut-être très populaire en ce moment mais une fois que les conséquences se feront sentir, les opportunistes partiront aussi vite qu’ils étaient arrivés. »

Pour la plupart des développeurs, il n’y a guère que 5 ans peut-être que l’open source est devenu populaire. La large communauté des concepteurs de logiciel débat rarement de la pérennité à long terme de l’open source, et n’a parfois même pas conscience du problème. Avec l’explosion du nombre de nouveaux développeurs qui utilisent du code partagé sans contribuer en retour, nous construisons des palaces sur une infrastructure en ruines.

Nadia Eghbal a déjà évoqué plusieurs fois les liens entre l’argent et l’open source (si vous avez manqué des épisodes). Elle y revient dans ce chapitre, en insistant sur les questions fondamentales que pose l’argent aux communautés open source ainsi qu’à leurs membres.

Question de nature quasi-philosophique : l’open source peut-il perdre son âme à cause de l’argent ? Question de gouvernance : qui va décider de l’utilisation des fonds ? Et pour finir question éthique et politique : jusqu’à où peut-on, doit-on accepter les requêtes des financeurs ?

La relation compliquée de l’open source avec l’argent

Traduction Framalang : goudron, Penguin, serici, goofy, Rozmador, xi, Lumibd, teromene, xi, Diane, et 3 anonymes

L’argent est un sujet tabou dans les projets open source, et ce depuis les premiers jours du mouvement du logiciel libre qui émergea en réponse directe aux pratiques commerciales des logiciels propriétaires. Dans le contexte du mouvement du logiciel libre, l’aversion pour l’argent est tout à fait compréhensible. L’argent est ce qui permettait de commercialiser les logiciels dans les années 1980 et il a fallu des décennies pour revenir sur cet état d’esprit et promouvoir les avantages liés à l’élaboration de logiciels qui soient libres d’utilisation, de distribution et de modification. Même si de nos jours, nous prenons les logiciels libres pour acquis, dans les années 1980, c’était une véritable contre-culture, un état d’esprit révolutionnaire.

Au sein même des communautés open source, il existe une croyance répandue selon laquelle l’argent est de nature à corrompre l’open source. Et en effet, le nombre de projets nés d’un « travail-passion » est assez incroyable. Aujourd’hui, le développement de logiciel est considéré comme un domaine lucratif, dont les écoles de programmation appâtent leurs futurs étudiants avec des promesses de premiers salaires en dollars à six chiffres. Par contraste, il y a quelque chose de pur et d’admirable dans le fait de créer un logiciel simplement pour le plaisir.

D’un point de vue plus pratique, les projets open source se créent traditionnellement autour d’un besoin réel et identifiable. Quelqu’un estime qu’un projet pourrait être mieux fait, décide de le forker, effectue des améliorations, puis les diffuse pour qu’on en fasse usage. Le pragmatisme est au cœur de la culture open source, comme le prouve sa scission stratégique avec le mouvement du logiciel libre à la fin des années 1990. Certains contributeurs open source craignent, peut-être avec raison, que l’argent n’introduise un développement « artificiel » du système, avec des développeurs qui lancent de nouveaux projets simplement pour acquérir des financements, plutôt que pour répondre à un besoin réel.

David Heinemeier Hansson (aussi connu sous le pseudo de DHH), qui a créé le framework populaire Ruby on Rails, mettait en garde en 2013 contre les mélanges entre open source et argent :

Si l’open source est une incroyable force pour la qualité et pour la communauté, c’est précisément parce qu’elle n’a pas été définie en termes de marché. Dans le cadre du marché, la plupart des projets open source n’auraient jamais eu leur chance.

Prenez Ruby on Rails. […] C’est une réalisation colossale pour l’humanité ! Des milliers de gens, collaborant pendant une décennie entière pour produire une structure et un écosystème incroyablement aboutis, disponibles pour tous gratuitement. Prenez une seconde pour méditer sur l’ampleur de cette réussite. Pas seulement pour Rails, évidemment, mais pour de nombreux autres projets open source, encore plus grands, avec une filiation plus longue et encore plus de succès.

C’est en considérant ce fantastique succès, dû aux règles de vie d’une communauté, que nous devrions être extraordinairement prudents avant de laisser les lois du marché corrompre l’écosystème.

Structurellement, le meilleur atout de l’open source : son penchant pour la démocratie, est aussi sa faiblesse. Beaucoup de projets open source ne sont rien de plus qu’un dépôt numérique public où est stocké du code auquel un groupe de gens contribue régulièrement : l’équivalent d’une association officieuse sur un campus universitaire. Il n’y a pas de structure légale et il n’y a pas de propriétaire ou de chef clairement défini. Les  « mainteneurs » ou les contributeurs principaux émergent souvent de facto, en fonction de qui a créé le projet, ou de qui y a investi beaucoup de temps ou d’efforts. Cependant, même dans ces cas-là, dans certains projets on répugne à introduire une hiérarchie favorisant clairement un contributeur par rapport à un autre.

En avril 2008, Jeff Atwood, un développeur .NET bien connu et dont nous avons déjà parlé, a annoncé qu’il donnait 5 000 $ au projet open source : ScrewTurn Wiki. ScrewTurn Wiki est un projet de wiki développé par Dario Solara, un autre développeur .NET, et maintenu par des volontaires. Atwood a dit à Dario que le don était « sans condition » : Solara pouvait utiliser l’argent de la manière qu’il jugerait la plus utile au projet.
Plusieurs mois plus tard, Atwood demanda à Solara comment il avait décidé de dépenser l’argent. Solara lui répondit que l’argent de la donation était « encore intact. Ce n’est pas facile de l’utiliser… Que suggères-tu ? » Atwood a écrit que cette réponse l’avait « terriblement déçu ».

La nature décentralisée du monde open source en a fait ce qu’il est : des logiciels produits de façon participative, que n’importe qui peut élaborer, partager, et améliorer. Mais quand vient le moment de discuter des besoins organisationnels, ou de la viabilité, il peut être difficile de prendre des décisions faisant autorité.

Ces transitions vers une viabilité à long terme peuvent êtres interminables et douloureuses. Un des exemples les plus connus est le noyau Linux, un projet open source utilisé dans de nombreux systèmes d’exploitation à travers le monde, parmi lesquels Android et Chrome OS. Il a été créé en 1991 par Linus Torvalds, un étudiant en informatique .
Au fur et à mesure que le noyau Linux gagnait en popularité, Linus rechignait à discuter de l’organisation du développement du projet, préférant tout gérer tout seul.  L’inquiétude et aussi la colère à l’égard de Torvalds grandirent chez les développeurs du projet, déclenchant de « vraies grosses disputes » selon Torvalds. Le conflit a atteint son apogée en 2002, on évoqua même un possible schisme.

Torvalds attribua ces conflits internes à un manque d’organisation, plutôt qu’à un quelconque problème technique :

Nous avons eu de vraies grosses disputes aux alentours de 2002, quand j’appliquais des correctifs à droite à gauche, et que les choses ne fonctionnaient vraiment pas. C’était très douloureux pour tout le monde, et également beaucoup pour moi. Personne n’aime vraiment les critiques, et il y avait beaucoup de critiques virulentes, et comme ce n’était pas un problème strictement technique, on ne pouvait pas juste montrer un correctif et dire :  « Hé, regardez, ce patch améliore les performances de 15% » ou quoique ce soit de ce genre. Il n’y avait pas de solution technique. La solution a été d’utiliser de meilleurs outils, et d’avoir une organisation du travail qui nous permette de mieux distribuer les tâches.

La Fondation Linux a été créée en 2007 pour aider à protéger et à maintenir Linux et ses projets associés. Torvalds ne pilote pas la Fondation Linux lui-même, il a préféré recevoir un salaire régulier en tant que « Compagnon Linux », et travailler sur ses projets en tant qu’ingénieur.

Malgré le fait que le logiciel open source soit admirablement ancré dans une culture du volontariat et de la collaboration relativement peu touchée par des motivations extérieures, la réalité est que notre économie et notre société, depuis les sociétés multimillionnaires jusqu’aux sites web gouvernementaux, dépendent de l’open source.

Dans l’ensemble, c’est probablement une évolution positive pour la société. Cela signifie que les logiciels ne sont plus limités à un développement privé et propriétaire, comme cela a été le cas pendant des dizaines d’années. Le fait que le gouvernement des États-Unis, ou un réseau social possédant des milliards d’utilisateurs, intègrent des logiciels construits par une communauté, annonce un futur optimiste pour la démocratie.

De plus, de nombreux projets fonctionnent très bien de manière communautaire lorsqu’ils sont d’une des deux tailles extrêmes possibles, c’est-à-dire soit des petits projets qui ne demandent pas de maintenance significative (comme dans l’exemple de Arash Payan et Appirater), soit de très gros projets qui reçoivent un soutien important de la part d’entreprises (comme Linux).

Cependant, beaucoup de projets sont coincés quelque part entre les deux : assez grands pour avoir besoin d’une maintenance significative, mais pas d’une taille suffisante pour que des entreprises déclarent leur offrir un soutien. Ces projets sont ceux dont l’histoire passe inaperçue, ceux dont on ne parle pas. Des deux côtés, on dit aux développeurs de ces projets « moyens » qu’ils sont le problème : du côté des « petits projets », on pense qu’ils devraient simplement mieux s’organiser et du côté des « gros projets », on pense que si leur projet était « assez bon », il aurait déjà reçu l’attention des soutiens institutionnels.

Il existe aussi des intérêts politiques autour de la question du soutien financier qui rendent encore plus difficile la prospection d’une source de financement fiable. On peut imaginer qu’une entreprise seule ne souhaite pas sponsoriser le développement d’un travail qui pourrait également bénéficier à son concurrent, qui lui n’aurait rien payé. Un mécène privé peut exiger des privilèges spécifiques qui menacent la neutralité d’un projet. Par exemple, dans les projets en lien avec la sécurité, le fait d’exiger d’être le seul à qui sont révélées les potentielles failles (c’est-à-dire payer pour être le seul à connaître les failles de sécurité plutôt que de les rendre publiques) est un type de requête controversé. Des gouvernements peuvent également avoir des raisons politiques pour financer le développement d’un projet en particulier, ou pour demander des faveurs spéciales comme une « backdoor » (une porte dérobée, c’est-à-dire un accès secret qui permet d’outrepasser les authentifications de sécurité), même si le projet est utilisé dans le monde entier.

Les récents démêlés légaux entre le FBI et Apple sont un bon révélateur des tensions qui existent entre technologie et gouvernement, au-delà même des projets open source.
Le FBI a, de manière répétée, et à l’aide d’assignations en justice, demandé l’aide d’Apple pour déverrouiller des téléphones afin d’aider à résoudre des enquêtes criminelles. Apple a toujours refusé ces requêtes. En février 2016, le FBI a demandé l’aide d’Apple pour déverrouiller le téléphone d’un des tireurs d’une attaque terroriste récente à San Bernardino, en Californie. Apple a également refusé de les aider, et a publié une lettre sur son site, déclarant :

Tout en croyant que les intentions du FBI sont bonnes, nous pensons qu’il serait mauvais pour le gouvernement de nous forcer à ajouter une « backdoor » dans nos produits. Et finalement, nous avons peur que cette demande mette en danger les libertés que notre gouvernement est censé protéger.

En mars 2016, le FBI a trouvé une tierce partie pour l’aider à déverrouiller l’iPhone et a laissé tomber l’affaire.

Une des plus grandes forces de l’open source est que le code est considéré comme un bien public, et beaucoup de projets prennent la gestion de ces projets au sérieux.  Il est important à titre personnel, pour beaucoup de développeurs de projets, que personne ne puisse prendre seul le contrôle d’une chose que le public utilise et dont il bénéficie. Toutefois, cet engagement à rester neutre a un prix, puisque beaucoup de ressources disponibles pour les développeurs de nos jours (comme les capitaux-risques ou les donations d’entreprises) attendent en contrepartie d’influer sur le projet ou des retours sur investissement.

Le logiciel open source est créé et utilisé de nos jours à une vitesse jamais vue auparavant. Beaucoup de projets open source sont en train d’expérimenter la difficile transition d’une création désintéressée à une infrastructure publique essentielle.
Ces dépendances toujours plus nombreuses signifient que nous avons pour responsabilité partagée de garantir à ces projets le soutien dont ils ont besoin.