In March 2026, I will be Mockito maintainer for 10 years (nearly a third of my whole life). Looking ahead, I decided that a decade milestone is a good moment to pass on maintainership to other folks. In the coming months until March, I will spend time ensuring a smooth transition in maintainership.
In this issue I list several considerations why I made the decision. Communication and discussion of plans for future maintainership will be somewhere else, most likely in a separate GitHub issue. Stay tuned for that.
Energy drain because of JVM agent change
As you might know, Mockito 5 shipped a breaking change where its main artifact is now an agent. That's because starting JVM 22, the previous so-called "dynamic attachment of agents" is put behind a flag. This change makes sense from a security point-of-view and I support it.
However, the way this was put forward to Mockito maintainers was energy draining to say the least. Mockito is probably the biggest user of such an agent and is often looked at for inspiration by other projects. As such, Mockito often pioneers on supporting JVM features, built on a solid foundation with ByteBuddy. Modules was such a feature that took months of hard work by Rafael to figure out, including providing feedback to JVM maintainers.
Unfortunately such a collaborative way of working was not the case when discussing agents. To me, it felt like the feature was presented as a done deal because of security. While dynamic attachment is problematic in many ways, no alternative solutions were proposed. That's okay, as Mockito pioneers on these solutions, yet in this case I felt we were left alone.
My personal take is that folks involved with the change severely underestimated the societal impact that it had. The fact that proper build support is non-existent to this day shows that agents are not a priority. That's okay if it isn't a priority, but when it was communicated with Mockito I perceived it as "Mockito is holding the JVM ecosystem back by using dynamic attachment, please switch immediately and figure it out on your own".
Here, the fact that I (and others) are volunteers doing their best for the project, is important to understand the societal impact. When you put individuals under pressure, who do this work in their own time out of goodwill, things crumble. It's commonly joked about with XKCD's on the fact that the whole open source world relies on a couple of individuals. That couldn't be more true in this situation, where the collaborative system collapses when too much pressure is put on individual folks.
This saga planted the seed to reconsider my position as maintainer.
Kotlin as the future and odd one out
It's undeniable that Kotlin as a language has grown in popularity in recent years. While Mockito maintains several flavors for JVM languages, these packages typically include sugar that makes integration nicer. In all cases, mockito-core remains the place where functionality is implemented.
Unfortunately, this model doesn't nicely apply to Kotlin. Where almost all JVM languages work similarly under the hood, Kotlin often does things differently. This means that in several places in mockito-core, there are separate flows dedicated to Kotlin. Most often that's a direct result of Kotlin doing (in my opinion) shenanigans on the JVM that the JVM never intended to support, yet was able to.
Even within Kotlin itself, features don't work consistently. Suspend functions are the most well-known example. As such, Mockito code becomes more spaghetti, it's API sometimes fully duplicated just to support a core Kotlin language feature and overall less maintainable.
While I fully understand the reasons that developers enjoy the feature richness of Kotlin as a programming language, its underlying implementation has significant downsides for projects like Mockito. Quite frankly, it's not fun to deal with.
To me, a future where Kotlin becomes more predominant is not a future that makes me hopeful I can keep on dedicating energy to Mockito.
Alternative open source activities
I have always been a fan of open source work and have contributed to hundreds of projects in all these years. Mockito is my most important project, but I have also consistently worked on others. In recent months, I have rediscovered the joy of programming by working on Servo. It's a web engine written in Rust.
When I need to choose how I want to spend my 2 hours of evening time in a given week, I rarely preferred Mockito in the last year. In the past, Mockito was my go-to and I enjoyed it a lot. Nowadays, Servo and related projects provide significantly more enjoyment.
Justifying why I needed to work on Mockito becomes difficult when (because of the above reasons) it feels like a chore. Volunteering work shouldn't feel like a chore, at least not for a long time.
Summing it up
As you have read, these three factors combined led me to the decision. The first point explains why I started to doubt my position, the second point why I am not hopeful for things to change in a good way and the third point how I found enjoyment in a different way.
While these points had impact on me as maintainer, my hypothesis is that it doesn't apply to others in the same way. I know others are eager to work on Kotlin support for example. That's why I concluded that a decade is enough time to have helped Mockito forward. Now it's time for somebody else to take over, as I believe that's in the best interest of Mockito as a project. Because ultimately that's why I chose to become maintainer in the first place: I believed that with my work, I could improve Mockito for millions of software engineers.
For those wondering: yes I wholeheartedly advise everyone to take on a volunteering task such as maintaining an open source project. It was an honour and privilege to do so and I thank those that I enjoyed working with.