リリースは政治パフォーマンス? 164
ストーリー by mhatta
昔々あるところにリリース延期を繰り返していたディストロがありました 部門より
昔々あるところにリリース延期を繰り返していたディストロがありました 部門より
Anonymous Coward曰く、"オープンソースだと特にそうだが、ソフトウェア開発の現場の近いところ
にいるとリリース作業を行うことが面倒くさく感じられてしまうもの。
CVS(SVN)から拾え、と言いたくなる時もあることだろうが、
Matz氏がふとRuby 1.8.5でのリリースエンジニアリングに関して
遅れても困る人はいないという言葉も含めたことからちょっとした
議論になっている。
これに反応したのは、mputの日記の
リリースは政治パフォーマンスなんだよという項目だが、
ここではリリースを
「技術革新だけではどうにも解決できない儀式的・政治的要件から
行われているのである」とし、現代では
「儀式的な傾向はより先鋭化していると感じるし、儀式としての
リリースがつつがなく執り行われるという事自体の重要性が増していると
思う」ということであり、リリースが遅れることは
社会的信用が目減りすることとしている。
これに対して、
Matz氏の反論では
「「期日通りのリリース」を選ぶか「期日は遅れるがいくつかバグが少ないリ
リース」を選ぶか、だ。期日通りのリリースには社会的信用を勝ちえるという
メリットがある。一方、バグにはその存在自身に社会的信用を失わせる働きが
ある。」として、Matz氏としては後者の方を重視するとのことことだ。
リリースのタイミングは難しいものだが、妥協点?はどこかにあるのだろうか?"
要約すると (スコア:4, すばらしい洞察)
ってトコですね
両者のブログに目を通したけど。 (スコア:4, すばらしい洞察)
rubyもかなり成熟しているようだし、今回のリリースを、
「ただ使うだけ」のユーザが待ち焦がれているとはちょっと
想像し難い。
そうでないユーザはsnapshot版などでなんとかしてきた筈。
つまるところ、リリース日を死守する意味合いは、この場合
あまり見えない。
つーことで、mput氏の意見に分がないように感じられる。
mput氏の日記 [mput.dip.jp]も(スコア:-1, 慇懃無礼)だし。
> はぁ。Ruby 1.8.0 のリリースから何も
> 学ばれなかったようで慶賀の至りです。
期日より頻度? (スコア:3, 参考になる)
新リリース予定の機能はあらかじめ知っていても、リリース日は
スラドで取り上げられてからリリースを知るなんて人も多いきがする。
無論、新機能がxx日に使えるようになるから、それにあわせて開発プロジェクトを...
っていう、つんだプロジェクトで働いている人は別だけど。。
まぁ、陳腐化しない頻度でちゃんとリリースされてれば良いかなって思う。
その頻度も難しいという話もあるけれど、、
#仕事で新発売のチップのリリース日をあてこんで失敗したのは内緒。
だめなものをリリースされても困る。 (スコア:3, 興味深い)
もう、表題そのままですが。
ある程度ならリリースの遅延はかまわないと思います。はい、ある程度にならね。
それにしても今回はmputさんの感情的な文章のほうが、より問題なのでは? 彼、ことばづかいだけで読者に相当マイナスの印象をあたえてしまって、損しちゃってるいるように見えます。あえて子供臭い言いまわしを用いて炎上させて、訴求力を得ようとしたのかしら。
としたら、スラドにピックアップされて見事目的達成。なんだか、私は、個人的に残念ですが。
Re:だめなものをリリースされても困る。 (スコア:4, 興味深い)
今回の件に限れば、Matzだってパーフェクト超人じゃないんだから、苦手なものだってあるよ。彼がリリースエンジニアリングが苦手なことを認めた上で、誰かが補佐してあげるとかもっと前向きな方向に議論が進んで欲しいなぁ。
Re:だめなものをリリースされても困る。 (スコア:1)
Matz以外にもザクザク仕事できちゃうひとたちが現われる、とか。いや、いまでも結構いるよね。
Matzだけにやる気燃料(例;根拠無いけど「あんみつ」「大福餅」)とかを投下しても限界っつーもんがあるわけで、Matz本人以外の有志のやる気、も大事。
とはいえ、もちろんMatz本人にやる気は常人の100倍以上あるでしょうけれど。なんてったって自分が作りはじめた言語なんだし。
しかし、会社全体でRubyの発展に社会人として責任をもって寄与しつつ、それを自分の会社の業務にFeedBackできる会社が現れる。というのは、夢、だ、ね。(他の言語だと実例があったりするのかしら)
慣習? (スコア:3, 興味深い)
期日を切らないと出来ない、というのはどこから出た発想なのでしょうか?
Re:慣習? (スコア:1, 参考になる)
リリース期日を決めても何の問題も無いと思うのだが。それを目処が立っていないのにも関わらず
期日をアナウンスするということをやっちゃってるのが問題なんでしょう。
市販品だとそれ売って食わないとならないから、期日ありきで逆算して物を作るというのはありがちだけどさ。
Re:慣習? (スコア:1)
セルフ船頭多くして船が雲にでも乗りましょうや。
ソフトウェアの生い立ちによる貴賎の話はまた別の機会に…
本件とはたぶん関係ないですが (スコア:3, おもしろおかしい)
Re:本件とはたぶん関係ないですが (スコア:1, おもしろおかしい)
# それは仕様です、とか
論点違う気がする (スコア:3, 興味深い)
「マトモになるまではある程度納期が当初の約定より遅れても仕方ない」
というのは、要するに当初の見積もりが甘かったという事でしょう。
開発側が納品先への言い訳にしてはならない筈。
バグのある状態で出荷するよりマシと開き直るなど、
論点のすりかえに過ぎず、もっての外ではないでしょか。
まず素直に当初の納期設定の甘さを認め、それについてちゃんと
誠心誠意謝罪してから対応策として語るのが筋かと。事象を一般論化して誤魔化すなど、
責任ある態度とは思えません。
#とりあえずタレコミ見て「6年のノウハウがあります大丈夫です心配要りません」
#とかいいつつ開始当初から大コケし、結局1ヶ月有償ベータサービスになってしまっている
#どこかのMORPGとかが頭に浮びました。
Re:論点違う気がする (スコア:2, すばらしい洞察)
その混同が「論点が違う」の「違う」点そのものなんじゃなかろうかとも思う。
# もう一つの問題は「自称お客様」が一杯居るって事だな。こんなに居るとは思わなんだ。
まったく「乙>matzさめ」だなー。
Windowsユーザーにとっては (スコア:3, 興味深い)
UNIXなどの場合は「リリースされたソースコードをコンパイルして使うのなら、SVNとかから取ってきた方を使っても手間はほとんど同じでは?」という考え方もできますが、Windowsのように「バイナリでのソフトウェア配布が常識」の場合では、バイナリ リリースがないとユーザーを減少させる事になりかねません。
Re:Windowsユーザーにとっては (スコア:2, 参考になる)
・リリース予定の1ヶ月程前には「コードフリーズ」といって、新機能追加を止め、デバッグ中心の期間を設ける
・リリース版は最低何時までセキュリティ対応を行なうかが明示される
ある程度定期的にこのリリースサイクルを回す事により、安定性向上とバージョンアップ時期の予定を立て易くする効果があります。
参考:http://sel.ist.osaka-u.ac.jp/~lab-db/betuzuri/archive/421/421.pdf [osaka-u.ac.jp]
ちなみに、このリリースではアプリケーションの管理システムであるportsのフリーズも行なわれ、バイナリ版であるpackagesの作成も行なわれます。
これを技術的に必要とみるか、開発工程の政治的理由とみるかってのはありますけど。
リリースエンジニアリング (スコア:3, 興味深い)
matz日記から [rubyist.net]
ツールに頼るまえに、まずはプロセスを見直すのがよろし。明確な目標もなく明快な計画もない。チームの誰も知らない。
そんなんじゃ遭難するのがオチですな。
宿題と同じ (スコア:2, おもしろおかしい)
//ええ、私がそうです
Re:宿題と同じ (スコア:2, おもしろおかしい)
俺:いつもと同様に、提出の目標と期日は、前もっては決められていません。
要するに、「宿題は提出されるときに提出される」のです。
参考URL
http://www.debian.org/releases/etch/ [debian.org]
1を聞いて0を知れ!
いにしえの習わしに従い~♪ (スコア:2, おもしろおかしい)
Oracle,Oracle~!
#ごめんなさい、ゴメンナサイ、ゴメンナサイ!
とりあえず (スコア:2, おもしろおかしい)
「がんばれ!アドミンくん」置いときますね。
PHP (スコア:2, 興味深い)
-- gonta --
"May Macintosh be with you"
リリースの種別 (スコア:2, 参考になる)
信頼できるマイルストーン(stable)
最新の機能の提供(betaもしくはdeveloper,unstable)
定期リリース(nightly,weekly,monthly)
機能は入るが、互換性があるもの(あえていえばfeature?)
互換性がある程度あるいは完全に無くなる直前(同上でsplit?)
問題点とくにセキュリティや危険な動作の修正(bugfix)
どこまでやるかによるでしょうが、ユーザー層によって必要なレベルが違う気がする。
ただ日時を守るのは定期リリースでしかないし、機能提供で不安定はstableじゃない。
でも非互換が出たらそこまでで区切ってリリースも必要だけど。
bugfixを指して新リリースも違う気がする。
でも、なあなあになるといけないからstable目標日時はあるべきだし。
次のリリースはどんなもので、目標の内どれだけを達成したらリリースするかが明確だったらいいんだけども。
# 普通に必要なのはstable + bugfixだと思うので、
# 自信が持てないならbeta + bugfixのバックポートにするほうがよい気がする。
## いやまあ、大変なのはわかるんですが
でもこれはただの愚痴になっちゃうか。
# ここでWindowsのSPを話しに入れると、フレームかなぁ...
M-FalconSky (暑いか寒い)
オープンソースビジネス (スコア:2, すばらしい洞察)
実際にコードを書いているプログラマーであるMatz氏が、品質の方を重視するのはそりゃ当然の話であって、RubyがMatz氏のものである限り、最終的にMatz氏の意見が通ってしまうのはどうしようもありません。
ここで、RubyがMatz氏のものであるのは何故か?という事を考えてみます。
それはMatz氏がコードを書いたからではありません。Rubyがオープンソースだからです。
商用プロダクトは対価を得るために社会的な信用を必要としますから、スケジュールと品質の妥協点を見出す時に、
・問題を完全に解決するスマートな方法よりもスケジュールを優先した間に合わせの方法を採用する
・重要度の低い問題を出荷時の制限事項とする
等の方法で(まあエロゲのような例外はありますけど)スケジュールを重視する事がよくあります。
しかし、これはMatz氏のような職人気質のプログラマーのプライドを挫く行為です。言い換えればMatz氏にとっての「イヤなこと」です。
Matz氏は、Rubyをオープンソースにする事で、対価を得ない事と引き換えに社会的な信用の必要性を減らし、品質に対する妥協を可能な限り減らす事を可能にして、開発のモチベーションを保っているというのがここまでのまとめです。
さて、RubyはMatz氏本人が「先立つモノ」が必要だという事を認める程大きくなりました。
Matz氏が今回「先立つモノ」として念頭に置いているのは「お金」である事は、ご自身の日記のコメントに記載されています。
しかし、Matz氏が念頭に置いているのは、「出資金」なのでしょうか? それとも「募金」なのでしょうか?
スケジュールをまともに守れないモノに出資する奇特な人はあまりいませんから、「先立つモノ」は募金的性格を持つものになるだろうと私は予想します。
出資を求める事で、品質を妥協するようなイヤなことも我慢して粛々とやるのが我慢できないから募金的性格を持つ「お金」を集めて人を雇おうというのがMatz氏の主張であるというのが私の結論です。
これは少なくともビジネスと呼ぶには値しない活動です。
「なかなか実現しない」のは当然だと思います。
Re:オープンソースビジネス (スコア:5, 参考になる)
途中までは話が進むんですけどねえ。
まつもと ゆきひろ /;|)
Re:オープンソースビジネス (スコア:3, 興味深い)
具体的な発言へのリンクを見つける元気がなかったのでAC、にしようと思ったけど同じくリリースマネジメントに悩むオープンソース関連者のはしくれとしてIDに。
-- Takehiro TOMINAGA // may the source be with you!
リリースエンジニアリング (スコア:2, 興味深い)
仮にRubyに専任リリースエンジニアが付いた所で、非互換な変更が減るかというとそうじゃないでしょう。「以前のバージョンと非互換な変更が入る度に細かくリリースし、それに対してバグ修正のみをバックポートしていく」というリリースポリシーはありかもしれませんが、それによって得られるのは「相互に互換性の無い古いバージョンがやたら増える」というだけのことで、ユーザーから見てあまりメリットがあるとは思えません。寧ろ混乱が生じて害ですし、それによって開発リソースが複数のバージョンに分散します。
「互換性の無い変更をするな、俺は昔のバージョンを使い続けたいんだ」という人は
- 文句だけ言ってないで自分でその古いバージョンのメンテに必要な人的リソースを捻出する
- 諦めて自分のスクリプトを修正する
- 開発ポリシーが自分に合った他のスクリプト言語を使う
しか選択肢がないと思うんですが…「すぐに『嫌なら使うな、forkしろ』とか言うな」と叩かれそうですが、そういう人たちの論調って「俺はMatzを説得も出来ないし自分で問題解決する実力もないから愚痴って粘着してるだけですが何か?」と言っている様に聞こえるんですよねえ。
ところで (スコア:2, すばらしい洞察)
すると問題になってしまうようなユーザサイドの人はいないのですか。
つーかいないからこんなタレコミが記事になるのか…。
nightly (スコア:2, すばらしい洞察)
Re:バージョン無用 (スコア:1)
Re:社会的信用が必要なのか (スコア:2, 参考になる)
そして、バージョンを切ってリリースしてくれると、そういったところでもバージョンアップしてくれるのでうれしいです。はい。
Re:なぜ (スコア:1)
「mputの日記」というのはリンク先のタイトルだから「氏」がついていないという話?
# 本当は「mput の日記。」みたいだけど。
Anonymous Coward になおさら言えた義理かよ (スコア:2, フレームのもと)
スラッシュドットの場とはいえ、こんな罵声を、しかも今回は匿名の影に隠れての文句。
保守担当者の辞任で明らかになったDebianプロジェクトの問題 [opentechpress.jp]の件で参照されている本人のブログには
活発な開発者の1人だったのに、読んだら死にたくなるような酷い内容のメールを送りつけられるのにはもう耐えられない旨の説明があったけどね。
何の貢献もしないで、「さっさと予定通りにバグの無い物を無償で出せよ!」と罵声を浴びせるような行為が、開発者のやる気を無くさせ、落胆させるという事すら理解できない自己中心野郎が増えるようだと、もうそのプロジェクトも終わりになっちゃうだろうな。
ついでに言うと (スコア:2, すばらしい洞察)
そして開発速度は落ちていき...、最後にはプロジェクトそのものがストップする。
などとおっしゃる。その頃、当の本人は自分の過去の発言などこれっぽっちも覚えちゃおらず、
# オンライン小説の方面でも似たような話が。
May the music be with you.
Re:Matzが言えた義理かよ (スコア:1, すばらしい洞察)
Re:Matzが言えた義理かよ (スコア:3, おもしろおかしい)
> その類いの脊髄反射レスって何かのお約束ですか?
お約束ですね.
たとえば ChangeLogにさえ目を通さないような門外漢が,リリースエンジニアリングのような専門用語を意味も理解せずに使っている場合に,使われる言い回しです.
門外漢な人に「おまえ何も分かっていないよ」と直接言うのは失礼にあたるので,「実際にメンテをすることを想像してごらん.Matzさんが頑張っているから ruby のプロジェクトはうまく動いているんだよ.」と優しく言っている訳です.
Re:Matzが言えた義理かよ (スコア:5, すばらしい洞察)
開発者が開発を放棄したために過去の遺物となったフリーソフトの事例なんて掃いて捨てるほどあるわけで。
それをわかっていない人は開発者のモチベーションを削りかねない発言を平気でするし、わかってるひとはそのことで開発者のモチベーションが削られることを非常に危惧している。
#実際問題としてそうそう簡単にMatz氏がRubyの開発を放棄するとは思えないわけですが、まぁそれはそれ。
Re:Matzが言えた義理かよ (スコア:1, すばらしい洞察)
権利意識ばかり肥大した連中の相手をさせられるのは、誰にとってもうんざりする事に決まっています。
あなたが、何もしない奴から「非難」されてやる気になる特殊体質の人だというのなら、何も言うことはありません。
Re:Matzが言えた義理かよ (スコア:2, すばらしい洞察)
というのは簡単だけど
「どうすれば互換性のスポイルが起きないようになるのか」
を「相手に考えさせている」のが「あなたが言うところの『非難』」が無責任で「何様?」なところ。
だから「非難なんかいらない。提案が欲しい」というコメントになるのです。
Re:Matzが言えた義理かよ (スコア:2, 参考になる)
バージョン番号のポリシーがちょっと変わって、次の安定版は1.9.1となるが、いずれにしても3年半くらいのインターバルかな。
Rubyを使ってきた身からすると、常に次期バージョンは輝いていて、リリースが待ち遠しい。
開発バージョン(1.5, 1.7, 1.9.0)で実験とテストを重ねに重ねているから、数字はマイナーでも気分はメジャーアップグレード。
Re:リリースに間に合うようにバグ潰しをしましょう (スコア:4, すばらしい洞察)
>両方守らないといけない。そんなの基本ですよ。
それを言うためには対価が必要なので基本でも何でもない。
Re:リリースに間に合うようにバグ潰しをしましょう (スコア:2, おもしろおかしい)
Dilbertのネタを思い出しました
部下:「リーダーのあなたがやる気を起こさせないから仕事が捗らないんです」
上司:『なら、やる気を起こさせるようなことを言わせる仕事をして見せてくれ』
部下:「そのためのやる気を起こさせて下さい」
上司:『お前から、最初にやらなきゃ駄目さ』
部下:「それじゃ僕がリーダーになっちゃうでしょ?」
There is no spoon.
Re:リリースに間に合うようにバグ潰しをしましょう (スコア:1, おもしろおかしい)
「両方」やらなくっちゃあならないってのが
「リーダー」のつらいところだな
覚悟はいいか?
Re:リリースに間に合うようにバグ潰しをしましょう (スコア:1, おもしろおかしい)
俺も出来てる
Re:リリースに間に合うようにバグ潰しをしましょう (スコア:2, 興味深い)
俺ゃ「それを言うには」と書いたんだがな。「言う人」が対象であって「作る人」じゃない。
「作る人」に関して言えば期日や品質をどうするか、どうできるかは本人次第であって、使うだけの人はそれを見て判断すりゃいいだけの話。言い替えりゃ予定調和の連鎖たる産業とやらに乗せるかどうかは「作る人」が決めるし、乗っているかどうかは各々判断すりゃいい。他に何があるってのさ。
Re:リリースに間に合うようにバグ潰しをしましょう (スコア:1)
>場合はともかく
そんな場合でも物理的や予算的に無理なものは無理だと言うことが(言える事が?)基本になってくれれば良いんですけどね。
#そして今日もまた物理学の常識が覆される
Re:リリースに間に合うようにバグ潰しをしましょう (スコア:3, すばらしい洞察)
例えばlinuxの生カーネルは殿の判断に左右されるけど、各ディストリビュータは、殿の判断では不要だけど産業レベルの要請では必要と思われるものを独自の判断でパッチを取捨選択してリリースしてる。
そういうディストリビュータに相当する存在があれば、生rubyは私物のままでかまわんのじゃなかろうか
Rubyが真に産業レベルの開発に使用可能であるならば、そういう開発者の職人的こだわりと産業界の要請のミスマッチを埋めるビジネスは近いうちあらわれるんじゃないかと
Re:リリースに間に合うようにバグ潰しをしましょう (スコア:2, すばらしい洞察)
開発体制や成果物に自分の意見を反映させたければお金を出して権力を握って言うことを聞かせるか、自分の実力や実績でトップを説得するしかないでしょう。ソースが公開されていれば最終手段としてforkするという手もありますね。
企業だろうがコミュニティ開発だろうが、お金や実力の無い人の言う事は聞き入れてもらえません。その辺を勘違いして逆恨みした人がここやブログで愚痴ってるだけでしょ。
Re:私だけではないはず (スコア:2, おもしろおかしい)
s/リリース延期/言い訳の電話
#そんな蕎麦屋に頼むな(笑)
/* Kachou Utumi
I'm Not Rich... */
Re:私だけではないはず (スコア:1, おもしろおかしい)
Re:私だけではないはず (スコア:1)
エロゲ真っ青の延期っぷりですからねぇ。