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

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

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

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

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

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

Github, un espace standardisé pour collaborer sur du code

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

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

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

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

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

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

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

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

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

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

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

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

Tendances macro dans un paysage en mutation constante

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Parmi les interrogations nombreuses et inquiètes qui ont accompagné l’élection du nouveau président des USA, nous retenons aujourd’hui la question de la maîtrise des armes les plus dangereuses dont va disposer l’exécutif. On pense bien sûr à l’arme nucléaire et au danger de son usage inconsidéré, mais une actualité tout aussi préoccupante nous invite à nous demander avec Cory Doctorow quelles conséquences la machine industrielle de la surveillance étatique peut avoir sur nos libertés, si elle tombe aux mains de… [mettre ici le nom de toute personnalité politique dont on peut redouter l’autoritarisme].

Cory Doctorow, qui est Canadien, réagit ici à la situation nord-américaine, mais la surveillance étatique est planétaire et nous sommes en France assez lourdement pourvus en outils de surveillance générale pour éprouver quelques inquiétudes : que deviendront par exemple le fichier TES (voir ce billet de Korben) et l’état d’urgence indéfiniment prolongé que veut imposer M. Cazeneuve si un gouvernement autoritaire accède au pouvoir bientôt ?

Au risque réel Doctorow répond par la nécessité de lutter avec nos armes, celles d’Internet. Cela suffira-t-il ?

On a donné à un cinglé les clés de la surveillance d’État

par Cory Doctorow

Article original A madman has been given the keys to the surveillance state

Traduction Framalang : Goofy, Framasky, Diane

Quand le Patriot Act a été promulgué aux USA le 26 octobre 2001, il a fait disparaître un grand nombre des contrepouvoirs vitaux qui s’interposaient entre le peuple américain et son gouvernement. Alors que les partisans de Bush applaudissaient le pouvoir sans précédent que leurs représentants à Washington détenaient désormais, les militants des libertés civiles les avertissaient : « Votre président vient de créer une arme qui sera utilisée par tous ceux qui le suivront ».

Lorsque les démocrates ont pris la Maison-Blanche en 2008, les Américains de droite ont tardé à se rendre compte qu’une nouvelle administration qui ne s’appuyait pas sur eux pour exercer son pouvoir avait la possibilité de surveiller tous leurs mouvements, pouvait pister toutes leurs communications, pouvait les soumettre à une détention sans mandat dans des « zones frontalières » qui couvraient la majeure partie de la population américaine, pouvaient saisir leurs biens sans les accuser d’aucun crime, et ils ont commencé à s’inquiéter sérieusement.

Lorsque l’administration Obama a doublé le programme Bush de surveillance de masse, en lui ajoutant de lois secrètes et une liste d’Américains et d’étrangers qui pourraient être carrément assassinés en toute impunité n’importe où dans le monde, ses partisans démocrates n’ont pas accepté d’entendre la moindre critique. Obama était un politicien expérimenté, le père tranquille de l’Amérique, un type avec tant d’équanimité qu’il avait besoin d’un interprète pour traduire sa colère. Il n’allait pas abuser de cette autorité.

Les sept années de G.W. Bush après le 11 Septembre nous ont donné les bases d’un État de surveillance auquel il manquait un fou dangereux pour devenir totalitaire. Ensuite, huit ans après la mise en œuvre concrète de cet État de surveillance, Obama a indiqué aux administrateurs compétents et aux divers intervenants — police locale, partenaires internationaux, entrepreneurs militaires et industriels avec de gros budgets de lobbying — que cette surveillance doit se maintenir indéfiniment.

Aujourd’hui, c’est à un cinglé qu’on a donné le contrôle d’un arsenal de surveillance qui inclut l’autorité légale pour nous espionner tous, tout le temps ; des offres commerciales des monopoles des télécoms qui transforment les dépenses d’un gouvernement impopulaire en affaires rentables avec de l’argent comptant qui servira au lobbying pour élargir leur clientèle ; et un stock de vulnérabilités technologiques mortelles dans les outils dont nous dépendons, que l’Amérique a transformés en armes pour attaquer ses ennemis, même si cela implique de laisser les Américains sans défense contre les criminels, les harceleurs nihilistes, l’espionnage d’États étrangers et l’espionnage industriel.

Le Royaume-Uni est sur le point d’adopter une loi de surveillance qui éclipse tous les pouvoirs de surveillance de Bush et Obama. Le cyber-arsenal que Theresa May veut déchaîner sur le monde ne permettra pas seulement de vous pister en temps réel avec un degré d’intrusion qui ne peut pas être surestimé, il va également amasser des stocks énormes de données de ce suivi qui seront inévitablement fuitées, à la fois publiquement — pensez au piratage de Sony — et en privé, ce que nous découvrirons seulement des années après les faits, quand nous verrons que des escrocs minables ont exploité nos moments de chagrin et de détresse les plus privés pour en faire leur profit.

Le dernier gouvernement canadien a adopté un projet de loi de surveillance qu’on pourrait facilement qualifier de fanfiction du Patriot Act. Le gouvernement actuel — dirigé par un homme charismatique auquel beaucoup font confiance pour prendre les bonnes décisions — a voté pour elle, parce que ses membres ne voulaient pas être considérés comme « mous sur le terrorisme » à la veille de l’élection, mais ils ont promis de régler la question plus tard. Jusqu’à présent, ils n’ont strictement rien fait du tout, et ils n’ont pas de feuille de route pour faire quoi que ce soit qui pourrait transformer cette épée en un soc de charrue⁽¹⁾. Ce qui est particulier avec les pouvoirs que donne la surveillance, c’est qu’ils sont terriblement jouissifs. Une fois que vous en disposez, ils sont si pratiques qu’il est très difficile de les jeter dans les poubelles de l’Histoire.

Le gouvernement allemand de Mme Merkel — elle-même est hantée par ses souvenirs personnels d’enfance sous la surveillance intrusive des espions de la Stasi — a été scandalisé d’apprendre que le gouvernement des USA enregistrait les conversations téléphoniques de la Chancelière elle-même. Mais en fin de compte, Merkel a conclu un accord entre ses espions et leurs homologues américains et elle a officialisé le complexe industriel de surveillance. L’Allemagne est maintenant à deux doigts d’un gouvernement néo-nazi d’extrême-droite qui pourrait s’installer au milieu de la toile que Merkel a permis à ses services secrets de tisser dans tous les coins de son pays.

Après les terribles attaques de Paris, François Hollande a renié sa promesse de démantèlement de la surveillance française. Il l’a plutôt radicalement étendue, créant une arme immortelle et pluripotente pour espionner et contrôler le peuple français. Hollande est sur le point de perdre le contrôle du gouvernement français au bénéfice des néofascistes de Marine Le Pen, cheffe héréditaire d’une tribu de racistes vicieux et autoritaires.

Les mouvements politiques vont et viennent, mais les autorités institutionnelles demeurent. Les militants des partis ont offert une couverture politique à leurs leaders pendant qu’ils créaient tranquillement les conditions du fascisme clé en mains. Maintenant nous sommes à un clic du totalitarisme.

Il n’est pas trop tard.

Démanteler la surveillance d’État ne sera pas facile mais les choses importantes le sont rarement. Des organisations comme l’EFF (USA), Openmedia (Canada), la Quadrature du Net (France) et l’Open Rights Group ont mené cette bataille depuis des années, longtemps avant que la plupart d’entre nous ne prenne conscience du danger. Leur temps est maintenant : le moment où le danger est visible mais que le mal n’est pas irréversible. C’est le moment où jamais.

Les quatre ans à venir apporteront des batailles bien plus urgentes que l’avenir d’Internet : des batailles sur le droit des femmes à disposer de leur corps ; sur les meurtres racistes de la police et l’incarcération de masse, sur les déportations de masse et les camps de concentration ; sur la discrimination selon le genre et l’homophobie ; sur l’accès aux premières nécessités, depuis l’alimentation jusqu’au logement, en passant par la couverture maladie.

Chacune de ces batailles sera gagnée ou perdue en utilisant Internet.

Nous manquons de munitions, de forces vives, nous sommes trop peu nombreux et n’avons pas de plan, mais nous pouvons tout de même gagner. Internet donne l’avantage à la guerre asymétrique, là où le pouvoir brut et l’argent peuvent être contrés par des tactiques novatrices et une opposition agile.

S’il nous faut remporter la victoire dans la lutte pour les droits humains et la dignité humaine, nous devons avoir pour arme un Internet libre, ouvert et équitable. Ça commence maintenant. Ça commence avec la prise de conscience suivante : nous ne pouvons pas nous permettre de créer des armes et des pouvoirs juste pour « notre camp » en croyant que l’autre camp, celui des « méchants », ne voudra pas s’en emparer. Nous avons chargé un fusil et l’avons mis entre les mains d’un cinglé. Engageons-nous à ne plus jamais le faire.

Nous continuons le combat.

À lire aussi sur le même sujet :

• How to Trump-Proof Your Electronic Communications

Note

(1) Dans la Bible, « De leurs glaives ils forgeront des houes, Et de leurs lances des serpes … » (Ésaïe 2:4). L’idée est bien sûr de convertir les armes de la guerre en outils pour la paix.

Participer à l’open source est souvent une activité bénévole donc non rémunérée mais qui peut parfois devenir chronophage et difficilement compatible avec une autre activité ou un emploi. Nadia Eghbal, dans ce nouveau chapitre nous donne à voir aujourd’hui les trois motivations principales des contributeurs de l’open source.

Pourquoi les gens continuent-ils de contribuer à ces projets, alors qu’ils ne sont pas payés pour cela ?

Traduction Framalang : Adélie, goofy, xi, woof, Diane, Asta, Rozmador, Lumibd, Piup, teromene, mika, lyn. et deux anonymes
De nombreuses infrastructures numériques sont entretenues par des contributeurs individuels ou par une communauté de contributeurs. Dans la plupart des cas, ces contributeurs ne sont pas directement rémunérés pour ce travail. En réalité, ils contribuent pour des raisons propres aux communautés open source, pour se construire une réputation, par exemple, ou dans un esprit de service public. Ce chapitre explorera certaines de ces motivations plus en détail.

Contribuer à l’open source pour se construire une réputation.

Se construire une réputation est peut-être la motivation la plus concrète pour contribuer à un projet open source. Pour les développeurs, rédacteurs techniques et autres, ces projets sont une occasion de faire leurs preuves en public, et leur offrent une chance de participer à quelque chose de grand et d’utile.
Dans le cadre d’un programme appelé Google Summer of Code (l’été du code de Google), Google propose des bourses d’été à des étudiants développeurs pour qu’ils contribuent à des projets open source populaires. Le programme fonctionne bien, parce que les développeurs sont des étudiants, novices dans le domaine de l’informatique et avides de démontrer leurs talents.
Les développeurs, en particulier, tirent profit de leurs expériences de contribution à l’open source pour se constituer un portfolio. De plus, en contribuant à des projets populaires dotés de communautés actives, un développeur a des chances de se construire une réputation en devenant « connu ».

GitHub, site web déjà cité, est une plateforme populaire pour l’élaboration collaborative de code. Quand un développeur contribue à un projet public de logiciel, ses contributions apparaissent sur son profil. Le profil GitHub d’un développeur peut faire office de portfolio pour des sociétés de logiciels, mais seules les contributions effectuées pour des projets publics (c’est-à-dire open source) sont visibles par tous.

Cependant, les motivations basées sur la réputation ne sont pas dénuées de risques, surtout parmi les jeunes développeurs. Un développeur dont la carrière est encore naissante peut contribuer à un projet open source dans le seul but de trouver un employeur, puis arrêter de contribuer une fois cet objectif atteint. De plus, un développeur cherchant uniquement à se construire un portfolio risque de proposer des contributions de moindre qualité, qui ne seront pas acceptées et qui pourront même ralentir le processus de développement du projet. Enfin, si le but d’une contribution publique de la part d’un développeur est de se construire une réputation, alors ce développeur sera tenté de contribuer uniquement aux projets les plus populaires et attractifs (une extension du « syndrome de la pie » déjà évoqué), et de ce fait, les projets plus anciens auront du mal à trouver de nouveaux contributeurs.

Le projet est devenu très populaire de manière inattendue, et son développeur se sent obligé d’en assurer le suivi.

Des entreprises, des particuliers ou des organisations peuvent devenir dépendants d’un projet open source populaire. En d’autres termes, le code est utilisé dans des logiciels opérationnels, écrits et déployés par d’autres, ces logiciels peuvent servir pour un tas de choses : achats en ligne ou soins médicaux. En raison de la complexité du réseau de dépendances (dont beaucoup ne sont même pas connues de l’auteur du projet, puisqu’il ne peut pas savoir exactement qui utilise son code), la personne qui maintient le projet peut se sentir moralement obligée de continuer à l’entretenir.
Arash Payan, le développeur d’Appirater mentionné au début de ce rapport, a publié son projet en 2009. Au sujet de sa décision de continuer à maintenir le projet, il déclare :

« Ce n’est pas quelque chose de très excitant, mais il y a tellement de gens qui utilisent le projet (qui en dépendent, même ?) pour leurs applications, que je me sens obligé d’en prendre soin correctement. Personnellement, j’ai quitté iOS, donc maintenir une bibliothèque iOS n’est pas exactement la première chose que je veux faire de mon temps libre. »

Payan estime que maintenir le projet à jour lui prend 1 à 2 heures par mois maximum, donc cela ne le dérange pas.
Mais certains projets devenus populaires de façon inattendue prennent plus de temps à maintenir. Andrey Petrov est un développeur indépendant qui a écrit une bibliothèque Python appelée urllib3. Sa publication en 2008 fut une avancée majeure pour la bibliothèque standard déjà existante, et elle est devenue populaire parmi les développeurs Python. Aujourd’hui, tous les utilisateurs de Python en dépendent.
Andrey a rendu le projet open source dans l’espoir que d’autres gens soutiendraient son développement et sa maintenance. Il est développeur indépendant ; bien qu’il apprécie de maintenir urllib3, il ne peut s’en occuper que pendant son temps libre puisqu’il n’est pas payé pour ce travail. Cory Benfield, qui est employé par la Hewlett Packard Enterprise pour aider à maintenir des bibliothèques Python d’importance critique (que HPE utilise et dont HPE dépend), est désormais affecté à la maintenance de urllib3 dans le cadre de son travail ; cela a allégé la charge de travail d’Andrey.

Le projet est une passion plus qu’un travail

Eric Holsher est l’un des créateurs de Read the Docs, une plateforme qui héberge de la documentation sur des logiciels. La documentation est l’équivalent d’un mode d’emploi. De même qu’on a besoin d’un mode d’emploi pour monter un meuble, un développeur a besoin de documentation pour savoir comment implémenter un projet. Sans la documentation adéquate, il serait difficile pour un développeur de savoir par où commencer.
Read the Docs fournit de la documentation pour 18 000 logiciels, y compris pour des entreprises clientes, et compte plus de 15 millions de pages consultées chaque mois.
Bien qu’il génère des revenus grâce à de grosses sociétés clientes, le projet Read the Docs est toujours majoritairement financé par les dons de ses utilisateurs. Le coût des serveurs est quant à lui couvert grâce au mécénat de l’entreprise Rackspace.
Eric et son cofondateur, Anthony Johnson, s’occupent de la maintenance du projet et n’en tirent pas de revenus réguliers bien qu’ils s’y consacrent à temps plein. Une subvention ponctuelle de 48 000 $ de la Fondation Mozilla, reçue en décembre 2015, les aidera à court terme à couvrir leurs salaires. Ils expérimentent actuellement un modèle publicitaire (qui ne piste pas ses utilisateurs) qui rendrait le modèle viable.
Eric remarque que la difficulté ne réside pas uniquement dans le travail de développement, mais aussi dans les fonctions extérieures au code, comme le support client, qui nécessite qu’un mainteneur soit d’astreinte chaque week-end en cas de problème. Pour expliquer pourquoi il continuait de maintenir le projet, Eric l’a qualifié de « travail-passion ».

« Soit les humains sont irrationnels, soit ils ne sont pas intéressés seulement par l’argent. Il y a clairement une autre motivation pour moi dans ce cas. C’est un travail-passion. Si je le voulais, je pourrais clore ce projet demain et ne plus jamais y revenir, mais je travaille dessus depuis 5 ans et je n’ai aucune envie que ça se termine. »

Eric est motivé pour travailler sur Read the Docs parce qu’il perçoit la valeur que cela crée pour les autres. Pour beaucoup de mainteneurs de projets, cet impact sur autrui est la première motivation, parce qu’ils peuvent directement constater l’effet positif que leur travail a sur la vie d’autres personnes. En ce sens, l’open source a beaucoup de points communs avec le secteur à but non-lucratif. Cependant, tout comme dans le secteur à but non-lucratif, cette mentalité de « travail-passion » peut augmenter la difficulté qu’ont les communautés open source à aborder le sujet qui fâche : comment pérenniser des projets qui nécessitent davantage de ressources et d’attention que ce que les contributeurs actuels peuvent fournir ?

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.

Damgan est un petit village d’environ 1650 habitants dans le sud du Morbihan, région Bretagne. L’Université Populaire du Numérique de Damgan y est née le 27 septembre 2016, c’est une association qui compte déjà 48 adhérents au bout d’un mois.

Transparence : cet article est une reformulation des réponses que j’ai rédigées avec mon ami Pierre Bleiberg pour un article de Ouest France, mais très largement tronquées à la publication.

Qu’est ce qui vous a poussé à créer cette Université Populaire du Numérique de Damgan ?

Je pense qu’il y a urgence. Et depuis longtemps. La révolution numérique est d’ordre culturel, or la population dans sa grande majorité se sent exclue de cette culture. Les ordinateurs, les tablettes, les smartphones sont entrés dans les foyers et beaucoup se sentent démunis face à ce matériel informatique. Bien sûr il y a la nécessité d’apprendre des bases « techniques », mais surtout de se frotter à de nouveaux usages, à une nouvelle façon de faire société dans un monde où nous sommes tous connectés à tous les autres et où chacun, même celui qui se croit déconnecté, a une partie de sa vie stockée quelque part sous forme de 0 et de 1.

Une éducation est nécessaire et ce n’est pas l’état qui peut en être le moteur : comme partout ailleurs, une grande partie des responsables n’ont pas eux-mêmes cette culture. C’est un phénomène transversal qui touche toutes les populations, tous les milieux sociaux, et contrairement à ce que les plus anciens peuvent croire, tous les âges. Les jeunes sont plus à l’aise face à la machine, mais ils ne sont pas pour autant plus cultivés sur le numérique.

Cela fait déjà longtemps qu’on parle de fracture numérique. Je lisais dans un magazine informatique qu’il y a en France entre 8 et 10 millions de Français incapables de naviguer sur le net ou d’envoyer un mail ; c’est aussi handicapant que de ne pas savoir lire. Cette fracture n’a jamais été réduite. Une des raisons est que cette culture porte en elle un modèle de partage et d’horizontalité qui s’oppose violemment à celui de nos sociétés ultra-hiérarchisées. C’est pourquoi je pense que l’effort doit venir de la société civile, que nous devons nous éduquer nous-mêmes dans l’échange.

À qui s’adresse cette association ? Comment organisez-vous les ateliers ?

Nous sommes au tout début de l’aventure, nous ne pouvons pas encore parler d’organisation précise. Nous avons mis en place deux premiers ateliers avec à chaque fois une quarantaine de participants. D’abord un sur les forums car nous avons décidé de nous former sur un outil commun avant toute autre chose (notre forum). S’il n’y a pas d’interaction entre nous, l’objectif est manqué. Nous avons une composante locale, on se rencontre pour créer une sphère de confiance, mais il faut aussi pouvoir se retrouver en ligne en dehors des ateliers.

Nous avons également des listes de diffusion et un blog. Nous ne sommes pas encore présents sur les réseaux sociaux, on va y venir mais ensemble, doucement. Nous pensons créer les comptes en atelier.

La seconde séance a été consacrée aux notions de base de la micro-informatique : les ordinateurs et leurs composants. J’ai également refait l’atelier sur les forums avec d’autres adhérents.

Le public est le plus varié possible. La moyenne d’âge est assez élevée pour l’instant car elle correspond à la population de Damgan, mais nous avons quelques jeunes et espérons bien en trouver d’autres. Et nous avons déjà des personnes qui n’habitent pas Damgan qui participent, d’autres qui sont intéressées. Et je répète que nous accueillons tous les âges, tous les niveaux avec bienveillance.

Notre démarche s’appuie sur celle de l’éducation populaire, sur l’échange et le partage de connaissances. Si la grande majorité des premiers adhérents a « besoin d’apprendre », nous espérons bien que demain les mêmes pourront partager à leur tour leurs connaissances et leur expérience. Des adhérents ont déjà proposé des sujets qu’ils pourraient nous présenter dans une section du forum consacrée aux « offres ».

Comment gérez-vous les différents niveaux des participant-e-s ?

C’est la grande difficulté. Avec ces premières rencontres on apprend à se connaître et on débat ensemble de la façon dont on va pouvoir s’organiser. Nous avons eu beaucoup de monde et nous sommes bien conscients qu’il va falloir essayer de faire des ateliers plus petits et plus ciblés. Nous demandons à tous d’être un peu patients et nous remercions nos adhérents d’essuyer les plâtres. Ce qui est sûr c’est que le besoin est réel, les gens sont motivés et je suis certain que nous allons faire de grandes choses.

Faut-il amener son matériel ? Faut-il être « connecté-e » ?

Pour l’instant les gens sont venus en grande majorité avec des portables ou des tablettes. Nous allons certainement devoir consacrer des ateliers différents pour ce qui est de la pratique entre l’ordinateur d’un côté et les tablettes/smartphones de l’autre. Mais cela dépend du sujet. On parle beaucoup de pratique mais nos ambitions sont très larges. Si nous organisons des débats sur les données personnelles, il n’y pas besoin de matériel.

Nous souhaitons également nous mettre au service des gens « déconnectés », inviter ceux qui n’ont ni matériel ni internet, pour par exemple faire avec eux des démarches administratives en ligne. Pour ceux qui veulent venir voir et qui n’ont pas de matériel, c’est évidemment possible. Et pourquoi pas créer des créneaux de « libre accès » pour ceux qui en ont le besoin. Nous verrons, ça dépendra aussi de nos moyens financiers et humains.

Ressentez-vous l’appréhension face à cet univers ?

L’appréhension face au numérique, elle est omniprésente. Pour les plus anxieux, quand les gens viennent c’est déjà qu’ils ont fait un grand pas. Nous avons récemment accueilli une dame qui était totalement perdue et très émue de cette situation. Mais elle va s’accrocher et on va voir avec elle pour démarrer en douceur avec des ateliers très basiques.

Nous savons également qu’il nous faudra aller chercher ceux qui n’osent pas venir.

Nous ferons tout pour dédramatiser et casser cette peur avec un maximum de convivialité et d’entraide.

Avez-vous des objectifs, des projets, un plan pour l’avenir ?

Je ne vois aucune limite à nos projets, il y a tant de choses à faire. Rien n’est planifié mais c’est le fruit d’années de réflexions et d’implication dans le domaine du partage de connaissances et de la passion du numérique. Nous avons choisi de nous lancer avant même de savoir comment on allait faire car cela faisait trop longtemps qu’on y réfléchissait, à un moment on s’est dit que si on attendait de pouvoir embrasser tout le spectre des besoins et des possibilités, d’avoir tout planifié, on ne démarrerait jamais. Alors on a fait le grand saut, et on a confiance en l’avenir !

• Site de l’université populaire du numérique de Damgan
• Page de contact

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 l’avions annoncé en février dernier sur le Framablog, nous travaillons depuis quelques mois à faire émerger le Collectif des Hébergeurs Alternatifs, Transparents, Ouverts, Neutres et Solidaires… bref : les CHATONS.

Le succès de la campagne Dégooglisons Internet a démontré, à l’ère post-Snowden, un intérêt réel du public pour des services web respectueux de vos données et basés sur du logiciel libre. Le problème, c’est que si les « Frama-bidules » deviennent la réponse par défaut à cette demande, alors nous créerons ce que nous combattons : une centralisation des utilisateurs, une concentration des données aussi dangereuse que douteuse.

Or, nous sommes loin d’être les premiers à proposer de telles solutions. Et de nombreuses associations, SCOP, initiatives, etc. sont prêtes à rejoindre un mouvement de décentralisation pour créer des services mutualisés dans un internet de la proximité et de la confiance. De là, il n’y avait qu’un pas à faire pour créer un collectif des hébergeurs proposant de remettre des valeurs et de l’humain dans vos mails, fichiers, partages et collaborations.

Concrètement, que sont les CHATONS ?

Le plus simple, c’est d’aller voir sur le site web chatons.org. Ce site, c’est avant tout une carte vous montrant où sont les hébergeurs de services les plus proches de chez vous, ce qu’ils proposent (du pad, du framadate, du mail etc.) et sous quelles conditions (adhésion, service payant, etc.).

CHATONS, c’est donc un collectif regroupant ces hébergeurs éthiques, libres et loyaux (que l’on nommera… « chatons » !).

L’avantage c’est que chacun de ces chatons s’est engagé sur une charte et un manifeste communs, qui vous garantissent entre autres :

• l’utilisation de logiciels libres (et autant que possible la contribution ^^) ;
• aucun profilage publicitaire (pas de pub autre que mécénat et sponsoring) ;
• le respect de vos données (droit d’accès, interopérabilité, non-transmission à des tiers) ;
• la transparence (sur la technique comme sur les finances) ;
• la neutralité (aucune surveillance ni censure en amont) ;
• le chiffrement (dès et tant que possible).

Au-delà de l’aspect utilisateur, le fait d’initier ce collectif permettra une solidarité entre ses membres pour échanger sur des aspects techniques, juridiques, d’éducation populaire… et ainsi de faciliter la création de nouveaux chatons près de chez vous !

Comme nous l’expliquions en février dernier, les objectifs du collectif sont multiples : rassembler, mutualiser, décentraliser, donner de la visibilité, fédérer, essaimer, partager… Autant dire que l’ambition est grande.

Voyez chaque chaton comme une AMAP (Association pour le Maintien de l’Agriculture Paysanne), sauf qu’au lieu d’un panier de légumes fourni par un agriculteur, il s’agit de services en ligne fournis par un hébergeur de proximité. Et comme avec une AMAP, vous pouvez rencontrer l’agriculteur/hébergeur, et même partager un verre avec lui 🙂

La première portée

La première portée compte 21 membres, dont 14 sont déjà actifs. Parmi ces derniers, vous trouverez notamment des chatons ouverts à tous et couvrant la France entière, comme La Mère Zaclys ou L’Autre.net. Mais aussi des chatons plus « locaux » comme Infini (Brest), Assodev-Marsnet (Marseille) ou G3L (Valence). Certains sont des associations, comme Alolise (Saint-Étienne), d’autres des entreprises, comme IndieHosters. Certains sont de taille conséquente, comme Framasoft (qui dépasse le million de visites par mois), et d’autres ne servent qu’un public bien plus restreint comme roflcopter.fr (Toulouse).

Et les 7 autres ? Ils sont tout simplement en gestation !

D’ailleurs, parmi ceux-là, Framasoft va accompagner trois d’entre eux :

• Le mouvement Colibris, qui est un mouvement humaniste et écologiste, qui souhaite « sortir de Google ». Une sensibilisation des acteurs du mouvement Colibris permettra de toucher une population sensible aux questions du bien commun et du « faire ensemble ».
• Le collectif « Bertel Numérique », situé sur la lointaine île de la Réunion (lointaine pour nous qui grelottons en métropole ^^), a ceci de particulier qu’il associe la volonté d’un grand réseau d’éducation populaire (les CÉMÉA) et les compétences d’une petite entreprise locale spécialisée dans le logiciel libre. La mission du collectif est bien évidemment de proposer de l’hébergement local (pourquoi faire parcourir 18 000 km à un email si c’est pour écrire à son voisin de bureau ?)
• La Fédération Française des Motards en Colère est, avouons-le, un (futur) chaton atypique, puisque sa mission semble bien éloignée des questions informatiques ! En fait, la fédération a toujours eu très à cœur la protection de la vie privée de ses adhérent-e-s, mais doutait d’avoir les compétences en interne pour gérer un certain nombre de services. À nous de lui prouver que c’est possible !

Évidemment, tous les chatons en gestation pourront profiter de l’aide des membres du collectif, sur la base du bon vieux principe « Si tu ne sais pas, demande. Si tu sais, partage ». Framasoft prêtera juste une attention particulière à ces trois-là, vous tiendra informés par des billets de blog réguliers indiquant l’avancement de ces projets, sans masquer les inévitables difficultés rencontrées, afin que ces expériences croisées puissent servir à tou-te-s.

Par ailleurs, nous annoncerons régulièrement de nouvelles « portées » sur ce blog, afin que chacun puisse trouver chaton à son pied 🙂

Des « chapéros » pour fêter ça !

Pour fêter l’événement, plusieurs chatons ont souhaité organiser un (ch)apéro dans leur ville.

Vous pourrez donc retrouver des chatons à :

• Paris : le mercredi 12 octobre 2016 de 19h00 à 22h30,
• Lyon : le mercredi 12 octobre 2016 de 19h00 à 21h00,
• Brest : le vendredi 14 octobre 2016 de 18h30 à 22h00,
• Marseille : le vendredi 21 octobre 2016 de 18h30 à 22h00.

Comme tout cela est très spontané et mouvant, il est conseillé de se référer directement à l’agenda du libre, avec le tag chatons.

Les CHATONS version 1.0 !

Alors voilà, ce mercredi 12 octobre, nous annonçons donc la naissance des CHATONS. Bien entendu, le projet est encore jeune, et de nombreux CHATONS sont encore en cours de création : c’est un travail sur le long terme avant que d’arriver à avoir un maillage géographique complet ;).

Si vous êtes simple utilisatrice ou utilisateur de services, ne vous attendez donc pas à une révolution aujourd’hui : il s’agit juste de l’annonce officielle du collectif. Ce sont en quelque sorte les premiers mètres d’un marathon qui durera probablement plusieurs années. Ne soyez donc pas frustré-e-s de ne pas trouver LE chaton correspondant à vos besoins. Cela viendra !

Si nous avons appelé de nos vœux la création de ce collectif, Framasoft est et ne restera qu’un chaton parmi les autres : c’est le collectif (et lui seul) qui gérera son fonctionnement et son avenir.

Pour tout vous avouer, nous envisageons ce collectif comme un logiciel libre : c’est une proposition qui évoluera selon les décisions de sa communauté de contributeurs, une espèce de v.1 ouverte aux participations, contributions, échanges…

Ainsi, le collectif est géré comme un projet logiciel, en utilisant une liste de diffusion et une plateforme de développement logiciel, sur laquelle sont rédigés et « patchés » les documents fondateurs du collectif. C’est aussi grâce à cet outil que vous pouvez suivre l’évolution des propositions (ou en faire de nouvelles vous-mêmes). Et si vous n’êtes pas satisfait-e de son fonctionnement, vous pourrez tout simplement forker le projet, et monter votre propre collectif ou fédération avec vos règles, sans pour autant devoir repartir de zéro.

Différentes extensions sont d’ores et déjà prévues, comme la fabrication d’un Mooc pour apprendre à maîtriser les différents aspects de la création d’un chaton (enjeux, aspects juridiques, aspects techniques), et bien évidemment une internationalisation. Nos amis québécois de FACiL nous ont déjà rejoints, des chatons belges et suisses devraient apparaître sous peu sur la carte, et d’autres pays se sont montrés intéressés (Espagne, Italie, Pays-Bas, Allemagne, etc.). Mais ne mettons pas les matous avant les chatons : il nous faut déjà sortir de notre panière !

Si nous nous adressions à des informaticien-ne-s, nous pourrions dire qu’aujourd’hui est le premier commit du projet CHATONS, et qu’il comporte nécessairement des bugs, mais que – ensemble – nous le ferons évoluer dans le temps, de version en version, jusqu’à ce qu’il remplisse son objectif : permettre à celles et ceux qui le souhaitent de pouvoir quitter les services centralisateurs.

Car pour reprendre ce que nous disions il y a quelques mois, et qui reste toujours valable :

Face à ce mouvement de concentration, qui pourrait bien transformer Internet en Googleternet ou Facebookternet, nous ne voyons qu’une seule voie (si vous en avez d’autres à proposer, on prend !) : décentraliser Internet en faisant en sorte qu’il demeure tel qu’il a été conçu. Neutre. Ouvert. Interopérable. Libre.

Si nous voulons une économie qui soit aussi sociale et solidaire, il va nous falloir un internet qui soit aussi social et solidaire. Et cela passera entre autre par une diversité d’acteurs indépendants proposant des services web libres, éthiques et respectueux de vos données, décentralisés et solidaires.

Pour aller plus loin :

• découvrir Les CHATONS,
• l’espace de travail et de développement : le Manifeste, la Charte, l’espace participatif,
• l’article fondateur,
• pour se détendre, le générateur de logos.