リリーススケジュールの問題では？
「期日通りのリリース」を選ぶか「期日は遅れるがいくつかバグが少ないリリース」を選ぶか、だ。 期日通りのリリースには社会的信用を勝ちえるというメリットがある。 一方、バグにはその存在自身に社会的信用を失わせる働きがある。
もちろん「期日通りにバグのないリリース」がもっとも良いのだが、 なかなかそれは実現しない。かならずどちらかを選ばなければならないとしたら？
Mac OS X への収録の話は別にしても(リリース日の決定に外的な要因が無いという前提で)、単純にリリーススケジュールの立て方がまずいだけという話ではないの？リリースが2週間遅れるくらいなら、最初から2週間遅いリリース日のほうがいいのは言うまでもないと思うのだが。最終 RC と変化がない stable リリースってちらほら見るしさ(いや、そんなに多くはないけど)、それくらいのスケジュールでやればいいんじゃなかろうか。コードが1週間変化せずに stable になったっていいんじゃないかと。
まぁ、メンテナが複数でボランティアベースの OSS では、メンテナの本業が忙しくなって反応が悪くなるとかあるので、見積もりが難しそうではあるが。
追記
Matzことまつもとさんからコメントを頂いた。
まつもと 『Rubyはメンテナが数十人を越えますし、正直どうやってスケジュール立てても絶対に狂いますね。全員が「この日にリリースすべし」っていうモチベーションを持つことさえ難しい。中には結局連絡付かない人もいるし。
全部私が面倒見れるなら、話はずっとずっと簡単なんですけどねえ。』 (2006/09/09 01:20)まつもと 『あ、そうそう。それに、リリースしようとして「もうすぐリリースなんだけど」って宣言すると、思い出したように「そういえばこういうバグがあったんだよ」って人が結構いるんですよ。
もっと早く言ってくれよーって感じ。まあ、愚痴ばかりなんでもう止めますね。』 (2006/09/09 01:22)
「どうやってスケジュールたてても絶対に狂いますね」ってようするに遠隔地で何十人もの人間をマネジメントしてスケジュールどおり進められるわけないという話だと思うのだけど、まぁ、それも一理あるよなぁ。モチベーション自体もリリース日までの期限に左右されるのは明白なので、リリースを単純に後ろにずらせばいいという話でもないし。
で、だったら alpha, beta, RC*1まで早くからロードマップにのせて stable 以下のリリースも細かい区切りにしてやれば有る程度のモチベーションが保てないかなぁ。2つ目のコメントにあるような事例も若干減りそうな気がする。
あれ、そういや Ruby って issue tracking してないんだっけ？ruby-devとか読んでないから良くわかんないんだけど。とりあえず trac とか入れておけば多少は早めのバグ報告が増えるのかな。ま、バグ報告って結構面倒だから気づいてもしてくれない人とか多そうだし、あと再現条件がわからないと報告しない人とかも多そう(バグかどうか自体判断しにくいし)。実際、知人の某氏はバグに気づいて放置してたし。
