- Ein zentraler Maintainer von Mockito hat angekündigt, seine rund 10-jährige Maintainer-Rolle bis März 2026 zu beenden und in den kommenden Monaten eine schrittweise Übergabe der Zuständigkeiten vorzunehmen
- Als einen direkten Auslöser der Entscheidung nannte er die Änderung der Agent-Richtlinie in JVM 22. Zwar könne er die sicherheitsbedingte Änderung nachvollziehen, doch die einseitige Forderung nach einer Umstellung ohne Alternative und die mangelnde Berücksichtigung auf Ökosystem-Ebene hätten eine große Belastung dargestellt
- Insbesondere erklärte er, dass Mockito zu den größten Nutzern von JVM-Agenten gehört, die Struktur jedoch dazu geführt habe, dass man die Problemlösung ohne Unterstützung durch Build-Tools oder kollaborative Diskussionen schultern musste, was Ressourcenverschleiß und eine Überlastung durch Verantwortung nach sich zog
- Als weiteren Faktor verwies er auf die strukturelle Komplexität der Kotlin-Unterstützung und erklärte, dass Kotlin-spezifische JVM-Verhaltensweisen und nicht dazu passende Funktionen innerhalb von Mockito zu mehr doppelten APIs und verzweigter Logik geführt hätten, was die Wartung erschwere
- Zuletzt teilte er mit, dass er in letzter Zeit bei der Arbeit an der Rust-basierten Web-Engine Servo mehr Freude und Motivation empfinde und angesichts begrenzter persönlicher Zeit zu dem Schluss gekommen sei, dass es schwierig sei, freiwillige Maintainer-Arbeit fortzusetzen, die sich wie eine Pflicht anfühlt
Der Meilenstein von 10 Jahren und die Entscheidung zur Übergabe
- Mit März 2026 erreicht er das 10-jährige Jubiläum als Mockito-Maintainer und betrachtet diesen Zeitpunkt als natürlichen Wendepunkt für eine Übergabe der Verantwortung
- In den kommenden Monaten will er sich als bisheriger Maintainer auf Wissensübergabe und die Stabilisierung des Übergangs konzentrieren
- Diskussionen über das künftige Maintainer-Modell und die langfristige Roadmap sollen in einem separaten GitHub-Issue geführt werden
Erschöpfung durch die Änderung der JVM-Agent-Richtlinie
- Hintergrund dafür, dass in Mockito 5 das Standard-Artefakt auf einen JVM-Agenten umgestellt wurde, ist die Richtlinienänderung, nach der das dynamische Anhängen von Agenten ab JVM 22 hinter einem Flag versteckt wurde
- Der sicherheitsbezogenen Stoßrichtung der Änderung stimmt er zu, kritisiert wird jedoch, dass die Entscheidung ohne alternatives Design oder Migrationsunterstützung faktisch vorgegeben wurde
- Obwohl Mockito häufig als führendes Praxisbeispiel für JVM-Funktionen genutzt wurde, habe bei dieser Änderung keine kollaborative Feedback-Schleife funktioniert
- Dass es für Agenten auf Ebene der Build-Tools weiterhin nur unzureichende Unterstützung gibt, wertet er als Zeichen dafür, dass die Priorität dieser Funktion niedrig ist
- Er betont, dass die Open-Source-Kollaborationsstruktur leicht zusammenbrechen kann, wenn freiwillige Maintainer übermäßig unter Druck gesetzt werden
Die strukturelle Last durch Kotlin-Unterstützung
- Die Verbreitung von Kotlin an sich bestreitet er nicht, doch aufgrund der Unterschiede in der internen Funktionsweise der JVM seien in
mockito-core zahlreiche Kotlin-spezifische Verarbeitungswege hinzugekommen
- Bei Kotlin-Funktionen wie suspend-Funktionen gebe es Fälle, in denen sie nicht konsistent funktionieren, was zu mehr API-Duplizierung und Komplexität führe
- In der Folge sei die Codebasis spaghettiartig geworden und deutlich schwerer wartbar, und er erwähnte offen, dass ihm diese Arbeit persönlich keinen Spaß mache
- Eine stärker Kotlin-zentrierte Zukunft habe langfristig als Faktor gewirkt, der seine Motivation zur Mockito-Wartung schwächt
Wiedergewonnene Freude durch andere Open-Source-Aktivitäten
- Er hat zu zahlreichen Open-Source-Projekten beigetragen und empfindet in letzter Zeit durch die Arbeit an der Rust-basierten Web-Engine Servo wieder mehr Freude an der Entwicklung
- Bei der Auswahl begrenzter Abendstunden hätten andere Projekte als Mockito dauerhaft größere Zufriedenheit geboten
- Er kam zu dem Schluss, dass ein auf Freiwilligenarbeit basierender Maintainer-Job, der sich über längere Zeit wie eine Pflicht anfühlt, nicht wünschenswert ist
Der Gesamthintergrund der Entscheidung und die Botschaft
- Ernüchterung durch die JVM-Richtlinienänderung, die Grenzen der Struktur für Kotlin-Unterstützung und die wiedergewonnene Motivation in anderen Projekten wirkten als zentrale Faktoren der Entscheidung
- Er räumt ein, dass diese Faktoren nicht auf alle Beitragenden gleichermaßen zutreffen und dass andere die Kotlin-Unterstützung aktiver vorantreiben könnten
- Er entschied sich, die Rolle abzugeben, weil ein Wechsel im Maintainer-Team der langfristigen Gesundheit des Projekts eher zugutekommt
- Die Erfahrung als Open-Source-Maintainer selbst bezeichnete er als Ehre und Privileg und empfahl auch anderen, sich freiwillig zu engagieren
Noch keine Kommentare.