Des routes et des ponts (16, 17, 18 et fin)
Nadia Eghbal
Aujourd'hui menu allégé (après les agapes), avec un bref chapitre de Des routes et des ponts [1] par Nadia Eghbal, ouvrage dont tous les chapitres précédents sont là.
Il s'agit cette fois-ci de dresser la liste des principes qui devraient gouverner le soutien durable aux projets et infrastructures open source.
Vers de meilleures stratégies
Élaborer des stratégies d'assistance efficaces
Même si les gens sont de plus en plus intéressés par les efforts pour soutenir les infrastructures numériques, les initiatives actuelles sont encore récentes, faites pour des cas particuliers ou fournissent seulement un support partiel (comme le partage d'avantages fiscaux par des organisations à but non lucratif avec des groupes extérieurs à celles-ci).
Le développement de stratégies de soutien efficaces demande une compréhension fine de la culture open source qui caractérise une très grande partie de notre infrastructure numérique, mais aussi de reconnaître que beaucoup de choses ont changé dans les cinq dernières années, y compris la définition même de l'open source.
L'argent seul ne suffira pas à répondre aux problèmes d'un projet d'infrastructure en difficulté, parce que l'open source s'épanouit grâce aux ressources humaines et non financières. Il existe beaucoup de façons d'accroître les ressources humaines, comme distribuer la charge de travail parmi davantage de contributeurs ou encourager les entreprises à faire publier en open source une partie du travail de leurs employés. Une stratégie de soutien efficace doit inclure plusieurs façons de générer du temps et des ressources au-delà du financement direct du développement. Elle doit partir du principe que l'approche open source n'est pas défectueuse en elle-même, mais manque simplement de ressources.
Soutenir les infrastructures nécessite d'intégrer le concept d'intendance en lieu et place du concept de contrôle. Comme nous l'avons vu, les infrastructures numériques ne ressemblent pas aux infrastructures physiques. Elles sont réparties entre de multiples acteurs et organisations, avec des projets de toute forme et de toute taille, et il est difficile de prédire quels projets deviendront un succès ou qui y contribuera sur le long terme.
Photo par Frédéric Bisson (CC BY 2.0) [2]
Avec cela en tête, voici quelques clés pour élaborer une stratégie d'assistance efficace :
Adopter la décentralisation, plutôt que s'y opposer
Les ressources de l'open source sont destinées à être partagées, c'est en partie ce qui leur donne autant d'impact.
Utiliser la force que donne l'aspect communautaire comme un levier, plutôt que de recentraliser l'autorité.
Travailler étroitement avec les communautés informatiques existantes
Les communautés informatiques sont actives, soudées et savent se faire entendre. Faites appel à elles plutôt que de prendre une décision en aparté. Les voix les plus sonores des communautés agissent comme un signal de danger quand un problème nécessite d'être soulevé.
Envisager une approche globale du soutien aux projets
Les projets ont besoin de bien plus que du code ou de l'argent, parfois même ils n'ont besoin ni de l'un ni de l'autre. Le soutien sur le long terme est davantage une question de temps accordé que d'argent. La revue de code, la documentation technique, les tests de code, la soutien de la communauté, et la promotion du projet constituent un ensemble de ressources importantes.
Aider les mainteneurs de projets à anticiper
Aujourd'hui, les efforts pour soutenir l'infrastructure numérique ont tendance a être uniquement de la réactivité liée aux circonstances ponctuelles. En plus des projets existants, il existe sûrement de nouveau projets qui ont besoin d'être lancés et accompagnés.
Pour les projets existants, les mainteneurs trouveront un grand avantage à pouvoir planifier en vue des trois à cinq ans à venir, et pas seulement pour six mois ou un an.
Voir les opportunités, pas seulement les risques
Soutenir l'open source de nos jours, cela ne consiste pas uniquement à éviter les scénarios catastrophes (par exemple les failles de sécurité), mais plutôt à donner les moyens à davantage de personnes de réaliser davantage de choses. Ce concept est une caractéristique essentielle de la culture open source actuelle, et permet aussi de mettre en place un soutien pérenne. Tenez compte dans votre stratégie de la façon dont vous pourriez accueillir davantage de personnes d'horizons, de compétences et de talents différents, plutôt que de limiter l'activité pour favoriser les personnes qui participent déjà.
David Heinemeier Hansson, le créateur de Ruby on Rails, compare l'open source à un récif de corail :
« C'est un milieu plus fragile que vous ne le pensez, et il est difficile de sous-estimer la beauté qui est involontairement en jeu. Marchez avec précaution. »
Photo par Wicker Paradise (CC-BY 2.0) [3]
Une vue d'ensemble
Nous arrivons bientôt au terme de notre traduction semaine après semaine de l'ouvrage Des routes et des ponts de Nadia Eghbal.
Aujourd'hui nous vous proposons un chapitre qui recense les moyens dont les institutions et entreprises pourraient contribuer au développement et à la pérennité des projets open source qui constituent la colonne vertébrale de l'infrastructure numérique.
Une esquisse du tableau
Il est trop tôt pour dire à quoi devrait ressembler le soutien institutionnel à long terme d'un point de vue prospectif, mais il y a plusieurs domaines de travail critiques qui peuvent nous aider à le déterminer. Les propositions suivantes sont rattachées à trois domaines :
Traiter les infrastructures numériques comme un bien commun essentiel et les élever au rang d'acteur intersectoriel clé ;
Travailler avec des projets pour améliorer les standards, la sécurité et les flux de production ;
Augmenter la taille du groupe de contributeurs de manière à ce que davantage de personnes, et davantage de personnes de types différents, puissent élaborer et soutenir ensemble les logiciels publics.
Conscientiser et éduquer les acteurs clés
Comme nous l'avons relevé dans ce rapport, beaucoup d'acteurs clés – dont les startups, les gouvernements, et les sociétés de capital risque – pensent à tort que les logiciels publics « fonctionnent, tout simplement » et ne requiert pas de maintenance supplémentaire. Pour entretenir correctement l'écosystème de nos infrastructures numériques, ces populations devraient être les premières à être informées du problème. Les infrastructures numériques ont besoin de porte-parole qui soient affranchis de toute contrainte politique ou commerciale et qui puissent comprendre et communiquer les besoins de l'écosystème.
Traiter les infrastructures numériques comme des biens publics essentiels pourrait également motiver l'investissement direct dans la construction de meilleurs systèmes à partir de zéro. Par exemple, aux États-Unis, les autoroutes inter états et le réseau de bibliothèques publiques furent dès l'origine conçus comme des ressources publiques. Les unes et les autres ont eu leur champion (respectivement le Président Dwight Eisenhower et le philanthrope Andrew Carnegie) qui ont clairement argumenté en faveur du bénéfice social et financier qui résulterait de tels projets.
Un réseau national d'autoroutes ne sert pas uniquement à nous relier en tant qu'individus, en facilitant les déplacements d'un endroit à un autre, mais il apporte aussi la prospérité financière dans tous les coins du pays, grâce à l'usage commercial des voies rapides pour acheminer les marchandises. Dans les bibliothèques Andrew Carnegie, publiques et gratuites, les livres étaient accessibles et non stockés en magasin, pour permettre aux gens de les feuilleter et d'y trouver eux-mêmes l'information sans avoir recours à une bibliothécaire. Cette pratique a aidé à démocratiser l'information et à donner aux gens les moyens de s'éduquer eux-mêmes.
Une meilleure éducation et une meilleure prise de conscience pourraient s'étendre jusqu'aux gouvernements, dont certains ont rendu, par la loi, les infrastructures numériques difficiles à soutenir et qui ne sont peut-être pas familiers des normes culturelles et de l'histoire de l'open source. Aux USA, l'IRS [NdT : Internal Revenue Service – organisme qui collecte l'impôt] a une définition très restrictive des activités caritatives, et comme l'open source est mal comprise, son impact positif sur la société demeure ignoré. Cela complique l'institutionnalisation de plus gros projets à travers une fondation ou une association professionnelle.
Mesurer l'utilisation et l'impact de l'infrastructure numérique
L'impact de l'infrastructure numérique est encore très difficile à mesurer. Les indicateurs habituels sont soit très imprécis, soit simplement indisponibles. Ce n'est pas un problème facile à résoudre. Mais sans données relatives aux outils utilisés et à notre dépendance vis-à-vis d'eux, il est difficile de se faire une idée nette de ce qui manque de financement.
Avec de meilleurs indicateurs, nous pourrions décrire l'impact économique de l'infrastructure numérique, identifier les projets essentiels qui manquent de financement, et comprendre les dépendances entre les projets et entre les personnes. Pour le moment, il est impossible de dire qui utilise un projet open source à moins que l'utilisateur, individu ou entreprise, ne le révèle. Pour déterminer quel projet a besoin de plus de soutien, nous ne disposons que d'informations anecdotiques.
De meilleures statistiques pourraient également nous aider à identifier les « contributeurs clé de voûte ». En biologie environnementale, une « espèce clé » est une espèce animale qui a un impact disproportionné sur son environnement au regard de ses effectifs. Dans la même idée, un « contributeur clé » pourrait être un développeur qui contribue à plusieurs projets essentiels, qui est le seul responsable d'un projet crucial, ou qui est généralement perçu comme influent et digne de confiance. Les « contributeurs clés » sont des défenseurs essentiels, les valoriser en leur fournissant les ressources dont ils ont besoin pourrait améliorer le système dans son ensemble. Comprendre les relations entre les communautés open source et les « contributeurs clés » pourrait aider à identifier rapidement les secteurs qui auront besoin de soutien supplémentaire.
On dispose également de peu de données sur les contributeurs eux-mêmes : qui contribue à l'open source, quelles conditions leur permettent de le faire, et quelles sont les contributions effectuées. Les femmes, les non-anglophones, et les nouveaux contributeurs à l'open source sont des exemples de population qui devraient être suivies dans le temps, en particulier pour mesurer l'impact des programmes de soutien.
Les seules statistiques disponibles sur les dépôts GitHub sont le nombre de personnes ayant étoilé (action semblable à liker), vu (c'est-à-dire qu'elles reçoivent des nouvelles du projet) ou « forké » un projet. Ces chiffres permettent de fournir des indicateurs concernant la popularité, mais ils peuvent être trompeurs. Beaucoup de personnes peuvent étoiler un projet, parce qu'il a une conception intéressante par exemple, sans toutefois l'intégrer à leur propre code.
Certains gestionnaires de paquets tels npm (qui est celui de Node.js) suivent les téléchargements. Le « popularity contest » de Debian piste les téléchargements du système d'exploitation libre Debian. Néanmoins, chaque gestionnaire de paquets est limité à un écosystème particulier, et aucun de ces gestionnaires ne peut donner une image du système dans son ensemble. Plusieurs projets ne sont pas inclus dans un gestionnaire de paquets et ne sont pas suivis. Libraries.io, un site web créé par Andrew Nesbitt, est une tentative pour agréger des données des projets open source en fonction de leur usage, il piste environ 1,3 millions de bibliothèques open source sur 32 gestionnaires de paquets.
Travailler avec les projets pour moderniser l'organisation de travail
Beaucoup de projets sont en difficulté et pas seulement à cause d'un manque de financement, mais aussi parce qu'il est difficile d'y contribuer, ou encore parce qu'il existe un goulot d'étranglement au niveau des mainteneurs qui traitent les demandes de modification (pull requests) de la communauté. C'est vrai, en particulier, pour les plus anciens projets qui ont été bâtis avec des outils de développement, des langages et des processus qui ne sont plus populaires (ceux qui par exemple utilisent un système de contrôle de version autre que Git, dont la popularité croît chez les développeurs).
On peut faire beaucoup de choses pour faciliter la contribution à un projet, depuis la migration vers un flux de travail (workflow) plus moderne, le nettoyage du code, la fermeture des pull request délaissées, jusqu'à la mise en place d'une politique claire pour les contributions. Certains projets expérimentent pour rendre les contributions plus simples. Le développeur Felix Geisendörfer, par exemple, a suggéré que chaque personne qui soumet une modification du code devrait avoir une permission de commit afin de réduire l'engorgement au niveau de l'unique mainteneur vérifiant et approuvant ces changements. Felix a estimé que « cette approche est un fantastique moyen d'éviter que le projet ne se ratatine en transformant le projet d'un seul homme en celui d'une communauté ».
Le règlement de contribution de Node.js, qui peut être adopté par les autres projets Node, met l'accent sur l'augmentation du nombre de contributeurs et sur leur autonomisation dans la prise de décision, plutôt que de désigner les mainteneurs comme seule autorité approbatrice. Leurs règles de contribution expliquent comment soumettre et valider des pull requests, comment consigner des bugs, etc. Les mainteneurs Node.js ont constaté qu'adopter de meilleures règles les avait aidés à gérer leur charge de travail et à faire évoluer leur communauté vers un projet plus sain et actif.
Photo par Jez Nicholson (CC BY-SA 2.0) [4]
Dans un premier temps, il y a des recherches à faire pour déterminer quels projets doivent avancer. Autrement dit, à quoi ressemble un « projet à succès », aussi bien en termes de financement et de modèles de gouvernance, que dans l'équilibre à trouver entre mainteneurs, contributeurs et usagers ! La réponse peut varier en fonction des différents types de projets et de leur ampleur.
Encourager les standards communs dans les projets open source
Bien que GitHub soit en train de devenir une plate-forme standard pour la collaboration sur le code, de nombreux aspects des projets open source ne sont pas encore standardisés, notamment l'ampleur et la richesse de la documentation, des licences et des guides de contribution, ainsi que le style de code et le formatage.
Encourager l'adoption de standards de projets pourrait faciliter, pour les mainteneurs, la gestion des contributions, tout en réduisant pour les contributeurs les obstacles à la participation.
Parmi les exemples de standardisation croissante, on trouve le code de conduite, qui est un règlement détaillant les attentes en termes d'attitude et de communication.
Ces dernières années, des codes de conduite ont été adoptés par un nombre croissant de communautés de projets, notamment Node.js, Django et Ruby. Bien que le processus d'adoption ait pu donner lieu à d'intenses débats au sein de certaines communautés, leur prolifération révèle un intérêt croissant pour la responsabilisation du comportement des communautés.
Augmenter le nombre de contributeurs et contributrices open source
Comme nous l'avons évoqué dans un chapitre précédent de ce rapport, l'industrie du logiciel est florissante, avec un nombre croissant de nouveaux développeurs mais aussi d'autres talents variés : il y a du travail à faire pour encourager ces nouveaux arrivants à contribuer à l'open source. Augmenter le nombre de contributeurs permet aux projets open source d'être plus durables, car davantage de personnes participent à leur développement. Permettre à davantage de personnes de contribuer à l'open source accroît également l'empathie et la communication entre les « utilisateurs » de l'open source et les projets dont ils dépendent.
« Your First PR » (« votre première PR », PR pour Pull Request, NdT) est un exemple d'initiative, développée par la programmeuse Charlotte Spencer, qui aide les nouveaux venus à effectuer leur première contribution à l'open source. « First Timers Only » (Réservé aux débutants) et « Make a Pull Request » (Faites une pull request) sont deux autres exemples de ressources populaires qui introduisent les nouveaux venus à l'open source. Certains projets open source utilisent également des étiquettes telles que « first bug » ou « contributor friendly » pour signaler les problèmes susceptibles d'être résolus par des contributeurs moins expérimentés. Il serait également bénéfique d'encourager les contributions à l'open source autres que le code, comme la rédaction de documentation technique, la gestion des tâches et des flux de travail, ou la création d'un site internet pour le projet.
En plus de l'augmentation de la proportion de techniciens talentueux contribuant à l'open source existe la possibilité de puiser dans un groupe de contributeurs plus large. Faire en sorte que les non-anglophones se sentent bienvenus dans les communautés open source, par exemple, pourrait rendre la technologie plus accessible à travers le monde. Et comme beaucoup de recruteurs utilisent les travaux open source comme un portfolio au moment d'embaucher un développeur, une communauté open source plus diverse encouragerait l'apparition d'un personnel technique globalement plus inclusif.
Améliorer les relations entre projets et acteurs extérieurs
Les entreprises sont une pièce incontournable de l'écosystème open source, et leur rôle ne fait que gagner en importance à mesure que davantage d'entre elles adoptent les logiciels open source. Faciliter la collaboration entre entreprises et projets, ainsi qu'aider les entreprises à comprendre les besoins des communautés open source, pourrait débloquer le soutien des entreprises susceptibles de devenir mécènes ou promoteurs de l'open source.
Selon l'étude annuelle des entreprises open source réalisée par Black Duck, seulement 27 % des entreprises ont un règlement formel concernant les contributions de leurs employés à l'open source. Clarifier la possibilité ou non pour les employés de contribuer à l'open source sur leur temps de travail, et les encourager à le faire, pourrait grandement améliorer le soutien des entreprises aux projets open source.
En 2014, un groupement d'entreprises a fondé le TODO Group, pour partager les bonnes pratiques autour de la participation corporative à l'open source. Parmi les membres de ce groupe, on trouve Box, Facebook, Dropbox, Twitter et Stripe. En mars 2016, le TODO Group a annoncé qu'il serait hébergé par la Fondation Linux en tant que projet collaboratif.
Les entreprises peuvent également fournir un soutien financier aux projets, mais il est parfois difficile pour elles de trouver comment formaliser leur mécénat. Créer des budgets dédiés au mécénat en direction des équipes d'ingénieurs ou des employés, ou encore créer des documents permettant aux projets de « facturer » plus facilement leurs services aux entreprises, sont autant d'initiatives qui pourraient augmenter les contributions financières à l'open source.
Poul-Henning Kamp, par exemple, travaille sur un projet open source nommé Varnish, utilisé par un dixième des sites les plus visités d'internet, notamment Facebook, Twitter, Tumblr, The New York Times et The Guardian. Pour financer ce travail, il a créé la Varnish Moral License pour faciliter la sponsorisation du projet par les entreprises.
Même si en pratique la relation est un mécénat, Poul Henning utilise une terminologie familière aux entreprises, avec des termes tels que « facturation » et « licences », pour réduire les obstacles à la participation.
Augmenter le soutien aux compétences diverses et aux fonctions hors-codage
Dans un passé pas si lointain, les startups de logiciels étaient fortement centrées sur les compétences techniques. Les autres rôles, comme le marketing et le design, étaient considérés comme secondaires par rapport au code. Aujourd'hui, avec la création et la consommation rapide de logiciels, cette conception ne tient plus. Les startups sont en concurrence pour capter l'attention de leurs clients. L'identité de la marque est devenue l'un des principaux facteurs de différenciation.
Ces cinq dernières années ont été celles de l'essor du développeur full stack (polyvalent) : des développeurs plus généralistes que spécialisés, capables de travailler sur plusieurs domaines d'un logiciel complexe, et qui sont susceptibles d'avoir des compétences dans la conception et la production. Les équipes de développement sont plus soudées, elles utilisent les méthodes agiles avec des approches de conception d'architecture logicielle (où le livrable est élaboré en faisant des navettes entre les équipes de techniciens, designers et commerciaux), plutôt qu'une approche en cascade (où chaque équipe apporte sa pièce à l'édifice avant de la transmettre au groupe de travail suivant).
Les projets open source ont connu peu d'évolutions de ce genre, malgré notre dépendance croissante à leurs logiciels. On comprend aisément que le code soit au cœur d'un projet open source, il est en quelque sorte le « produit final » ou le livrable. Les fonctions relatives à la gestion de la communauté, à la documentation, ou à la promotion du projet, qui sont la marque d'une organisation saine et durable, sont moins valorisées. Il en découle que les projets sont déséquilibrés. Beaucoup de choses pourraient être entreprises pour financer et soutenir les contributions autres que le code, des dons en nature pour payer les serveurs par exemple, ou des avantages comme une assurance maladie. Disposer de soutiens de ce type permettrait de réduire notablement la charge des développeurs.
À la croisée des chemins
Le 12 septembre dernier, Framalang commençait la traduction de l'ouvrage de Nadia Eghbal Des routes et des ponts. Aujourd'hui, nous vous proposons le dernier chapitre de ce livre.
Ce chapitre s'interroge sur la marche à suivre pour continuer les avancées technologiques et sociales des cultures open source et libres. Cette conclusion rappelle qu'à l'heure de l'information, tout le monde est concerné par les technologies ouvertes, bien que nous n'en ayons souvent que peu conscience. Ainsi, afin de pouvoir continuer d'utiliser cette infrastructure qui a été mise à notre disposition, nous devons nous mobiliser pour en garantir la pérennité.
L'état actuel de notre infrastructure numérique est un des problèmes les moins bien compris de notre temps. Il est vital de le comprendre.
En s'investissant bénévolement dans notre structure sous-jacente, les développeurs ont facilité la construction de logiciels pour autrui. En la fournissant gratuitement plutôt qu'en la facturant, ils ont alimenté une révolution de l'information.
Les développeurs n'ont pas fait cela pour être altruistes. Ils l'ont fait car c'était la meilleure manière de résoudre leurs propres problèmes. L'histoire du logiciel open source est l'un des grands triomphes de nos jours pour le bien public.
Nous avons de la chance que les développeurs aient limité les coûts cachés de ces investissements. Mais leurs investissements initiaux ne nous ont amenés que là où nous sommes aujourd'hui.
Nous ne sommes qu'au commencement de l'histoire de la transformation de l'humanité par le logiciel. Marc Andreessen, co-fondateur de Netscape et reconnu comme capital-risqueur derrière la société Andreessen Horowitz, remarque en 2011 que « le logiciel dévore le monde » [5]. Depuis lors, cette pensée est devenue un mantra pour l'ère moderne.
Le logiciel touche tout ce que l'on fait : non seulement les frivolités et les loisirs, mais aussi les choses obligatoires et critiques. OpenSSL, le projet décrit au début de cet essai, le démontre bien. Dans une interview téléphonique, Steve Marquess explique qu'OpenSSL n'était pas utilisé seulement par les utilisateurs de sites web, mais aussi par les gouvernements, les drones, les satellites et tous « les gadgets que vous entendez bipper dans les hôpitaux » [Entretien téléphonique avec Steve Marquess, NdA.].
Le Network Time Protocol [protocole de temps par le réseau, NdT], maintenu par Harlan Stenn, synchronise les horloges utilisées par des milliards de périphériques connectés et touche tout ce qui contient un horodatage. Pas seulement les applications de conversations ou les courriels, mais aussi les marchés financiers, les enregistrements médicaux et la production de produits chimiques.
Et pourtant, Harlan note :
Il y a un besoin de soutenir l'infrastructure publique libre. Mais il n'y a pas de source de revenu disponible à l'heure actuelle. Les gens se plaignent lorsque leurs horloges sont décalées d'une seconde. Ils disent, « oui nous avons besoin de vous, mais nous ne pouvons pas vous donner de l'argent » [6].
Licence CC-BY-SA 4.0 [7]
Durant ces cinq dernières années, l'infrastructure open source est devenue une couche essentielle de notre tissu social. Mais tout comme les startups ou la technologie elle-même, ce qui a fonctionné pour les 30 premières années de l'histoire de l'open source n'aidera plus à avancer. Pour maintenir notre rythme de progression, nous devons réinvestir dans les outils qui nous aident à construire des projets plus importants et de meilleure qualité.
Trouver un moyen de soutenir l'infrastructure numérique peut sembler intimidant, mais il y a de multiples raisons de voir le chemin à parcourir comme une opportunité.
Premièrement, l'infrastructure est déjà là, avec une valeur clairement démontrée. Ce rapport ne propose pas d'investir dans une idée sans plus-value. L'énorme contribution sociale de l'infrastructure numérique actuelle ne peut être ignorée ni mise de côté, comme cela est déjà arrivé dans des débats tout aussi importants sur les données, la vie privée, la neutralité du net, ou l'opposition entre investissement privé et investissement public. Il est dès lors plus facile de faire basculer les débats vers les solutions.
Deuxièmement, il existe déjà des communautés open source engagées et prospères avec lesquelles travailler. De nombreux développeurs s'identifient par le langage de programmation qu'ils utilisent (tels que Python ou JavaScript), la fonction qu'ils apportent (telles qu'analyste ou développeur opérationnels), ou un projet important (tels que Node.js ou Rails). Ce sont des communautés fortes, visibles, et enthousiastes.
Les constructeurs de notre infrastructure numérique sont connectés les uns aux autres, attentifs à leurs besoins, et techniquement talentueux. Ils ont déjà construit notre ville ; nous avons seulement besoin d'aider à maintenir les lumières allumées, de telle sorte qu'ils puissent continuer à faire ce qu'ils font de mieux.
Les infrastructures, qu'elles soient physiques ou numériques, ne sont pas faciles à comprendre, et leurs effets ne sont pas toujours visibles, mais cela doit nous encourager à les suivre plus en détail, pas moins. Quand une communauté a parlé si ouvertement et si souvent de ses besoins, tout ce que nous devons faire est d'écouter.
Remerciements
Merci à tous ceux qui ont courageusement accepté d'être mentionnés dans cet ouvrage, ainsi qu'à ceux dont les réponses honnêtes et réfléchies m'ont aidée à affiner ma pensée pendant la phase de recherche :
André Arko, Brian Behlendorf, Adam Benayoun, Juan Benet, Cory Benfield, Kris Borchers, John Edgar, Maciej Fijalkowski, Karl Fogel, Brian Ford, Sue Graves, Eric Holscher, Brandon Keepers, Russell Keith-Magee, Kyle Kemp, Jan Lehnardt, Jessica Lord, Steve Marquess, Karissa McKelvey, Heather Meeker, Philip Neustrom, Max Ogden, Arash Payan, Stormy Peters, Andrey Petrov, Peter Rabbitson, Mikeal Rogers, Hynek Schlawack, Boaz Sender, Quinn Slack, Chris Soghoian, Charlotte Spencer, Harlan Stenn, Diane Tate, Max Veytsman, Christopher Allan Webber, Chad Whitacre, Meredith Whittaker, Doug Wilson.
Merci à tous ceux qui ont écrit quelque chose de public qui a été référencé dans cet essai. C'était une partie importante de la recherche, et je remercie ceux dont les idées sont publiques pour que d'autres s'en inspirent.
Merci à Franz Nicolay pour la relecture et Brave UX pour le design de ce rapport.
Enfin, un très grand merci à Jenny Toomey et Michael Brennan pour m'avoir aidée à conduire ce projet avec patience et enthousiasme, à Lori McGlinchey et Freedman Consulting pour leur retours et à Ethan Zuckerman pour que la magie opère.
Framasoft remercie chaleureusement les 40 traducteurs et traductrices du groupe Framalang qui depuis septembre ont contribué à vous proposer cet ouvrage (qui sera disponible en Framabook... quand il sera prêt) :
Adélie, AFS, alien spoon, Anthony, Asta (Gatien Bovyn), astraia_spica, Bam92 (Abel Mbula), Bidouille, Bromind (Martin Vassor), Ced, dominix, Edgar Lori, flo, glissière de sécurité, goofy, goudron, Julien / Sphinx, jums, Laure, Luc, Lumibd, lyn, Mika, MO, Opsylac (Diane Ranville), pasquin, Penguin, peupleLà, Piup, roptat, Rozmador, salade, serici, teromene, Théo, urlgaga, woof, xi (Juliette Tibayrenc), xXx.
https://framablog.org/2016/12/26/des-routes-et-des-ponts-16-strategies/
https://framablog.org/2017/01/02/des-routes-et-des-ponts-17-une-vue-densemble/
https://framablog.org/2017/01/10/des-routes-et-des-ponts-18-a-la-croisee-des-chemins/
Cet article est sous licence Creative Commons (selon la juridiction française = Paternité - Pas de Modification).
http://creativecommons.org/licenses/by-nd/2.0/fr/
NOTES
[1] https://fordfoundcontent.blob.core.windows.net/media/2976/roads-and-bridges-the-unseen-labor-behind-our-digital-infrastructure.pdf
[2] https://www.flickr.com/photos/zigazou76/8707576899/in/photolist-egsBfc-dEAdCX-nzTCwF-dmEEAe-o2ZGfB-928pY7-tRDxhB-dmEDHk-dmECtP-oUa8C9-8NJfqD-dHwD1v-pbDZv8-aJm6T-evjfeD-rxN8no-4BrqYN-8NCFPD-7zFZsd-oUY9vv-oUV1rb-oUY96x-tyAys8-evjfia-q2fHTz-h3FKsP-nonD2k-dtGQT2-j5MYA3-e1Agsy-e1uzE6-e1uzHF-nEyTqX-nENw21-7jR5i9-bjGUKH-e1Agd5-5g487F-pvrB73-6Z5cQZ-pznprq-9jnfmd-dmEGVw-eRwohs-aqvTte-6tSTKD-8DpMfz-evD9Dh-e1AgKj-8zt2Na
[3] https://www.flickr.com/photos/wicker-furniture/
[4] https://www.flickr.com/photos/jnicho02/
[5] http://www.wsj.com/articles/ SB10001424053111903480904%20576512250915629460
[6] http://www.informationweek.com/it-life/ntps-fate-hing-es-on-father-time/d/d-id/1319432
[7] https://upload.wikimedia.org/wikipedia/commons/d/d2/Ntpq_-p_query.jpg
|