Open Source Is Not Enough Source Code Ep. 28
La promesse d’Elon Musk de rendre le code de X open source ne suffit pas à en faire un véritable projet open source, car l’ouverture réelle repose sur la gouvernance, l’infrastructure, la pérennité et les mécanismes de vérification indépendants, bien au-delà de la simple publi...
SYNTHÈSE STRUCTURÉE
Le contexte de l’annonce : une réponse à une crise de confiance
L’intervenant souligne que la promesse de Musk du 15 juillet 2026 n’est pas née d’une vision, mais d’une urgence : « It came from a fire that needed putting out ». Huit jours plus tôt, des chercheurs en sécurité avaient découvert que Grok Build, l’outil de codage de xAI, téléchargeait les dépôts de code privés des utilisateurs vers des serveurs Google Cloud sans les informer clairement. Sam Altman a qualifié la situation de « concerning ». L’annonce de transparence totale est donc une réponse à un scandale de confidentialité, pas une initiative stratégique.
Un historique de promesses non tenues
Depuis le rachat de Twitter en 2022, Musk a promis la transparence à plusieurs reprises, mais les résultats ont été partiels et incohérents :
- Mars 2023 : publication partielle de l’algorithme de recommandation sur GitHub, mais la modération du contenu et la logique de classement ont été omises.
- Janvier 2026 : version plus complète de l’algorithme, construite sur Grok, avec une promesse de mises à jour toutes les 4 semaines.
- Entre-temps, plusieurs efforts open source de la plateforme ont été abandonnés ou laissés à l’abandon. L’intervenant résume : « One door opens, three others close. That is the pattern. A loud announcement, selective openness, then silence. »
La distinction fondamentale : logiciel libre vs open source
L’intervenant rappelle que Richard Stallman a fondé la Free Software Foundation en 1985 avec quatre libertés essentielles : exécuter le programme, étudier son fonctionnement, redistribuer des copies et distribuer des versions modifiées. Pour Stallman, « free should be understood as in free speech, not as in free beer ». Le terme « open source » est apparu en 1998 comme une approche plus pragmatique et moins idéologique, avec 10 critères techniques. Stallman a critiqué cette approche dans son essai « Why open source misses the point of free software », arguant que se concentrer sur les avantages pratiques sans l’éthique trahit l’esprit original.
Le code seul ne suffit pas : la gouvernance est essentielle
L’intervenant insiste : « Code is a necessary condition, not a sufficient one. » Un écosystème libre ne se résume pas à des fichiers .c ou .py dans un dépôt public. Il repose sur la gouvernance, les processus de décision, les droits de merge et le contrôle de l’infrastructure. Dans les grands projets open source (Linux, Debian, Kubernetes), les décisions sont collégiales, avec des mainteneurs et des processus de revue. Chez X, « the entire power structure is vertical. Musk decides, full stop. Publishing the code does not change that. It only changes who can see the decisions, not who makes them. »
L’infrastructure : le vrai verrou
Même si le code source de X est publié, l’infrastructure de production (serveurs, données utilisateurs, modèles de recommandation) reste la propriété exclusive de l’entreprise. L’intervenant compare cela à « publishing a recipe while keeping the only oven in the world capable of baking it ». On peut lire l’algorithme, mais on ne peut pas exécuter sa propre instance de X avec les mêmes données et la même puissance réseau.
La pérennité : un indicateur clé
Un écosystème open source ne se mesure pas à une annonce unique, mais à la constance dans le temps. L’intervenant cite Debian, qui existe depuis 1993 et a conservé les mêmes principes fondateurs pendant plus de 30 ans. À l’inverse, X a un historique de publications partielles suivies de silence, et d’abandon d’efforts open source existants. « That is what builds trust, not a tweet with trust me written at the bottom. »
Les incitations structurelles : pourquoi ouvrir le code ?
L’intervenant distingue deux motivations : ouvrir pour construire une communauté et redistribuer le pouvoir (open source dans l’esprit), ou ouvrir pour éteindre un incendie réputationnel après un scandale de confidentialité, pour générer du marketing. Dans ce second cas, « public code is just glass on top of a cage that stays locked. You can see inside. You still cannot walk in. And you certainly cannot change the structure of the cage itself. »
Le piège de la vérification par des tiers
Musk promet des réviseurs tiers pour vérifier que le code publié correspond exactement à ce qui tourne en production. L’intervenant trouve cela ironique : « Who chooses the third-party reviewers? If the answer is X itself, then the transparency check is itself opaque. » C’est un serpent qui se mord la queue. La véritable transparence ne demande pas de faire confiance à la parole de celui qui promet d’être transparent, mais exige des mécanismes vérifiables indépendamment.
Les pratiques concrètes de transparence vérifiable
L’intervenant oppose la phrase « trust through transparency » à un ensemble de pratiques d’ingénierie spécifiques :
- Reproducible builds : compiler le même code source donne exactement le même résultat binaire, bit pour bit, sur n’importe quelle machine. Cela permet à un inconnu de vérifier indépendamment que le binaire en production correspond au code source public.
- Public transparency logs : chaque version signée est enregistrée dans un journal public que tout le monde peut inspecter, et personne ne peut modifier ou supprimer des entrées après coup.
L’intervenant cite l’essence de l’argument de Stallman : « Not trust me because I am good, but you should not need to trust anyone because you hold the power to verify it yourself. »
CONCEPTS CLÉS
- Open source washing : pratique où une entreprise publie une version édulcorée de son code source tout en gardant le système réel (celui qui tourne en production) différent et fermé.
- Reproducible builds : technique de compilation garantissant que le même code source produit exactement le même binaire, permettant une vérification indépendante.
- Public transparency logs : journaux publics et immuables où chaque version signée est enregistrée, permettant à quiconque de vérifier l’intégrité des publications.
- Gouvernance open source : ensemble des processus de décision, des droits de merge et des mécanismes de revue qui déterminent qui contrôle réellement l’évolution d’un projet.
- Copyleft : licence de logiciel libre qui impose que les versions modifiées du code soient distribuées sous les mêmes termes, garantissant que les libertés restent préservées.
CONCLUSION
La promesse de Musk de rendre le code de X open source, même si elle était tenue intégralement, ne ferait pas de X un véritable acteur de l’écosystème open source. L’intervenant conclut : « Open source is not enough. You need an ecosystem. And ecosystems are not announced with a post. They are built brick by brick by people willing to actually give up control, not just perform it. » La leçon pour tout administrateur système est que l’ouverture du code n’est qu’une condition nécessaire, jamais suffisante. Ce qui compte vraiment, c’est qui détient le pouvoir de décision, qui contrôle l’infrastructure, et si les mécanismes de transparence sont vérifiables indépendamment. Un projet qui publie son code mais garde le contrôle vertical de sa gouvernance et de son infrastructure reste, dans les faits, un système fermé.