L’article suivant a été initialement publié sur Moyen et est republié ici avec la permission de l’auteur.
L’open source évolue depuis un demi-siècle, mais les deux dernières décennies ont préparé le terrain pour la suite. Les années 2000 ont été la « scène vedette » : celle où l’open source est devenu courant, commercial et visible. Les années 2010 l’ont décentralisé, brisant la hiérarchie et rendant le forking normal. Aujourd’hui, dans les années 2020, la situation se transforme à nouveau avec l’entrée en scène de l’IA générative – en tant que participante.
Cette décennie n’est pas seulement plus rapide. C’est un autre type de vitesse. L’IA commence à écrire, refactoriser et remixer du code et des projets open source à une échelle qu’aucun responsable humain ne peut égaler. GitHub ne se contente pas de se développer ; il est en train de muter, rempli de dérivés du travail humain générés par l’IA, en passe de gérer près d’un milliard de référentiels d’ici la fin de la décennie.
Si nous voulons comprendre ce qui arrive à l’open source aujourd’hui, il est utile de revenir sur son évolution. L’histoire de l’open source n’est pas une ligne droite : c’est une série de tournants. Chaque décennie a changé non seulement la technologie mais aussi la culture qui l’entoure : de la rébellion dans les années 1990 à la reconnaissance dans les années 2000, en passant par la décentralisation dans les années 2010. Ces changements ont jeté les bases de ce qui va suivre : une ère où le code n’est pas seulement écrit par les développeurs mais par les agents qu’ils gèrent.
Années 1990 : préparer le terrain
La fin des années 80 et le début des années 90 ont été définis par des piles propriétaires : Windows, AIX, Solaris. Au milieu des années 90, les développeurs ont commencé à se rebeller. L’open source n’était pas seulement un idéal ; c’est ainsi que le Web s’est construit. La plupart des sites exécutaient Apache sur le front-end mais s’appuyaient sur des moteurs commerciaux tels que Dynamo et Oracle sur le back-end. La première toile était ouverte sur les bords et fermée au centre.
Dans les universités et les laboratoires de recherche, le même schéma est apparu. Les outils GNU comme Emacs, GCC et gdb étaient partout, mais ils fonctionnaient sur des systèmes propriétaires : SGI, Solaris, NeXT, AIX. L’open source avait pris racine, même si les plateformes n’étaient pas ouvertes. Mike Loukides et Andy Oram Programmation avec le logiciel GNU (1996) ont parfaitement capturé ce monde : un labyrinthe de variantes d’UNIX où chaque système interrompait vos scripts d’une nouvelle manière. Quiconque a appris la syntaxe de ligne de commande sur AIX au début des années 90 trébuche encore aujourd’hui sur macOS.
Ce changement – Linux et FreeBSD rencontrant le Web – a jeté les bases de la prochaine décennie d’infrastructure ouverte. De toute évidence, les travaux de Tim Berners-Lee au CERN ont été l’événement charnière qui a défini le siècle prochain, mais je pense que la victoire la plus tactique des années 1990 a été celle de Linux. Même si Linux n’est devenu viable pour une utilisation à grande échelle qu’avec la version 2.4 dans les années 2000, il a ouvert la voie.
Années 2000 : la décennie de l’Open Source
Les années 2000 ont été marquées par la généralisation de l’open source. Les entreprises qui vendaient autrefois des systèmes fermés ont commencé à financer les fondations qui les mettaient au défi : IBM, Sun, HP, Oracle et même Microsoft. Ce n’était pas de l’altruisme ; c’était une stratégie. L’open source est devenu une arme concurrentielle et le fait de s’engager est devenu une forme de capital social. Les communautés autour d’Apache, d’Eclipse et de Mozilla ne se contentaient pas d’écrire du code ; ils ont construit une sorte de jeu de réputation. «Je m’engage» pourrait financer une startup ou vous décrocher un emploi.
À mesure que l’open source prenait de l’ampleur, la visibilité est devenue sa propre forme de pouvoir. Être engagé était un capital social et la renommée au sein de la communauté créait une hiérarchie. Le mouvement qui avait commencé comme une rébellion contre le contrôle propriétaire a commencé à construire ses propres « hauts lieux ». Les fondations sont devenues des scènes ; les conférences sont devenues de la politique. La nature centralisée de CVS et de Subversion a renforcé cette hiérarchie : le contrôle d’un référentiel maître unique signifiait le contrôle du projet lui-même. Le forking n’était pas considéré comme une collaboration ; c’était un défi. Et ainsi, même dans un mouvement voué à l’ouverture, l’autorité a commencé à se concentrer.
À la fin de la décennie, l’open source avait recréé les mêmes structures qu’il avait autrefois tenté de démanteler et il y avait des luttes de pouvoir autour du fork et du contrôle – jusqu’à ce que Git arrive et rende discrètement le fork non seulement normal mais encouragé.
En 2006, Linus Torvalds a discrètement abandonné quelque chose qui allait tout remodeler : Git. C’était controversé, désordonné et profondément décentralisé : le bon outil au bon moment.
Années 2010 : la grande décentralisation
Les années 2010 ont tout décentralisé. Git a supprimé Subversion et CVS, ce qui rend le forking normal. GitHub a transformé le contrôle de version en réseau social et, soudain, l’open source n’était plus une poignée de projets centraux, mais des milliers d’expériences concurrentes. Git a créé un fork bon marché et local : n’importe qui pouvait bifurquer instantanément, pirater de manière isolée, puis décider de fusionner à nouveau. Cette idée a changé la psychologie de la collaboration. L’expérimentation est devenue normale et non subversive.
L’effet était explosif. SourceForge, qui abrite l’ère CVS/SVN, hébergeait environ 240 000 projets en 2010. Dix ans plus tard, GitHub comptait environ 190 millions de référentiels. Même si la moitié étaient des projets de jouets, cela représenterait un bond de deux à trois ordres de grandeur dans la vitesse de création de projets : environ un nouveau référentiel toutes les quelques secondes à la fin des années 2010. Git n’a pas seulement accéléré les commits ; cela a changé le fonctionnement de l’open source.
Mais les mêmes frictions qui ont disparu ont également fait disparaître les filtres. Parce que Git a rendu l’expérimentation sans effort, les « projets jetables » sont devenus viables : des frameworks à moitié finis, des prototypes et des expériences personnelles cohabitant avec du code de qualité production. Au milieu de la décennie, l’open source était entré dans sa phase cambrienne : alors que les années 2000 nous ont donné cinq ou six frameworks frontaux crédibles, les années 2010 en ont produit 50 ou 60. Git n’a pas seulement décentralisé le code, il a également décentralisé l’attention.
Années 2020 : comment appellerons-nous cette décennie ?
Maintenant que nous sommes au milieu des années 2020, quelque chose de nouveau se produit. L’IA générative s’est glissée discrètement dans le flux de travail, remodelant une fois de plus l’open source, non pas en le tuant mais en rendant le forking encore plus facile. Il constitue également l’un des principaux intrants de formation pour les résultats qu’il génère.
Remontez deux décennies dans les années 2000 : si une bibliothèque ne faisait pas ce dont vous aviez besoin, vous rejoigniez la liste de diffusion, gagniez la confiance et deveniez peut-être un contributeur. C’était lent, politique et parfois productif. Mais pour que vous ou les entreprises pour lesquelles vous travaillez puissiez influencer un projet et valider du code, nous parlons de mois ou d’années d’investissement.
Aujourd’hui, si un projet est correct à 90 %, vous le lancez, décrivez le correctif à une IA et vous passez à autre chose 5 minutes plus tard. Aucune file d’attente d’examen. Pas de débats sur les styles de corsets. La culture pull-request qui une fois définie l’open source commence à sembler facultative car toi n’y investissons pas de temps pour commencer.
En fait, vous ne savez peut-être même pas que vous avez créé et corrigé quelque chose. L’un des 10 agents que vous avez lancés en parallèle pour réimplémenter une API a peut-être créé une bibliothèque, l’a corrigée pour votre cas d’utilisation spécifique et l’a publiée sur votre référentiel npm GitHub privé pendant que vous étiez en train de déjeuner. Et vous ne prêtez peut-être même pas attention à ces détails.
Prédiction de tendance : nous allons très bientôt donner un surnom aux développeurs qui utilisent GenAI et qui sont incapables de lire le code qu’il a généré, car cela se produit.
L’Open Source est-il terminé ?
Non, mais ça change déjà. Les grands projets continueront : React, Next.js et DuckDB continueront de croître car les modèles d’IA les préfèrent déjà. Et je pense qu’il existe encore des communautés ou des développeurs qui souhaitent collaborer avec d’autres humains.
Mais il y a une vague de contributions et de projets open source générés par l’IA qui commenceront à affecter l’écosystème. Les bibliothèques plus petites et plus ciblées commenceront à voir plus de forks. C’est ma prédiction, et cela pourrait arriver au point où cela n’a plus beaucoup de sens de les suivre.
Au lieu d’une demi-douzaine de frameworks stables par catégorie, nous verrons des centaines de petits frameworks et forks optimisés par l’IA, chacun résolvant parfaitement le problème d’un développeur, puis disparaissant. Le lien social qui liait autrefois l’open source – mentorat, débat, maintenance partagée – s’amincit. La collaboration cède la place à une personnalisation radicale. Et je ne sais pas si c’est une si mauvaise chose.
La décennie du « fourchette et oublie »
Cela s’annonce comme la décennie du « fourchette et oublie ». Les développeurs (et les agents qu’ils exécutent) évoluent à une nouvelle vitesse : créer des fourches, appliquer des correctifs et passer à autre chose. GitHub rapporte plus de 420 millions de référentiels au début de 2023, et il est en passe d’atteindre le milliard d’ici 2030.
Nous avons démoli les « hauts lieux » qui définissaient les années 2000 et les avons remplacés par l’innovation sans friction des années 2010. La question est désormais de savoir si nous reconnaîtrons l’open source d’ici la fin de cette décennie. Je fais toujours attention aux bibliothèques que j’utilise, mais la plupart des développeurs qui utilisent des outils comme Cursor pour écrire du code complexe ne le font probablement pas – et n’en ont peut-être pas besoin. L’agent l’a déjà fourché et est passé à autre chose.
C’est peut-être ça la nouvelle liberté : bifurquer, oublier et laisser les machines se souvenir pour nous.
