BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース Jenkins,Hudson,そして Eclipse

Jenkins,Hudson,そして Eclipse

ブックマーク

原文(投稿日:2011/05/11)へのリンク

Hudson を Eclipse 財団に移行する 先日の提案に伴って,これが Jenkins と Hudson の再統合につながるのではないか,さらにはコードライセンスの EPL への変更があり得るのではないか,などの憶測が生まれている。

今回の移行に関する発表にまったく関与できなかった Jenkins コミュニティからは,憤怒の声が多数 (コメントスレッドに見られるように) 上がっている。さらに,移行を承認する企業がいくつかある一方で, まだ CloudBees がその中に含まれていないのだ。

Eclipse 財団に移行するという案は,実は プロジェクトが分裂する 以前にもあった。しかし,プロセスがあまりにも重い,という理由で,その時は拒否されている。Jenkins が常に迅速かつ反復的な手法で開発されているのに対して,Oracle と Sonatype は定期的なリリースと,プロセスの予測可能性 (結局は Jenkins コミュニティでも同じことが起きるのだが) の確保を望んでいたのだ。

現在の状況に対する見解を CloudBees に求めたところ,Hudson/Jenkins の製作者である Kohsuke Kawaguchi,CloudBees の CEO である Sacha Labourey の両氏から回答があった。

InfoQ: 今回の Eclipse 財団への移行案について,ドメインと商標の件も含めた意見をお聞かせください。

Kohsuke Kawaguchi: とても驚きました。ブログにも書いたのですが,これはある意味で,Jenkins プロジェクト成功のひとつの形だと思っています。プロジェクトの分割問題が起きていた頃,ドメインと商標の問題は大きな論点のひとつでした。彼らは商標を他に譲渡することに対して,強硬に反対しました – 彼らがコミュニティに求めていたものを手に入れる上で,実は商標が大きく影響していたからです。私たちと議論していた時点で今回のような選択をしてくれればよかったのですが,それでもあなたが言うように,今回の移行の必要性を Oracle が認識する上で,私たちの努力は意味のあるものだったと思います。Eclipse 財団については,ベンダに中立な,非常に信頼できる組織という印象です。

InfoQ: 現在のコードは MIT ライセンスの下で,複数の個人あるいは企業が著作権を所有しています。このことが著作権所有者によるソフトウェアのライセンス変更を妨げるわけではありませんが,最近になって Hudson にマージされたコード変更については,(Oracle や Sonatype ではなく) Jenkins コミュニティがかなりの部分を所有していますね。そのような解釈で正しいでしょうか?

Kohsuke Kawaguchi: はい,私もそう思っています。

 

InfoQ: 仮に Eclipse 財団が CloudBees に対して,Hudson のコードベースを Eclipse に移行する上で,それらを EPL にライセンス変更するように主張したとします。あなた方はそれを支援しますか,あるいは意識的に参画を避けますか?

Sacha Labourey: CloudBees は Jenkins コミュニティに参加しています。コミュニティがどのような方向に進むのであれ,私たちはそれを公式にサポートするつもりです。Eclipse のライセンスよりも MIT ライセンスの方がオープンで,企業の関与も少なく,好ましいと思っていますので,そちらを選択する方がより包括的でオープンだとは思いますが,どのオープンソースライセンスであっても特に反対するつもりはありません。

InfoQ: 現時点でそうであるように,今回の提案は開始点に過ぎません。今後新たな 参加者や合流がある ことも考えられます。今のところベンダが中心で,コミュニティの参加が少ない点にも注目されます。CloudBees として,あるいはその他のメンバとして,関係者の立場で参加することに関心がありますか?

Kohsuke Kawaguchi: Jenkins コミュニティでは 5月11日 UTC 18:00 に,ミーティングJenkins IRC チャットチャネル上で行う予定です。その時,この問題に対するコミュニティの立場を確認できればと思っています。私たちは,すべての選択肢を同じように検討しています。CloudBees としては,Jenkins コミュニティの下した決定を 支援する つもりです。

 

私個人としては,"プロジェクト分割" での苦い経験がまだ記憶に新しいこともあって,少し慎重に考えています。人間関係と相互信頼で構築されたオープンソースプロジェクトにおいて,これまでにたくさんのことを行ってきました。もう一度同じ関係を築くのは難しいことです。

InfoQ: Jenkins で現在運用されているモデルと比較して,Eclipse のモデルをどう思われますか? Eclipse のプロジェクトが一般的に運用している方法に対して,明らかな違い(あるいは反対意見)があるでしょうか?

Kohsuke Kawaguchi: Eclipse のプロジェクトにはプロジェクトリーダ,PMC(プロジェクトマネジメント・コーディネータ),コミッタが存在します。一方,Jenkins プロジェクトにはガバナンスボードとコミッタがいます。このように技術的な多少の違いはありますが,プロジェクトの運営や議決体制を運用する方法にそれほど差があるとは思いません。

重要な相違点だと思うのは,Jenkins プロジェクトではコミッタシップの敷居がとても低いことです。私たちは以前から,コミッタになる上で参加頻度や自己証明といったものを求めてきませんでした。結果的にそれが多くの開発者を集め,コードベースの変更を小さく抑えることに役立ったのです。さらに私たちは,プラグイン開発者とも親密な関係を維持していて,それがコミュニティに新たな血を送り込む役割を果たしています。このアジリティこそが私たちの DNA であり,初期段階における Hudson の成功要因でもあったのです。Jenkins コミュニティが現在のように組織されているのは,バランスの取れたガバナンスを維持しながら私たちを成功に導いたこの方法を持続させるためなのです。

最後のポイントについては,Jenkins コミュニティでも議論の的になっているようだ。Eclipse 財団にはコミッタになる上での 法的ガイドライン があり,コミットアクセスの許可を受ける前に関係書類へのサインが必要となる。手続きの完了には2週間程度を要する場合もある。ただし今回の提案は Hudson のコアを Eclipse に移動するというものであって,プラグインについてはこれまでどおり別の場所 (GitHub など) にホストされる。つまりアジリティが影響するのはコアのランタイムのみで,プラグインの提供者ではないのだ。

もうひとつ重要なのは,プロジェクトのリーダーシップだ。Kohsuke がプロジェクトをリードしなければ,Jenkins コミュニティの多くの支持を得ることは叶わないだろう。しかしプロジェクトフォーラムにこの話題はなく,それが実現する可能性は見えていない。それでも Eclipse のプロセスでは,コミッタの権利としての議決権が平等であることが保証されているので,プロジェクトの分裂時のような問題が発生することはないだろう。

最終的に Eclipse 財団の1プロジェクトになるのか,あるいは独立したエンティティになるのか,いずれにしても Jenkins コミュニティは,Jenkins が Eclipse 財団の一部となることを承認するだろう。Kohsuke と CloudBees はその決定に大きな影響力を持ち,当初存在した障害の大部分は解決されることになる。その一方で,2つのプロジェクトに存在する相互不信とプロセスのインピーダンスミスマッチは,再統合を図るにはいまだ大きすぎる相違点であるように思われる。

最後に,もし Jenkins コミュニティが自身のプロセスを維持し,独立したプロジェクトとしての存続を選択したならば,EPL 組織に雇用されていない 著作権所持者の権利承諾を得ることなく Hudson が EPL に移行できるかどうか,たちまち不明確になる。現在のコードベースの中に,プロジェクト分離以後の作成コードを Hudson にマージして戻した部分が存在するのは確実なので,著作権所持者が EPL へのライセンス変更に同意しなければ,これらのコードをそのまま使用することが不可能になるかも知れない。

Jenkins コミュニティが Eclipse の提案に同意するかどうか。エンドユーザ(とプラグイン開発者)たちにとっては,2つに分岐したプロジェクトのどちらかを選択しなくてよい方が好都合なことは言うまでもない。

この記事に星をつける

おすすめ度
スタイル

BT