最近のJenkins会議で、Hudsonプロジェクトとの和解が可能かどうか（HudsonのEclipse.orgに移る提案が出された 後に）、そのためには何が必要か、という議論がなされた。
前回の会議 でこの話題は持ち上がり、その結果 Possible Jenkins Umbrella Foundations と Hudson/Jenkins和解要求ウィキ ページができた。
JenkinsにはHudsonと和解するつもりはなく、Eclipseファンデーションや Apache ファンデーションのような他の団体に移ることもないことは、現在のところ確実のようだ。個人的な問題を横において、Jenkinsの毎週のリリースサイクルとGitHubでのソース管理がいかなる団体への移行計画に対しても障害だろう。
Apache ファンデーションは リードオンリーのGitミラーサイトを持っているが、ソースコードのマスター管理は、まだ subversionで行っている。Eclipseのプロジェクトが{CVS,Subversion} からGitに移行するものが増えているが、ソース管理は今だに Eclipse.orgのハードウェアで行われている（ GitHubにミラーしているが）。
Jenkinsコミュニティは頑固なようで、公式なプロセスには従いたらず、特定な方法に従うことに反対票を投じている者が何人もいる（特に新しいコミッターを仲間にいれることについて）。このことは、IP関係に神経を配るのが他の団体と違う、Eclipseに加わる可能性のないことを物語っている。実際、Jenkinsと別れた後のHudsonの開発のほとんどは、コードベースから LGPL依存部を削除する ような問題に取り組んできた。このような作業はApacheあるいはEclipseファンデーションに移るには必要なステップである。LGPL依存部は全てHudsonから削除されたが、例外は XOM、XML処理ライブラリである。
Chris Aniszczykは、投稿の中で、その提案についての考えと、Eclipseではプロジェクトは頻繁にリリースできる、という Eclipseプロセスについて書いている。例えばMylynは四半期毎にリリースし、 EGit/JGitは2,3月毎にリリースしている。
GitHubに残りたい、公式の開発プロセスには従いたくない、毎週リリースしたい、という強い願望があるので、JenkinsをEclipseあるいはApacheファンデーションに移すのは難しい。実際、 Eclipse Hudson提案に同意するような興味のあるコメントは、Jenkins（すなわち CloudBees）の誰からも無い。しかしHudsonがEclipseで成功することを望まない多くのコメンテーターがいる。
このことが今の両プロジェクトにどう影響しているだろうか？ もしOracleがそもそも、もっと速く移すことができたなら、おそらく分岐は現在のようには起きていなかっただろう。しかし、2つのプロジェクトは、それぞれの分岐後の道を歩み続けるだろう。JenkinsがHudsonよりずっと頻繁にリリースしているのは事実であり、両グループは、双方のリリース頻度の計画はエンドユーザーにとって、もっと有益である、と話している。
皮肉にも、JenkinsがEclipseに移ることに反対する意見の一つは、 EGit/JGitをEclipseへ移した、 Shawn Pearce氏の最初の経験を参考にしている（ Eclipse.orgの悲劇、Eclipse.org JGitの愚かさは続いている）。これらは文書化の観点からEclipseにおけるIPプロセスのある部分に対する失望を物語っている。しかし、Eclipseへ移ってから、JGitは1500以上のコミットがあり、EGitは2009年の9月末以来1800以上のコミットがあった。EGit/JGit 1.0 リリースが2,3週間後にあるが、 EGit とJGitが新しい家で萎んでしまっている、と言う人間はいない。
次のJenkins会議は来週の予定だが、おそらく現状維持で、ファンデーションを移ることもなく、毎週リリースを続けるだろう。