「オープンソースソフトウェアのつくりかた」公開中 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 のパッケージングの最新の方法について
それぞれ１行ずつくらい説明かヒントがあってもよいのでは。
「経験豊富な開発者に尋ねてみましょう。」だけでは悲しい。
あと、強調は斜字体より太いフォントの方がよいとおもいますが、
ブラウザによっては見え方がちがうのかしらん。
love && peace && free_software
t-nissie
Re:ざっと見て気がついたこと (スコア:1)
ご指摘有り難うございます。
> * autotoolsは本やWebページより「infoを見よ」のほうがよいのでは。
> * Bazaar (http://bazaar-vcs.org/) についての記述が古い。
autotoolsについては、僕も割と原著にあるURLや書籍を参照したりしていたので、スルーしてしまっていました(´ー｀; )
最近はinfoの方が新しいのでしょうか。ちょっと調べてみますね。
Bazaar の記述が古過ぎるのはまことに仰る通りです(´ー｀; )
注釈をいれるか、Karl と連絡を取って原著の部分と一緒に書き換えるかしようと思います。
> * Perl, Python, Ruby のパッケージングの最新の方法について
> それぞれ１行ずつくらい説明かヒントがあってもよいのでは。
> 「経験豊富な開発者に尋ねてみましょう。」だけでは悲しい。
これも注釈かfootnoteの形でヒントを入れようと思います。ありがとうございます。
> あと、強調は斜字体より太いフォントの方がよいとおもいますが、
> ブラウザによっては見え方がちがうのかしらん。
どこの部分のことを見てそう思われましたか？
斜体字で表現されるのは複数の文脈でありうるため、具体的に教えて頂ければ
幸いです。
# 無精、短気、傲慢、これ最強
Re:ざっと見て気がついたこと (スコア:1)
HTMLで斜体にするだの、横倍角にするだのっていうのがそもそもの間違いです。
HTMLとしては強調していることが指定できれば、それをどう表示するかはブラウザ依存ですよ。
I'm not right, but I'm right.
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 のパッケージングの最新の方法について
> それぞれ１行ずつくらい説明かヒントがあってもよいのでは。
以下に注釈を入れてみました。
http://www.producingoss.com/ja/packaging.html#ftn.id324405 [producingoss.com]
# 無精、短気、傲慢、これ最強
Re:ざっと見て気がついたこと (スコア:1)
> * Perl, Python, Ruby のパッケージングの最新の方法について
> それぞれ１行ずつくらい説明かヒントがあってもよいのでは。
以下に注釈を入れてみました。
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章 さあ始めましょう
ドキュメント
日本語第３文
（誤）未完成のものであったもかまいません。
（正）未完成のものであってもかまいません。
// このような瑣末な指摘は、オフトピックかもしれません。
// 予め、お詫び申し上げます。
Re: typo (スコア:1)
> http://producingoss.com/ja/getting-started.html#documentation [producingoss.com]
> 第2章 さあ始めましょう
> ドキュメント
> 日本語第３文
> （誤）未完成のものであったもかまいません。
> （正）未完成のものであってもかまいません。
ご指摘ありがとうございます。早速修正させていただきました。
// このような瑣末な指摘は、オフトピックかもしれません。
// 予め、お詫び申し上げます。
いえいえ。大変ありがたいことです。有難うございます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 @@
彼らは誰でもプロジェクトに参加しやすくなるような雰囲気作りを心がけています。
たとえ時にはそれが現在のメンバー間の連携を乱すことになったとしても。
彼らは何が失礼で何がそうでないのかをきちんとわかっています。
- そこが他のプロジェクトとは異なるところです。
+ その基準は他の文化におけるものとは大きく異なっているかもしれません。
最も重要なのは、長年そのプロジェクトに参加している人たちがこれらの考えを身に着けており、
プロジェクトがどうあるべきかという指針を大雑把につかんでいることです。
- 失敗するプロジェクトはたいてい、無意識のうちにこの基本から逸脱してしまいます。
- そして、デフォルトの振る舞いがどうあるべきかという共通認識を持つこともなくなります。
- こういう状態になると、いざ何か問題が起こったときにそれが急速に悪化してしまうようになります。
- これは、お互いの意見の相違を解決して何とかしようとする文化が確立されていないからです。
+ うまくいっていないプロジェクトはたいてい、無意識のうちにこの基本から逸脱しています。
+ また、デフォルトの振る舞いがどうあるべきかという共通認識を持っていないことが多いです。
+ こうなると、いざ何か問題が起こったときに状態が急速に悪化してしまうようになります。
+ 争いを解決するためのよりどころとなるべき確立された文化的行動様式を参加者が持ち合わせていないからです。
</para>
<!--
@@ -405,9 +405,9 @@
反対に、そのような背景を知らない人は、
プロジェクトを作成したりプロジェクトに参加したりする手続きを見て
非常に難しくてびっくりすることばかりだと感じられるでしょう。
- フリーソフトウェアの開発にかかわる人は飛躍的に増えてきていますが、
- その多くは後者 (つまり背景を知らない人) です。
- これは、ちょうど最近の移民文化と似ています。
+ フリーソフトウェアの開発にかかわる人は依然として飛躍的に増えつづけています。
+ したがって、後者に属する人 (つまり背景を知らない人) がたくさんいるのです。
+ つまり、主として新しい移民による文化だということです。
この傾向はもうしばらくは続くことでしょう。
もし自分も「背景を知らない人」のひとりだと思われるなら、
ぜひ次のセクションを読んでください。ここでは、
@@ -522,12 +522,13 @@
それよりも技術的な問題のほうが大きかったのです。
あるデータをどこかからどこかへ移動しようとすると、
現在に比べて非常に不便でやっかいでした。
- せいぜい、同じ研究室内や同じ会社の従業員同士で情報を共有するくらいが関の山だったのです。
- 目の前にいる人たちでなくみんなと情報を共有しようと思ったら、
- とたんに敷居が高くなってしまいました。
- この敷居を乗り越えるために、さまざまな手段が試みられました。
- 時にはディスクやテープを通常の封書でやりとりすることもありましたし、
- 時にはメーカー自身が間に入ってパッチのやりとりをしたりもしていました。
+ 研究所や企業によっては小さな構内ネットワークを持っており、
+ そこでは構成員の間で容易に情報を共有することができました。
+ しかし情報をどこの誰とでも共有しようと思ったら、
+ 高い敷居を乗り越えないといけませんでした。
+ 多くの場合、その敷居は実際に乗り越えられました。
+ 時にはグループ同士で連絡をとり、ディスクやテープを郵便でやりとりすることもありましたし、
+ 時にはメーカー自身が間に入り、パッチの取引所としての役割を果たすこともありました。
初期のコンピュータ開発者の多くが大学で働いていたことも幸いしました。
大学では、自分の得た知識をみんなに広めることがごく普通に行われていたからです。
しかし、データを共有するにあたって物理的な距離の隔たりが常に障害となりました。
@@ -564,12 +565,12 @@
strategy.</para>
-->
<para>
- 業界が成熟してくるにつれて、いくつかの変化が同時に発生しました。
+ 業界が成熟してくるにつれて、相互関係のあるいくつかの変化が同時に発生しました。
まず、さまざまなものがあったハードウェア設計が徐々に淘汰され、
いくつかの勝ち組に絞られていきました。
他より技術的に優れていたもの、他よりマーケティングが上手だったもの、
あるいはその両方を兼ね備えていたものなどが残ることとなったのです。
- と同時に (これは決して偶然とはいえないでしょうが)、
+ と同時に (これは全くの偶然というわけではありません)、
いわゆる「高級プログラミング言語」が台頭してきました。
これは、その言語で書いたプログラムを自動的に翻訳 (「コンパイル」)
し、さまざまなコンピュータ上で動かすことを可能とするものでした。
@@ -605,10 +606,10 @@
<para>
ここにきて、各メーカーはソフトウェアのコードに対する著作権を
より厳格に適用する必要に迫られることになったのです。
- もしユーザーが自由にコードを改変して周囲に配布しようとするなら、
+ もしユーザーが自分たちでコードを自由に共有し改変し続ければ、
今やハードウェアの「追加機能」として販売されるようになったものを
- 自前で再実装する必要が出てきました。
- 悪いことに、そのコードは競合他社の手に渡ってしまうかも知れません。
+ 自前で再実装してしまうかもしれません。
+ さらに悪いことに、そのコードは競合他社の手に渡ってしまうかも知れません。
皮肉にも、これらの出来事はちょうどインターネットが誕生したのと同じころに発生したのです。
ソフトウェアを共有する際の技術的な障害がようやく解消されたと思ったら、
そのときにはコンピュータ業界の常識が変わっていたというわけです。
@@ -816,14 +817,14 @@
-->
<para>
新しいオペレーティングシステムの開発のかたわら、Stallman
- は新しい著作権ライセンスの作成も行っていました。
- このライセンスは、コードが常に自由に扱えることを保証するものでした。
- GNU General Public License (GPL) は、法的な面からも賢明なものでした。
- コードの複製や変更には一切の制限を設けず、コピーしたものやその派生物
- (改造したものなど) も同じライセンスのもとで自由に配布できます。
- 何か制限が付加されることはありません。
- これは著作権法の形をとっていますが、
- 実際にはこれまでの著作権法とは正反対の効果を狙ったものです。
+ は新しい著作権ライセンスを考案しました。
+ 自分のコードが永久に自由であることを保証するためです。
+ GNU General Public License (GPL) は、法律における見事な柔術です。
+ コードの複製や変更には一切の制限を設けません。コピーしたものやその派生物
+ (改造したものなど) の配布は同じライセンスのもとで行われなければならず、
+ いかなる制限も付加されてはいけません。
+ このライセンスは著作権法を利用していますが、
+ 狙っている効果は伝統的な著作権とは正反対のものなのです。
つまり、ソフトウェアの再配布を制限するのではなく、たとえ作者であっても
<emphasis>再配布を制限すること</emphasis> 自体を禁止しているのです。
Stallman にとって、自分のコードを単にパブリックドメインにするよりも
@@ -834,8 +835,8 @@
そうされたところで元のコードは自由なままで残り続けるわけですが、
でも結局は Stallman の努力した結果が敵陣営
—独占的ソフトウェア—に利益をもたらすことになってしまいます。
- GPL は、フリーソフトウェアを保護主義的に守ろうとして考え出されたものです。
- そのため、自由でないソフトウェアが GPL のコードから一切の恩恵を受けられないようになっています。
+ GPL は、フリーソフトウェアに対する保護主義の一形式と考えることができます。
+ というのは、自由でないソフトウェアが GPL のコードを完全に好きなように利用することはできないからです。
GPL とその他のフリーソフトウェアライセンスとの関係については、
<xref linkend="legal"/> で詳しく説明します。
</para>
@@ -936,10 +937,12 @@
フリーなオペレーティングシステムを作ろうとしていたのは GNU だけではなかったのです
(たとえば、後に NetBSD や FreeBSD となるコードはこの時点ですでに開発が進められていました)。
Free Software Foundation の存在意義は、
- 彼らが書いたコードだけではなくその政治的な立場にもありました。
- フリーソフトウェア運動について語る際に、
+ 彼らが書いたコードだけにあるのではありません。
+ 彼らは政治的メッセージを言葉巧みに伝えました。
+ 利便性ではなく、信条としてのフリーソフトウェアを語ったのです。そのため、
プログラマーは政治的な面を気にせざるを得ないようになってきました。
- FSF の考えに異を唱える人でさえも、それを表明する必要がありました。
+ FSF と意見が異なる人でさえ、立場が違うということを明確にするためには、
+ 政治的な問題に足を突っ込まざるを得なかったのです。
FSF は、彼らのコードに GPL やその他のテキストを同梱することで彼らの思想を効率的に広めました。
彼らの書いたコードが広まれば広まるほど、
彼らのメッセージも広まることになりました。
@@ -979,7 +982,7 @@
ほとんどありませんでした。その中でも最も重要なもののひとつが
<firstterm>Berkeley Software Distribution</firstterm> (<firstterm>BSD</firstterm>)
でしょう。これは、徐々に Unix オペレーティングシステム
- —1970 年代後半時点では AT&T の研究プロジェクトとして独占化されていました—
+ —1970 年代の終わり頃まで AT&T における半ば独占的な研究プロジェクトでした—
を再実装しようという動きで、カリフォルニア大学バークレー校のプログラマーがはじめました。
BSD グループは「プログラマー同士お互いに手を取り合って団結しなければならない」
といった政治的な声明は出しませんでした。
@@ -987,9 +990,10 @@
さまざまな場所に散らばった開発者たちが協力し、Unix
のコマンドラインユーティリティやコードライブラリ、
そしてオペレーティングシステムのカーネル自体についても１から書き直していきました。
+ そのほとんどはボランティアによるものでした。
BSD プロジェクトは、イデオロギーを前面に押し出さないフリーソフトウェアプロジェクトとして
最も有名な例です。また、
- オープンソースの世界に参加しようとする開発者にとってもよい訓練の場となりました。
+ その後オープンソースの世界に残って活躍することになる多くの開発者のための訓練の場としての役割も果たしました。
</para>
<!--
@@ -1022,7 +1026,7 @@
world when done.</para>
-->
<para>
- 別の共同開発の例としては <firstterm>X
+ 別の盛んな共同開発の例としては <firstterm>X
Window System</firstterm> があります。これは
フリーでネットワーク越しに使用できるグラフィック環境で、
1980 年代半ばに MIT とハードウェアベンダーが共同で開発しました。
@@ -1040,6 +1044,7 @@
</para>
</footnote>
自体はフリーソフトウェアですが、
+ その主な目的は、いわば競争する参加企業間の試合の場をならすことであり、
独占的ソフトウェアの支配を終わらせるといった意図はありませんでした。
もうひとつの例を挙げましょう。GNU プロジェクトの数年前に開発が始まった TeX
です。これは、Donald Knuth によるフリーで高品質な組版システムです。
@@ -1051,8 +1056,7 @@
特に立場を表明していませんでした。彼は、単に
<emphasis>真の</emphasis> 目的 (コンピュータプログラミングに関する書籍の出版)
を達成するためのまともな組版システムがほしかっただけなのです。
- そして、自分の作ったものを一般に公開しないなどということは、
- 彼にとってはありえないことだったのです。
+ そして彼にとって、自分の作ったシステムを一般に公開しない理由はなかったのです。
</para>
</sect3>
@@ -1092,7 +1096,7 @@
がフリーでないソフトウェアを指すときに使用する用語) をなくすんだ！
という道徳的な衝動にかられる人もいましたが、
単に技術的な興味からフリーソフトウェアを開発している人もいました。
- また、他人と共同作業をするのが楽しいとか、
+ また、同じ趣味を持つ人と共同作業をするのが楽しいとか、
有名になりたいとかいう理由の人もいたことでしょう。
しかし、このように本質的に異なる動機を持った人たちが
お互いに悪影響を及ぼしあうことはありませんでした。
@@ -1109,7 +1113,7 @@
superior to the nearest non-free alternative; in others, it was at
least comparable, and of course it always cost less. While only a few
people might have been motivated to run free software on strictly
-philosophical grounds, a great many people were happy to run it
+ philosophical grounds, a great many people were happy to run it
because it did a better job. And of those who used it, some
percentage were always willing to donate their time and skills to help
maintain and improve the software.</para>
@@ -1123,8 +1127,8 @@
フリーソフトウェアの思想に厳密に従うためにフリーソフトウェアを使用するという人は
あまり多くなかったかもしれません。多くの人たちは、
単にそちらのほうが高性能だからという理由でフリーソフトウェアを選択していました。
- そしてそのような人たちの中には、
- ソフトウェアの保守や改善のために力を貸してくれる人も見られるようになりました。
+ そしてソフトウェアを使う人たちの中には、
+ そのソフトウェアの保守や改善のために時間と力を貸してくれる人が常にある程度以上いたのです。
</para>
<!--
@@ -1211,7 +1215,7 @@
無料のソフトウェアがすべてフリー (自由) であるとは限りません。
たとえば、1990 年代のブラウザ戦争の際に
Netscape と Microsoft はともにブラウザを無償でばらまき、
- それによって市場のシェアをかき乱そうとしました。
+ 市場のシェアを獲得しようと躍起になりました。
このどちらのブラウザも、"自由なソフトウェア" という意味でのフリーではありませんでした。
そのソースコードを見ることができなかったり、
あるいはたとえ見ることができたとしてもそれを改造して再配布する権利がなかったりしたのです。
@@ -1254,14 +1258,14 @@
しかし、英語がインターネット上での標準言語として使われている現状では、
英語の問題は、ある意味ではすべての人たちの問題であるともいえます。
この「フリー」という言葉の意味の履き違えがあまりにも広まってしまったので、
- フリーソフトウェア開発者は公式な声明を出すことにしました。
+ フリーソフトウェア開発者は決まり文句をつくり出しました。
"<emphasis>フリー (free)</emphasis> とは、<emphasis>自由 (freedom)</emphasis>
のことです。つまり、<emphasis>フリースピーチ (言論の自由)</emphasis>
というときの「フリー」であり、<emphasis>フリービール (無料のビール)</emphasis>
というときの「フリー」とは違います。"
しかし、何度も何度もこれを説明しなければならないのは大変です。
多くのプログラマーが、この「フリー」というあいまいな単語のせいで
- 自分たちのソフトウェアが正しく理解されないと感じるようになりました。
+ 自分たちのソフトウェアが世間に正しく理解されないと感じるようになりました。
</para>
<!--
@@ -1279,11 +1283,11 @@
<para>
しかし、問題はもっと深いところにありました。
「自由」という言葉には道徳的な意味が含まれています。
- 自由であることが目的なのならば、フリーソフトウェアがよりよいものになるのか
- 特定の状況において特定のビジネスで有益になるのか
- といったことはどうでもよかったのです。
- 単にその動機にちょっとしたよい副作用があっただけで、
- 基本的には技術的でも商業的でもなく、道徳的なものでした。
+ 自由であることが目的なのならば、フリーソフトウェアがよりよいものになろうが
+ 特定の状況において特定のビジネスで有益になろうが、
+ そんなことはどうでもよかったのです。
+ 単にその動機にちょっとしたよい副作用があっただけです。
+ 心底は技術的でも商業的でもなく、道徳的な動機だったのです。
さらに「自由という意味のフリー」という立ち位置は、
フリーなプログラムのサポートもしたいが別の独占的ソフトウェアの商売も続行したい
という企業にとってはちょっと不便なものでした。
@@ -1356,8 +1360,8 @@
OSI のウェブページは <ulink url="http://www.opensource.org/"/> です。
</para>
</footnote>
- OSI は、「フリーソフトウェア」という言葉そのものももちろん、
- 特に「フリー」という言葉に混乱の原因があるのではと考えました。
+ OSI は、「フリーソフトウェア」という言葉が混乱の元であるというだけでなく、
+ 「フリー」という単語が、より全般的な問題の徴候のひとつであると考えました。
フリーソフトウェア運動をより広めるためには、
何らかのマーケティング戦略が必要です。しかし、
道徳だの社会全体の利益だのといった言葉は
@@ -1375,10 +1379,10 @@
-->
<para><emphasis>
Open Source Initiative はフリーソフトウェアのマーケティングプログラムです。
- 「フリーソフトウェア」を、イデオロギーの小さな枠の中だけでなく
- 現実の世の中に広めるために存在します。
- 目指すところは変わりませんが、
- 負け犬的な考え方や象徴主義はありません。……
+ イデオロギーについて熱弁をふるうのではない、
+ 手堅く実際的な立場において「フリーソフトウェア」を広めるためのものです。
+ 勝算のある中身はそのまま、
+ 勝ち目の無い態度や象徴主義を変えたのです。……
</emphasis></para>
<!--
@@ -1443,6 +1447,7 @@
-->
<para><emphasis>
ハッカーたちにとっては、これは信じがたいことでしょう。
+ 技術者というのは、具体的で中身のあるものに置き換えて考える傾向があるからです。
しかし、何かを売るときにはイメージというものが重要なのです。
</emphasis></para>
@@ -1455,8 +1460,10 @@
-->
<para><emphasis>
マーケティングにおいては、見た目が重要となります。
+ 私たちが進んでバリケードを取り壊し、
+ 喜んで産業界と一緒に仕事をしようとしているように見せることは、
私たちの実際の振る舞いや信念、そしてソフトウェア自体と同じくらい
- 見た目も重視されるのです。
+ 価値のあることなのです。
</emphasis></para>
<!--
@@ -1492,14 +1499,14 @@
この文には、さまざまなツッコミどころがあります。
まず、「私たちの信念」とは書かれていますが、
その信念とはいったい何なのかということは巧妙に省略されています。
- ある人にとっては、よりよいコードを生み出すことが目的となるでしょうし、
+ ある人にとっては、オープンソースの手法はよりよいコードを生み出すという信念かもしれません。
あらゆる情報を共有すべきだという信念の人もいるかもしれません。
「盗人」という言葉は、(おそらく) 違法コピーのことを指しているのでしょう。
この言い方には異議がある人も多いことでしょう。
元の所有者がまだそれを保持しているのだから
「盗人」はおかしいのではないかと思われるかもしれません。
フリーソフトウェア運動が反商業主義だと非難される可能性については説明していますが、
- それが何かの事実にもとづくものなのかどうかには触れていません。
+ その非難が何かの事実にもとづくものなのかどうかには触れていません。
</para>
<!--
@@ -1514,8 +1521,9 @@
-->
<para>
別に、OSI のウェブサイトが矛盾していて紛らわしいと言っているわけではありません。
- そうじゃないんです。OSI が言っているのは、
- これまでのフリーソフトウェア運動が忘れていたことのひとつ、つまり「よいマーケティング」です。
+ そうじゃないんです。
+ これまでのフリーソフトウェア運動が欠いてきたものだと OSI が主張する、まさにそれの例になっているんです。
+ そう、「よいマーケティング」です。
「よい」とは、「業界で生き残っていける」という意味です。
Open Source Initiative は、多くの人々に彼らが待ち望んでいたものを与えました。
道徳的な十字軍ではありません。
@@ -1566,8 +1574,8 @@
Debian プロジェクトは 100% フリー (もちろん「自由」という意味です)
なコンピュータ環境を作ることを目標としていますが、
このように政治的な態度を明確に打ち出している組織でさえも、
- フリーでないコードも提供しています。これにより、
- 方向性が完全に一致しているわけではないプログラマーとも共同作業ができるようにしています。
+ フリーでないコードも提供しています。また、
+ 方向性が完全に一致しているわけではないプログラマーとも共同作業をしています。
</para>
</sect1>
@@ -1595,12 +1603,12 @@
フリーソフトウェアプロジェクトを運営するにあたって、
このような重い哲学的な内容を日々の作業で意識する必要はありません。
プログラマーも「みんなこの思想に同意すべきだ」なんていうように主張することはありません
- (いきなりそんなことを言い出すプログラマーは、
- どんなプロジェクトであってもうまくやっていけないでしょう)。
+ (そんなことを言うプログラマーは、
+ 自分がどんなプロジェクトでもうまくやっていけないことにすぐ気づくでしょう)。
しかし「フリー」と「オープンソース」の違いという問題があるということは意識しておきましょう。
- 参加者どうしがいざこざを起こす可能性を少なくしたり、
- 開発者の動機をよりよく理解したりし、
- プロジェクトをうまく取りまとめられるようになります。
+ ひとつには、参加者に反目するような内容の発言を避けるためです。
+ また、開発者の動機を理解するというのは、
+ プロジェクトをうまく取りまとめるための最良の方法 (ある意味、唯一の方法) だからです。
</para>
<!--
@@ -1689,7 +1697,7 @@
カネの問題は、プロジェクトが失敗する要因のうちのほんのひとつでしかありません。
どんな開発言語を選択するか、どんなライセンスを選択するか、
開発手順はどうするか、どんなツールを使用するか、
- あるいはプロジェクトをどのように宣伝するかなど、
+ あるいは新しいプロジェクトをどのように宣伝するかなど、
さまざまな要因がほかにも考えられます。
では、実際にプロジェクトを開始するにはどうしたらいいのか。
それを <link linkend="getting-started">次の章</link> で取り上げます。
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 ?
-->
-私の願いの２番目は、もっと感情的なことだ。このプロジェクトが始まってか
-らかなりの年月がたっているにもかかわらず、例の sleep(1) のスレッドが炎
-上したときにこのちょっとしたことができなかった。自分より年下のやつが何
-かしようとすると、人はなぜみんなあんなに攻撃的になるんだろう？
+私の願いの２番目はもっと感情的なものだ。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>
- フリーソフトウェアの配布作業は、通常の２倍の作業量となります。
+ フリーソフトウェアの配布作業は、２つの側面を有しています。
ソフトウェアのユーザーを獲得すると同時に、開発者も獲得しなければならないからです。
- これら２つは決して競合するものではありません。
- しかし、プロジェクトをどのように見せるかという点において、これは少々複雑な話になります。
+ これら２つは必ずしも競合するものではありません。
+ しかし、プロジェクトを初めにどのように見せるかを考えると、これは少々複雑な話になります。
ユーザーと開発者の両方に対して有用な情報もあれば、
そのどちらか一方にしか役立たない情報もあります。
- これら２種類の情報の割合には気をつける必要があります。つまり、
+ どちらの情報もスケールするプレゼンテーション (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)