L’un des défis les plus difficiles pour un mainteneur de projet open source est de dire non à une bonne idée. Un utilisateur propose une fonctionnalité bien conçue, utile et sans faille technique, et pourtant la réponse est « non ». Pour l’utilisateur, cela peut sembler incompréhensible. Pour le mainteneur, c’est une nécessité de gouvernance. Après avoir créé et entretenu deux projets open source très réussis — Prefect et FastMCP — et contribué à l’établissement d’un troisième dans Apache Airflow, j’ai compris que cette gouvernance est véritablement le cœur du travail. Le succès d’un projet ne se mesure pas au nombre de fonctionnalités ajoutées, mais à la cohérence de sa vision et à sa capacité à résonner avec ses utilisateurs. Comme le souligne Chris White, CTO de Prefect : « Les gens choisissent un logiciel quand ses abstractions correspondent à leur modèle mental. » Le rôle du mainteneur est donc d’établir ce modèle mental, puis de construire un logiciel qui l’incarne fidèlement. Une fonctionnalité utile mais déconnectée de cette vision peut être aussi nuisible qu’un ajout bénéfique. Face à l’expansion du projet, cette défense de l’âme du logiciel commence par une documentation claire non seulement de comment le projet fonctionne, mais surtout de pourquoi il existe. Des guides pour développeurs et des déclarations de but définissent la philosophie du projet, fixent les attentes dès le départ. Cela crée un effet de levier puissant : plus le projet est clair sur sa raison d’être, plus il attire des contributeurs partageant cette vision. Leurs contributions renforcent et affinent cette vision, qui justifie à son tour le cadre du projet. Le processus devient alors un outil d’alignement, pas une bureaucratie. Le mainteneur peut alors défendre le dépôt avec confiance, sachant que la charge de la preuve incombe à la proposition de contribution, non au projet. Ce travail s’est considérablement compliqué avec l’essor des modèles de langage (LLM). Autrefois, écrire du code était coûteux, ce qui incitait les contributeurs à discuter avant de coder. Aujourd’hui, le code est abondant, bon marché, et souvent généré sans contexte. On reçoit des PR complètes, bien écrites, mais sans discussion préalable, sans compréhension de la philosophie du projet. Leur objectif était de satisfaire une demande, pas de servir une vision. Ce n’est pas une critique de toutes les contributions. Les PR spontanées, bien alignées, sont une joie. Mais la balance a changé : le ratio signal-bruit s’est dégradé, et les contributions non sollicitées sont désormais plus souvent des efforts de haute intensité pour peu de valeur réelle. Dans FastMCP, nous avons tenté de corriger cela en exigeant une issue pour chaque PR. Mais cela a eu un effet pervers : des issues d’une seule phrase créées juste avant la PR. Plus efficace que les règles procédurales est une phrase simple : « Nous ne sommes pas convaincus que le cadre devrait assumer cette responsabilité. » Si un contributeur veut nous convaincre, c’est un effort qui profite à tous. La charge de la preuve reste toujours sur le contributeur. Un autre défi est la durabilité. Un mainteneur peut ne pas être prêt à assumer à long terme la maintenance d’une fonctionnalité. Chaque PR fusionnée transfère une responsabilité importante. Si elle introduit des bugs, des incohérences ou des demandes supplémentaires, c’est souvent le mainteneur qui doit répondre. Pour y faire face, FastMCP a mis en place un module contrib : des fonctionnalités utiles mais non intégrées au cœur du projet, maintenues par leurs auteurs. Aucune garantie n’est donnée pour la compatibilité future. Beaucoup de ces modules auraient plus de succès en tant que projets autonomes, mais c’est une manière de favoriser la collaboration tout en préservant la cohérence du cœur du projet. Je regrette de constater que mon propre comportement a changé : autrefois, nous répondions en 15 minutes aux questions. Aujourd’hui, si une demande est vague ou générée par un LLM, je me retrouve à adopter ce même niveau de faible engagement. Entre un mur de texte généré par IA et une question claire avec un exemple minimal, je choisis toujours le second. Cela décrit une approche artisanale, réfléchie, qui peut sembler étrange dans un monde de « vibe coding » et de commits à l’aveugle. Pourtant, dans mon parcours, c’est cette rigueur qui a fait la différence entre un projet utile et un grand projet. Ce n’était pas seulement « la communauté » — c’était une gouvernance attentive. J’espère qu’elle ne disparaîtra pas. Il y a deux semaines, j’ai assisté à des réunions du comité MCP à New York. J’ai vu une équipe naviguer avec intelligence ce même dilemme. MCP, un protocole jeune, est sous pression constante pour faire plus, être plus, tout résoudre. Pourtant, ce qui m’a le plus marqué, c’est la volonté de débattre, d’évaluer chaque proposition selon une vision partagée de ce que le protocole devrait être — et surtout, de ce qu’il ne devrait pas être. David répétait souvent : « C’est une bonne idée. Mais est-ce ce qu’un protocole devrait faire ? » Tenir ferme comme cela, c’est le travail difficile, nécessaire, de maturité technologique fondée sur une rigueur philosophique. Je suis reparti plus confiant que jamais en ce comité et en MCP, précisément parce qu’ils comprennent que leur rôle n’est pas seulement de construire, mais d’être des gardiens réfléchis. C’était une émotion forte de voir ce stewardship en action, et j’espère le voir s’étendre davantage dans l’open source.