Le mainteneur principal de Mockito quitte ses fonctions après 10 ans

• Le mainteneur principal de Mockito a annoncé qu’il mettrait fin à près de 10 ans de travail de maintenance en mars 2026, avec un transfert progressif des responsabilités prévu dans les prochains mois
• Comme l’un des déclencheurs directs de cette décision, il cite le changement de politique concernant les agents sur JVM 22 : il comprend l’objectif de sécurité de cette évolution, mais estime que l’exigence d’une transition unilatérale sans alternative et le manque de prise en compte de l’écosystème ont représenté une lourde charge
• Il explique notamment que, bien que Mockito soit l’un des plus gros utilisateurs d’agents JVM, l’absence de support des outils de build ou de discussions collaboratives l’a conduit à assumer seul la résolution du problème, ce qui a entraîné épuisement des ressources et surcharge de responsabilité
• Il souligne aussi comme autre facteur la complexité structurelle du support de Kotlin, en expliquant que certaines fonctionnalités incompatibles avec le mode de fonctionnement propre de Kotlin sur la JVM ont entraîné dans Mockito une augmentation des API dupliquées et de la logique conditionnelle, rendant la maintenance plus difficile
• Ces derniers temps, il dit trouver davantage de plaisir et de motivation dans son travail sur Servo, le moteur web en Rust, et, compte tenu de son temps personnel limité, il est arrivé à la conclusion qu’il lui est difficile de poursuivre un travail de maintenance bénévole qui ressemble à une obligation

---

Un cap de 10 ans et la décision de transmettre le rôle

• En mars 2026, il atteindra le 10e anniversaire de sa maintenance de Mockito, et considère cette échéance comme un point de bascule naturel pour transmettre la responsabilité
• Au cours des prochains mois, il prévoit de se concentrer sur le transfert des connaissances et la stabilisation de la transition en tant que mainteneur actuel
• Les discussions sur la future organisation de la maintenance et la feuille de route à long terme auront lieu dans une issue GitHub distincte

L’épuisement causé par le changement de politique sur les agents JVM

• Si, dans Mockito 5, l’artefact par défaut a été converti en agent JVM, c’est dans le contexte du changement de politique de la JVM 22 qui a relégué l’attachement dynamique d’agents derrière un flag
• Il se dit d’accord avec l’intention de sécurité de ce changement, mais critique le fait que la décision ait été imposée sans conception alternative ni aide à la migration
• Bien que Mockito ait souvent servi d’exemple pionnier pour les fonctionnalités de la JVM, aucune boucle de retour collaborative n’a véritablement fonctionné lors de ce changement
• Il estime que le manque persistant de support au niveau des outils de build pour les agents montre que cette fonctionnalité reste une faible priorité
• Il souligne que si une pression excessive est exercée sur des mainteneurs bénévoles, la structure de collaboration open source peut facilement se briser

Le poids structurel provoqué par le support de Kotlin

• Il ne remet pas en cause l’essor de Kotlin, mais explique qu’en raison des différences de fonctionnement internes sur la JVM, de nombreux flux de traitement spécifiques à Kotlin ont été ajoutés à mockito-core
• Certaines fonctionnalités de Kotlin, comme les fonctions suspend, ne fonctionnent pas de manière cohérente, ce qui accroît la duplication d’API et la complexité
• En conséquence, la base de code s’est transformée en spaghetti et la difficulté de maintenance a augmenté, et il reconnaît franchement que ce travail n’est pas agréable pour lui
• Un avenir davantage centré sur Kotlin a aussi contribué à affaiblir sa motivation à long terme pour maintenir Mockito

Retrouver du plaisir dans d’autres activités open source

• Il a contribué à de nombreux projets open source et, récemment, il retrouve le plaisir du développement grâce à son travail sur Servo, le moteur web en Rust
• Dans le choix limité de ses soirées, d’autres projets lui apportent davantage de satisfaction que Mockito de façon continue
• Il considère qu’un travail de maintenance bénévole qui finit par ressembler à une obligation sur le long terme n’est pas souhaitable

Contexte global de la décision et message transmis

• Le sentiment de lassitude causé par les changements de politique de la JVM, les limites structurelles du support de Kotlin et le regain de motivation dans d’autres projets ont constitué les facteurs clés de sa décision
• Il reconnaît que ces facteurs ne s’appliquent pas de la même manière à tous les contributeurs et que d’autres peuvent être plus enclins à investir dans le support de Kotlin
• Il a décidé de quitter son rôle en estimant qu’un changement de mainteneur serait plus bénéfique pour la santé à long terme du projet
• Il décrit son expérience de la maintenance open source comme un honneur et un privilège, et encourage aussi les autres à contribuer bénévolement