Raphael Amorim n’a pas décidé que l’open source était une erreur.

Il continue de maintenir Rio, son émulateur de terminal public sous licence MIT.2

Mais Canario, son autre terminal construit pour le travail avec des agents de code, devient fermé.1

La raison qu’il donne est beaucoup moins philosophique : il n’a plus envie de payer le coût humain qui accompagne un dépôt ouvert.

Le code gratuit crée du travail payant en attention

Dans son billet du 11 août, Amorim rappelle qu’il contribue à l’open source depuis ses 17 ans. Il a aidé à ouvrir des projets internes dans plusieurs entreprises et continue à travailler publiquement sur Rio.1

Canario est différent. Il l’a construit pour lui-même, sans financement de VC et sans objectif déclaré d’en faire une entreprise. Rio et ses autres projets absorbent déjà son temps.1

Ouvrir le code ne signifie pourtant pas simplement pousser un repository sur GitHub.

Il faut lire les issues. Examiner les pull requests. Répondre aux discussions. Décider si un comportement est un bug, une préférence ou une demande de support. Refuser des changements. Expliquer le refus. Recommencer la semaine suivante.

C’est précisément le coût qu’Amorim décrit.1

Et l’IA change l’équation d’une manière assez asymétrique.

Générer une PR coûte moins cher que la lire

Amorim cite explicitement les issues faibles et les pull requests générées par IA parmi les raisons qui rendent la maintenance plus pénible.1

Il ne donne pas de volume précis. Il serait donc faux d’écrire que Canario a été « submergé par des milliers de PR IA » ou que l’IA est l’unique cause de fermeture.

Son argument est plus simple : produire une contribution de faible effort est devenu extrêmement facile, mais son examen reste du travail humain.1

Ce décalage est intéressant parce qu’il inverse une partie de la promesse habituelle des agents de code.

Pour l’auteur de la PR, générer un patch peut prendre quelques minutes. Pour le mainteneur, le coût n’est pas le nombre de lignes tapées. Il doit comprendre l’intention, vérifier le diff, lancer ou lire les tests, repérer les effets de bord et décider s’il accepte d’en devenir responsable pour les années suivantes.

Une contribution peut donc être presque gratuite à produire tout en restant chère à absorber.

Fermer la porte plutôt que construire un videur

On pourrait imaginer ajouter davantage d’automatisation : bots de tri, score de confiance, règles de contribution, CI plus stricte, agent qui relit l’agent.

Amorim choisit une solution beaucoup plus directe. Canario avance à son propre rythme, sans « drop-in requests », sans issues de spam et sans PR générées à examiner.1

Ce choix retire aussi une partie des bénéfices du développement ouvert : corrections externes, forks plus faciles à suivre, inspection du code courant et contributions imprévues.

Il ne prétend pas le contraire. Il dit simplement que cet échange ne vaut plus son temps pour ce projet précis.

Les anciennes versions de Canario restent, selon lui, présentes dans d’anciennes versions de Rio et peuvent être forkées.1 Le Rio actuel reste public, MIT, activement maintenu, avec plus de 7 000 stars lors de notre vérification.2

Ce n’est donc pas une conversion générale à la cathédrale fermée. C’est un mainteneur qui choisit où il veut encore tenir le bazar.

L’open source n’est pas seulement une licence

Les discussions sur l’open source traitent souvent la disponibilité du code comme le centre du système.

Pour le mainteneur, le vrai objet est aussi une file d’attente sociale.

Chaque repository public possède une entrée où arrivent bugs, opinions, questions, patches, demandes urgentes de quelqu’un qui n’a jamais lu la documentation et, désormais, contributions que leur auteur n’a peut-être pas entièrement lues non plus.

La licence décide ce que les autres ont le droit de faire avec le code. Elle ne décide pas combien d’attention le mainteneur doit leur donner.

Cette distinction devient plus importante avec les agents. Si la production de code augmente brutalement, les communautés doivent soit augmenter leur capacité de revue, soit rendre l’entrée plus coûteuse, soit accepter davantage de bruit, soit fermer certaines portes.

Canario illustre la dernière option.

Le paradoxe de l’abondance

Les agents promettent de rendre la contribution open source plus accessible. C’est réellement utile pour quelqu’un qui comprend un projet mais écrit lentement, découvre un langage ou veut automatiser une partie fastidieuse.

La même baisse de coût permet aussi d’envoyer un patch avant d’avoir suffisamment compris le projet.

Ces deux réalités peuvent coexister.

Le problème n’est donc pas « code IA = mauvais ». Le critère qui devient rare est la preuve qu’une contribution mérite le temps d’un autre humain.

Tests, reproduction claire, motivation, compréhension du contexte, petit scope : ces signaux étaient déjà utiles avant les agents. Ils deviennent plus précieux quand produire 300 lignes n’est plus un signal d’effort.

Amorim a choisi de ne pas résoudre ce problème dans Canario.1

C’est peut-être le détail le plus instructif de sa décision. Une technologie qui rend la construction moins chère peut rendre la sélection plus importante, et parfois pousser un projet à protéger la ressource qu’elle n’a pas automatisée : l’attention de son mainteneur.