L'article aborde la question de l'acceptation des contributions générées par les LLM dans les projets open source, en la présentant comme un "pari pascal" moderne. Il distingue trois approches : l'acceptation majoritaire, le rejet strict, et une position intermédiaire jugée peu durable.
La position intermédiaire, telle que celle adoptée par Debian, est présentée comme une illusion de neutralité qui, à terme, conduit à une adoption inéluctable du code généré, sans en assumer la responsabilité. L'auteur soutient que rester dans cette zone grise équivaut, dans les faits, à une acceptation lente et non déclarée, qui peut être vue comme naïve ou hypocrite.
Face à ce dilemme, l'article suggère que chaque projet open source doit faire un choix urgent et clair entre accepter ou rejeter les contributions issues des LLM. Le rejet, bien qu'il puisse aliéner certains contributeurs, semble préférable car il évite de dépendre de technologies propriétaires et de perdre l'indépendance, tout en préservant la communauté des utilisateurs qui ne recherchent pas de logiciels spécifiquement "anti-IA".
L’auteur, utilisateur de GNU/Linux depuis 1999, explique comment il a surmonté ses appréhensions pour contribuer au noyau Linux, malgré un parcours non traditionnel en programmation. Il détaille son expérience avec des noyaux personnalisés pour smartphones (comme Dora sur un OnePlus 7 Pro), où il a d’abord modifié des modules existants avant de corriger des bugs, comme celui affectant le haut-parleur d’écoute (earpiece) sur un OnePlus 6 sous postmarketOS.
Son approche pragmatique montre que des contributions au noyau ne nécessitent pas une expertise avancée en électronique ou en programmation bas niveau, tant que l’on évite de toucher directement au matériel. Il illustre cela par la correction d’un compteur de référence mal géré dans le module wcd934x, résolvant un problème persistant après un mois de débogage.
Enfin, il partage ses corrections ultérieures de traces dans les logs du noyau, tout en reconnaissant que certains bugs, comme un crash aléatoire au démarrage, restent à résoudre. Son récit souligne que la contribution au noyau Linux est accessible, même pour des profils non experts, à condition de s’appuyer sur des outils comme les logs et les commits communautaires.
L’auteur, développeur de Writizzy, explore les dilemmes liés à l’ouverture du code de son produit, malgré son attachement à l’open source et ses avantages (contribution à l’écosystème, transparence, visibilité accrue). Il souligne que l’open source peut servir de levier marketing et favoriser une distribution plus large, comme en témoignent des plateformes comme Ghost, WordPress ou GitLab, où des acteurs économiques profitent de l’écosystème sans toujours contribuer en retour.
Cependant, il craint que Writizzy, s’il devient open source, ne subisse une exploitation commerciale disproportionnée par des tiers, captant une partie des revenus générés sans participer à la maintenance ou à l’amélioration du projet. Cette crainte s’appuie sur des exemples comme Substack ou Beehiiv, dont les modèles économiques reposent sur des logiciels non open source, tandis que Ghost, open source, génère une économie parallèle estimée entre 15 et 25 millions de dollars, dont une partie échappe à l’éditeur.
Face à ce dilemme entre éthique et viabilité économique, l’auteur envisage deux options : adopter une licence restrictive limitant l’usage commercial ou accepter cette dynamique sans garantie de retour sur investissement. Il souligne que Ghost, en tant qu’organisation sans actionnaires, peut se permettre cette approche, mais que pour un projet personnel, la question reste ouverte.
Tout est dans le titre
L'auteur montre comment il a contribué à Firefox en corrigeant un bug
L'auteur explique comment il s'est retrouvé à contribuer à un plugin Jenkins : très intéressant
Tout est dans le titre... et la plupart des conseils s'appliquent aussi à d'autres projets libres