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

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

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

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

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

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

Au sein d’une entreprise

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

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

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

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

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

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

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

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

Via une startup

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

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

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

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

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

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

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

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

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

Par des personnes ou un groupe de personnes

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

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

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

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

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

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

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

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

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

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

Dans ce nouveau chapitre de l’ouvrage de Nadia Eghbal Des routes et des ponts que le groupe Framalang vous traduit semaine après semaine (si vous avez raté les épisodes précédents), l’autrice⁽¹⁾ établit cette fois-ci une comparaison éclairante entre l’infrastructure physique dont nous dépendons sans toujours en avoir conscience et l’infrastructure numérique dont la conception et le processus sont bien différents.

Qu’est-ce qu’une infrastructure numérique, et comment est-elle construite ?

Traduction Framalang : Diane, Penguin, Asta, teromene, Julien / Sphinx, Luc, salade, AFS, xi, goofy

Dans un chapitre précédent de ce rapport, nous avons comparé la création d’un logiciel à la construction d’un bâtiment. Ces logiciels publiquement disponibles contribuent à former notre infrastructure numérique. Pour comprendre ce concept, regardons comment les infrastructures physiques fonctionnent.

Tout le monde dépend d’un certain nombre d’infrastructures physiques qui facilitent notre vie quotidienne. Allumer les lumières, aller au travail, faire la vaisselle : nous ne pensons pas souvent à l’endroit d’où viennent notre eau ou notre électricité, mais heureusement que nous pouvons compter sur les infrastructures physiques. Les partenaires publics et privés travaillent de concert pour construire et maintenir nos infrastructures de transport, d’adduction des eaux propres et usées, nos réseaux d’électricité et de communication.

De même, même si nous ne pensons pas souvent aux applications et aux logiciels que nous utilisons quotidiennement, tous utilisent du code libre et public pour fonctionner. Ensemble, dans une société où le numérique occupe une place croissante, ces projets open source forment notre infrastructure numérique. Toutefois, il existe plusieurs différences majeures entre les infrastructures physiques et numériques, qui affectent la manière dont ces dernières sont construites et maintenues. Il existe en particulier des différences de coût, de maintenance, et de gouvernance.

Les infrastructures numériques sont plus rapides et moins chères à construire.

C’est connu, construire des infrastructures matérielles coûte très cher. Les projets sont physiquement de grande envergure et peuvent prendre des mois ou des années à réaliser.

Le gouvernement fédéral des États-Unis a dépensé 96 milliards de dollars en projets d’infrastructure en 2014 et les gouvernements des différents états ont dépensé au total 320 milliards de dollars cette même année. Un peu moins de la moitié de ces dépenses (43 pour cent) a été affectée à de nouvelles constructions ; le reste a été dépensé dans des opérations de maintenance de l’infrastructure existante.

Proposer puis financer des projets de nouvelles infrastructures physiques peut être un processus politique très long. Le financement des infrastructures de transport a été un sujet délicat aux États-Unis d’Amérique au cours de la dernière décennie lorsque le gouvernement fédéral a été confronté à un manque de 16 milliards de dollars pour les financer.

Le Congrès a récemment voté la première loi pluriannuelle de financement des transports depuis 10 ans, affectant 305 milliards de dollars aux autoroutes et autres voies rapides après des années d’oppositions politiques empêchant la budgétisation des infrastructures au-delà de deux années.

Même après qu’un nouveau projet d’infrastructure a été validé et a reçu les fonds nécessaires, il faut souvent des années pour le terminer, à cause des incertitudes et des obstacles imprévus auxquels il faut faire face.

Dans le cas du projet Artère Centrale/Tunnel à Boston, dans le Massachusetts, connu aussi sous le nom de Big Dig, neuf ans se sont écoulés entre la planification et le début des travaux. Son coût prévu était de 2,8 milliards de dollars, et il devait être achevé en 1998. Finalement, le projet a coûté 14,6 milliards de dollars et n’a pas été terminé avant 2007, ce qui en fait le projet d’autoroute le plus cher des États-Unis.

En revanche, les infrastructures numériques ne souffrent pas des coûts associés à la construction des infrastructures physiques comme le zonage ou l’achat de matériels. Il est donc plus facile pour tout le monde de proposer une nouvelle idée et de l’appliquer en un temps très court. MySQL, le second système de gestion de base de données le plus utilisé dans le monde et partie intégrante d’une collection d’outils indispensables qui aidèrent à lancer le premier boum technologique, fut lancé par ses créateurs, Michael Widenius & David Axmark, en mai 1995. Ils mirent moins de deux années à le développer.

Il a fallu à Ruby, un langage de programmation, moins de trois ans entre sa conception initiale en février 1993 et sa publication en décembre 1995. Son auteur, l’informaticien Yukihiro Matsumoto, a décidé de créer le langage après une discussion avec ses collègues.

Les infrastructures numériques se renouvellent fréquemment

Comme l’infrastructure numérique est peu coûteuse à mettre en place, les barrières à l’entrée sont plus basses et les outils de développement changent plus fréquemment.

L’infrastructure physique est construite pour durer, c’est pourquoi ces projets mettent si longtemps à être planifiés, financés et construits. Le métro de Londres, le système de transport en commun rapide de la ville, fut construit en 1863 ; les tunnels creusés à l’époque sont encore utilisés aujourd’hui.

Le pont de Brooklyn, qui relie les arrondissements de Brooklyn et de Manhattan à New York City, fut achevé en 1883 et n’a pas subi de rénovations majeures avant 2010, plus de cent ans plus tard. L’infrastructure numérique nécessite non seulement une maintenance et un entretien fréquents pour être compatible avec d’autres logiciels, mais son utilisation et son adoption changent également fréquemment. Un pont construit au milieu de New York City aura un usage garanti et logique, en proportion de la hausse ou la diminution de la population. Mais un langage de programmation ou un framework peut être extrêmement populaire durant plusieurs années, puis tomber en désuétude lorsque apparaît quelque chose de plus rapide, plus efficace, ou simplement plus à la mode.

Par exemple, le graphique ci-dessous montre l’activité des développeurs de code source selon plusieurs langages différents. Le langage C, l’un des langages les plus fondamentaux et les plus utilisés, a vu sa part de marché diminuer alors que de nouveaux langages apparaissaient. Python et JavaScript, deux langages très populaires en ce moment, ont vu leur utilisation augmenter régulièrement avec le temps. Go, développé en 2007, a connu plus d’activité dans les dernières années.

Tim Hwang, dirigeant du Bay Area Infrastructure Observatory, qui organise des visites de groupe sur des sites d’infrastructures physiques, faisait remarquer la différence dans une interview de 2015 donnée au California Sunday Magazine :

« Beaucoup de membres de notre groupe travaillent dans la technologie, que ce soit sur le web ou sur des logiciels. En conséquence, ils travaillent sur des choses qui ne durent pas longtemps. Leur approche c’est ‘On a juste bidouillé ça, et on l’a mis en ligne’ ou : ‘On l’a simplement publié, on peut travailler sur les bogues plus tard’. Beaucoup d’infrastructures sont construites pour durer 100 ans. On ne peut pas se permettre d’avoir des bogues. Si on en a, le bâtiment s’écroule. On ne peut pas l’itérer. C’est une façon de concevoir qui échappe à l’expérience quotidienne de nos membres. »

Cependant, comme l’infrastructure numérique change très fréquemment, les projets plus anciens ont plus de mal à trouver des contributeurs, parce que beaucoup de développeurs préfèrent travailler sur des projets plus récents et plus excitants. Ce phénomène est parfois référencé comme le « syndrome de la pie » chez les développeurs, ces derniers étant attirés par les choses « nouvelles et brillantes », et non par les technologies qui fonctionnent le mieux pour eux et pour leurs utilisateurs.

Les infrastructures numériques n’ont pas besoin d’autorité organisatrice pour déterminer ce qui doit être construit ou utilisé

En définitive, la différence la plus flagrante entre une infrastructure physique et une infrastructure numérique, et c’est aussi un des défis majeurs pour sa durabilité, c’est qu’il n’existe aucune instance décisionnelle pour déterminer ce qui doit être créé et utilisé dans l’infrastructure numérique. Les transports, les réseaux d’adduction des eaux propres et usées sont généralement gérés et possédés par des collectivités, qu’elles soient fédérales, régionales ou locales. Les réseaux électriques et de communication sont plutôt gérés par des entreprises privées. Dans les deux cas, les infrastructures sont créées avec une participation croisée des acteurs publics et privés, que ce soit par le budget fédéral, par les entreprises privées ou les contributions payées par les usagers.

Dans un État stable et développé, nous nous demandons rarement comment une route est construite ou un bâtiment électrifié. Même pour des projets financés ou propriétés du privé, le gouvernement fédéral a un intérêt direct à ce que les infrastructures physiques soient construites et maintenues.

De leur côté, les projets d’infrastructures numériques sont conçus et construits en partant du bas. Cela ressemble à un groupe de citoyens qui se rassemblent et décident de construire un pont ou de créer leur propre système de recyclage des eaux usées. Il n’y a pas d’organe officiel de contrôle auquel il faut demander l’autorisation pour créer une nouvelle infrastructure numérique.

Internet lui-même possède deux organes de contrôle qui aident à définir des standards : l’IETF (Internet Engineering Task Force) et le W3C (World Wide Web Consortium). L’IETF aide à développer et définit des standards recommandés sur la façon dont les informations sont transmises sur Internet. Par exemple, ils sont la raison pour laquelle les URL commencent par “HTTP”. Ils sont aussi la raison pour laquelle nous avons des adresses IP – des identifiants uniques assignés à votre ordinateur lorsqu’il se connecte à un réseau. À l’origine, en 1986, il s’agissait d’un groupe de travail au sein du gouvernement des USA mais l’IETF est devenue une organisation internationale indépendante en 1993.

L’IETF elle-même fonctionne grâce à des bénévoles et il n’y a pas d’exigences pour adhérer : n’importe qui peut joindre l’organisation en se désignant comme membre. Le W3C (World Wide Web Consortium) aide à créer des standards pour le World Wide Web. Ce consortium a été fondé en 1994 par Tim Berners-Lee. Le W3C a tendance à se concentrer exclusivement sur les pages web et les documents (il est, par exemple, à l’origine de l’utilisation du HTML pour le formatage basique des pages web). Il maintient les standards autour du langage de balisage HTML et du langage de formatage de feuilles de style CSS, deux des composants de base de n’importe quelle page web. L’adhésion au W3C, légèrement plus formalisée, nécessite une inscription payante. Ses membres vont des entreprises aux étudiants en passant par des particuliers.

L’IETF et le W3C aident à gérer les standards utilisés par les pièces les plus fondamentales d’Internet, mais la couche du dessus – les choix concernant le langage utilisé pour créer le logiciel, quels frameworks utiliser pour les créer, ainsi que les bibliothèques à utiliser – sont entièrement auto-gérés dans le domaine public (bien entendu, de nombreux projets de logiciels propriétaires, particulièrement ceux qui sont régis par de très nombreuses normes, tels que l’aéronautique ou la santé peuvent avoir des exigences concernant les outils utilisés. Ils peuvent même développer des outils propriétaires pour leur propre utilisation).

Avec les infrastructures physiques, si le gouvernement construit un nouveau pont entre San Francisco et Oakland, ce pont sera certainement utilisé. De la même façon, lorsque le W3C décide d’un nouveau standard, tel qu’une nouvelle version de HTML, il est formellement publié et annoncé. Par exemple, en 2014, le W3C a annoncé HTML 5, la première révision majeure de HTML depuis 1997, qui a été développé pendant sept ans.

En revanche, lorsqu’un informaticien souhaite créer un nouveau langage de programmation, il ou elle est libre de le publier et ce langage peut ou peut ne pas être adopté. La barre d’adoption est encore plus basse pour les frameworks et bibliothèques : parce qu’ils sont plus faciles à créer, et plus facile pour un utilisateur à apprendre et implémenter, ces outils sont itérés plus fréquemment.

Mais le plus important c’est que personne ne force ni même n’encourage fortement quiconque à utiliser ces projets. Certains projets restent plus théoriques que pratiques, d’autres sont totalement ignorés. Il est difficile de prédire ce qui sera véritablement utilisé avant que les gens ne commencent à l’utiliser.

Les développeurs aiment se servir de l’utilité comme indicateur de l’adoption ou non d’un projet. Les nouveaux projets doivent améliorer un projet existant, ou résoudre un problème chronique pour être considérés comme utiles et dignes d’être adoptés. Si vous demandez aux développeurs pourquoi leur projet est devenu si populaire, beaucoup hausseront les épaules et répondront : « C’était la meilleure chose disponible ». Contrairement aux startups technologiques, les nouveaux projets d’infrastructure numérique reposent sur les effets de réseau pour être adoptés par le plus grand nombre.

L’existence d’un groupe noyau de développeurs motivés par le projet, ou d’une entreprise de logiciels qui l’utilise, contribue à la diffusion du projet. Un nom facilement mémorisable, une bonne promotion, ou un beau site Internet peuvent ajouter au facteur « nouveauté » du projet. La réputation d’un développeur dans sa communauté est aussi un facteur déterminant dans la diffusion d’un projet.

Mais en fin de compte, une nouvelle infrastructure numérique peut venir d’à peu près n’importe où, ce qui veut dire que chaque projet est géré et maintenu d’une façon qui lui est propre.

(1) pourquoi « autrice » ? Il semble que ce mot soit légitime au regard de l’histoire de la langue. Voyez aussi une étude plus complète.

Voici un nouveau chapitre de l’ouvrage de Nadia Eghbal Des routes et des ponts que le groupe Framalang vous traduit semaine après semaine (si vous avez raté les épisodes précédents). Elle brosse un rapide historique qui permet de distinguer Libre et open source puis établit une liste d’avantages du code dont les sources sont ouvertes et librement modifiables.

Une rapide histoire des logiciels publiquement disponibles et de leurs créateurs

Traduction Framalang : goofy, Julien/Sphinx, jums, xi, woof, Asta, Edgar Lori, jbm, Mika, penguin

Bien que nous ayons utilisé l’expression « free software » pour désigner des logiciels qui ne coûtaient rien à leurs utilisateurs, il faudrait plutôt employer l’expression « logiciel libre ». Cette expression aux riches connotations fait référence en particulier aux propriétés des licences avec lesquelles les logiciels sont publiés. Les partisans du logiciel libre soulignent le fait que « free » doit être compris sous l’angle de la liberté politique et non sous celui de la gratuité. Parfois, c’est le terme espagnol « libre » qui est utilisé pour marquer cette distinction (à la différence de « gratis » qui signifie gratuit).

Pendant les années 1970, lorsque les ordinateurs n’en étaient qu’à leurs balbutiements, les développeurs devaient construire leurs propres ordinateurs et écrire eux-mêmes des logiciels adaptés. Les logiciels n’étaient pas encore standardisés et n’étaient pas considérés comme des produits rentables.

En 1981, IBM a présenté le « IBM PC » pour « Personal Computer » (N.D.T. « ordinateur personnel »), qui a permis au grand public d’accéder au matériel informatique. En quelques années, les ordinateurs construits sur mesure tombèrent en déclin au fur et à mesure que tout le monde adoptait le standard IBM. IBM est ainsi devenu l’ordinateur le plus présent au sein d’un marché fortement fracturé : en 1986, IBM avait conquis plus de la moitié du marché des ordinateurs personnels.

Avec la venue de matériel standardisé est apparue la possibilité de créer des logiciels standardisés. Soudain, tout le monde avait pour objectif de créer un business autour des logiciels. IBM a engagé une société inconnue à l’époque sous le nom de Microsoft pour écrire le système d’exploitation de son nouveau PC. Ce système d’exploitation, MS-DOS, fut publié en 1981. D’autres sociétés lui emboîtèrent le pas, proposant des logiciels sous licences commerciales. Ces licences empêchaient l’utilisateur de copier, modifier ou redistribuer les logiciels.

Il existe encore aujourd’hui de nombreux logiciels propriétaires comme Adobe Photoshop, Microsoft Windows, ou GoToMeeting par exemple. Alors que ces programmes propriétaires peuvent générer du profit pour les entreprises qui créent et distribuent ces produits, leurs restrictions limitent leur portée et leur diffusion. Toute modification apportée au design ou à la conception du programme doit provenir de l’entreprise elle-même. De plus, les logiciels propriétaires sont chers, ils coûtent souvent plusieurs centaines de dollars et n’autorisent l’acheteur dûment identifié à utiliser qu’une seule et unique copie.

Naturellement, certains informaticiens se sont sentis préoccupés par la direction fermée et propriétaire que prenaient les logiciels, estimant que cela nuisait au véritable potentiel du logiciel. Richard Stallman, un programmeur au laboratoire d’intelligence artificielle du MIT, a particulièrement ressenti la nécessité pour le logiciel d’être libre et modifiable.

Au cours des années qui suivirent, comme plusieurs de ses collègues se mettaient à travailler sur des projets de logiciels propriétaires, Stallman a estimé qu’il ne pouvait ignorer la situation plus longtemps. En 1983, il a lancé GNU, un système d’exploitation libre, et ce faisant, a déclenché ce qui est devenu le « mouvement du logiciel libre », qui a galvanisé un groupe de personnes qui croyaient que les logiciels pourraient avoir une plus grande portée et bénéficier à la société si ceux-ci étaient mis à disposition librement. Stallman a fondé plus tard la Free Software Foundation en 1985, afin de soutenir GNU ainsi que d’autres projets de logiciels libres.

La Free Software Foundation définit le logiciel libre comme « un logiciel qui donne à l’utilisateur la liberté de le partager, l’étudier et le modifier ». GNU définit quatre libertés associées à de tels logiciels :

Le mouvement du logiciel libre a été et continue d’être profondément engagé dans la défense d’intérêts sociaux. En 1998, lorsque Netscape libéra le code source de son navigateur populaire, le débat commença à passer de la politique à la technologie.

Certains technologues pensaient que se concentrer sur les bénéfices pratiques des logiciels libres permettrait de diffuser le message associé à un public plus large.

Ils ont par exemple souligné que le logiciel libre était moins cher à créer et qu’il permettait d’obtenir une meilleure qualité car le public pouvait trouver des bogues et contribuer en proposant des correctifs. Ce type de pragmatisme se détachait de l’obligation morale exprimée par Stallman et ses partisans quant à l’obligation de promouvoir le logiciel libre. Ces technologues se sont réunis à Palo Alto pour une séance de discussion stratégique.

Christine Peterson, une spécialiste des nanotechnologies qui était présente suggéra l’expression « open source ».

Peu de temps après, deux personnes qui assistaient aussi à cette rencontre, Bruce Perens et Eric Raymond, créèrent l’Open Source Initiative.

Un logiciel dont le code source est disponible publiquement sera qualifié d’« open source ». C’est un peu comme avoir une voiture et être capable d’ouvrir le capot pour connaître comment elle fonctionne plutôt que d’avoir le moteur verrouillé et inaccessible. Les licences open source incluent toujours des clauses qui permettent au public d’utiliser, de modifier et de redistribuer le code. Sous cet angle, il n’y pas de différence juridique entre les licences libres et les licences open source. En fait, certains font référence à l’open source comme une campagne de publicité pour le logiciel libre.

Cependant, la distinction la plus importante entre ces mouvements reste la culture qu’ils ont fait naître. Le mouvement du logiciel open source s’est écarté des aspects socio-politiques du mouvement du logiciel libre pour se concentrer sur les bénéfices pratiques du développement logiciel et encourager des applications créatives et commerciales plus larges. À ce propos, Stallman a écrit :

« l’open source est une méthodologie de développement ;

le logiciel libre est un mouvement de société. »

Bien que « logiciel libre » et « logiciel open source » soient souvent discutés ensemble, ils sont politiquement distincts, le premier étant plus étroitement lié à l’éthique et le second au pragmatisme (dans la suite de cet ouvrage on utilisera le terme « open source » afin de souligner son rôle essentiel dans l’infrastructure logicielle.) L’open source a ouvert un espace permettant l’émergence de différents styles et façons de développer du logiciel, libérés des complexités éthiques. Une organisation peut rendre son code public, mais n’accepter des changements que de certains contributeurs. Une autre organisation peut exiger que le code soit développé en public et accepter des changements de n’importe qui, de manière à ce que davantage de personnes puissent prendre part au processus. En 1997, Raymond a écrit un essai influent intitulé La cathédrale et le bazar (publié plus tard sous la forme d’un livre, en 1999) qui explore ces divers modes de développement.

Aujourd’hui, l’open source s’est répandue dans le monde du logiciel pour un certain nombre de raisons, liées à la fois à l’efficacité et au coût. C’est aussi comme cela qu’est bâtie une bonne partie de notre infrastructure numérique. Nous avons discuté de la façon dont la disponibilité de ces logiciels a bénéficié à toute la société, mais l’open source a aussi beaucoup apporté à ses créateurs.

L’open source revient moins cher à créer
Avant que les logiciels open source n’existent, les entreprises high-tech considéraient les programmes comme n’importe quel autre produit payant : une équipe d’employés développait le produit en interne puis on le vendait au grand public. Ce qui représentait un modèle économique très clair, mais impliquait aussi des coûts de développement accrus. Les logiciels propriétaires nécessitent une équipe payée à plein temps pour assurer le développement, ce qui inclut des développeurs, des designers, des commerciaux et des juristes. Il est bien moins coûteux de simplement confier le développement à une communauté de développeurs bénévoles qui conçoivent et assurent la maintenance du produit.

L’open source est plus facile à diffuser
On a plus envie d’adopter un logiciel dont l’usage est gratuit et de le modifier, plutôt qu’un logiciel dont la licence coûte des centaines de dollars et qui a été développé dans une boîte noire. Non seulement les développeurs vont vouloir l’utiliser sans frais, mais ils pourraient même inciter leurs amis à l’utiliser eux aussi, ce qui va amplifier sa diffusion.

L’open source est plus ouvert à la personnalisation
Les logiciels open source sont copiables et adaptables aux besoins de chacun, avec différents degrés de permission. Si un développeur veut améliorer un logiciel existant, il ou elle peut copier le projet et le modifier (une pratique appelée « forker » en franglais).

Beaucoup de projets à succès ont commencé comme une modification de logiciels existants, par exemple WordPress (gestionnaire de contenu utilisé par 23% des sites web dans le monde), PostgreSQL (l’une des bases de données parmi les plus populaires et dont l’adoption est croissante dans le monde entier), Ubuntu (un système d’exploitation) et Firefox (un des navigateurs web parmi les plus populaires). Dans le cas de WordPress, le logiciel a été forké depuis un projet existant appelé b2 (aussi connu sous le nom de cafelog). Deux développeurs, Matt Mullenweg et Mike Little, ont décidé qu’ils souhaitaient une meilleure version de b2 et ont donc forké le projet.
Mullenberg a décidé de copier b2, plutôt qu’un autre projet appelé TextPattern, car les licences b2 étaient plus permissives. Son idée d’origine, de 2003, est décrite ci-dessous :

Que faire ? Bon, TextPattern ressemble à tout ce que je rêve d’avoir, mais ça n’a pas l’air d’être sous une licence suffisamment en accord avec mes principes. Heureusement, b2/cafelog est sous GPL [GNU General Public Licence, une licence de logiciel libre], ce qui veut dire que je peux utiliser les lignes de code existantes pour créer un fork/une copie. […]
Ce travail ne sera jamais perdu, car si je disparais de la surface de la Terre dans un an, tout le code que j’aurai écrit sera accessible par tout le monde ; et si quelqu’un d’autre veut continuer le travail, libre à lui.

Si le logiciel était développé dans un environnement fermé et propriétaire, les développeurs n’auraient aucune possibilité de le modifier, à moins de travailler dans l’entreprise propriétaire. S’ils essayaient de réaliser leur propre version qui imite l’original, ils s’exposeraient à des poursuites en lien avec la propriété intellectuelle. Avec les logiciels open source, le développeur peut simplement modifier le logiciel lui-même et le distribuer publiquement, comme l’a fait Mullenweg. Les logiciels open source permettent ainsi une prolifération rapide des idées.

L’open source facilite l’adaptation des employés
Il faut du temps pour étudier une ressource logicielle, qu’il s’agisse d’un nouveau langage de programmation ou d’un nouveau framework. Si toutes les entreprises utilisaient leurs propres outils propriétaires, les développeurs auraient moins envie de changer d’entreprise, parce que leurs compétences techniques ne seraient applicables que sur leur lieu de travail actuel.
Il leur faudrait de nouveau apprendre à utiliser les outils propres à leur nouveau lieu de travail.

Quand les entreprises utilisent la technologie open source, un développeur a un ensemble de compétences réutilisables, ce qui lui donne plus de libertés pour travailler là où il préfère. Par exemple, de nombreuses entreprises utilisent le même langage de programmation Ruby pour leurs logiciels. De plus, si le produit des entreprises lui-même est open source, la production appartient autant au développeur qu’à l’entreprise. Le développeur peut emporter son travail avec lui s’il décide de quitter l’entreprise (alors qu’il pourrait par exemple être au contraire limité par une clause de confidentialité si le le code était propriétaire). Tous ces bénéfices offrent plus de moyens d’actions aux employés par rapport à ce que ces derniers auraient eu avec un logiciel propriétaire. De nos jours, de nombreuses entreprises mettent en avant leur utilisation de logiciels open source comme tactique de recrutement, parce que cette utilisation favorise le développeur.

L’open source est potentiellement plus stable et plus sûre.
Théoriquement, quand un projet de logiciel a de nombreux contributeurs et une communauté florissante, le code devrait être moins vulnérable aux failles de sécurité et aux interruptions de service. En effet, dans ce cas, on devrait avoir plus de personnes révisant le code, cherchant des bugs et résolvant tous les problèmes repérés.
Dans un environnement de logiciel propriétaire au contraire, seule l’équipe en charge du développement du code verra ce dernier. Par exemple, au lieu de 20 personnes pour examiner le code d’Oracle, un projet open source populaire pourrait avoir 2000 volontaires qui recherchent les failles du code (remarquons que cette croyance n’est pas toujours en accord avec la réalité, et a parfois créé le problème inverse : on a pu surestimer le nombre de personnes vérifiant des logiciels open source, alors même qu’en réalité personne n’en prenait la responsabilité. Ceci sera discuté dans une prochaine section).
Le logiciel open source a clairement certains avantages. Comment ces projets s’inscrivent-ils collectivement dans un écosystème plus large ?

Nous poursuivons la lecture du livre Des routes et des ponts de Nadia Eghbal que le groupe Framalang vous traduit au fil des semaines. Après nous avoir expliqué en termes simples de quoi sont constitués les logiciels (n’hésitez pas à reprendre les épisodes précédents, si par exemple vous avez oublié ce qu’est un framework ou une bibliothèque), elle nous explique en quoi l’accès libre et gratuit à ces composants a révolutionné l’industrie du logiciel : son fonctionnement, son financement, mais aussi la formation des professionnels.

Comment la gratuité des logiciels a transformé la société

par Nadia Eghbal

Traduction Framalang : Luc, urlgaga, Penguin, Mika, Asta, Edgar Lori, Julien / Sphinx, flo, xi, Bromind, goofy, salade, lyn. et 3 anonymes.

La première réflexion qui vient à l’esprit est : « Pourquoi ces développeurs ont-ils rendu leur logiciel gratuit ? Pourquoi ne pas le faire payer ? »
Les arguments en faveur du logiciel public reposent sur sa riche histoire politique et sociale. Mais d’abord, regardons la vérité en face : notre société ne serait pas là où elle est aujourd’hui si des développeurs n’avaient pas rendu le logiciel libre et gratuit.

Avec le logiciel libre, la production de logiciel est plus simple et considérablement moins chère

Uber, un service de transport de personne, a annoncé récemment que des développeurs avaient créé un système permettant de réserver une voiture en utilisant Slack (une application de développement collaboratif) et non l’application mobile Uber. Le projet a été bouclé en 48 heures par une équipe de la App Academy, une école de programmation.
Uber a constaté que l’équipe avait été capable d’achever le projet rapidement car elle « avait utilisé des bibliothèques ouvertes telles que rails, geocoder et unicorn pour accélérer le développement tout en travaillant sur une base solide.»
En d’autres termes, la quantité de code que l’équipe a dû écrire par elle-même a été fortement réduite car elle a pu utiliser des bibliothèques libres créées par d’autres.
Ruby Geocoder, par exemple, est une bibliothèque réalisée en 2010 et maintenue par Alex Reisner, un développeur indépendant. Geocoder permet à une application de chercher facilement des noms de rues et des coordonnées géographiques.
Unicorn est un serveur datant de 2009, il est administré par une équipe de sept contributeurs (leurs noms sont visibles sur le site web d’Unicorn) encadrés par Eric Wong, un développeur.
Créer un nouveau logiciel n’a jamais été aussi simple, car il existe de plus en plus de portions de code « prêtes à l’emploi » dont on peut se servir. Pour en revenir à la métaphore de l’entreprise de bâtiment, il n’est plus nécessaire pour construire un immeuble de fabriquer soi-même tout ce dont on a besoin, il est plus simple d’acheter du « préfabriqué » et d’assembler fondation, structure porteuse et murs comme des Legos.
Du coup, il n’est plus nécessaire de savoir comment construire un logiciel à partir de zéro pour être qualifié de développeur. le service des statistiques sur le travail des USA (Bureau of Labor Statistics) estime que l’emploi des développeurs va augmenter de 22% entre 2012 et 2022, soit bien plus rapidement que la moyenne dans les autres professions.

Le logiciel libre est directement responsable de la renaissance actuelle des startups

Les coûts de lancement d’une entreprise ont énormément baissé depuis la première bulle internet de la fin des années 90. Le capital-risqueur et ex-entrepreneur Mark Suster évoquait son expérience dans un billet de blog de 2011 :

Quand j’ai monté ma première entreprise, en 1999, l’infrastructure coûtait 2,5 millions de dollars, simplement pour commencer, et il fallait y ajouter 2,5 millions de dollars de plus pour payer l’équipe chargée de coder, lancer, gérer, démarcher et vendre notre logiciel. […]

 

Nous avons à peine perçu le premier changement d’ampleur dans notre industrie. Il a été porté par l’introduction du logiciel libre et plus précisément par ce que l’on a appelé la pile LAMP. Linux (au lieu de UNIX), Apache (un logiciel de serveur web), MySQL (à la place d’Oracle) et PHP. Il y a bien sûr eu des variantes – nous préférions PostgreSQL à MySQL et beaucoup de gens utilisaient d’autres langages de programmation que PHP.

 

Le libre est devenu un mouvement, un état d’esprit. Soudain, les logiciels d’infrastructure étaient presque gratuits. Nous avons payé 10% du tarif normal pour l’achat des logiciels et le reste de l’argent est allé dans le support. Un tel effondrement de 90% des coûts engendre de l’innovation, croyez-moi.

La disponibilité actuelle des composants logiciels libres et gratuits (associée à des services d’hébergement moins chers comme Amazon Web Services et Heroku) permet à une startup technologique de se lancer sans avoir besoin de millions de dollars. Les entrepreneurs peuvent tout à fait sortir un produit et trouver un marché sans dépenser un seul dollar, la levée de fonds auprès de capital-risqueurs se faisant seulement après avoir montré la viabilité de leur projet.
Alan Schaaf, qui a fondé Imgur, un site populaire de partage d’images faisant partie des 50 sites les plus consultés au monde, a justement déclaré que les sept dollars nécessaires à l’achat du nom de domaine représentaient la seule dépense indispensable au démarrage de son entreprise. Imgur était rentable et avant de lever 40 millions de dollars en 2014 auprès de l’entreprise de capital-risque Andreessen Horowitz, Schaaf n’a eu recours à aucun fond extérieur pendant 5 ans (source).
Les capital-risqueurs ainsi que les autres acteurs de l’investissement ont, à leur tour, commencé à investir des montants moindres, développant ainsi de nouvelles formes de fond d’investissement dont voici trois exemples.

Aujourd’hui, avec 10 millions de dollars, on peut financer cent entreprises contre seulement une ou deux dans les années 90.

Le logiciel libre a simplifié l’apprentissage de la programmation, rendant la technologie accessible à tous, partout dans le monde.

Si aujourd’hui vous voulez apprendre à coder chez vous, vous pouvez commencer par étudier Ruby on Rails. Rails est le nom d’un framework et Ruby est un langage de programmation. N’importe qui disposant d’un accès internet peut installer gratuitement ces outils sur n’importe quel ordinateur. Parce qu’ils sont libres et gratuits, ils sont également très populaires, ce qui signifie qu’il existe énormément d’informations en ligne permettant de bien démarrer, du simple tutoriel au forum d’aide. Cela montre qu’apprendre comment coder est aussi accessible que d’apprendre à lire et écrire l’anglais ou le français.
Pour comparer, l’utilisation de frameworks et de langages non open source impliquaient : de payer pour y avoir accès, d’utiliser un système d’exploitation et des logiciels spécifiques, et d’accepter des contraintes de licence susceptibles d’entraver le dépôt d’un brevet pour un logiciel construit sur la base de ce framework. Aujourd’hui il est difficile de trouver des exemples de frameworks qui ne sont pas publics. L’un des plus célèbres exemples de framework propriétaire est le .NET, développé et sorti en 2002. En 2014, Microsoft a annoncé la sortie d’une version publique de .NET, appelée .NET Core.
Audrey Eschright, une développeuse, a décrit comment les logiciels open source l’ont aidée à apprendre la programmation à la fin des années 90.

Je voulais apprendre à programmer mais je n’avais pas d’argent. Pas la version « étudiante fauchée » : ma famille était pauvre mais également dans une situation chaotique…. Cela peut sembler étrange aujourd’hui, mais à l’époque il y avait en fait deux options pour quelqu’un qui voulait écrire de véritables logiciels : on pouvait utiliser un ordinateur avec Windows et payer pour les coûteux outils de développement de Microsoft, ou on pouvait avoir accès a un système Unix et utiliser [le compilateur] gcc…. Mon but devint donc d’avoir accès à des systèmes Unix pour pouvoir apprendre à programmer et faire des trucs sympas.

Jeff Atwood, un développeur .NET de longue date, a expliqué sa décision d’utiliser Ruby pour un nouveau projet, Discourse, en 2013 :

Quand on habite en Argentine, au Népal ou en Bulgarie par exemple, il est vraiment très difficile de démarrer en programmation avec les outils fournis par Microsoft. Les systèmes d’exploitation, les langages et les outils open source permettent de mettre tout le monde au même niveau, ils constituent le socle sur lequel travaillera, partout dans le monde, la prochaine génération de programmeurs, celle qui nous aidera à changer le monde.

Le nombre de startups a explosé et dans leur sillage sont apparues de nombreuses initiatives pour enseigner la programmation aux gens : aux enfants et aux adolescents, mais aussi aux membres de communautés défavorisées, aux femmes ou aux personnes en reconversion professionnelle. Parmi ces initiatives on retrouve Women Who Code, Django Girls, Black Girls Code, One Month et Dev Bootcamp.
Certaines de ces organisations offrent leurs services gratuitement, tandis que d’autres les font payer. Toutes se reposent sur des logiciels libres et gratuits dans leur enseignement. Par exemple, Django Girls a appris à coder à plus de 2000 femmes dans 49 pays. Bien que l’organisation n’ait pas développé Django elle-même, elle a le droit d’utiliser Django, que les étudiantes téléchargent et utilisent gratuitement dans leur programme d’apprentissage.

Dev Bootcamp apprend à programmer aux personnes qui veulent changer de carrière, et prépare n’importe qui, du professeur d’anglais au vétéran, à devenir développeur professionnel. Le programme coûte entre 12 et 14 000 dollars. Dev Bootcamp enseigne entre autres Ruby, JavaScript, Ruby on Rails et SQL. Les étudiants peuvent télécharger et utiliser tous ces outils gratuitement, et Dev Bootcamp n’a pas besoin de payer pour les utiliser. Dev Bootcamp a été acheté par Kaplan en 2014 pour un prix inconnu.
Si des logiciels aussi importants n’étaient pas gratuits, beaucoup de gens seraient dans l’incapacité de participer à la renaissance technologique actuelle. Il existe encore de nombreux obstacles économiques et sociaux qui empêchent qu’ils soient encore plus nombreux à participer, comme le prix du matériel nécessaire pour avoir un ordinateur portable et une connexion Internet, mais les outils de programmation eux-mêmes ne coûtent rien.

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

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

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

De quoi sont faits les logiciels

par Nadia Eghbal

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

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

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

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

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

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

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

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

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

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

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

Frameworks (environnements de développement)

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

Langages

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

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

Bibliothèques

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

Bases de données

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

Serveurs web et d’applications

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

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

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

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

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

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

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

Voici l’introduction du livre Des routes et des ponts de Nadia Eghbal (si vous avez raté le début…) que le groupe Framalang vous traduit au fil des semaines.

Dans cette partie, après avoir exposé la pression croissante de la demande de maintenance, elle retrace un épisode tout à fait emblématique, celui d’Heartbleed, quand il y a quelques années le monde de l’informatique prenait conscience qu’un protocole sensible et universel de sécurité n’était maintenu que par une poignée de développeurs sous-payés.

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

Introduction

Traduction Framalang : Piup, xi, jums, goofy, Ced, mika, Luc, Laure, Lumibd, goofy, alienspoon, Julien / Sphinx

Tout, dans notre société moderne, des hôpitaux à la bourse en passant par les journaux et les réseaux sociaux, fonctionne grâce à des logiciels. Mais à y regarder de plus près, vous verrez que les fondations de cette infrastructure logicielle menacent de céder sous la demande. Aujourd’hui, presque tous les logiciels sont tributaires de code dit open source : public et gratuit, ce code est créé et maintenu par des communautés de développeurs ou disposant d’autres compétences. Comme les routes ou les ponts que tout le monde peut emprunter à pied ou dans un véhicule, le code open source peut être repris et utilisé par n’importe qui, entreprise ou particulier, pour créer des logiciels. Ce code constitue l’infrastructure numérique de la société d’aujourd’hui, et tout comme l’infrastructure matérielle, elle nécessite une maintenance et un entretien réguliers. Aux États-Unis par exemple, plus de la moitié des dépenses de l’état pour les réseaux routiers et ceux de distribution d’eau est consacrée à leur seule maintenance.

Mais les ressources financières nécessaires pour soutenir cette infrastructure numérique sont bien plus difficiles à obtenir. La maintenance de code open source était relativement abordable à ses débuts, mais de nos jours les financements ne viennent en général que d’entreprises de logiciels, sous forme de mécénat direct ou indirect. Dans la foulée de la révolution de l’ordinateur personnel, au début des années 1980, la plupart des logiciels du commerce étaient propriétaires, et non partagés. Les outils logiciels étaient conçus et utilisés en interne dans chaque entreprise, qui vendait aux clients une licence d’utilisation de ses produits. Beaucoup d’entreprises trouvaient que l’open source était un domaine émergent trop peu fiable pour un usage commercial. Selon elles, les logiciels devaient être vendus, pas donnés gratuitement.

En fait, partager du code s’est révélé plus facile, plus économique et plus efficace que d’écrire du code propriétaire, et de nos jours tout le monde utilise du code open source : les entreprises du Fortune 500, le gouvernement, les grandes entreprises du logiciel, les startups… Cependant, cette demande supplémentaire a augmenté la charge de travail de ceux qui produisent et entretiennent cette infrastructure partagée, mais comme ces communautés sont assez discrètes, le reste du monde a mis longtemps à s’en rendre compte. Parmi nous, beaucoup considèrent qu’ouvrir un logiciel est aussi normal que pousser un bouton pour allumer la lumière, mais nous ne pensons pas au capital humain qui a rendu cela possible.

Face à cette demande sans précédent, si nous ne soutenons pas notre infrastructure numérique les conséquences seront nombreuses. Du côté des risques, il y a les failles de sécurité et les interruptions de service causées par l’impossibilité pour les mainteneurs de fournir une assistance suffisante. Du côté des possibilités, les améliorations de ces outils logiciels sont nécessaires pour accompagner la renaissance actuelle des startups, qui dépendent étroitement de l’infrastructure numérique. De plus, le travail effectué dans l’open source est un atout dans le portfolio des développeurs et facilite leur recrutement, mais ce réservoir de talents est beaucoup moins diversifié que celui de l’industrie informatique dans son ensemble. Une augmentation du nombre de contributeurs serait donc profitable au domaine des technologies de l’information au sens large.

Aucune entreprise ou organisation n’a de raison de s’attaquer seule à ce problème, car le code open source est un bien public. C’est pourquoi nous devons réussir à travailler ensemble pour entretenir notre infrastructure numérique. Il existe par exemple la Core Infrastructure Initiative (CII) de la fondation Linux et le programme Open Source Support de Mozilla, ainsi que des initiatives de nombre d’entreprises de logiciel à différents niveaux.
L’entretien de notre infrastructure numérique est une idée nouvelle pour beaucoup, et les défis que cela pose ne sont pas bien cernés. De plus, l’initiative de cette infrastructure est distribuée entre beaucoup de personnes et d’organisations, ce qui met à mal les modèles classiques de gouvernance. Beaucoup de ces projets qui contribuent à l’infrastructure n’ont même pas de statut juridique. Toute stratégie de maintenance devra donc accepter et exploiter ces aspects décentralisés et communautaires du code open source.

Enfin, pour construire un écosystème sain et durable, il sera crucial d’éduquer les gens à ce problème, de faciliter les contributions financières et humaines des institutions, de multiplier le nombre de contributeurs open source et de définir les bonnes pratiques et stratégies au sein des projets qui participent de cette infrastructure.

En 1998, une équipe d’experts en sécurité se constitua au Royaume-Uni pour élaborer une panoplie d’outils de chiffrement libres destinés à Internet.

Très vite, tout le monde se mit à parler de leur projet, intitulé OpenSSL (les développeurs avaient pris comme base de départ un projet australien existant, SSLeay). Non seulement il était complet et relativement fiable, mais il était libre. Il n’est pas facile d’écrire de la cryptographie et OpenSSL avait résolu un problème épineux pour les développeurs du monde entier : en 2014, deux tiers des serveurs web utilisaient OpenSSL, et les sites pouvaient donc transmettre de façon sécurisée les codes de cartes de crédit et autres informations sensibles via Internet.

Pendant ce temps, le projet était toujours géré de façon informelle par un petit groupe de volontaires. Un conseiller du Département de la Défense des États-Unis, Steve Marquess, avait remarqué qu’un contributeur, Stephen Henson, travaillait à temps plein sur OpenSSL. Par curiosité, Marquess lui demanda ce qu’il gagnait, et apprit avec surprise que le salaire de Henson était cinq fois plus faible que le sien.

Marquess s’était toujours considéré comme un bon programmeur, mais ses talents faisaient pâle figure à côté de ceux de Henson. Comme bien d’autres, Marquess imaginait à tort que quelqu’un d’aussi talentueux que Henson aurait un salaire à sa mesure.

Henson travaillait sur OpenSSL depuis 1998. Marquess avait rejoint le projet plus récemment, au début des années 2000, et avait travaillé avec Henson pendant plusieurs années avant d’apprendre sa situation financière.

Comme il avait travaillé avec le Département de la Défense, Marquess savait à quel point OpenSSL était crucial, non seulement pour leur propre système, mais pour d’autres industries dans le monde, de l’investissement à l’aéronautique en passant par la santé. Jusqu’alors, il avait « toujours supposé (comme le reste du monde) que l’équipe d’OpenSSL était grande, active et bien financée. »
En réalité, OpenSSL ne rapportait même pas assez pour payer un seul salarié.

Marquess décida de s’impliquer dans le projet : il avait contribué au code de temps à autre, mais il se rendit compte qu’il serait plus utile en tant qu’homme d’affaires. Il commença par négocier des petits contrats de conseil par le biais d’une entreprise à but non lucratif existante pour maintenir OpenSSL à flot dans ses années les plus dures. Comme le volume des contrats croissait, il créa une entité légale pour collecter ces revenus, l’OpenSSL Software Foundation (OSF).
Malgré le nombre de personnes et d’entreprises qui utilisaient leur logiciel, l’OSF ne reçut jamais plus de 2 000 dollars de dons par an. Les revenus bruts de l’activité de conseil et des contrats ne dépassèrent jamais un million de dollars, qui furent presque entièrement dépensés en frais d’hébergement et en tests de sécurité (qui peuvent coûter plusieurs centaines de milliers de dollars).

Il y avait juste assez pour payer le salaire d’un développeur, Stephen Henson. Cela signifie que les deux tiers du Web reposaient sur un logiciel de chiffrement maintenu par un seul employé à temps plein.

L’équipe d’OpenSSL continua à travailler de façon relativement anonyme jusqu’en avril 2014, quand un ingénieur de chez Google, Neel Mehta, découvrit une faille de sécurité majeure dans OpenSSL. Deux jours plus tard, un autre ingénieur, de l’entreprise finlandaise Codenomicon, découvrit le même problème.
Tous deux contactèrent immédiatement l’équipe d’OpenSSL.

Ce bug, surnommé Heartbleed, s’était glissé dans une mise à jour de 2011. Il était passé inaperçu pendant des années. Heartbleed pouvait permettre à n’importe quel pirate suffisamment doué de détourner des informations sécurisées en transit vers des serveurs vulnérables, y compris des mots de passe, des identifiants de cartes de crédit et autres données sensibles.

Joseph Steinberg, un éditorialiste spécialisé en cybersécurité, écrivit : « on pourrait dire que Heartbleed est la pire vulnérabilité découverte… depuis qu’Internet a commencé à être utilisé pour des opérations commerciales. »

Grâce à un large écho médiatique, le grand public entendit parler de ce bug informatique, au moins de nom. Des plateformes majeures, comme Instagram, Gmail ou Netflix, furent affectées par Heartbleed.

Certains journalistes attirèrent l’attention sur l’OpenSSL lui-même, et la manière dont l’équipe de développement avait lutté pendant des années pour pouvoir continuer ses travaux. Les experts en sécurité connaissaient les limites d’OpenSSL, mais l’équipe ne parvenait pas à capter les ressources ou l’attention adéquates pour résoudre les problèmes.

Marquess écrivit à propos de Heartbleed « ce qui est mystérieux, ce n’est pas qu’une poignée de bénévoles surchargés de travail ait raté ce bug, mais plutôt qu’il n’y a pas eu davantage de bugs de ce genre. »

Les gens envoyèrent des dons pour soutenir la fondation, et Marquess les remercia pour leur enthousiasme, mais le premier cycle de dons ne totalisa qu’environ 9 000 dollars : largement en deçà du nécessaire pour soutenir une équipe dédiée.

Marquess adressa alors à Internet un vibrant plaidoyer pour une levée de fonds :

Les gars qui travaillent sur OpenSSL ne sont là ni pour l’argent, ni pour la gloire (qui, en dehors des cercles geeks, a entendu parler d’eux ou d’OpenSSL avant la sortie de heartbleed[sic] dans les médias ?). Ils travaillent pour la fierté de créer et parce qu’ils se sentent responsables de à quoi ils croient.

Il faut des nerfs d’acier pour travailler pendant des années sur des centaines de milliers de lignes d’un code très complexe, où tout le monde peut voir chacune des lignes que vous manipulez, en sachant que ce code est utilisé par des banques, des pare-feux, des systèmes d’armement, des sites web, des smartphones, l’industrie, le gouvernement, partout. Et tout cela en acceptant de ne pas être apprécié à votre juste valeur et d’être ignoré jusqu’à ce que quelque chose tourne mal.

Il devrait y avoir au moins une demi-douzaine de membres à temps plein dans l’équipe au lieu d’un seul pour se consacrer au soin et à la maintenance que demande OpenSSL, sans devoir gérer en même temps l’aspect commercial.

Si vous êtes un décideur dans une multinationale ou un gouvernement, pensez-y. Je vous en prie. Je me fais vieux, je fatigue et j’aimerais prendre ma retraite un jour.

Après Heartbleed, OpenSSL obtint enfin le financement nécessaire – en tous cas jusqu’à présent. L’équipe dispose à l’heure actuelle d’assez d’argent pour payer quatre employés à temps plein pendant trois ans. Mais au bout d’un an et demi de ce financement, Marquess n’est pas certain de l’avenir.

Il a admis que Heartbleed a été une bénédiction pour eux, mais qu’il est « légèrement ironique » que ce soit une faille de cette ampleur qui ait donné plus de visibilité à leur cause. Et quand l’argent sera épuisé et que le monde sera passé à autre chose, Marquess craint qu’ils ne se retrouvent dans la même situation qu’avant Heartbleed, voire pire : la clientèle que Marquess a mis des années à se constituer a disparu, puisque l’équipe travaille maintenant à plein temps sur OpenSSL et n’a plus le temps d’exécuter des contrats.

Marquess lui-même a bientôt l’âge de la retraite. Il est le seul qui accepte de s’occuper des affaires commerciales et du rôle exécutif associés à OpenSSL comme les impôts, la recherche de clients, et la gestion des donateurs. Le reste de son équipe préfère se concentrer sur l’écriture et la maintenance du code. Il ne peut embaucher personne pour le remplacer quand il prendra sa retraite, parce qu’il ne perçoit en ce moment aucun salaire. « Je ne crois pas qu’on puisse tenir comme ça plus d’un an ou deux » a-t-il remarqué.

L’histoire d’OpenSSL n’est pas unique, et par bien des aspects, Marquess trouve que lui et son équipe font partie des mieux lotis. Bien d’autres projets sont toujours en manque de reconnaissance et de financement, alors qu’ils constituent l’infrastructure numérique, infrastructure absolument cruciale puisque tous les logiciels d’aujourd’hui, et par conséquent tous les aspects de notre vie quotidienne, en dépendent.

Relever ses courriels, lire les actualités, vérifier le prix des actions, faire des achats en ligne, aller chez le médecin, appeler le service client – qu’on le réalise ou non, tout ce que nous faisons est rendu possible par des projets comme OpenSSL. Sans eux, la technologie sur laquelle repose la société moderne ne pourrait tout simplement pas fonctionner.

Beaucoup de ces projets sont créés et maintenus par des volontaires et offerts au public gratuitement. Tous ceux qui le veulent, de Facebook au programmeur amateur, peuvent utiliser ce code pour créer leurs propres applications. Et ils le font.

S’il est difficile de croire, comme le dit Marquess, « qu’un groupe hétéroclite d’amateurs puisse faire mieux que de gigantesques sociétés avec leur argent et leurs ressources », voyez plutôt comme c’est lié à la montée en puissance du travail collaboratif pair-à-pair dans le monde.

Des startups jusqu’ici impensables comme Uber ou AirBnB se sont transformées en l’espace de quelques années en poids lourds du monde des affaires et remettent en question des industries phares comme le transport ou l’hôtellerie. Des musiciens se font un nom sur YouTube ou Soundcloud plutôt qu’en passant par les majors. Créateurs et artistes concrétisent leurs idées via des plateformes de financement participatif telles que Kickstarter ou Patreon.

Les autres projets de l’infrastructure sont également issus de la passion et de la créativité de développeurs qui se sont dit : « Je pourrais faire ça mieux », et qui collaborent pour développer et livrer du code au monde entier. La différence, c’est que des millions de personnes ont besoin de ce code dans leur vie quotidienne.

Comme le code n’est pas aussi sexy qu’une vidéo virale sur YouTube ou une campagne Kickstarter, le grand public est très loin de pouvoir l’apprécier à sa juste valeur, si bien que le code qui a révolutionné les technologies de l’information manque très largement du soutien des institutions.

Mais nous ne pourrons ignorer cela plus longtemps.

Ces cinq dernières années, notre dépendance aux logiciels ainsi qu’au code libre et public qui les fait fonctionner s’est accélérée. Les technologies se sont fait une place dans tous les aspects de nos vies, et plus les gens utilisent de logiciels, plus on en crée, et plus cela demande de travail de maintenance.

Toutes les startups qui réussissent ont besoin d’une infrastructure publique pour assurer leur succès, pourtant aucune entreprise n’est assez motivée pour agir seule. Pendant que le monde progresse à toute vitesse vers l’ère moderne des startups, du code et des technologies, l’infrastructure reste à la traîne. Les fissures des fondations ne sont pas encore très visibles, mais elles s’élargissent. Après des années de croissance sans précédent qui nous ont propulsés dans une époque de croissance et de prospérité, nous devons maintenant agir pour nous assurer que le monde que nous avons bâti en si peu de temps ne va pas s’effondrer brutalement sans crier gare.

Pour comprendre comment nous pouvons préserver l’avenir, nous devons d’abord comprendre ce qu’est le logiciel lui-même.

(À suivre…)

La semaine prochaine : comment on fabrique des logiciels…

Les membres du groupe Framalang ont toujours un gros appétit, il faut à leur insatiable faim de traduction de nouveaux aliments. C’est un morceau de choix qu’ils ont décidé de traduire et publier progressivement ici même…

… un livre entier de Nadia Eghbal qui porte sur l’infrastructure cachée ou discrète de la grande soupe numérique où nous grenouillons. Cet ouvrage a été financé par la Fondation Ford et sa source est sous licence CC BY 4.0, ce qui vous permet d’en profiter.

Nous vous proposons aujourd’hui seulement l’avant-propos.

Histoire de susciter votre curiosité voici quelques titres des chapitres que nous vous proposerons semaine après semaine :

• Une brève histoire du code public et libre et de ceux qui l’ont libéré
• Pourquoi les gens continuent-ils à contribuer à ces projets sans être payés ?
• Comment sont gérés les projets d’infrastructure numérique ?
• Les rapports difficiles de l’open source avec l’argent
• …

Des routes et des ponts (1)

Document original (lien direct vers le PDF) Roads and Bridges, The Unseen Labor behind Our Digital Structure
par : Nadia Eghbal

Traduction Framalang : astraia_spica, Mika, peupleLà, roptat, xi, Luc, mika, Lyn., Julien / Sphinx, Lumibd, goofy

Avant-propos

Le problème exposé dans cet ouvrage m’est apparu sur une intuition. Pour avoir travaillé dans des startups puis dans des sociétés de capital-risque, j’ai pu constater que des sommes d’argent considérables affluaient dans les entreprises de logiciel. Par ailleurs, en tant que développeuse de logiciel en amateur, j’étais bien consciente que je n’aurais rien pu produire toute seule. J’utilisais du code gratuit et public (plus connu sous le nom de code open source) dont j’assemblais des éléments afin de répondre à des objectifs personnels ou commerciaux. Et franchement, les personnes impliquées dans ces projets avaient, quel que soit leur rôle, fait le plus gros du travail.

Cette observation m’a tourné dans la tête pendant plusieurs années, tandis que j’assistais à l’explosion à droite et à gauche des bootcamps où étaient diplômés de nouveaux développeurs de logiciel et que je voyais des startups lever plusieurs dizaines de millions de dollars pour vendre des produits qui tournaient sans doute avec plus de code libre que de code propriétaire. Ayant précédemment travaillé dans des associations à but non lucratif, je faisais immédiatement le lien avec les biens publics et les défis qui leur sont associés. Pourtant ce vocabulaire était étrangement absent du langage de mes pairs dans le monde du logiciel.

Après avoir quitté mon travail dans une entreprise de capital-risque l’an dernier, je me suis mis en tête d’étudier ce paradoxe auquel je ne cessais de penser : il existe des logiciels précieux qui ne peuvent pas s’appuyer sur des modèles commerciaux et auxquels manquent le soutien des pouvoirs publics.

C’est plutôt amusant, mais le code open source ne figurait pas sur ma liste initiale. Comme mes collègues, j’avais supposé, à tort, que c’était l’exemple même de ressources logicielles à la disposition du public qui bénéficiaient d’un fort soutien. Lorsque j’ai mentionné l’open source à mes amis et mentors, ils m’ont aimablement dissuadée de poursuivre mes recherches dans ce domaine, puis incitée à plutôt trouver d’autres exemples de domaines qui avaient vraiment besoin de soutien.

Pourtant, je suis tombée sur un certain nombre de projets open source qui mettaient à mal ces préjugés. Il s’est avéré que maintenir les projets dans la durée était un problème connu dans le monde des contributeurs de l’open source. Plus je creusais la question et plus je découvrais des billets de blog, des articles et des forums de discussion qui abordaient la tension et l’épuisement éprouvés par ceux qui maintiennent les projets open source. Tout le monde m’indiquait une autre personne à contacter et sans m’en apercevoir j’ai récolté un nombre incroyable de témoignages à ce sujet.

Je me suis rendu compte que j’avais découvert un problème certes « bien connu » des producteurs (les contributeurs de l’open source) mais dont les consommateurs (les entreprises de logiciels et les autres utilisateurs de code open source) n’avaient apparemment aucune idée. Cette anomalie m’a incitée à me pencher sur le problème.

Par ailleurs, il semble que le milieu de l’open source soit lui-même en train d’évoluer, voire de bifurquer. J’ai eu des conversations très diverses avec des interlocuteurs de différentes générations, tous contributeurs open source. Ils semblaient avoir des philosophies et des valeurs divergentes, au point de donner l’impression de ne pas utiliser le même vocabulaire. J’ai appris que dans les trois à cinq dernières années, la production ainsi que la demande avaient explosé dans le monde de l’open source grâce à l’amélioration des outils pour les développeurs et à celle de l’organisation du travail. Les contributeurs de l’open source d’aujourd’hui sont très différents de ceux d’il y a 10 ans, sans parler de ceux d’il y a 30 ans. Or ces différentes générations ne communiquent pas entre elles, ce qui rend difficile toute conversation productive sur la maintenance pérenne des logiciels.

Au hasard d’une conversation avec Ethan Zuckerman, du MIT Center for Civic Media, j’ai eu l’occasion de partager plus largement mes découvertes.

Bien que ne sachant pas exactement ce qu’il y avait derrière ni si j’employais les bons mots, j’ai décrit à Ethan le problème dont je m’étais rendu compte et il a eu la gentillesse de me mettre en contact avec Jenny Toomey de la Fondation Ford. Jenny m’a suggéré de rassembler les résultats de mes recherches dans un rapport. Au fur et à mesure de son écriture a émergé cet ouvrage sur notre société numérique moderne, et sur l’infrastructure cachée qui la sous-tend.

Le présent ouvrage n’aurait jamais vu le jour si Ethan et Jenny n’avaient pas donné sa chance à une idée tout juste ébauchée qui désormais, grâce au travail d’écriture, s’est transformée en quelque chose de construit. Je les remercie énormément d’avoir fait confiance à leur intuition. Je suis aussi reconnaissante envers Michael Brennan et Lori McGlinchey pour leurs conseils, leur regard, et leur enthousiasme au cours de la relecture. Enfin, et c’est sans doute le plus important, j’ai une dette envers toutes les personnes qui travaillent dans l’open source et qui ont rendu leur histoire publique pour que des gens comme moi puissent la lire — et particulièrement ceux qui ont pris de leur temps malgré un agenda chargé pour me divertir au détour d’une conversation ou d’un courriel. Ce rapport est un concentré de leur sagesse et non de la mienne. Je suis particulièrement reconnaissante pour les conversations que j’ai pu avoir avec Russel Keith-Magee, Eric Holscher, Jan Lehnardt, Audrey Petrov et Mikeal Rogers, ils continuent à m’inspirer par leur patience et leur dévouement à l’égard du travail open source.

Merci d’avoir été aussi attentionnés.

Le groupe Framalang a traduit l’article de Julien, qui a listé tous les moyens de se tirer une balle dans le pied quand on coordonne un projet libre.

Apprenez à les éviter !

Conduite de projets Open Source : 10 erreurs à éviter

Article original : https://julien.danjou.info/blog/2016/foss-projects-management-bad-practice
Auteur : Julien Danjou(CC-BY-SA)
Traduction : lyn., KoS, AlienSpoon, David 5.1, Simon, goofy, Slimane Aguercif, Fred, galadas, terhemis, gégé

Il y a quelques semaines, lors de l’OpenStack Summit (réunion annuelle des contributeurs à OpenStack, NDT), j’ai eu l’occasion de discuter de mon expérience de la conduite de projets Open Source. Je me suis rendu compte qu’après avoir fait partie de plusieurs communautés et beaucoup contribué pendant des années, je pourrais faire profiter les nouveaux venus de conseils et d’avis expérimentés.

Il existe une foule de ressources disponibles expliquant comment conduire un projet Open Source. Mais aujourd’hui, je voudrais aborder ce sujet sous un angle différent, en insistant sur ce qu’il convient de ne pas faire avec les personnes qui y participent. Je tire cette expérience des nombreux projets Open Source auxquels j’ai participé ces dernières années. Je vais décrire, sans ordre particulier, quelques mauvaises pratiques que j’ai constatées, en les illustrant par des exemples concrets.

1. Considérer les contributeurs comme une nuisance

Quand les informaticiens sont au travail, qu’ils soient chargés du développement ou de la maintenance d’un logiciel, il est une chose dont ils n’ont pas besoin : du travail supplémentaire. Pour la plupart d’entre eux, la première réaction à toute contribution externe est : « Zut, du travail en plus ». Et c’est effectivement le cas.

Par conséquent, certains développeurs essayent d’éviter ce travail supplémentaire : ils déclarent ne pas vouloir de contributions, ou font en sorte que les contributeurs se sentent indésirables. Cela peut prendre de nombreuses formes, comme les ignorer ou être désagréable avec eux. Ainsi, les développeurs évitent d’avoir à traiter le surplus de travail qu’on leur met sur le dos.

C’est une des plus grandes erreurs que l’on peut commettre, et une vision fausse de l’Open Source. Si des gens vous apportent du travail supplémentaire, faites tout ce que vous pouvez pour bien les accueillir afin qu’ils continuent à travailler avec vous. Il s’agit peut-être de ceux qui prendront votre relève d’ici peu. Préparez votre future retraite.

Prenons le cas de mon ami Gordon, que j’ai vu démarrer en tant que contributeur sur Ceilometer en 2013. Il examinait très bien le code, si bien qu’il me donnait en fait davantage de travail : non seulement en détectant les anomalies dans mes contributions, mais aussi en me faisant vérifier les siennes. Au lieu de m’en prendre à lui pour qu’il arrête de me faire retravailler mon code et vérifier ses correctifs, j’ai proposé qu’on lui fasse davantage confiance en l’ajoutant officiellement à l’équipe des correcteurs sur un des projets.

Et s’ils ne font pas cette première contribution, ils ne feront pas non plus la seconde. En fait, ils n’en feront aucune ; et ces projets perdraient alors leurs futurs correcteurs.

2. Ne confier aux autres que le sale boulot

Lorsque de nouveaux contributeurs se présentent pour travailler sur un certain projet, leurs motivations peuvent être très diverses. Certains sont des utilisateurs, d’autres veulent simplement voir ce que c’est de contribuer. Ressentir le frisson de la participation, comme un simple exercice ou avec la volonté d’apprendre afin de contribuer en retour à l’écosystème qu’ils utilisent.

En général, les développeurs confient le sale boulot à ces personnes, c’est à dire des tâches sans intérêt, à faible valeur ajoutée, et qui n’auront sans doute aucun impact direct sur le projet.

Pour certains, ce n’est pas grave, pour d’autres, ça l’est. Certains seront vexés de se voir confier du travail sans grand intérêt, alors que d’autres seront heureux de le faire pourvu qu’on leur témoigne de la reconnaissance. Soyez sensible à cela, et félicitez ces personnes. C’est la seule manière de les garder dans le projet.

3. Mépriser les petites contributions

Quand le premier patch d’un nouveau contributeur est une correction d’orthographe, qu’en pensent les développeurs ? Qu’ils s’en fichent, que vous gâchez de leur temps précieux avec votre petite contribution. Et personne ne s’intéresse à la perfection grammaticale d’une documentation, n’est-ce pas ?

C’est faux. Voyez mes premières contributions à home-assistant et Postmodern : j’ai corrigé des fautes d’orthographe dans la documentation.

J’ai contribué au projet Org-mode pendant quelques années. Mon premier patch corrigeait simplement une chaîne de caractères du code. Ensuite, j’ai envoyé 56 patchs, corrigeant des bogues et ajoutant de nouvelles fonctionnalités élégantes, et j’ai aussi codé quelques extensions. À ce jour, je suis toujours seizième dans la liste des plus gros contributeurs d’Org-mode, qui en contient 390. Certainement pas ce qu’on appellerait un petit contributeur, donc. Je suis sûr que la communauté est bien contente de n’avoir pas méprisé ma première correction dans la documentation.

4. Mettre la barre trop haut pour les nouveaux arrivants.

Quand de nouveaux contributeurs arrivent, leurs connaissances du projet, de son contexte, et des technologies sont très variables. L’une des erreurs que les gens font le plus souvent consiste à demander aux nouveaux contributeurs des choses trop compliquées, dont ils ne pourront pas venir à bout. Cela leur fait peur (surtout les timides ou les introvertis) et ils risquent de disparaître, se croyant trop stupides pour aider.

Avant de faire le moindre commentaire, vous ne devriez avoir strictement aucun a priori sur leur niveau. Cela permet d’éviter ce genre de situations. Il faut également mettre beaucoup de délicatesse quand vous estimez les compétences des nouveaux, car certains pourraient se vexer si vous les sous-estimez trop.

Quand son niveau est bien estimé (un petit nombre d’échanges devrait suffire), vous devez former votre contributeur en ne le guidant ni trop ni trop peu, afin qu’il puisse s’épanouir. Il faut du temps et de l’expérience pour y parvenir, et vous allez probablement perdre certains contributeurs avant de bien maîtriser ce processus, mais c’est un chemin que tous ceux qui gèrent des projets doivent suivre.

Façonner ainsi les nouveaux arrivants est au cœur de la gestion de vos contributeurs, et ce quel que soit votre projet. Et je suis quasiment sûr que cela s’applique à tout projet, même en dehors du logiciel libre.

5. Exiger des gens qu’ils fassent des sacrifices sur le plan personnel

C’est un point qui dépend beaucoup du projet et du contexte, mais il est très important. Dans le logiciel libre, où la plupart des gens vont contribuer par bonne volonté et parfois sur leur temps libre, vous ne devez surtout pas exiger d’eux qu’ils fassent des sacrifices personnels importants. Ça ne passera pas.

L’une des pires manières de faire cette erreur est de fixer un rendez-vous à l’autre bout du monde pour discuter du projet. Cela place les contributeurs qui vivent loin dans une situation injuste, car ils ne peuvent pas forcément quitter leur famille pour la semaine, prendre l’avion ou un autre moyen de transport, louer une chambre d’hôtel… Ce n’est pas bon : tout devrait être mis en œuvre pour que les contributeurs se sentent partie prenante du projet et intégrés à la communauté, sans que l’on exige cela de leur part. Entendons-nous bien, cela ne veut pas dire qu’il faut s’interdire toute rencontre ou activité sociale, au contraire. Pensez simplement à n’exclure personne lorsque vous discutez d’un projet.

Il en va de même pour les moyens de communication susceptibles de compliquer la vie des participants : se retrouver sur IRC (il est difficile pour certaines personnes de réserver une heure, surtout lorsqu’il faut tenir compte des différents fuseaux horaires), faire une visioconférence (en particulier quand on n’utilise pas de logiciel libre et gratuit), etc.

En gros, tout ce qui impose de se synchroniser en temps réel avec l’avancement du projet est contraignant pour certains contributeurs.

C’est pourquoi le meilleur moyen de communiquer reste le courriel, mais tous les outils de communication asynchrones (pisteurs de bogues, etc.) feront l’affaire dans la mesure où ils permettent à chacun de travailler à son rythme et à l’heure qui lui convient.

6. Ne pas avoir de code de conduite

À une époque où de plus en plus de communautés s’ouvrent à un public plus large que celui auquel elles étaient habituées (ce qui est fantastique), les codes de conduite semblent être un sujet à la mode, mais aussi délicat.

En réalité, toutes les communautés ont un code de conduite, qu’il soit inscrit noir sur blanc ou suivi inconsciemment par chacun. Sa forme dépend de la taille et de la culture de la communauté.

Cependant, en fonction de la taille de votre communauté et de la façon dont ce code s’applique, vous auriez peut-être intérêt à l’écrire dans un document, comme l’a par exemple fait Debian.

Ce n’est pas parce que vous aurez rédigé un code de conduite que tous les membres de votre communauté vont soudain se transformer en adorables Bisounours le suivant à la lettre, mais il fournit des règles que vous pouvez citer en cas de besoin. Il peut être utile de le transmettre à certains pour leur faire comprendre que leur comportement ne convient pas, et cela peut aider si une exclusion devient nécessaire, même s’il ne sert que rarement à cela, puisqu’en général personne ne veut aller aussi loin.

Je pense qu’on peut très bien se passer d’un tel document sur de petits projets. Mais vous devez garder à l’esprit qu’un code de conduite implicite découlera de votre comportement. La manière dont vos membres les plus influents communiqueront avec les autres installera l’ambiance à travers tout le réseau. Ne sous-estimez pas cela.

Quand nous avons commencé le projet Ceilometer, nous avons suivi le code de conduite du projet OpenStack avant même qu’il ait été écrit, et probablement avons-nous même placé la barre un peu plus haut. En étant agréables, accueillants et ouverts d’esprit, nous avons réussi à obtenir une certaine mixité, avec plus de 25% de femmes dans notre équipe permanente — bien au dessus de la moyenne actuelle d’OpenStack et de la plupart des projets de logiciel libre !

7. Mettre les non-anglophones à l’écart

Il est important d’être conscient que la grande majorité des projets de logiciel libre utilisent l’anglais en tant que langue de communication principale. C’est logique. C’est une langue répandue, et qui semble remplir ce rôle correctement.

Mais une grande partie des codeurs n’ont pas l’anglais pour langue maternelle. Beaucoup ne le parlent pas couramment. Cela signifie que le rythme auquel ils peuvent converser peut-être très lent, ce qui peut en frustrer certains, notamment ceux qui sont nés en terre anglophone.

On peut observer ce phénomène dans les rencontres de codeurs, lors de conférences par exemple. Quand les gens débattent, il peut être très difficile pour certains d’expliquer leurs pensées en anglais et de communiquer à un rythme correct, ce qui ralentit la conversation et la transmission des idées. La pire chose qu’un anglophone puisse faire dans ce cas est de leur couper la parole, ou de les ignorer, pour la seule raison qu’ils ne parlent pas assez vite. Je comprends que cela puisse être frustrant, mais le problème n’est pas la façon de parler des non-anglophones mais les outils de communication utilisés qui ne mettent pas tout le monde au même niveau en privilégiant des conversations orales.

La même chose s’applique, à un moindre degré, aux rencontres sur IRC, qui sont relativement synchrones. Les médias complètement asynchrones ne pâtissent pas de ce défaut, et c’est pourquoi ils faudrait, à mon avis, les privilégier.

8. Pas de vision, aucune délégation des tâches

C’est une autre grosse erreur de gestion si le responsable ne parvient pas à gérer la croissance du projet alors que des gens sont disponibles et prêts à aider.

Évidemment, lorsque le flux des contributeurs commence à grossir, ajoutant de nouvelles fonctionnalités, demandant des retours et des instructions à suivre, certains responsables se retrouvent la tête sous l’eau et ne savent pas comment répondre. Ce qui a pour conséquences de frustrer les contributeurs, qui vont simplement partir.

Il est important d’avoir une vision de votre projet et de la communiquer. Dites clairement à vos contributeurs ce que vous voulez, et ne voulez pas, dans votre projet. Exprimer ces informations de manière claire (et non-agressive !) permet de minimiser les frictions entre vos contributeurs. Ils vont vite savoir s’ils veulent rejoindre ou non votre navire et quoi en attendre. Donc, soyez un bon capitaine.

S’ils choisissent de travailler avec vous et de contribuer, vous devez rapidement commencer à croire en eux et à leur déléguer certaines de vos responsabilités. Cela peut être n’importe quelle tâche que vous faites d’habitude vous-même : vérifier les patchs de certains sous-systèmes, traquer les bogues, écrire la documentation… Laissez les gens s’approprier entièrement une partie du projet car ils se sentiront responsables et ils y mettront autant de soin que vous. Faire le contraire en voulant tout contrôler vous-même est la meilleure façon de vous retrouver seul avec votre logiciel open source.

Aucun projet ne va gagner en taille et en popularité de cette manière.

En 2009, quand Uli Schlachter a envoyé son premier patch à awesome, cela m’a donné plus de travail. J’ai du vérifier son patch, et j’étais déjà bien occupé pour sortir la nouvelle version d’awesome sur mon temps libre en dehors de mon travail ! Le travail d’Uli n’était pas parfait, et j’ai eu à gérer les bogues moi-même. Plus de travail. Alors qu’ai-je fait ? Quelques minutes plus tard, je lui ai répondu en lui envoyant un plan de ce qu’il devait faire et de ce que je pensais de son travail.

En retour, Uli envoya d’autres patchs et améliora le projet. Savez-vous ce que fait Uli aujourd’hui ? Il est responsable du gestionnaire des fenêtres awesome à ma place depuis 2010. J’ai réussi à transmettre ma vision, déléguer, puis à quitter le projet en le laissant dans de bonnes mains !

9. Ignorer certains types de contributions

Les gens contribuent de différentes manières, et pas toujours en codant. Il y a beaucoup de choses autour d’un projet de logiciel libre : la documentation, le tri de bogues, le support, la gestion de l’expérience utilisateur, la communication, les traductions…

Par exemple, il a fallu du temps pour que Debian songe à donner le statut de Développeur Debian à leurs traducteurs. OpenStack prend la même direction en essayant de reconnaître les contributions autres que techniques.

Dès lors que votre projet commence à récompenser certaines personnes et à créer différents statuts dans la communauté, vous devez faire très attention à n’oublier personne, car c’est le meilleur moyen de perdre des contributeurs en chemin.

10. Oublier d’être reconnaissant

Cette liste est le fruit de nombreuses années de bidouillages open source et de contributions à des logiciels libres. L’expérience et le ressenti de chacun sont différents, et les mauvaises pratiques peuvent prendre différentes formes : si vous connaissez ou si vous avez vous-même rencontré d’autres obstacles dans vos contributions à des projets open-source, n’hésitez pas à compléter la liste dans les commentaires. C’est une forme de contribution.