Jenkins 1.397がこの週末にリリースされたが、Sonatypeは、自分達のユーザーにHudoson支持を表明した。元々 Java.netでホストされており、Kenaiの移行問題がGitHub へコミュニティ（とデータベース）を移そうという、最初の動きに拍車をかけ、結局、Hudsonから Jenkinsに名称変更と分岐をもたらすことになった。
分裂後、Oracleは、以前のように、Oracle/Java インフラ上で、Hudsonを継続する ことをアナウンスした。Hudsonをベースにした 商用製品 を持つSonatypeは、その隙間を埋めるように入り込んできて、HudosonのMarven化をベースにした 変更に力を注いできた。
Sonatypeには、組織的に、成長したプロジェクトを転換した経験がある。Maven 3は、昨年のInfoQで記事になったように、依存性注入のフレームワーク（Guice)上に作られた、多くのテストとリファクタリングの作業結果である。同じ計画がHudsonの移行にも適用されるだろう。それは、もっと強力であり、WAR中に一緒になっている依存しあったライブラリを分岐する。依存性の仕組みを近代化することにより、Sonatypeは、開発者が将来、貢献するのが、より簡単になることを望んでいる。Hudson-JSR330 GitHub フォークは、分裂以前にSonatypeがやった成果を含んでおり、今、その進化のコースに従って公開された。
さて、Hudsonの将来は、再びGitHubに戻ったようである。それは、Jason van Zyl 氏が hudson-devの投票の結果をツイートした後のことである。それ以前に彼は、OracleのTed FarrellとWinston Prakash の両氏からその変更の承認を得ていた。Hudsonの名前は、github.com/hudson にある。Jenkinsに名称変更したことで、Hudsonという名前は、完全に自由になったからである。
Hudsonの開発の後で、OracleとSonatypeの両社が有料のサポートをするので、その将来は、名祖の継続的統合ツールにとって明るいように見える。しかしJenkinsもまた引き続き進歩しているので、時間と共に両社は、離れていくだろう。皮肉にも、Hudsonは、名前はそのままだが、JSR-330をサポートをするためのリファクタリングとビルド プロセスのMaven化は、継続的に、漸増的に進化しているJenkinsに比べて、はるかに大きな変化を見せている。