「javacとHotSpot JVMがオープンソース化」記事へのコメント

基盤ができた、と

[kicchy (4711)]

前向きに考えると、

オープンソースにするとき、怖いのが
ちょっとした改変の派生バージョンが沢山できてしまい
開発リソースが分かれて、結局全体の開発スピードが
落ちてしまうこととか、ユーザも分かれてしまって
Javaで開発する側も、それぞれのJVM毎の対応を迫られたりしてしまうことだと思うんです。

そうならないためには、オープンソースにしたとしても
中心的なJVMとして、派生JVMを振り切って先頭を走って
開発し続けて、デファクトスタンダードの地位を
キープし続けないとダメだと思う。

今回、Mustang [java.net]開発で培ったコミュニティとの接点と
開発サイクルで、その自信が付いたから
オープンソース化することにしたんじゃないかなぁ。
タイミングとしてはそんな印象を受けます。

forkってそんなにマズイこと？

[bero (5057)]

forkってそんなにマズイこと？実はしょっちゅうおこってんじゃないの？
1 仮fork(俺fork)
2 しばらくunofficial版/patchとして公開
3 本家に投げる
4a 本家に入る
-> fork終了(して本家追っかけ)
-> branchとして継続して定期的に本家と同期 -> 全部入ったらfork終了
4b 本家に入らない
-> マジfork
という流れかと。
「本家に入らない」のは、方針の違いだったり投げ方が悪かったりすることもあるけど、単にレスポンスが悪いだけのことも。

たとえばlinux kernelなんかCPU/archの数だけforkがある（あった）んじゃないの？
キモはforkじゃなくて

fork がマズイ場合、マズクない場合

[Anonymous Coward]

fork する事により、ある種の規格互換性が失われて、それが利用者世界で大きな不都合となる場合はマズイって事で。 Sunが（表向きに）発言している理由ですよね。

forkっていうか、特殊ケースだけど。
Bugzilla-ja はオリジナル Bugzilla を日本語対応させたコードだけど、本家で運用している Bugizlla は多言語で運用してはいないので（多言語で議論交わす訳にはいかないｗ）本家へ patch を返すような事はしてないんじゃないかな。 本家で利用される可能性は少ないし、patchマージ＆以後の維持を本家に背負わせるコスト（Bugzillaメンテナが多言語に精通しているとは限らないし）、patch 投げるコスト、色々考えると毎回日本語化の枝を生やすのも選択肢としてはアリかなぁと。

個別の事情によって、あらゆる面でfork が最適解というのはありえるかなぁと。

Re:fork がマズイ場合、マズクない場合

[bero (5057)]

bugzilla-jaはよく知らなかったのでちょいと調べてみたんですが
特殊ケースではなく、むしろ非常によくあるパターンだと思います。

fork(*1)
  l10nなlocal fork
  仮に本家に投げてもlocal杉なので蹴られる
  そのうち死亡

本家にi18n入る（または入れる）

fork(*1)はステてfork(*2)して作り直し
「オマイラはutf8にしさえすればi18nと思っとんのか！」と文句言いながらja修正(*3)
fork(*2)版をユーザに使ってもらってja部分のバグ出し　← 今ここ
本家に投げる
ja開発者は独自メンテしなくてよくなってハッピー
本家でCJKのCK部分ができる(*3でちゃんとやってれば不要かも）
jaだけでなくCJK全部の利用者が使えてハッピー

fork(*1)を独自メンテするのは短期的にはquick hackでとりあえず動かすのに有効ですが（イニシャルコストが低い）、本家追随ｘバージョンアップが毎回かかる（ランニングコストが高い）ので長期的には死亡パターンかと（本家の開発が止まってたら別ですが）。