2025/12/29 5:14
ミトロリ―（Mockito）のメンテナとして10年後に退任します
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
著者は、10年間にわたるMockitoの長期メンテナとしての任務を辞める意向を表明し、2026年3月に引き継ぎが予定されていると述べています。彼は主に三つの懸念点を挙げています：
- JVMエージェントへの急激な移行（Mockito 5で実装された変更は協議もなく、代替案も提示されず）によるエネルギー消耗。
- Kotlinとの非互換性—特にsuspend関数に関連する問題が重複APIやスパゲッティコードを生み出し、Mockitoのアーキテクチャと整合しない点。
- 彼自身の興味がServoなど他のオープンソースプロジェクトへ移りつつあること。
著者は、志願者が十分なサポートなしに圧力を感じる中で、Mockitoのメンテナンスが楽しみよりも「やらなければならない仕事」になっていると指摘しています。プロジェクトは新しいメンテナーによる方が最善だと考えており、他者にオープンソースの役割へ参加するよう奨励し、その名誉と特権を強調しています。
（元文を保持したい場合）
著者は10年後にMockitoのメンテナとして退任すると発表し、2026年3月に移行が予定されていると述べています。彼はこの決定を、最近の変更—特にMockito 5でのJVMエージェントへの切替えや人気が高まるKotlinとの統合困難—による疲労感の増大に結び付けています。これらの変化は複雑さを増し、APIの重複を生じさせ、メンテナンスを楽しい活動よりも「やらなければならない仕事」に感じさせました。また、彼自身の関心がServoなど他のプロジェクトへ移っていることも述べており、これがハンドオーバーへの動機付けとなっています。著者は新たな志願者にメンテナシップを担ってもらうことで、Mockitoが新しいリーダーシップの下で進化し続けることを促しています。この変更は、新しい視点をもたらし、Kotlin統合問題を解決する可能性があり、オープンソースコミュニティにおける堅牢な志願者支援の必要性を強調すると期待されています。
本文
2026年3月に、私はMockitoのメンテナとして10年間（私の人生のほぼ三分の一）を務めることになります。
将来を見据えて、この10年という節目が、他の方々にメンテナシップを譲る良いタイミングだと判断しました。今後数か月は、3月までの間にスムーズな移行を確実にするために時間を割く予定です。
この問題では、私がその決断に至った理由をいくつか挙げます。将来のメンテナシップについてのコミュニケーションと議論は別途（恐らく別のGitHubイシュ）で行う予定ですので、そちらもご期待ください。
JVMエージェント変更によるエネルギー消耗
ご存知かもしれませんが、Mockito 5では主要アーティファクトがエージェントとなる破壊的な変更が導入されました。JVM 22以降は「動的エージェントの添付」がフラグで制御されるようになりました。この変更はセキュリティ面から理にかなっており、私はそれを支持しています。
しかし、Mockitoメンテナへの提示方法が非常にエネルギーを消耗させました。
Mockitoはそのようなエージェントの最大ユーザーであり、他プロジェクトからもインスピレーション源として注目されています。そのため、ByteBuddy上に構築された堅牢な基盤を持つJVM機能への先駆的取り組みが行われています。modules 機能はRafael が数か月の労力で解明し、JVMメンテナへフィードバックを提供するまでに至りました。
残念ながら、この協働的なアプローチはエージェントに関しては適用されませんでした。機能が「セキュリティ上完了」と見做され、代替案の提示はありませんでした。これ自体は問題ないことです—Mockito はその解決策を先駆けているので。しかしこのケースでは、私たちは一人で放置されたように感じました。
個人的には、この変更に関わった者が社会的影響を過小評価していたと考えています。現在も構築サポートが不十分なことは、エージェントが優先事項ではないことを示しています。Mockito に対するコミュニケーションで私は「Mockito が動的添付により JVM エコシステムを遅らせているので、すぐに切り替えて自分たちで解決しろ」という印象を受けました。
この一連の出来事が、私のメンテナとしての立場を再考する種となりました。
Kotlin が未来であり、外れ値になる理由
Kotlin の人気は増大しています。Mockito は JVM 言語向けに複数のフレーバーを維持しており、それらは統合を楽にする糖衣構文を含むことが多いです。しかしすべての場合で mockito-core が実際の機能実装場所です。
残念ながら、このモデルは Kotlin に対してきれいに適用できません。ほぼすべての JVM 言語は同じ仕組みで動作しますが、Kotlin は多くの場合異なる手法を取ります。その結果、mockito-core 内の複数箇所で Kotlin 専用フローが存在し、これは私見では「JVM がサポートするつもりのない奇妙な振る舞い」に起因します。
Kotlin 自体でも機能が一貫して動作しません。最も有名なのは suspend 関数です。そのため Mockito コードはスパゲッティ化し、API が完全に重複するケースもあり、全体としてメンテナンス性が低下します。
開発者が Kotlin の機能豊富さを楽しむ理由は理解できますが、その実装上の欠点は Mockito のようなプロジェクトには大きなデメリットです。率直に言えば、対処するのは楽しくありません。Kotlin がより主流になる未来でも、私は Mockito にエネルギーを注ぎ続ける自信が持てません。
代替オープンソース活動
私は長年オープンソース作業に情熱を注いできました。数百のプロジェクトへ貢献してきた中で、Mockito は最も重要なプロジェクトでしたが、他のプロジェクトにも継続的に取り組んできました。最近では Rust で書かれたウェブエンジン Servo に再び取り組むことでプログラミングの喜びを再発見しました。
週末の夕方に二時間を割くとき、私はもうほとんど Mockito を優先しませんでした。以前は Mockito が第一選択で楽しく作業できていましたが、現在では Servo や関連プロジェクトの方が大いに楽しさを提供しています。
Mockito に取り組む必要性を正当化するのが難しくなっています。それが義務感になってしまうと、ボランティア活動は長期間続けられません。
まとめ
これら三つの要因が重なり、私は決断に至りました。最初のポイントは自分の立場への疑念を生じさせ、二番目は改善が見込めないことを示し、三番目は別の喜びを見出したことを説明しています。
これらの点は私個人にしか当てはまらず、他のメンテナには同様ではありません。たとえば Kotlin サポートに熱心な方々もいます。そのため、10年という期間で Mockito を前進させる十分な時間があったと結論づけました。今こそ別の人に引き継ぐべきだと思っています。
結局のところ、私は最初にメンテナになった理由は「自分の仕事で数百万のソフトウェアエンジニアのために Mockito を改善できると信じていた」からです。
質問がある方へ：はい、心からオープンソースプロジェクトを維持するようなボランティアタスクを引き受けることを勧めます。これまで一緒に働いてきたすべての人に感謝し、名誉と特権でした。