<!-- A bike shed on the other hand. Anyone can build one of those over @@ -201,10 +201,10 @@ doing his job, that he is paying attention, that he is *here*. --> さぁ一方自転車小屋だ。週末をつぶせばだれでも作ることができ、余った時間 -でゲームだのテレビだのを楽しむことさえできるだろう。どんなに用意周到で -あったとしても、どんなに妥当な提案だったとしても、だれかがあなたの芽を -摘みにかかる。自分もなにかやっていることを示すために。自分もそれに注目 -してることを示すために。「俺を忘れるな」と言いたいがために。 +にテレビで試合を見て楽しむことさえできるだろう。どんなに用意周到であっ +たとしても、どんなに妥当な提案だったとしても、だれかが機会をとらえては、 +自分もなにかやっていることを示したり、自分もそれに注目してることを示し +たり、「俺を忘れるな」と言ったりするだろう。
<!-- In Denmark we call it "setting your fingerprint". It is about @@ -215,9 +215,9 @@ --> デンマークでは、こういったことを「指紋をつける」って言うんだ。個人的な プライドや見栄のために何かをして、あとからその証拠を見せられるようにす -る。「ほら見ろよ。これ、俺がやったんだ」てな具合にね。政治家どものやり -そうなことでもあるが、最近は一般人もよくそんなことをしてる。ほら、よく -生乾きのセメントに足跡がついてたりするだろう? +る。「ほら見ろよ。これ、俺がやったんだ」てな具合にね。政治家どものよく +やりそうなことでもあるが、一般人だって機会があればやりそうだよ。ほら、 +よく生乾きのセメントに足跡がついてたりするだろう?
<!-- I bow my head in respect to the original proposer because he stuck
ch05.xml の以下の御指摘については、翻訳漏れの部分がありますので、その部分は取り入れ させて頂きました。但し、原文が "the end result is as likely as not to be determined by ..." となっていますので、オリジナルの訳の意味はそのままにしてあります。
--- appc.xml.orig 2009-03-18 12:14:44.000000000 +0900 +++ appc.xml 2009-03-21 15:36:58.000000000 +0900 @@ -59,9 +59,8 @@ scared away from sending another one, and today I have the time and inclination to do so. --> -最後に送ったパンフレットは無事受け取ってもらえたようだし、改めて送りな -おさなくてもすみそうだ。というわけで、ちょっとみんな私の話を聞いてくれ -ないか。 +この前送ったパンフレットはよく受け取ってもらえたし、また別のを送っても +いいかなって思ってた。で、今日はその時間と気力があったんで。
<!-- I've had a little trouble with deciding on the right distribution @@ -226,9 +225,10 @@ and walked away after less than a handful of messages in that thread. --> -最初にこの提案をした人には敬意を表したい。だって、この劇場のいちばんす -みっこの席にいたときから自分の信念を貫き通して、ついに今日その変更がツ -リーに取り込まれたわけだから。ということで、私も引き下がるようにしよう。 +最初にこの提案をした人には敬意を表したい。だって、くだらぬ批評家たちの +妨害行為にもめげず自分の信念を貫き通して、その変更がいまやツリーに取り +込まれてるわけだから。私ならあのスレッドの一握りのメッセージすら受け取 +る前に諦めて逃げてただろうね。
<!-- And that brings me, as I promised earlier, to why I am not subscribed @@ -321,8 +321,8 @@ | 今あなたが送ろうとしているメールは何10万人もの人に届きます.| | 受け取った人がそれを読むべきかどうかを判断するのに少なくと | | も10秒はかかるでしょう。つまり、あなたのメールを読むために | - | 少なくとも0.5人月が費やされるわけです。さらに、ほとんどの | - | 人はメールをダウンロードして読まないといけません。 | + | 少なくとも0.5人月が費やされるわけです。さらに、多くの人は | + | メールをダウンロードするのにお金を払わないといけません。 | | | | あなたのメールは、ほんとうにみんながそれだけの手間をかけて | | でも読む価値のあるものですか? | @@ -404,15 +404,16 @@ enough to do this tiny deed, so why are they suddenly so enflamed by somebody else so much their junior doing it ? --> -私の願いの2番目は、もっと感情的なことだ。このプロジェクトが始まってか -らかなりの年月がたっているにもかかわらず、例の sleep(1) のスレッドが炎 -上したときにこのちょっとしたことができなかった。自分より年下のやつが何 -かしようとすると、人はなぜみんなあんなに攻撃的になるんだろう? +私の願いの2番目はもっと感情的なものだ。sleep(1) スレッドで敵対的な批判 +をした古参たちは、プロジェクトへの参加歴が長いというのに、このちょっと +したことをやろうとなんて思わなかった。明らかにね。それなのに、自分より +かなり下の後輩がそれをやろうとすると、なぜいきなり彼らはすごい勢いで燃 +え上がるんだろうか?
<!-- I wish I knew. --> -わかっていると思いたい。 +わかっていればなぁ。
<!-- I do know that reasoning will have no power to stop such "reactionaire
[patch] (スコア:1)
ていただければ幸いです。
「カネで愛は買えない」のセクションにもいくつか気になる部分がありますが、
それはまた後ほど書きます。
--- ch04.xml.orig 2009-03-13 13:41:53.000000000 +0900
+++ ch04.xml 2009-03-13 17:24:30.000000000 +0900
@@ -1230,11 +1230,11 @@
メーリングリストでの議論や既に有効になっている合意をベースにしていることを明示するようにしましょう。
実際に記録するときは、
メーリングリストのアーカイブにある関連したスレッドを参照するようにし、
- 参照すべき場所がわからないときは、周りに尋ねるようにしましょう。
+ 不明な点があるときにはもう一度尋ねるようにしましょう。
記録した文書には人々を驚かせるようなことを書くべきではありません。
- たとえば、根拠を書かずに、合意の中身だけを説明するようなことです。
+ それは合意の典拠ではなく、単に合意について記述したものに過ぎないのです。
もちろん、成功すればそれを権威あるものとして人々が引用しはじめるかもしれませんが、
- それはプロジェクトの総意を正確に反映しているだけに過ぎません。
+ それはその記録がプロジェクトの総意を正確に反映していることを示しているに過ぎません。
</para>
<!--
--- ch05.xml.orig 2009-03-13 13:41:53.000000000 +0900
+++ ch05.xml 2009-03-13 17:36:25.000000000 +0900
@@ -855,8 +855,9 @@
X は ユーザーにとってもの凄く重要だ / 誰も満足しない余計な飾りだよね」
といったものになります。現実世界での使い方が示されていないと、
議論の短縮や決着に繋がらないばかりか、実際のユーザー体験からは程遠い議論になってしまいます。
- そういった議論を止める力が働かない限り、行き着くところは結局何も決まらない、
- ということになりがちです。
+ そういった議論を止める力が働かない限り、
+ 結局それを決めるのはもっとも口が達者だった人、あるいはもっとも頑固だった人、
+ あるいは一番の古参、ということになってしまうかもしれません。
</para>
<!--
Re:[patch] (スコア:1)
--- ch05.xml.orig 2009-03-13 13:41:53.000000000 +0900
+++ ch05.xml 2009-03-13 20:00:19.000000000 +0900
@@ -1038,7 +1038,8 @@
1日に2回メーリングリストに繰り返し投稿することではありません。
カネが作り出す <emphasis>可能性がある</emphasis> 葛藤を鎮める機会を探っておくべき、
というだけです。そういった葛藤が既にあるものと考える必要はありませんが、
- カネによってそういうことが起きるかもしれない、ということを認識しておく必要はあります。
+ カネによってそういうことが起きる可能性を認識している、
+ ということを行動で示しておく必要はあります。
</para>
<!--
@@ -1054,9 +1055,9 @@
-->
<para>
- そういった葛藤の良い例が Subversion プロジェクトで起こりました。
- Subversion は、プロジェクト開始時からカネを出していて、
- 何人かの開発者 (お断り: 筆者もそのうちのひとりです) に給料を支払っていた <ulink url="http://www.collab.net/">CollabNet</ulink> が始めたものです。
+ そういった行動の良い例が Subversion プロジェクトで起こりました。
+ Subversion は、何人かの開発者 (お断り: 筆者もそのうちのひとりです) に給料を支払って <ulink url="http://www.collab.net/">CollabNet</ulink> が始めたものです。
+ CollabNet は、プロジェクト開始時からずっとプロジェクトに一番カネを出しています。
プロジェクトが始まってすぐ、CollabNet は Mike Pilato という別の開発者を雇いました。
彼を雇うまでに、コーディングは既に始まっていました。
Subversion はまだ開発の初期段階でしたが、
@@ -1079,13 +1080,13 @@
Mike を雇うことで、面白い疑問が出てきました。
Subversion プロジェクトには、
新しい開発者にコミット権限をどうやって与えるかに関するルールが既にありました。
- まず、彼は開発用メーリングリストに修正プログラムをいくつか投稿しました。
+ まず、彼は開発用メーリングリストに修正プログラムをいくつか投稿します。
十分な量の修正が彼の修正プログラムによって行われ、他のコミッター達は、
- 彼が自分がしていることをよく理解していることを知りました。
- その後、Mikeは直接コミットしたらいいじゃないかと提案した人がいました(<xref linkend="committers"/> で説明していますが、
- この提案は非公式なものでした)。
- そして提案をした人の一人が彼にメールを送り、既にいるコミッター達が同意するものと見做して、
- プロジェクトリポジトリへのコミット権限を与えたのです。
+ 彼が自分がしていることをよく理解していることを知ります。
+ その後、コミッターの誰かが彼は直接コミットしたらいいじゃないかと提案します(<xref linkend="committers"/> で説明していますが、
+ この提案は内密に行います)。
+ そして既にいるコミッター達が同意をすれば、コミッターの一人が彼にメールを送り、
+ プロジェクトリポジトリへのコミット権限を提供するのです。
</para>
<!--
@@ -1116,8 +1117,8 @@
プロジェクトが設定したガイドラインを無視する権利があると宣言することになってしまいます。
それによる影響はすぐには顕在化しないでしょうが、
カネを貰っていない開発者がコミッターを選ぶ権利を奪われたと感じてしまう事態が徐々に出てくるでしょう。
- CollabNet に雇われていない人がコミット権限を得るには、
- カネでそれを買わねばならならないのです — つまり、CollabNet はコミット権限を買っているだけなのです。
+ CollabNet に雇われていない人はコミット権限を努力して獲得しなければならないのに、
+ CollabNet はコミット権限をただ買うだけで手に入れられるなんて。
</para>
<!--
Re:[patch] (スコア:1)
tkobaさん、重ねてpatchありがとうございます m(_ _)m
> - カネによってそういうことが起きるかもしれない、ということを認識しておく必要はあります。
> + カネによってそういうことが起きる可能性を認識している、
> + ということを行動で示しておく必要はあります。
上記の部分は明らかな誤訳なので、少し調整した上で採用させて頂きました
> - そういった葛藤の良い例が Subversion プロジェクトで起こりました。
> + そういった行動の良い例が Subversion プロジェクトで起こりました。
上記も、誤訳に関連した部分ですので、少し調整した上で採用させて頂きました。
> - Subversion は、プロジェクト開始時からカネを出していて、
> - 何人かの開発者 (お断り: 筆者もそのうちのひとりです) に給料を支払っていた CollabNet が始めたものです。
> + そういった行動の良い例が Subversion プロジェクトで起こりました。
> + Subversion は、何人かの開発者 (お断り: 筆者もそのうちのひとりです) に給料を支払って CollabNet が始めたものです。
> + CollabNet は、プロジェクト開始時からずっとプロジェクトに一番カネを出しています。
ここは、おそらく文章の繋がりに関する指摘であり、どのように繋げるか、という話だと思います。
tkobaさんの繋げ方の方が読みやすいと考えたので、そのまま採用させて頂きました。
> - まず、彼は開発用メーリングリストに修正プログラムをいくつか投稿しました。
> + まず、彼は開発用メーリングリストに修正プログラムをいくつか投稿します。
> (...snip)
ここの部分はプロジェクトの一般的なルールに関するものだから、現在形にすべきという指摘だと
思います。尤もだと思いますので、概ね採用させて頂きました。
> - CollabNet に雇われていない人がコミット権限を得るには、
> - カネでそれを買わねばならならないのです — つまり、CollabNet はコミット権限を買っているだけなのです。
> + CollabNet に雇われていない人はコミット権限を努力して獲得しなければならないのに、
> + CollabNet はコミット権限をただ買うだけで手に入れられるなんて。
earn をどう解釈するか、という問題だと思います。「努力する」の方が、カネを出しているヒトと
そうでないヒトの比較として正しいものだと思いますので、少し私流に調整した上で採用させて頂きました。
最終的な修正は、以下をご覧ください。ありがとうございます。
http://www.producingoss.com/ja/money-vs-love.html [producingoss.com]
# 無精、短気、傲慢、これ最強
[patch] bikeshed (スコア:1)
# 改行位置の変更で膨れ上がっています。
bikeshedメールはch06で一部引用されていますが、訳をappcと統一したほうが
いいのではないでしょうか。
あと気になったのは、board of directors が「取締役会」となっていますが、
これは役所の話のはずなので別の語をあてたほうがいいと思います。Wikipedia
の「パーキンソンの凡俗法則」のエントリでは「委員会」となっています。
cf. http://ja.wikipedia.org/wiki/パーキンソンの凡俗法則
--- appc.xml.orig 2009-03-13 13:41:53.000000000 +0900
+++ appc.xml 2009-03-16 20:00:56.000000000 +0900
@@ -188,10 +188,10 @@
-->
パーキンソンによると、原子炉施設はあまりに巨大で高価そして複雑であるた
めにみんながその内容を把握できなくなるということだ。考えようともせずに
-思考停止してしまい、「まぁ誰かがチェックしてくれるから取り返しのつかな
-い事態は避けられるだろう」ということになってしまう。リチャート・P・ファ
-インマンの著書には、これに関連するロス・アラモスでの興味深い事例がいく
-つか紹介されている。
+思考停止してしまい、「まぁここまで来る前に誰か他の人が一部始終をチェッ
+クしただろう」ということになってしまう。リチャート・P・ファインマンの著
+書には、これに関連するロス・アラモスでの興味深い事例がいくつか紹介され
+ている。
<!--
A bike shed on the other hand. Anyone can build one of those over
@@ -201,10 +201,10 @@
doing his job, that he is paying attention, that he is *here*.
-->
さぁ一方自転車小屋だ。週末をつぶせばだれでも作ることができ、余った時間
-でゲームだのテレビだのを楽しむことさえできるだろう。どんなに用意周到で
-あったとしても、どんなに妥当な提案だったとしても、だれかがあなたの芽を
-摘みにかかる。自分もなにかやっていることを示すために。自分もそれに注目
-してることを示すために。「俺を忘れるな」と言いたいがために。
+にテレビで試合を見て楽しむことさえできるだろう。どんなに用意周到であっ
+たとしても、どんなに妥当な提案だったとしても、だれかが機会をとらえては、
+自分もなにかやっていることを示したり、自分もそれに注目してることを示し
+たり、「俺を忘れるな」と言ったりするだろう。
<!--
In Denmark we call it "setting your fingerprint". It is about
@@ -215,9 +215,9 @@
-->
デンマークでは、こういったことを「指紋をつける」って言うんだ。個人的な
プライドや見栄のために何かをして、あとからその証拠を見せられるようにす
-る。「ほら見ろよ。これ、俺がやったんだ」てな具合にね。政治家どものやり
-そうなことでもあるが、最近は一般人もよくそんなことをしてる。ほら、よく
-生乾きのセメントに足跡がついてたりするだろう?
+る。「ほら見ろよ。これ、俺がやったんだ」てな具合にね。政治家どものよく
+やりそうなことでもあるが、一般人だって機会があればやりそうだよ。ほら、
+よく生乾きのセメントに足跡がついてたりするだろう?
<!--
I bow my head in respect to the original proposer because he stuck
Re:[patch] bikeshed (スコア:1)
2.と3.は「パーキンソンの法則」の日本語訳にあわせたものです。 4.はもともと http://www.freebsd.org/doc/ja_JP.eucJP/books/faq/misc.html#BIKESHED-PAINTING [freebsd.org] の訳を引用させていただいていたものですが、新たに翻訳した内容にそろえました。
TAKAGI Masahiro a.k.a. m-takagi
Re:[patch] (スコア:1)
patchありがとうございます m(_ _)m
ch04.xml の内容については、概ね誤訳といって良いものと思います。すみません(´ー`; )
概ね内容を取り入れ、採用させて頂きました。ありがとうございます。
----
ch05.xml の以下の御指摘については、翻訳漏れの部分がありますので、その部分は取り入れ
させて頂きました。但し、原文が "the end result is as likely as not to be
determined by ..." となっていますので、オリジナルの訳の意味はそのままにしてあります。
- そういった議論を止める力が働かない限り、行き着くところは結局何も決まらない、
- ということになりがちです。
+ そういった議論を止める力が働かない限り、
+ 結局それを決めるのはもっとも口が達者だった人、あるいはもっとも頑固だった人、
+ あるいは一番の古参、ということになってしまうかもしれません。
# 無精、短気、傲慢、これ最強
as likely as not (スコア:1)
mumumuさん、patchの採用ありがとうございます。
as likely as not ですが、これはイディオムで probably という意味があります。
cf. http://idioms.thefreedictionary.com/as+likely+as+not [thefreedictionary.com]
Re:as likely as not (スコア:1)
> as likely as not ですが、これはイディオムで probably という意味があります。
なるほど。御指摘有難うございます。
この点についても、採用させて頂きました。ありがとうございますm(_ _)m
最終的な修正は以下をご覧下さい。
http://producingoss.com/ja/open-motives.html [producingoss.com]
# 無精、短気、傲慢、これ最強
[patch] ch00 (スコア:1)
直訳になる方向で直していますので、訳がこなれていない部分が多々あると思
いますが、ご了承ください。
--- ch00.xml.orig 2009-03-13 13:41:53.000000000 +0900
+++ ch00.xml 2009-03-18 02:38:59.000000000 +0900
@@ -24,16 +24,14 @@
以前のように怪しげな目を向けられることはなくなりました。
「あぁ、オープンソースね。Linux みたいなものでしょ?」
とみんなすぐにわかってくれます。「そうそう! そうなんだ」。
- 別に完璧に理解してもらえなくたってかまわないんです。
+ もはや完全な辺境でなくなったのは嬉しいことです。
ちょっと前までは、次にくる質問は決まっていました。
「それで、どうやってお金を稼いでいるの?」
- この質問にきちんと答えるために、
- オープンソースの世界がどのように成り立っているのかを一度まとめてみることにしました。
- オープンソース界の住人たちがいちばん大事にしているのは、
- そのソフトウェアがそこに存在すること。
- ソフトウェアを販売してお金を儲ける必要はなく、
- そのソフトウェアの保守が続けられていること、
- 日常の作業用の道具として使えることが重要なのです。
+ 答えとして、私はオープンソースの経済学について手短に述べたでしょう。
+ すなわち、あるソフトウェアが存在することで利益を得る組織があるのですが、
+ その組織はそのソフトウェアを販売する必要はなく、
+ ただそのソフトウェアが利用可能であり保守されているということを確かめたいのです、
+ 商品ではなく道具として。
</para>
<!--
@@ -62,7 +60,7 @@
開発者以外でも多くの人が理解しています -
あるいは少なくとも驚かないようになってきています。
最近は、質問の内容がこんなふうに変わってきました。
- "<emphasis>オープンソースの仕事って、どんなことをしているんですか?</emphasis>"
+ "<emphasis>オープンソースって、どのように動いているんですか?</emphasis>"
</para>
<!--
@@ -91,14 +89,14 @@
考えれば考えるほど、その話題が複雑なものであるように思えてきたのです。
フリーソフトウェアのプロジェクトを運営するというのは
普通の商売とはちょっと違います (たとえば、
- 会ったこともないボランティアのグループを相手にして
- 自社の製品についての交渉を毎日のように行うなんてことは
+ 自社製品の性質を決めるために会ったこともないボランティアのグループと
+ 毎日のように話し合いを行わなければならないなんてことは
普通はありませんよね?)。
また、ごく一般的な非営利組織を運営したり
政府を運営したりというのとも少々異なります。
- まぁそれぞれ似ている点もあるのですが、これまでの経験から言うと
+ まぁそれぞれ似ている点もあるのですが、徐々に分かってきたのは、
フリーソフトウェアは <foreignphrase>sui
- generis</foreignphrase> (独特) です。
+ generis</foreignphrase> (独特) だということです。
比較対象となるものはいくらでもありますが、
その中のどれとも違うのです。
実際のところ、フリーソフトウェアプロジェクトを「運営することができる」
@@ -107,10 +105,10 @@
ことはできます。また、さまざまな人たちがそのプロジェクトに影響を与えることができます。
中には強烈に影響を及ぼす人もいるでしょう。
しかし、そのプロジェクト自体は特定の個人の所有物とすることはできません。
- そのプロジェクトに興味を持つ人がどこかに一人でもいる限り、
+ そのプロジェクトの継続に興味を持つ人がどこかに一人でもいる限り、
一方的にそのプロジェクトを終了することもできません。
誰もが限りない力を持っています。と同時に、誰もが無力だと言う一面もあります。
- 興味深い話です。
+ 奇妙な推進力がもたらされているのです。
</para>
<!--
@@ -129,15 +127,16 @@
-->
<para>
といったわけで、私は本書を執筆することになったのです。
- フリーソフトウェアプロジェクトは、
Re:[patch] ch00 (スコア:1)
ありがとうございました。いただいたパッチをほぼそのまま取り込ませていただきました。
# こうして見ると、原文の意味を取り違えてしまっているところがけっこう目立ちますなぁ。まだまだ修行が足りぬ……
TAKAGI Masahiro a.k.a. m-takagi
[patch] ch01 (スコア:1)
--- ch01.xml.orig 2009-03-13 13:41:53.000000000 +0900
+++ ch01.xml 2009-03-21 15:43:05.000000000 +0900
@@ -54,7 +54,7 @@
また、いつ「プロジェクトが失敗した」と判断するのかがはっきりしないのも
私たちが失敗について聞くことがない理由のひとつでしょう。
「そのプロジェクトが消滅した瞬間」というのを特定することはできません。
- 徐々に動きが鈍くなっていき、いつのまにか止まってしまっているのです。
+ 参加者が少しずつ他へ移っていき、プロジェクトで作業するのをやめるだけなのです。
「プロジェクトに対して最後に変更が加えられたとき」を知ることはできますが、
実際にその変更を加えた人は「それがプロジェクトに対する最後のコミットとなる」
とは決して思っていなかったことでしょう。
@@ -66,7 +66,7 @@
現在参加しているプロジェクトを捨ててもうひとつのほうに移動したとしましょう。
そして移った先のプロジェクトをどんどん成長させていきました。
この場合、元のプロジェクトは「消滅した」のでしょうか?
- それとも「あるべき場所に移動しただけ」なのでしょうか?
+ それとも「引っ越しただけ」なのでしょうか?
</para>
<!--
@@ -113,8 +113,8 @@
「どうやったら失敗するか」についても説明します。
それを知ることで、問題が発生したときに軌道修正ができるようになるでしょう。
本書を読み終えられた皆さんは、オープンソース開発において陥りがちな
- 落とし穴を避けるさまざまなテクニックを身に着けることでしょう。
- それにとどまらず、成功するプロジェクトの成長にかかわれるようになることを期待しています。
+ 落とし穴を避けるさまざまなテクニックだけでなく、
+ 成功しているプロジェクトの巨大化や保守をうまく扱うためのテクニックも身に着けていることでしょう。
成功というものはゼロサムゲームではありません。本書では、
いかにして競合プロジェクトを出し抜くかといったことは扱いません。
実際のところ、オープンソースプロジェクトを運営する上では
@@ -257,7 +257,7 @@
新参者がプロジェクトに参加しやすくするには、
ユーザー向けドキュメントや開発者向けドキュメントを整備したり
ウェブサイトを開いて初心者向け情報を掲載したり
- ソフトウェアのコンパイルをできるだけお手軽に行えるようにしたりといった作業が必要となります。
+ ソフトウェアのコンパイルやインストールをできるだけお手軽に行えるようにしたりといった作業が必要となります。
残念ながら、世の多くのプログラマーは
これらの作業を二の次にしてコードだけに注力しがちです。
理由はいくつかあります。
@@ -366,13 +366,13 @@
彼らは誰でもプロジェクトに参加しやすくなるような雰囲気作りを心がけています。
たとえ時にはそれが現在のメンバー間の連携を乱すことになったとしても。
彼らは何が失礼で何がそうでないのかをきちんとわかっています。
- そこが他のプロジェクトとは異なるところです。
+ その基準は他の文化におけるものとは大きく異なっているかもしれません。
最も重要なのは、長年そのプロジェクトに参加している人たちがこれらの考えを身に着けており、
プロジェクトがどうあるべきかという指針を大雑把につかんでいることです。
- 失敗するプロジェクトはたいてい、無意識のうちにこの基本から逸脱してしまいます。
- そして、デフォルトの振る舞いがどうあるべきかという共通認識を持つこともなくなります。
- こういう状態になると、いざ何か問題が起こったときにそれが急速に悪化してしまうようになります。
- これは、お互いの意見の相違を解決して何とかしようとする文化が確立されていないからです。
+ うまくいっていないプロジェクトはたいてい、無意識のうちにこの基本から逸脱しています。
+ また、デフォルトの振る舞いがどうあるべきかという共通認識を持っていないことが多いです。
+ こうなると、いざ何か問題が起こったときに状態が急速に悪化してしまうようになります。
+ 争いを解決するためのよりどころとなるべき確立された文化的行動様式を参加者が持ち合わせていない
Re:[patch] ch01 (スコア:1)
TAKAGI Masahiro a.k.a. m-takagi
[patch] appc (スコア:1)
--- appc.xml.orig 2009-03-18 12:14:44.000000000 +0900
+++ appc.xml 2009-03-21 15:36:58.000000000 +0900
@@ -59,9 +59,8 @@
scared away from sending another one, and today I have the time
and inclination to do so.
-->
-最後に送ったパンフレットは無事受け取ってもらえたようだし、改めて送りな
-おさなくてもすみそうだ。というわけで、ちょっとみんな私の話を聞いてくれ
-ないか。
+この前送ったパンフレットはよく受け取ってもらえたし、また別のを送っても
+いいかなって思ってた。で、今日はその時間と気力があったんで。
<!--
I've had a little trouble with deciding on the right distribution
@@ -226,9 +225,10 @@
and walked away after less than a handful of messages in that
thread.
-->
-最初にこの提案をした人には敬意を表したい。だって、この劇場のいちばんす
-みっこの席にいたときから自分の信念を貫き通して、ついに今日その変更がツ
-リーに取り込まれたわけだから。ということで、私も引き下がるようにしよう。
+最初にこの提案をした人には敬意を表したい。だって、くだらぬ批評家たちの
+妨害行為にもめげず自分の信念を貫き通して、その変更がいまやツリーに取り
+込まれてるわけだから。私ならあのスレッドの一握りのメッセージすら受け取
+る前に諦めて逃げてただろうね。
<!--
And that brings me, as I promised earlier, to why I am not subscribed
@@ -321,8 +321,8 @@
| 今あなたが送ろうとしているメールは何10万人もの人に届きます.|
| 受け取った人がそれを読むべきかどうかを判断するのに少なくと |
| も10秒はかかるでしょう。つまり、あなたのメールを読むために |
- | 少なくとも0.5人月が費やされるわけです。さらに、ほとんどの |
- | 人はメールをダウンロードして読まないといけません。 |
+ | 少なくとも0.5人月が費やされるわけです。さらに、多くの人は |
+ | メールをダウンロードするのにお金を払わないといけません。 |
| |
| あなたのメールは、ほんとうにみんながそれだけの手間をかけて |
| でも読む価値のあるものですか? |
@@ -404,15 +404,16 @@
enough to do this tiny deed, so why are they suddenly so enflamed
by somebody else so much their junior doing it ?
-->
-私の願いの2番目は、もっと感情的なことだ。このプロジェクトが始まってか
-らかなりの年月がたっているにもかかわらず、例の sleep(1) のスレッドが炎
-上したときにこのちょっとしたことができなかった。自分より年下のやつが何
-かしようとすると、人はなぜみんなあんなに攻撃的になるんだろう?
+私の願いの2番目はもっと感情的なものだ。sleep(1) スレッドで敵対的な批判
+をした古参たちは、プロジェクトへの参加歴が長いというのに、このちょっと
+したことをやろうとなんて思わなかった。明らかにね。それなのに、自分より
+かなり下の後輩がそれをやろうとすると、なぜいきなり彼らはすごい勢いで燃
+え上がるんだろうか?
<!--
I wish I knew.
-->
-わかっていると思いたい。
+わかっていればなぁ。
<!--
I do know that reasoning will have no power to stop such "reactionaire
Re:[patch] appc (スコア:1)
TAKAGI Masahiro a.k.a. m-takagi
[patch] ch02 (1/2) (スコア:1)
--- ch02.xml.orig 2009-03-13 13:41:53.000000000 +0900
+++ ch02.xml 2009-03-24 16:01:16.000000000 +0900
@@ -101,9 +101,8 @@
-->
<para>
しかし、Raymond の指摘は今でも洞察に満ちています。
- ソフトウェアの作者自身がそのソフトウェアに興味を持っているというのは、
- 成功するために必要不可欠なことです。なぜなら、
- 彼らは自分自身でそれを使うことになるからです。
+ ソフトウェアの作者自身がその成功に直接的な興味を持っている、
+ なぜなら彼らは自分自身でそれを使うことになるから、というのが本質的な条件です。
もしそのソフトウェアが期待通りに動かなければ、
日々それを使用している作者は不満に思うことになるでしょう。
たとえば OpenAdapter プロジェクト (<ulink url="http://www.openadapter.org/"/>)
@@ -112,13 +111,13 @@
さまざまな金融情報システムを統合するためのものです。
どう考えても、これは「開発者の個人的な悩み解決」
のために作られたものとはいえないでしょう。
- どちらかというと「制度上の問題を解決」するためのものです。
- しかし、この問題はその機関とパートナーの経験から直接くるものです。
- したがって、もしこのプロジェクトがうまくいかなければ、それが直接影響することになるでしょう。
+ これは「機関の悩み解決」をするためのものです。
+ しかし、この悩みはその機関とパートナーの経験から直接くるものです。
+ したがって、もしこのプロジェクトがうまくいっていなければ、それと気づくことができるでしょう。
このようなプロジェクトは、よりよいソフトウェアを産み出すでしょう。
- なぜなら、あるべき方向に導こうとみんながフィードバックを行うからです。
- プログラムというのは、見知らぬ誰かが彼ら自身の問題を解決できるように書くものではありません。
- 最初は自分たち自身の問題を解決するために書かれます。
+ なぜなら、フィードバックループが正しい方向に流れるからです。
+ そのプログラムは、見知らぬ誰かに売りつけて、<emphasis>彼らの</emphasis>問題を解決できるよう書かれるのではありません。
+ 最初は自分たち<emphasis>自身の</emphasis>問題を解決するために書かれます。
そしてそれがみんなと共有されるようになります。
「問題」を病気にたとえると、ソフトウェアは薬のようなものです。
流行病を完全に根絶するために薬をばらまくのと同じように、ソフトウェアを配布するようになります。
@@ -137,7 +136,7 @@
<para>
本章では、新しいフリーソフトウェアプロジェクトをスタートさせる方法を扱います。
しかし、本章にかかれている内容の多くは、
- 保険所が薬を配布するときの方法と似ていることでしょう。
+ 保健機関が薬を配布するときの方法と似ていることでしょう。
両者の目標はよく似ています。薬の効能ははっきり示さないといけないでしょうし、
それを本当に必要とする人に手渡さないといけないでしょうし、
またそれを受け取った人は薬の扱い方を知っていなければなりません。
@@ -159,18 +158,18 @@
investing effort.</para>
-->
<para>
- フリーソフトウェアの配布作業は、通常の2倍の作業量となります。
+ フリーソフトウェアの配布作業は、2つの側面を有しています。
ソフトウェアのユーザーを獲得すると同時に、開発者も獲得しなければならないからです。
- これら2つは決して競合するものではありません。
- しかし、プロジェクトをどのように見せるかという点において、これは少々複雑な話になります。
+ これら2つは必ずしも競合するものではありません。
+ しかし、プロジェクトを初めにどのように見せるかを考えると、これは少々複雑な話になります。
ユーザーと開発者の両方に対して有用な情報もあれば、
そのどちらか一方にしか役立たない情報もあります。
- これら2種類の情報の割合には気をつける必要があります。つまり、
+ どちらの情報もスケールするプレゼンテーション (scaled presentation) の原則にしたがっていなければなりません。すなわち、
Re:[patch] ch02 (1/2) (スコア:1)
TAKAGI Masahiro a.k.a. m-takagi
Re:[patch] ch02 (1/2) (スコア:1)
TAKAGI Masahiro a.k.a. m-takagi