Depuis plusieurs années, Framasoft est honoré et enchanté des illustrations que lui fournit David Revoy, comme sont ravi⋅es les lectrices et lecteurs qui apprécient les aventures de Pepper et Carrot et les graphistes qui bénéficient de ses tutoriels. Ses créations graphiques sont sous licence libre (CC-BY), ce qui est un choix courageux compte tenu des « éditeurs » dépourvus de scrupules comme on peut le lire dans cet article.

Cet artiste talentueux autant que généreux explique aujourd’hui son embarras face aux IA génératives et pourquoi son éthique ainsi que son processus créatif personnel l’empêchent de les utiliser comme le font les « IArtistes »…

Article original en anglais sur le blog de David Revoy

Traduction : Goofy, révisée par l’auteur.

Intelligence artificielle : voici pourquoi je n’utiliserai pas pour mes créations artistiques de hashtag #HumanArt, #HumanMade ou #NoAI

par David REVOY

 

« C’est cool, vous avez utilisé quel IA pour faire ça ? »

« Son travail est sans aucun doute de l’IA »

« C’est de l’art fait avec de l’IA et je trouve ça déprimant… »

… voilà un échantillon des commentaires que je reçois de plus en plus sur mon travail artistique.

Et ce n’est pas agréable.

Dans un monde où des légions d’IArtistes envahissent les plateformes comme celles des médias sociaux, de DeviantArt ou ArtStation, je remarque que dans l’esprit du plus grand nombre on commence à mettre l’Art-par-IA et l’art numérique dans le même panier. En tant qu’artiste numérique qui crée son œuvre comme une vraie peinture, je trouve cette situation très injuste. J’utilise une tablette graphique, des layers (couches d’images), des peintures numériques et des pinceaux numériques. J’y travaille dur des heures et des heures. Je ne me contente pas de saisir au clavier une invite et d’appuyer sur Entrée pour avoir mes images.
C’est pourquoi j’ai commencé à ajouter les hashtags #HumanArt puis #HumanMade à mes œuvres sur les réseaux sociaux pour indiquer clairement que mon art est « fait à la main » et qu’il n’utilise pas Stable Diffusion, Dall-E, Midjourney ou n’importe quel outil de génération automatique d’images disponible aujourd’hui. Je voulais clarifier cela pour ne plus recevoir le genre de commentaires que j’ai cités au début de mon intro. Mais quel est le meilleur hashtag pour cela ?

Je ne savais pas trop, alors j’ai lancé un sondage sur mon fil Mastodon

Résultats

Sur 954 personnes qui ont voté (je les remercie), #HumanMade l’emporte par 55 % contre 30 % pour #HumanArt. Mais ce qui m’a fait changer d’idée c’est la diversité et la richesse des points de vue que j’ai reçus en commentaires. Bon nombre d’entre eux étaient privés et donc vous ne pouvez pas les parcourir. Mais ils m’ont vraiment fait changer d’avis sur la question. C’est pourquoi j’ai décidé de rédiger cet article pour en parler un peu.

Critiques des hashtags #HumanMade et #HumanArt

Tout d’abord, #HumanArt sonne comme une opposition au célèbre tag #FurryArt de la communauté Furry. Bien vu, ce n’est pas ce que je veux.

Et puis #HumanMade est un choix qui a été critiqué parce que l’IA aussi était une création humaine, ce qui lui faisait perdre sa pertinence. Mais la plupart des personnes pouvaient facilement comprendre ce que #HumanMade signifierait sous une création artistique. Donc 55 % des votes était un score cohérent.

J’ai aussi reçu pas mal de propositions d’alternatives comme #HandCrafted, #HandMade, #Art et autres suggestions.

Le succès de #NoAI

J’ai également reçu beaucoup de suggestions en faveur du hashtag #NoAI, ainsi que des variantes plus drôles et surtout plus crues. C’était tout à fait marrant, mais je n’ai pas l’intention de m’attaquer à toute l’intelligence artificielle. Certains de ses usages qui reposent sur des jeux de données éthiques pourraient à l’avenir s’avérer de bons outils. J’y reviendrai plus loin dans cet article.
De toutes façons, j’ai toujours essayé d’avoir un état d’esprit « favorable à » plutôt que « opposé à » quelque chose.

C’est aux artistes qui utilisent l’IA de taguer leur message

Ceci est revenu aussi très fréquemment dans les commentaires. Malheureusement, les IArtistes taguent rarement leur travail, comme on peut le voir sur les réseaux sociaux, DeviantArt ou ArtStation. Et je les comprends, vu le nombre d’avantages qu’ils ont à ne pas le faire.

Pour commencer, ils peuvent se faire passer pour des artistes sans grand effort. Ensuite, ils peuvent conférer à leur art davantage de légitimité à leurs yeux et aux yeux de leur public. Enfin, ils peuvent probablement éviter les commentaires hostiles et les signalements des artistes anti-IA des diverses plateformes.
Je n’ai donc pas l’espoir qu’ils le feront un jour. Je déteste cette situation parce qu’elle est injuste.
Mais récemment j’ai commencé à apprécier ce comportement sous un autre angle, dans la mesure où ces impostures pourraient ruiner tous les jeux de données et les modèles d’apprentissage : les IA se dévorent elles-mêmes.

Quand David propose de saboter les jeux de données… 😛 

Pas de hashtag du tout

La dernière suggestion que j’ai fréquemment reçue était de ne pas utiliser de hashtag du tout.
En effet, écrire #HumanArt, #HumanMade ou #NoAI signalerait immédiatement le message et l’œuvre comme une cible de qualité pour l’apprentissage sur les jeux de données à venir. Comme je l’ai écrit plus haut, obtenir des jeux de données réalisées par des humains est le futur défi des IA. Je ne veux surtout pas leur faciliter la tâche.
Il m’est toujours possible d’indiquer mon éthique personnelle en écrivant « Œuvre réalisée sans utilisation de générateur d’image par IA qui repose sur des jeux de données non éthiques » dans la section d’informations de mon profil de média social, ou bien d’ajouter simplement un lien vers l’article que j’écris en ce moment même.

Conclusion et considérations sur les IA

J’ai donc pris ma décision : je n’utiliserai pour ma création artistique aucun hashtag, ni #HumanArt, ni #HumanMade, ni #NoAI.
Je continuerai à publier en ligne mes œuvres numériques, comme je le fais depuis le début des années 2000.
Je continuerai à tout publier sous une licence permissive Creative Commons et avec les fichiers sources, parce que c’est ainsi que j’aime qualifier mon art : libre et gratuit.

Malheureusement, je ne serai jamais en mesure d’empêcher des entreprises dépourvues d’éthique de siphonner complètement mes collections d’œuvres. Le mal est en tout cas déjà fait : des centaines, voire des milliers de mes illustrations et cases de bandes dessinées ont été utilisées pour entraîner leurs IA. Il est facile d’en avoir la preuve (par exemple sur haveibeentrained.com  ou bien en parcourant le jeu de données d’apprentissage Laion5B).

Je ne suis pas du tout d’accord avec ça.

Quelles sont mes possibilités ? Pas grand-chose… Je ne peux pas supprimer mes créations une à une de leur jeu de données. Elles ont été copiées sur tellement de sites de fonds d’écran, de galeries, forums et autres projets. Je n’ai pas les ressources pour me lancer là-dedans. Je ne peux pas non plus exclure mes créations futures des prochaines moissons par scans. De plus, les méthodes de protection comme Glaze me paraissent une piètre solution au problème, je ne suis pas convaincu. Pas plus que par la perspective d’imposer des filigranes à mes images…

Ne vous y trompez pas : je n’ai rien contre la technologie des IA en elle-même.On la trouve partout en ce moment. Dans le smartphones pour améliorer les photos, dans les logiciels de 3D pour éliminer le « bruit » des processeurs graphiques, dans les outils de traduction [N. de T. la présente traduction a en effet été réalisée avec l’aide DeepL pour le premier jet], derrière les moteurs de recherche etc. Les techniques de réseaux neuronaux et d’apprentissage machine sur les jeux de données s’avèrent très efficaces pour certaines tâches.
Les projets FLOSS (Free Libre and Open Source Software) eux-mêmes comme GMIC développent leurs propres bibliothèques de réseaux neuronaux. Bien sûr elles reposeront sur des jeux de données éthiques. Comme d’habitude, mon problème n’est pas la technologie en elle-même. Mon problème, c’est le mode de gouvernance et l’éthique de ceux qui utilisent de telles technologies.

Pour ma part, je continuerai à ne pas utiliser d’IA génératives dans mon travail (Stable Diffusion, Dall-E, Midjourney et Cie). Je les ai expérimentées sur les médias sociaux par le passé, parfois sérieusement, parfois en étant impressionné, mais le plus souvent de façon sarcastique .

Je n’aime pas du tout le processus des IA…

Quand je crée une nouvelle œuvre, je n’exprime pas mes idées avec des mots.
Quand je crée une nouvelle œuvre, je n’envoie pas l’idée par texto à mon cerveau.

C’est un mixage complexe d’émotions, de formes, de couleurs et de textures. C’est comme saisir au vol une scène éphémère venue d’un rêve passager rendant visite à mon cerveau. Elle n’a nul besoin d’être traduite en une formulation verbale. Quand je fais cela, je partage une part intime de mon rêve intérieur. Cela va au-delà des mots pour atteindre certaines émotions, souvenirs et sensations.
Avec les IA, les IArtistes se contentent de saisir au clavier un certains nombre de mots-clés pour le thème. Ils l’agrémentent d’autres mots-clés, ciblent l’imitation d’un artiste ou d’un style. Puis ils laissent le hasard opérer pour avoir un résultat. Ensuite ils découvrent que ce résultat, bien sûr, inclut des émotions sous forme picturale, des formes, des couleurs et des textures. Mais ces émotions sont-elles les leurs ou bien un sous-produit de leur processus ? Quoi qu’il en soit, ils peuvent posséder ces émotions.

Les IArtistes sont juste des mineurs qui forent dans les œuvres d’art générées artificiellement, c’est le nouveau Readymade numérique de notre temps. Cette technologie recherche la productivité au moindre coût et au moindre effort. Je pense que c’est très cohérent avec notre époque. Cela fournit à beaucoup d’écrivains des illustrations médiocres pour les couvertures de leurs livres, aux rédacteurs pour leurs articles, aux musiciens pour leurs albums et aux IArtistes pour leurs portfolios…

Je comprends bien qu’on ne peut pas revenir en arrière, ce public se sent comme empuissanté par les IA. Il peut finalement avoir des illustrations vite et pas cher. Et il va traiter de luddites tous les artistes qui luttent contre ça…

Mais je vais persister ici à déclarer que personnellement je n’aime pas cette forme d’art, parce qu’elle ne dit rien de ses créateurs. Ce qu’ils pensent, quel est leur goût esthétique, ce qu’ils ont en eux-mêmes pour tracer une ligne ou donner tel coup de pinceau, quelle lumière brille en eux, comment ils masquent leurs imperfections, leurs délicieuses inexactitudes en les maquillant… Je veux voir tout cela et suivre la vie des personnes, œuvre après œuvre.

J’espère que vous continuerez à suivre et soutenir mon travail artistique, les épisodes de mes bandes dessinées, mes articles et tutoriels, pour les mêmes raisons.

---

Vous pouvez soutenir la travail de David Revoy en devenant un mécène ou en parcourant sa boutique.

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.