Le 21 juin 2026, Mitchell Hashimoto a publié sur son blog personnel un billet de moins de 500 mots : lui et sa femme font un nouveau don de 400 000 $ à la Zig Software Foundation (ZSF), portant le total à 700 000 $. Pas de communiqué de presse, pas de déclaration conjointe, pas de banderole « partenariat stratégique ». Un chèque personnel, un blog personnel, un jugement personnel.
Cela n’a rien à voir avec le modèle de flux financier auquel le monde open source s’est habitué.
Le sponsoring open source par les entreprises, le geste standard, c’est : siège au conseil d’administration, droit de vote au comité de pilotage technique, influence sur la roadmap, co-branding, communiqué de presse conjoint. L’argent vient avec des conditions — parfois écrites dans le contrat, parfois cachées dans les comptes-rendus de réunions d’« alignement stratégique ». Google sponsorise Kubernetes, Microsoft sponsorise la Fondation Rust, Meta sponsorise la Fondation PyTorch — cet argent fait vivre des infrastructures critiques, mais il apporte aussi des jeux complexes de gouvernance. La relation de pouvoir entre le sponsor et le projet n’est jamais unidirectionnelle.
Mais un don personnel massif, c’est autre chose.
L’argent que Hashimoto donne à Zig n’a pas acheté un siège au conseil, ni un droit de veto sur la direction du langage, ni aucune forme de contrôle. Il écrit même clairement sur son blog qu’il utilise massivement l’IA pour l’aider à coder, alors que la ZSF est connue pour sa politique stricte d’« interdiction des soumissions de code généré par LLM » — son opinion et celle de la fondation ne concordent pas parfaitement. Mais cela n’affecte pas sa décision de don. « Je n’ai que du respect pour la ZSF : respect pour les gens, les politiques, et le projet lui-même », dit-il. « Internet et l’open source sont grands en partie parce que les projets peuvent être bizarres, différents. »
C’est précisément la valeur unique du don personnel — « être en désaccord n’affecte pas ma décision d’investir » — c’est en soi une déclaration de profondeur de confiance. Cette confiance a un objet clair : la direction que prend l’autre.
Je ne veux pas idéaliser le don personnel. Les grands donateurs individuels sont eux-mêmes le produit des inégalités de richesse. Hashimoto, en tant que cofondateur de HashiCorp, possède un patrimoine personnel considérable depuis le rachat de l’entreprise par IBM pour 6,4 milliards de dollars. Le fait même qu’une personne puisse signer un chèque de 400 000 $ montre que ce modèle n’est ni reproductible ni scalable. Un commentateur de la communauté Zig, colindean, a eu raison de dire sur Lobsters : « Chaque centime compte. Peut-être que ça commence par donner 5 $ par mois à la fondation de votre langage préféré. » L’effet agrégé des petits dons individuels et le don massif unique d’une personne fortunée sont deux niveaux différents du même écosystème — l’un fournit la résilience de base, l’autre la poussée stratégique.
Mais ce rôle de poussée stratégique, presque personne dans les discussions actuelles ne l’a sérieusement analysé.
Quand une entreprise donne 250 000 $ à une fondation open source (le seuil habituel pour devenir « sponsor platine »), elle obtient des droits de participation à la gouvernance. Cet argent est fondamentalement un achat — achat d’influence, achat d’accès anticipé, achat de visibilité de marque sur le pipeline de recrutement. Quand un individu donne à titre personnel un montant équivalent ou supérieur, sans exiger aucun droit de gouvernance, cet argent est fondamentalement un pari. Un pari sur la direction, pas sur le retour.
La différence entre les deux est particulièrement nette dans le cas de Zig. Comparons la structure de financement de la Fondation Rust et de la Fondation Zig : la liste des sponsors platine de la Fondation Rust inclut Google, Microsoft, Amazon, Huawei, Meta — chacun ayant quelqu’un qui siège au conseil d’administration de la fondation. C’est un constat factuel. Rust bénéficie ainsi d’un solide soutien en ressources corporate, mais doit en contrepartie équilibrer en continu la gouvernance entre de multiples parties prenantes. La Fondation Zig, elle, a eu environ 670 000 $ de revenus pour l’exercice 2024, dont environ 170 000 $ de petits dons communautaires via GitHub Sponsors, et 150 000 $ de dons personnels de Hashimoto. 92% des dépenses vont directement à la rémunération des contributeurs.
Ces deux voies ne sont ni meilleures ni pires l’une que l’autre, elles résolvent des problèmes différents. Mais la discussion sur la gouvernance open source se concentre presque exclusivement sur le modèle de sponsoring corporate — comment gérer les conflits d’intérêts, comment équilibrer l’influence des entreprises, comment éviter la « capture ». Le don personnel massif comme source alternative de financement est gravement sous-estimé.
Pourquoi Hashimoto choisit-il Zig ?
Cette question mérite à elle seule d’être développée. Ce n’est pas qu’il n’aurait pas les moyens de choisir Rust. Il a écrit Vagrant, Packer, Consul, Terraform, Vault — ces outils constituent la moitié de l’infrastructure cloud moderne. Son jugement d’ingénieur mérite d’être pris au sérieux.
La chronologie de son choix pour Zig : il commence à s’intéresser au projet Zig en 2019, exprime publiquement son enthousiasme en 2021, commence à contribuer au compilateur Zig début 2022 (sa première PR fait trois lignes, lui a pris quatre ou cinq heures), lance la même année le projet d’émulateur de terminal Ghostty — entièrement écrit en Zig. Aujourd’hui, il a des dizaines de contributions au compilateur Zig, et Ghostty est sorti en 1.0 en tant qu’organisation à but non lucratif indépendante.
Ce qui l’attire dans Zig, ce n’est pas la part de marché (loin derrière Rust), ni la maturité de l’écosystème (la bibliothèque standard évolue encore rapidement), ni le soutien corporate (quasiment aucune adoption officielle par de grandes entreprises). Ses raisons de choisir Zig sont techniques :
Pas d’allocation implicite. L’un des principes de conception de la bibliothèque standard de Zig est que toute allocation mémoire doit recevoir explicitement un paramètre d’allocateur. Aucune fonction n’appellera malloc à votre insu. Ce que cela signifie en programmation système ? Que lorsque vous écrivez un émulateur de terminal, la boucle de rendu ne déclenchera pas soudainement une pause de GC, ni une gigue parce qu’une concaténation de chaînes alloue 4 Ko de tas en arrière-plan, sous l’objectif de 60 fps. Les performances de rendu de Ghostty bénéficient directement de ce design.
L’ABI C comme citoyen de première classe. Le @cImport de Zig peut directement inclure des fichiers d’en-tête C, les binaires compilés par Zig peuvent appeler des bibliothèques C de manière transparente et être appelés par du code C. Pour un ingénieur comme Hashimoto, qui construit des systèmes de bas en haut, cette caractéristique dépasse de loin le cadre d’une simple « fonctionnalité de compatibilité » — c’est une nécessité vitale. Ghostty doit interagir profondément avec CoreGraphics de macOS, GTK de Linux, les bibliothèques de rendu de polices de chaque plateforme — toutes ces interfaces sont en C. Le traitement de l’interopérabilité C par Zig est direct : il fait du C une partie du langage, sans ajouter de couche d’abstraction FFI.
comptime. Le calcul à la compilation de Zig n’est pas un système de macros, ni de la métaprogrammation par templates, c’est un sous-ensemble du même langage qui s’exécute au moment de la compilation. Hashimoto a lui-même écrit une visite guidée des cas d’usage de comptime, montrant des scénarios réels allant du filtrage de sous-ensembles d’unions tagguées à la génération de code par compilation conditionnelle. Pour construire un émulateur de terminal multiplateforme — devant décider à la compilation, selon la plateforme cible, du backend de rendu, du chemin de traitement des polices, du mode d’intégration de la méthode de saisie — la valeur de comptime est qu’il constitue une véritable arme architecturale, bien au-delà du « sucre syntaxique ».
Derrière ces choix de conception se cache une philosophie unifiée : ne pas décider à la place du programmeur. Le système de propriété de Rust gère la sécurité mémoire pour vous, c’est sa proposition de valeur centrale. Zig ne gère rien pour vous — il vous met l’allocateur dans la main, vous expose le flux de contrôle, vous expose l’ABI. Il fait confiance à votre jugement.
Cette philosophie explique précisément pourquoi le comportement de don de Hashimoto et les politiques de la ZSF peuvent coexister malgré leurs divergences. Hashimoto utilise massivement l’IA pour écrire du code, la ZSF interdit le code généré par IA dans le dépôt principal. Les deux positions découlent de la même prémisse : être responsable de ses outils et de ce qu’on produit. Hashimoto utilise l’IA pour accélérer le développement, mais il examine chaque ligne de code produite par l’IA — il a écrit comment il utilise l’IA pour implémenter des fonctionnalités non triviales de Ghostty, en insistant précisément sur le fait que « vous devez avoir suffisamment de jugement pour vérifier la sortie de l’IA ». La ZSF interdit les contributions IA, avec la même logique de responsabilité qualité — dans un contexte où l’on ne peut pas vérifier chaque ligne de code généré par IA, refuser les contributions IA est la garantie la moins coûteuse. Aucun des deux n’a tort, tous deux prennent au sérieux la question d’« être responsable de son code ».
Revenons à la discussion Lobsters. Le commentaire le plus digne d’attention vient de kristoff — contributeur core de Zig, 63 votes, le plus upvoté. Il dit : « Mitchell est extrêmement généreux envers le projet et la communauté Zig. Mais ce qui est intéressant, c’est que son soutien financier, bien qu’impressionnant, n’est pas sa contribution la plus précieuse à Zig. »
La force de cette phrase vient de ce qu’elle émane de quelqu’un à l’intérieur du projet, pas d’un observateur extérieur. Un contributeur core d’un projet qui a reçu 700 000 $ de dons dit que « l’argent n’est pas la chose la plus précieuse qu’il nous ait donnée » — il est en train de redéfinir la valeur.
Qu’est-ce qui est plus précieux que l’argent ? kristoff ne développe pas, mais la réponse est éparpillée dans la trajectoire de Hashimoto ces dernières années : le code qu’il a soumis au compilateur Zig, sa série d’articles sur la structure interne du compilateur Zig (Tokenizer → Parser → AstGen → Sema), ses présentations techniques au Zig Showtime, la preuve qu’il a apportée avec Ghostty que Zig est viable pour des projets de niveau production. L’effet de levier de ces contributions dépasse de loin 700 000 $ — elles abaissent la barrière d’entrée pour les autres développeurs, fournissent des cas de validation dans le monde réel, attirent plus de contributeurs.
La comparaison entre la valeur de l’argent et celle du code dans l’open source n’est pas une question binaire. L’argent permet aux développeurs de travailler à plein temps, le code fait avancer le projet lui-même. La ZSF dépense 92% de son budget en rémunération directe des contributeurs — ce chiffre montre que l’argent est converti en code. Mais la conversion a pour prérequis que quelqu’un veuille écrire ce code, quelqu’un veuille le review, quelqu’un veuille être responsable de sa qualité. Hashimoto apparaît simultanément aux deux extrémités de cette chaîne de conversion.
C’est un chemin que peu empruntent. La plupart des fondateurs tech fortunés choisissent l’investissement providentiel, à la recherche de rendements financiers. Quelques-uns choisissent la philanthropie, donnant à l’éducation, la santé, le climat — autant de causes légitimes et importantes. Mais signer un chèque de 400 000 $ à la fondation d’un langage de programmation, sans exiger de siège au conseil, sans exiger d’infléchir la roadmap, sans même être complètement d’accord avec toutes les politiques de la fondation — cela dépasse le cadre de la philanthropie, c’est quelque chose de plus rare : le pur « je crois que vous faites ce qui est juste ».
L’open source a besoin de sponsoring corporate. Mais l’open source a aussi besoin de ces personnes : qui ont de l’argent, qui comprennent la technologie, qui ont du jugement sur les directions, et qui respectent l’indépendance des projets. La discussion actuelle sur la gouvernance open source se concentre presque exclusivement sur la gestion de l’influence des entreprises, mais il y a peut-être une question plus simple qui mérite l’attention : comment faire pour que davantage de personnes disposant de ressources s’impliquent, à la manière de Hashimoto.
La réponse ne viendra d’aucun cadre de gouvernance ni document de bonnes pratiques. Elle viendra de la diffusion d’une culture : des gens qui écrivent du code, qui gagnent de l’argent, puis qui regardent en arrière vers les outils et les langages qui leur ont permis d’écrire du bon code, et qui — d’égal à égal — disent : cette direction est la bonne, je veux qu’elle continue.
C’est la part la plus lourde de ces 700 000 $ : la posture derrière le chiffre.