伽藍とバザール の商品レビュー
プログラマーであった著者がLinuxに代表されるオープンソースソフトウェアについてまとめ、1999年に出版された一連の論文集。既に古典とも言えるが、オープンソースという潮流を語る上で欠かせず、いつか読みたいと思っていた一冊。 邦訳のタイトルは少しわかりづらくなっているが、原題は...
プログラマーであった著者がLinuxに代表されるオープンソースソフトウェアについてまとめ、1999年に出版された一連の論文集。既に古典とも言えるが、オープンソースという潮流を語る上で欠かせず、いつか読みたいと思っていた一冊。 邦訳のタイトルは少しわかりづらくなっているが、原題は「The Cathedral and the Bazaar」。伝統的なウォーターフォール型の指揮命令系統に基づくソフトウェア開発を”Cathedral(大聖堂、邦訳では仏教における大構造物として伽藍という訳語が選択されている)”に、オープンソースソフトウェアのように自由にプログラマが参加し、その開発が進められていく様を”Bazaar”に例えたものであり、原題で読むとその意味するところはすっきりする。 1990年代、Linuxに代表されるように、ソフトウェアの世界で発展したオープンソースという文化は、その後、Creative Commonsに代表される著作権の分野など、広範に広がっていく。その潮流を辿る上でも未だに得られるものが多く、全く古びていない面白さがあった。
Posted by
- 良いソフトはすべて、開発者の個人的な悩み解決から始まる - はやめのリリース、しょっちゅうリリース →自分たちの仕事が絶えず進捗している様子がわかるのがご褒美になる - 目玉の数さえ十分あれば、どんなバグも深刻ではない - 自分の問題の捉えた方がそもそも間違っていたと認識...
- 良いソフトはすべて、開発者の個人的な悩み解決から始まる - はやめのリリース、しょっちゅうリリース →自分たちの仕事が絶えず進捗している様子がわかるのがご褒美になる - 目玉の数さえ十分あれば、どんなバグも深刻ではない - 自分の問題の捉えた方がそもそも間違っていたと認識することで、最も衝撃的で革新的な解決策が生まれることはよくある - 「完成」とは、付け加えるものが何もなくなった時ではなく、むしろ取り去るものがなくなったとき - ツールは全て期待通りの役に立たなきゃダメだが、すごいツールが全く予想もしてなかったような役にも立ってしまう - 面白い問題を解決するには、まず自分にとって面白い問題を見つけることが始めよう - 開発者コミュにティの形成を始めるときには、まず何よりもそれが目に見える将来には何か本当に使える代物に発展させらると説得できること
Posted by
Linux のオープンソース開発方式がなぜこうもうまくいくか、を論述したもの。 伝統的な開発方式(伽藍方式:中央集権的に組み立てあげていき、ある程度完成するまで、オープンにしないような開発スタイル)と、オープンソース開発方式(バザール方式:ボランタリーベースで任せられるものは任...
Linux のオープンソース開発方式がなぜこうもうまくいくか、を論述したもの。 伝統的な開発方式(伽藍方式:中央集権的に組み立てあげていき、ある程度完成するまで、オープンにしないような開発スタイル)と、オープンソース開発方式(バザール方式:ボランタリーベースで任せられるものは任せて、しょっちゅうリリース、たとえ乱文でもどんどんオープンにする開発スタイル)との対比で書かれており、筆者が自身で同様にオープンソース開発(バザール方式)で試してみた経験を通じて、様々な気づきとともに書かれているのが面白い。 ただオープンソースにするのではなく、うまく機能させるためには、 - まず、このプロジェクトが将来本当に使える何かに発展させられる、とユーザ/ハッカーを説得し、惹きつけること - ユーザ/ハッカーをたえず刺激(全体の動きの中の一員となることで得られるエゴ)しつづけ、ご褒美(自分の仕事が絶えず進歩し続けている感覚)を与え続けること - ユーザ/ハッカーから得られる良いアイデアを認識し、それを取り込むこと - はやめしょっちゅうのリリースをすること などが大事、と書かれていた点が、参考になった。 (必ずしもオープンソースの話だけではなく、現在の開発などでも活かせそう。) また、エンジニアとしてのライフハックのようなものが散りばめられており、 - 良いソフトはすべて、開発者の個人的な悩み解決から始まる - 白紙で始めるよりは、よくできた部分解から始めた方がほぼ絶対に楽 - 賢いデータ構造と間抜けなコードのほうが、その逆よりずっとまし - 「完成」(デザイン上の)とは、付け加えるものが何もなくなったときではなく、むしろなにも取り去るものがなくなったとき - 閉ざされたプロジェクトの中で、自分の脳味噌だけを使う開発者は、オープンで、フィードバックが何百人から戻ってくるようにできる開発者に負けてしまう - オープンソースは、プログラミング人口のトップ5%しか受け入れられない。 など、刺激のある言葉が多く、今の仕事の仕方そのものに関しても考えさせられた。
Posted by
- ネタバレ
※このレビューにはネタバレを含みます
研修の読書会で読んだ。さすがに古いし、『伽藍とバザール』だけだとオープンソースバンザイすぎる極端な比較 表現等が目立つが、『魔法のおなべ』や『ノウアスフィアの開墾』も併せて読み進めていくと、Linuxカーネルを代表とするバザール形式のソフトウェア開発手法の持つ力やハッカー文化がなぜ贈与文化としての面を持っているのかが理解出来ると思う。
Posted by
ネットコミュニティ、オープンソースモデルを理解する上では最も基礎となるといっていいほどの名著。 ネット上のバーチャルなコミュニティにとどまらず、地域社会におけるボランタリーな組織形成、経済圏の形成においても様々な示唆が加えられており、実用的な観点からも非常に価値ある一冊。
Posted by
オープンソース方式の開発をバザール 従来のクローズドな開発手法を伽藍 というメタファを用い、バザール方式の利点、 伽藍方式の欠点などをまとめた論文。 伽藍は翻訳時のもので、原文は大聖堂を指している。 1997年の論文にも関わらず、記述されている内容は 今日のアジャイル・XP・...
オープンソース方式の開発をバザール 従来のクローズドな開発手法を伽藍 というメタファを用い、バザール方式の利点、 伽藍方式の欠点などをまとめた論文。 伽藍は翻訳時のもので、原文は大聖堂を指している。 1997年の論文にも関わらず、記述されている内容は 今日のアジャイル・XP・スクラム・リーンなどに繋がるような ものが多く、著者のエリック・レイモンド氏の先見性がうかがえる。 以下、いいな、と思った原則。 ・よいソフトはすべて、開発者の個人的な悩み解決から始まる ・何を書けばいいのかわかってるのがよいプログラマ。 なにを書き直せば(そして使い回せば)いいのかわかっているのが、すごいプログラマ ・すごいプログラマは建設的な面倒くさがり ・まともな行動をとっていれば、おもしろい問題のほうからこっちを見つけてくれる ・早めのリリース、ひんぱんなリリース。そして顧客の話を聞くこと ・伝統的な開発マネジメントは、そのままではいい仕事をしてくれない、 やる気のないプログラマたちを補うためのもの など。
Posted by
あちらこちらで書名を聞いたり参照されているので気になっていたが、なかなか読む機会がなかった。 しかし、今度は絶版になっていることが分かったが、何とか手に入れることができた。 オープンソースに関する数少ないハイレベルな論考集と評価されているだけあって、大変興味深く面白く読むこと...
あちらこちらで書名を聞いたり参照されているので気になっていたが、なかなか読む機会がなかった。 しかし、今度は絶版になっていることが分かったが、何とか手に入れることができた。 オープンソースに関する数少ないハイレベルな論考集と評価されているだけあって、大変興味深く面白く読むことができた。 話し言葉のニュアンス等翻訳者のレベルの高さが感じられる。 個人的には縦書きではなく横書きであったらと思ったりもするのだが。
Posted by
「ユーザ候補は、「安定」とされたカーネル最新版を使うか、最先端の新しい機能を使うかわりにバグの危険をおかすか、という選択ができるようになっている。」 オープンソース。周りの人を巻き込み、よりよいものを作る。ブレストに似ている。そのかわり、その技術は他の者にも利用される。それでも...
「ユーザ候補は、「安定」とされたカーネル最新版を使うか、最先端の新しい機能を使うかわりにバグの危険をおかすか、という選択ができるようになっている。」 オープンソース。周りの人を巻き込み、よりよいものを作る。ブレストに似ている。そのかわり、その技術は他の者にも利用される。それでも、みんなが向上するから、社会的に見ればとてもいいことなんだと思う。
Posted by
- 1