「オープンソースソフトウェアのつくりかた」公開中 55
ストーリー by hayakawa
@ToDo:後でゆっくり読む 部門より
@ToDo:後でゆっくり読む 部門より
mumumu 曰く、
オープンソースプロジェクトの運営やエンジニアリングのノウハウなどがまとめられている「Producing Open Source Software」を日本語に翻訳した「オープンソースソフトウェアのつくりかた」というドキュメントを公開しています。
「Producing Open Source Software」は、CVSやSubversionの開発に携わっている Karl Fogel氏の手によるものであり、著者の経験と多くの事例に基づいた非常に幅広いトピックが含まれています。「CreativeCommons Attribution-ShareAlike (3.0) license」(日本語訳版は「CreativeCommons Attribution-ShareAlike (表示・継承) license (3.0, 2.1-jp)」)で公開されていますが、2005年にO'Reillyから書籍としても販売されています。発刊から4年たった今でも色褪せていない内容だとタレコミ子は感じています。
スラッシュドットジャパンの読者の中には、オープンソースプロジェクトを実際に運営されている方々も多いことでしょう。そういった方々には勿論楽しんで頂けると思いますし、そうでなくてもソフトウェアの開発者であれば、様々な意味で参考になる部分があると思います。現在は下訳が終わったばかりで、細かいブラッシュアップを行っている状態です。お読みになってみてお気付きの点がございましたら、コメント等で指摘頂ければ幸いです。
まずはautotoolsの正しい使い方を学べ (スコア:2, 参考になる)
はなしはそれからだ。
サブディレクトリで
とできないのはautotoolsの使い方がどこか間違っているのだ。
love && peace && free_software
t-nissie
Re:まずはautotoolsの正しい使い方を学べ (スコア:3, 参考になる)
サブディレクトリに限定することはないよ。任意のディレクトリでそれができる方が使い勝手がいいし、ちゃんと書けばできるし。
ただし、構築中にソース自体やマニュアルの元やらリソースやらを生成する場合もあり、ソースディレクトリでしか実行できないものがあっても autotools の使い方を一概に間違っているとは言えないけど。
てゆーか ../configure && make するだけだったら autotools の使い方を間違っているというのは違う気が。やっぱり./bootstrap か ./autogen.sh あたりからはじめないと。
Re:まずはautotoolsの正しい使い方を学べ (スコア:1)
configureするとHAVE_HOGEとかHAVE_HOGE_Hとか定義されるわけだが、
それらの定義をソース中で正しく使っているソフトはほとんどない(FSFくらい)。単にコンパイルエラーになる。
ならばconfigureする意味なくね?plainなMakefileでよくね?
ざっと見て気がついたこと (スコア:2)
* autotoolsは本やWebページより「infoを見よ」のほうがよいのでは。
* Bazaar (http://bazaar-vcs.org/) についての記述が古い。
* Perl, Python, Ruby のパッケージングの最新の方法について
それぞれ1行ずつくらい説明かヒントがあってもよいのでは。
「経験豊富な開発者に尋ねてみましょう。」だけでは悲しい。
あと、強調は斜字体より太いフォントの方がよいとおもいますが、
ブラウザによっては見え方がちがうのかしらん。
love && peace && free_software
t-nissie
Re:ざっと見て気がついたこと (スコア:1)
ご指摘有り難うございます。
> * autotoolsは本やWebページより「infoを見よ」のほうがよいのでは。
> * Bazaar (http://bazaar-vcs.org/) についての記述が古い。
autotoolsについては、僕も割と原著にあるURLや書籍を参照したりしていたので、スルーしてしまっていました(´ー`; )
最近はinfoの方が新しいのでしょうか。ちょっと調べてみますね。
Bazaar の記述が古過ぎるのはまことに仰る通りです(´ー`; )
注釈をいれるか、Karl と連絡を取って原著の部分と一緒に書き換えるかしようと思います。
> * Perl, Python, Ruby のパッケージングの最新の方法について
> それぞれ1行ずつくらい説明かヒントがあってもよいのでは。
> 「経験豊富な開発者に尋ねてみましょう。」だけでは悲しい。
これも注釈かfootnoteの形でヒントを入れようと思います。ありがとうございます。
> あと、強調は斜字体より太いフォントの方がよいとおもいますが、
> ブラウザによっては見え方がちがうのかしらん。
どこの部分のことを見てそう思われましたか?
斜体字で表現されるのは複数の文脈でありうるため、具体的に教えて頂ければ
幸いです。
# 無精、短気、傲慢、これ最強
Re:ざっと見て気がついたこと (スコア:1)
HTMLで斜体にするだの、横倍角にするだのっていうのがそもそもの間違いです。
HTMLとしては強調していることが指定できれば、それをどう表示するかはブラウザ依存ですよ。
Re:ざっと見て気がついたこと (スコア:1)
> * Bazaar (http://bazaar-vcs.org/) についての記述が古い。
それぞれに注釈を入れるとともに、Karl にも記述があまりにも古いと
指摘しておきました。
http://www.producingoss.com/ja/vc-systems.html#ftn.id344142 [producingoss.com]
http://www.producingoss.com/ja/vc-systems.html#ftn.id344202 [producingoss.com]
> * Perl, Python, Ruby のパッケージングの最新の方法について
> それぞれ1行ずつくらい説明かヒントがあってもよいのでは。
以下に注釈を入れてみました。
http://www.producingoss.com/ja/packaging.html#ftn.id324405 [producingoss.com]
# 無精、短気、傲慢、これ最強
Re:ざっと見て気がついたこと (スコア:1)
> * Perl, Python, Ruby のパッケージングの最新の方法について
> それぞれ1行ずつくらい説明かヒントがあってもよいのでは。
以下に注釈を入れてみました。
http://www.producingoss.com/ja/packaging.html#ftn.id324405 [producingoss.com]
「Perlは云々(t-nissieはよく知らないです)。
Pythonではsetuptoolsによってパッケージのビルド、配布、インストール、
アップグレード、アンインストールなどができる。
RubyにはRubyGems(gemコマンド)というパッケージ管理の仕組みがあり、
rakeとRakefileとを使うことでパッケージの作成と配布が簡単にできる。」
というかんじでしょうか。今でもRubyならruby setup.rbなどは
使われているので、どう書くのが最適なのかちょっとわかりません。
*
たとえどの標準使うかがはじめわからなくても、 適用できる標準が*存在する*と思っても大丈夫です。
のような、emで囲まれているところがFirefoxでも見にくかったです。
cssを書き換えるだけで太字にできるのではないでしょうか。
(「標準使う」→「標準を使う」?)
love && peace && free_software
t-nissie
萌える本は? (スコア:2, 興味深い)
Re:萌える本は? (スコア:2, すばらしい洞察)
Creative Commons Attribution SA 3.0(2.1-jp) の条件を守れば、萌える2次著作物も作れます。
Karl の口調をツンデレにしたり、萌絵を散りばめるなどして売り込んでくださいw
# 無精、短気、傲慢、これ最強
typo (スコア:1)
タレコミ子です。
> 翻訳についてはまだ下訳が終わったばかりの直後で、
上記は、「下訳が終わったばかりで」として下さい。すみません(´ー`;)
# 無精、短気、傲慢、これ最強
Re:typo (スコア:1, 興味深い)
「つくりかた」という邦訳に違和感を覚えます。書いてあることは、ほぼコミュニティ経営のノウハウですから、"produce"を「作る」と訳すのは許されても、"how to produce ..."は「...の作り方」にはなりません。多分。日本語でもプロデューサーなどという肩書きが通用するくらいなので、和漢的な訳は難しいのかもしれませんが、開発-製作の対立項を意識しないと、和文のタイトルだけターゲットがボケてしまうと思います。
Re:typo (スコア:2, 興味深い)
> 「つくりかた」という邦訳に違和感を覚えます。書いてあることは、ほぼコミュニティ経営のノウハウですから、"produce"を「作る」と訳すのは許されても、"how to produce ..."は「...の作り方」にはなりません。多分。
御指摘有難うございます。
翻訳プロジェクトに加わって「つくりかた」というタイトルをみたとき、非常に悩みました。
仰る通り、書いていることは(エンジニアリングも含めた)コミュニティ経営のノウハウです。ただ、「コミュニティ経営的」なニュアンスについては、「How to Run a Successful Free Software Project」という副題で既に付いてしまっています。
ではこの副題を生かした上で、「ソフトウェアを produce する」という訳をどうすればいいか、というのを悩んだ挙句、この本にはソフトウェアを「つくるため」のエンジニアリング的なノウハウも含んでいるのだからOKなのではないか、という思いが残ってそのままになっています。
# 無精、短気、傲慢、これ最強
Re: (スコア:0)
「作り方」じゃなくて「つくりかた」なところから、悩まれたのだろうなぁと思いました。
「作る」「創る」「造る」のどれかに特定できなかったということですよね。
Re:typo (スコア:2, 参考になる)
> 「作る」「創る」「造る」のどれかに特定できなかったということですよね。
僕個人の思考からいえば、仰る通りです。
#もともとこの訳をつけた高木さん [hatena.ne.jp]は、別の考え方を持っているのかもしれません。
# 無精、短気、傲慢、これ最強
Re: (スコア:0)
# 意訳にしてもずれちゃってますか?
ライセンスの話かと思った (スコア:1)
たしかに。
最初タイトルを見て、
んなもんいわゆるFOSSでよくつかわれてるライセンスにすればいいだけじゃん。
ソフトウェアの作り方なんてラインセンスに関係あるかよ、と思った。
#むしろ「ソフトウェアの作り方」について鉄板があるなら教えてくれと。
屍体メモ [windy.cx]
Re: (スコア:0)
私は良いんじゃないかと思いますけどね。
OSSをOSSたらしめているのは、ソースコードでもライセンスでもなく、コミュニティじゃないかと思うので
Re:typo (スコア:1)
結局オープンソースソフトウェアを「つくる」という表現が、読者に複数の印象を抱かせてしまう
から、皆さんから御指摘を頂いてるのだと思っています。
なので、タイトルについてはもう一度検討してみます。
# 無精、短気、傲慢、これ最強
Re:typo (スコア:1)
> 上記は、「下訳が終わったばかりで」として下さい。
上記修正しました。ご指摘ありがとうございます。
# 編集段階で見落としてました。ごめんなさい。
混沌の中にこそ真実がある・・・かもしれないけど探すのめんどい
Re: typo (スコア:0)
まだじっくり見てないのですが、typo の類もこちらで報告してよいでしょうか。
http://producingoss.com/ja/packaging.html [producingoss.com]
> CHANGE ファイルと ChangeLog ファイル
「CHANGE ファイル」 → 「CHANGES ファイル」
http://producingoss.com/ja/release-lines.html [producingoss.com]
> ただ (訳注: メジャー番号が上がった) 1.1.0 をリリースすることが、
この文脈だと「メジャー番号」→「マイナー番号」ではないでしょうか。
Re: typo (スコア:1)
> まだじっくり見てないのですが、typo の類もこちらで報告してよいでしょうか。
大歓迎です。有難うございます。
> http://producingoss.com/ja/packaging.html [producingoss.com]
> CHANGE ファイルと ChangeLog ファイル
>
>「CHANGE ファイル」 → 「CHANGES ファイル」
>
> http://producingoss.com/ja/release-lines.html [producingoss.com]
> ただ (訳注: メジャー番号が上がった) 1.1.0 をリリースすることが、
>
> この文脈だと「メジャー番号」→「マイナー番号」ではないでしょうか。
なるほど。2点とも仰る通りですね。早速修正させていただきました m(_ _)m
# 無精、短気、傲慢、これ最強
Re: typo (スコア:1)
http://producingoss.com/ja/getting-started.html#documentation [producingoss.com]
第2章 さあ始めましょう
ドキュメント
日本語第3文
(誤)未完成のものであったもかまいません。
(正)未完成のものであってもかまいません。
// このような瑣末な指摘は、オフトピックかもしれません。
// 予め、お詫び申し上げます。
Re: typo (スコア:1)
> http://producingoss.com/ja/getting-started.html#documentation [producingoss.com]
> 第2章 さあ始めましょう
> ドキュメント
> 日本語第3文
> (誤)未完成のものであったもかまいません。
> (正)未完成のものであってもかまいません。
ご指摘ありがとうございます。早速修正させていただきました。
// このような瑣末な指摘は、オフトピックかもしれません。
// 予め、お詫び申し上げます。
いえいえ。大変ありがたいことです。有難うございますm(_ _)m
# 無精、短気、傲慢、これ最強
オープンソースソフトの作り方ってこんなの? (スコア:1)
↓
せっかくだからバイナリ配布→GPL違反とかいわれる→潔白を証明するためソースを公開
↓
ソースくれくれ言われる→あまり考えずにオープンなライセンスでソース公開
↓
どうしようかなーと思案
↓
いつのまにかソースを出さないと犯罪者みたいに言われる→うっとおしいのでソース公開
↓
うっとおしいので開発終了してバイナリ配布もやめる
↓
平和な日々
[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
日本語版の本が有れば欲しい。 (スコア:0)
Re:日本語版の本が有れば欲しい。 (スコア:2, 興味深い)
> 出版予定はあるのでしょうか?
はい。4月以降に出版されることが決まっていますが、最終的な出版日時は未定になっています。
# 無精、短気、傲慢、これ最強
看板に偽りあり (スコア:0)
Re:看板に偽りあり (スコア:2, すばらしい洞察)
題名は 「ソフトウェアのつくりかた」ではなく、「オープンソースソフトウェアのつくりかた」ですから。
# 無精、短気、傲慢、これ最強
一気にtxtとかで見れるやつはないの? (スコア:0)
いちいち次のページに飛ぶのめんどくさい
Re:一気にtxtとかで見れるやつはないの? (スコア:1)
http://producingoss.com/ja/producingoss.html [producingoss.com] で、1ページ全部のHTMLを落とせるので、
適宜 html2text なりで変換して頂ければと思います。
# 無精、短気、傲慢、これ最強
ついでに (スコア:0)
ページの上の方にも「ホーム」と「上に戻る」のリンクがあると便利なんだけど…
でも原著とは合わせた方がいいですね。
Re: (スコア:0)