サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
都知事選
producingoss.com
明瞭に、わかりやすく書くという技術は、 オープンソース界で暮らす上で最も重要なもののひとつといえるでしょう。 ある意味ではプログラミング技術よりも重要かもしれません。 プログラミングの技術は優れているがコミュニケーションスキルに欠ける人は、 一度にひとつずつのことしかこなせません。 また、周りの人の気を引くことにも苦労するかもしれません。 逆に、プログラマーとしては二流だがコミュニケーションスキルが優れている人は、 周りの人をうまく巻き込んでさまざまな作業をこなすことができます。 そして、結果としてプロジェクトをよい方向に引っ張っていってくれるのです。 コードを書く能力のある人が、 必ずしも他人とうまくやっていくためのコミュニケーション能力があるとは限りません。 よいプログラムを書く能力と技術的な問題をうまく説明する能力とには それなりの相関関係はあるかもしれませんが、 「技術的な問題を説
プロジェクトが続いていくと、プロジェクトは優しい独裁者モデルから離れ、 より開かれた民主主義的なプロセスに移行します。 これは特定の優しい独裁者に必ずしも満足していないからではありません。 単にグループ主体の統治の方が、 生物学のメタファーを借りて言えば "進化的に安定している" からです。 優しい独裁者が身を引いたり、 決定する権限を多くの人に平等に与えようとするときはいつでも、 グループが新しい、独裁的でない仕組みに移行する機会になります — これは言ってみれば組織化を行うということです。 開発者のグループは最初の1、2回はこの機会を利用しませんが、 結局は利用することになります。いったんそうしてしまえば、 もとの仕組みに戻ることはありません。何故かは常識でわかることです。 仮に N人 からなるグループが、ある人に特別な権限を与えていると仮定すると、 N - 1 人が自分の影響力を弱め
メーリングリストは、プロジェクト内でのコミュニケーションに必要不可欠なものです。 ウェブページ以外にユーザーに見せるものがあるとすれば、 まず最初はそのプロジェクトのメーリングリストとなるでしょう。 しかし、メーリングリストに参加する前に、 ユーザーはまずそのメーリングリストのインターフェイス (たとえば "メーリングリストに参加する" など) に出会うことになります。 ここから、次の「メーリングリスト第一法則」が得られます。 いきなりそんなことを言われても驚きますよね。 メーリングリストの管理用にわざわざソフトウェアをセットアップするなんて、 ちょっとやりすぎのように感じられるかもしれません。 小規模で流量の少ないメーリングリストは手動で管理するほうが楽に見えます。 参加申し込み用のアドレスをひとつ作成してそれをあなた宛てに転送されるようにしておき、 届いたメールの内容を見て、アドレス一
多くの人の貢献によって成り立っている、 フリーなコードやドキュメントの著作権をうまく扱う方法は3つあります。 ひとつめは、(私はお勧めしませんが) 著作権にまつわる問題をすべて無視してしまうことです。 ふたつめは、contributor license agreement (貢献者ライセンス同意書、以下 CLA) をプロジェクトで働く人達から集め、 個人が行った貢献をプロジェクトが使う権利を明示的に与えてもらうことです。 ほとんどのプロジェクトは通常これで十分です。また、裁判の管轄区域によっては、 CLA は電子メールで送ることができるのも優れています。 三つめは、プロジェクト (通常は非営利な法的主体) が全ての著作権を保持するために、貢献する人から著作権を実際に譲ってもらうことです。 これがもっとも法的には隙のない方法ですが、貢献する人にとってはもっとも厄介です。 よって、この方法を求
扱いにくい人たちに対して電子会議室上で対応するのは、 面と向かって対応することに比べて多少難しくなります。 ここで言う "扱いにくい" とは "失礼な" という意味ではありません。 確かに失礼な人たちは不快なものですが、彼らが必ずしも扱いにくいというわけではありません。 本書では、すでに失礼な人たちへの対処法は説明済みです。 とりあえず一言指摘したあとは、そのまま無視してしまうか、 何事もなかったかのように他の人たちと同じよう接すればいいのです。 それでも彼らが失礼な振る舞いを続けるようなら、 彼らはきっとそのプロジェクトの誰にも見向きもされなくなるでしょう。 自業自得です。 本当にやっかいなのは、あからさまに失礼な態度であるとはいえないが プロジェクトの進み具合に悪影響を与えている人たちです。 彼らは他の人たちの時間や労力を余計に費やさせるだけで プロジェクトに何の利益ももたらしません
フリーソフトウェアについて人々がよくする最初の質問は、 "プロジェクトはどういう仕組みで動くの? プロジェクトを維持しているものは何? 誰に決定権があるの?" といったものです。 私は、実力主義や、協力の精神、読めば何をやっているかわかるコード、 などについて当たり障りなく答えて、 いつも釈然としない思いがします。 実のところ、こうした質問に答えるのは簡単ではありません。 実力主義、協力、そして動くコードは全て答えの一部ではありますが、 日々の単位でプロジェクトがどう動いているかについて殆ど説明していませんし、 プロジェクト内で起こる衝突をどうやって解決するのかについては何も触れていません。 この章では、成功しているオープンソースプロジェクトに共通している、 基本的な仕組みを説明します。 "成功している" というのは、ただ技術的に質が高いだけでなく、 プロジェクトが健全に運営されており、生
オンラインのプロジェクトに参加するひとたちが陥りがちな罠のひとつに 「すべてのメッセージに返信しなければ!」というものがあります。 そんなことはありません。 第一、数ヶ月を経てある程度の規模になったプロジェクトについて、 すべてのスレッドの議論を追いかけるなんて不可能です。 また、自分が注目しているスレッドについても、 その投稿の多くは別に返信を要求しているものではないでしょう。 開発系のフォーラムでは特に、次のようなメッセージが多くなる傾向があります。 これらのいずれについても、本質的には 返信は不要です。注意深くスレッドを観察していれば、 あなたが言いたいことはきっと他のだれかが言ってくれるでしょう (みんなが同じように考えていたら、結局だれも発言しなくなってしまうんじゃないの? と思われるかもしれませんが、そんなことはありません。 たいていの場合、何か言わずにはいられない人が 誰かし
2007 年半ばの時点で私が把握しているオープンソースのバージョン管理システムは、 これらがすべてです (その後、2011 年後半にいくつか追加しました)。 このうち、私が常用しているのは Subversion と Git で、 それ以外に Bazaar と CVS もよく使っています。 その他の大半のシステムについては、 使用経験がないに等しいものばかりです。 ここにあげた情報は、それぞれのシステムのウェブサイトを参考にしたものです。 http://en.wikipedia.org/wiki/List_of_revision_control_software もご覧ください。 Subversion が書かれた最大の目的は、CVS にとってかわるシステムを作ることです。 CVS とほぼ同じような方法でバージョン管理を行いますが、 CVS ユーザーがしばしば悩まされていた問題点や機能不備など
このサイトについて このページは、「オープンソースソフトウェアの育て方」 (原著:Producing Open Source Software) のサポートページです。ダウンロード情報、購入情報、正誤表等の情報を公開しています。 ダウンロード 書籍版について 正誤表 ダウンロード このサイトの内容を様々なフォーマットに固めたものを以下からダウンロードできます。 PDF版は、オライリー・ジャパンのサイトから購入出来ます。 テキスト版(UTF-8) HTML分割版(tar.gz) HTML分割版(zip) ひとつの巨大なHTML版(tar.gz) ひとつの巨大なHTML版(zip) また、ソースコードは Subversion 経由でダウンロードすることができます。 Web でのブラウズ も可能です。 svn co http://svn.red-bean.com/repos/producingo
別にそんな必要はありません。 だって、そんなのどうでもいいことじゃないですか。 それに、もっとマシな時間の使い方もあるでしょ? Poul-Henning Kamp による、かの有名な "bikeshed" メール (その一部を 6章コミュニケーション で取り上げました) は、集団での議論が陥りがちな罠について非常にうまく説明した論考です。 彼の承諾を得て、ここにそれを掲載します。原文の URL は http://www.freebsd.org/cgi/getmsg.cgi?fetch=506636+517178+/usr/local/www/db/text/1999/freebsd-hackers/19991003.freebsd-hackers です。リンクしやすいように、bikeshed.com を示してもよいでしょう。 Subject: A bike shed (any colour
フリーソフトウェアプロジェクトを運営していくには、 さまざまな情報を取捨選択する技術が必要です。 これらの技術を使いこなせばこなすほど、また周りの人に使わせれば使わせるほど、 プロジェクトがうまくいく可能性が高くなります。 プロジェクトの規模が大きくなればなるほど、この傾向は強まります。 うまく情報を管理しないと、オープンソースプロジェクトは ブルックスの法則 [15] (プロジェクトの終盤になってから人を増やしたところで、 かえってプロジェクトの完成が遅れてしまう) の罠に陥ってしまいます。 Fred Brooks は、プロジェクトの複雑度はそれにかかわる関係者の数の 2乗に比例するとしています。 メンバーの数がほんの数人の時は、簡単にお互いの意思疎通ができます。 しかしメンバーが数百人規模に膨れ上がると、 もはや他のメンバーが何をしているのかをすべて把握することは不可能です。 フリーソ
プロジェクトでどのバグ追跡システムを採用していても、 文句を言う開発者は必ずいます。 この傾向は他の標準的な開発ツールよりも強いようです。 私は、バグ追跡システムが使う人の目に見えることと、 ユーザーと開発者がやりとりを双方向に行うツールであることから、 (時間があれば)改善したいと思う点が想像しやすいこと、 そしてそれを口に出して説明しやすいのが理由だと思っています。 こうした不平不満は話半分に聞いておきましょう — 以下に示すバグ追跡システムの多くはとても優れたソフトウェアです。 以下の一覧では、バグ追跡システムが追跡するものとして「問題」という用語を使います。 しかし、それぞれのシステムは、 これに対応するものとして「欠陥」や「バグ」あるいは「チケット」などの独自の用語を使うこともあることに注意してください。 注意: この調査が最初に行われたのは 2005 年であり、 それ以降にもい
Copyright © 2005-2022 Karl Fogel, under the CreativeCommons Attribution-ShareAlike (4.0) license.
プロジェクトに適用するライセンスを選ぶときは、 できる限り新しいものを作らずに既にあるものを使うようにしましょう。 有り物を使う理由はふたつあります。 ライセンスが既に知られているからです。 あなたが人気のあるライセンスのうちのひとつを使えば、 コードを使う人が法律用語をわざわざ読む必要はないと思うでしょう。 ずっと以前に読んだことがあるからです。 ライセンスの質が保たれているからです。 自分の思い通りになる弁護士のチームがいなければ、 法的に隙がないライセンスを生み出すことはできないでしょう。 この章で触れているライセンスには、多くの人々の経験や思考が詰まっています。 つまり、あなたのプロジェクトに本当に変わった要求がない限り、 さらに行動する必要はないということです。 自分のコードをできる限り多くの開発者と派生物で使ってもらい、 かつ独占的なコードで使われるのを気にしないのならば、 M
本書の英語版(『Producing Open Source Software』)が世に出たあと、 この本は翻訳者のコミュニティーに翻訳してもらえるようになりました。 これは名誉なことですし、私にとって予想外のことであり、喜ばしいことです。 翻訳作業にあたっては、私は彼らの翻訳のほとんどを受動的に受け入れていただけでした。 残念なことに私は日本語が読めないので、この日本語版の翻訳についても同じことが言えます。 私は翻訳の中身についてはコメントできませんが、少なくとも翻訳してくれた人たちについてはコメントできます。彼らは初めから終わりまで翻訳を楽しんでくれました。私の仕事はといえば、彼らが作業するための環境(リポジトリやメーリングリストなど)を整えて、必要なときに質問に答えたら、あとは彼らの作業の邪魔をしないようにするだけでした。 私が整えた作業環境も、特に作業しやすいというわけではありません
ソフトウェア特許は、フリーソフトウェアの世界で現在注目されている問題です。なぜなら、 フリーソフトウェアのコミュニティーが防ぐことができない、 現実的な唯一の脅威となっているからです。 著作権と商標の問題はいつでも回避することができます。 仮にあなたのコードが他の人のコードと似ていて、誰かの著作権を侵害していたとしても、 あなたはその部分を書き直せばよいのです。 また、誰かがあなたのプロジェクトの名前に対して商標権を持っていたとしても、 最悪プロジェクトの名前を変えれば済みます。 プロジェクト名の変更は一時的には不便かもしれませんが、 長い目で見れば問題にならないでしょう。なぜなら、コードそれ自体はいつも通り動くからです。 しかし、特許はあるアイディアを実装することに対して一律に適用されるものです。 誰がコードを書くかは関係ありませんし、 どのプログラミング言語を使うかさえ関係ないのです。
親友である Karen Underhill と Jim Blandy に本書をささげます。 ふたりがいなければ、本書を完成させることはできなかったでしょう。 本書の英語版(『Producing Open Source Software』)が世に出たあと、 この本は翻訳者のコミュニティーに翻訳してもらえるようになりました。 これは名誉なことですし、私にとって予想外のことであり、喜ばしいことです。 翻訳作業にあたっては、私は彼らの翻訳のほとんどを受動的に受け入れていただけでした。 残念なことに私は日本語が読めないので、この日本語版の翻訳についても同じことが言えます。 私は翻訳の中身についてはコメントできませんが、少なくとも翻訳してくれた人たちについてはコメントできます。彼らは初めから終わりまで翻訳を楽しんでくれました。私の仕事はといえば、彼らが作業するための環境(リポジトリやメーリングリストな
ここまで取り上げてきたのは、プロジェクトの立ち上げ時に一度だけ必要となる作業でした。 ライセンスの選択や最初のウェブサイトの作成などです。 しかし、プロジェクト開始時に最も大切なのは、それ以外の動的な作業です。 メーリングリストのアドレスを決めるなんていうのは簡単なことです。 でも、そのメーリングリストでのやり取りを有益で前向きなものに保つのは それとはまったく別の話となります。 これまで何年にもわたって社内の閉じた環境で開発が進められてきたものをオープンにすると、 その開発プロセスはこれまでとはかわります。これまでの開発者たちに対して、 その変更に対応できるように準備をさせなければなりません。 最も困難なのが、はじめの一歩です。なぜなら、今後の方向性に関する先例もなければ 今後どのようになっていくのかもまだはっきりわからないからです。 プロジェクトの安定性は、形式張った方針からくるもので
ほとんどのフリーソフトウェアプロジェクトは失敗します。 しかし、失敗例について聞くことはあまりありません。 みんなの気を引くのは成功したプロジェクトだけだからです。 世の中には途方もない数のフリーソフトウェアプロジェクトが存在する [4] ので、たとえ成功するプロジェクトがその中のごく一部に過ぎなかったとしても、 多くのプロジェクトが成功しているように見えてしまうのです。 また、いつ「プロジェクトが失敗した」と判断するのかがはっきりしないのも 私たちが失敗について聞くことがない理由のひとつでしょう。 「そのプロジェクトが消滅した瞬間」というのを特定することはできません。 参加者が少しずつ他へ移っていき、プロジェクトで作業するのをやめるだけなのです。 「プロジェクトに対して最後に変更が加えられたとき」を知ることはできますが、 実際にその変更を加えた人は「それがプロジェクトに対する最後のコミッ
あなたが選ぶライセンスは、それがオープンソースである限り、 プロジェクトで採用するにあたって大きな影響を与えないはずです。 ユーザーは、ソフトウェアを機能や質を見て選ぶことが一般的で、 ライセンスの詳細を見て選んだりはしません。それでも、 プロジェクトが採用するライセンスが目的に確実に合ったものにすることと、 ライセンスに関する決定を他の人と議論できるようにするために、 フリーソフトウェアのライセンス問題に関する基本的なことがらはやはり理解する必要があります。 しかしながら私は法律家ではないですし、この章の内容も、 法的なアドバイスを正式に受けて書いているわけではないことに注意してください。 そうするには、法律家を雇うか、あなた自身が法律家になる必要があるでしょう。 オープンソースライセンスについて議論するときにまず明らかになることは、 同じ意味を持つ異なる単語がたくさんあるらしいというこ
リリースを安定させるプロセス とは、 リリースブランチをリリースできる状態に持っていく作業です。 つまり、どの変更をリリースに含めるか、含めないかを決定し、 その方針に従ってブランチを整備することです。 この "決定" という言葉には、厄介なことがたくさん含まれています。 リリース直前に新機能がたくさん出てくるのは、 協調的なソフトウェアプロジェクトでは日常茶飯事です。 開発者はリリースが近いことを知ると、 それに乗り遅れまいとして大急ぎで変更作業を終えようとします。 これは勿論、リリースするときにはまさに起こって欲しくないことです。 開発者は自分の好きなペースで新機能を実装していればいいのであって、 自分の変更が今回、または次のリリースに含まれるかどうかは心配しない方がいいのです。 ひとつのリリースに多くの変更を直前に詰め込もうとすればするほど、 コードは不安定になり、(普通)多くのバグ
あらゆるオープンソースプロジェクトにおいて唯一公式に識別可能なのは、 コミッターかそうでないかということです。 ここでは「コミッター」について注目してみましょう。 メンバーをできる限り平等に扱うことを心がけていたとしても、 コミッターだけは別に扱うということは避けられないでしょう。 「別に扱う」といっても、特に差別的な意味はありません。 コミッターの役割は欠かせないものであり、 それなしではプロジェクトがうまく回ることはないと考えます。 品質管理のためにはコントロールが必要です。 自分にはプログラムに変更を加える能力があると考える人は多くいますが、 実際に行うのはそのうちの一部の人となります。 プロジェクトは、各個人の自己判断に依存してはいけません。 何らかの基準を設け、それを満たした人にのみコミット権を与えるべきです [34]。 一方、変更を直接コミットできる権限を持つ人たちのまわりには
このセクションでは、ライセンスの選択方法について 手っ取り早く大雑把に説明します。 個々のライセンスについての法的な意味合いや 他のフリーソフトウェアと組み合わせて使用する際に出てくる影響などについての詳細は 10章ライセンス、著作権、特許 をご覧ください。 世の中には、フリーソフトウェア用の優れたライセンスがたくさんあります。 ここでは、そのほとんどについては取り上げません。 なぜならそれらは特定の人や組織の法的な需要を満たすためだけに書かれたものだったり あなたのプロジェクトには適切でないものだったりするからです。 ここで取り上げるのは、よく用いられているものに限定します。 ほとんどの場合は、ここで取り上げたものの中からライセンスを選択することになるでしょう。 あなたプロジェクトのコードが独占的ソフトウェアに流用されることが気にならないのなら、 MIT/X スタイル のライセンスを使用
バージョン管理システム(あるいは リビジョン管理システム)は、 プロジェクト内のさまざまなファイルの変更履歴を管理するための テクノロジーや習慣を組み合わせたものです。 たとえば、ソースコードやドキュメント、 ウェブページなどがバージョン管理の対象となります。 もしこれまでにバージョン管理システムを使ったことがないのなら、 まずはバージョン管理システムを使ったことのある人を探して プロジェクトに引きずり込みましょう。いまどきのプロジェクトなら、 少なくともソースコードくらいはバージョン管理されていて当然です。 また、たかがバージョン管理程度のことすらできていないプロジェクトなど、 誰もまともに取り合ってくれないかもしれません。 バージョン管理がこれほどまで一般的になった理由は、 プロジェクトを運営していく上でいろいろな場面で役立つということです。 開発者どうしのコミュニケーション、リリース
この章では、フリーソフトウェアのプロジェクトが、 ソフトウェアをパッケージングしてリリースする方法と、 開発パターン全体がこうした目標にどう繋がっているのかについて述べていきます。 オープンソースプロジェクトと独占的なソフトウェアのプロジェクトとの主な違いは、 開発チームに対して中央集権的な管理が行なわれているかどうかにあります。 新しいリリースを準備しているとき、この違いは特にはっきりします。 独占的なソフトウェアのプロジェクトでは、企業は今度のリリースにかかわる作業に集中し、 新機能の開発や重大でないバグフィックスは、 リリースが終わるまで脇に置いてくれと開発チーム全体に求めることができます。 ボランティアの集団はそんな一枚岩ではありません。 オープンソースプロジェクトの人々は様々な理由で働いています。 よってリリース作業を手伝うことに興味がない人たちは、 たとえリリース作業が進行中で
開発者の視点から見ると、 フリーソフトウェアプロジェクトは継続してソフトウェアをリリースしている状態です。 開発者は通常、最新の利用可能なコードをいつも実行しています。 なぜならバグを発見したいですし、 最新だが機能として不安定な領域を避けつつ、 間近なところでプロジェクトの状態を追いかけているからです。 彼らは毎日ソフトウェアのコピーを更新していますが、 一日に一回以上更新することもあります。 よって変更をコミットするときは、 他の開発者も24時間以内にコミットした変更のコピーを入手すると期待できるのです。 では、プロジェクトはソフトウェアをどうやって正式にリリースすべきなのでしょうか。 ある時点のソースツリーのスナップショットを取得してパッケージにまとめ、 たとえばバージョン "3.5.0" として世界中に配布すべきなのでしょうか。 常識からいって答えはNOです。第一、開発ツリー全体が
製作著作 © 2005-2013 Karl Fogel, 高木正弘, Yoshinari Takaoka(a.k.a mumumu), under a CreativeCommons Attribution-ShareAlike (表示・継承) license (3.0, 2.1-jp)
Producing Open Source Software How to Run a Successful Free Software Project by Karl Fogel (Consulting: Open Tech Strategies, LLC) 2020-08-14: The 2nd Edition rewrite is finished and is all online below. Thanks to all the backers of the campaign that funded the rewrite! I'm doing a copy-editing and minor-improvements pass before sending it to the printer, for the reasons given in this update. Prod
このページを最初にブックマークしてみませんか?
『Producing Open Source Software』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く