本当は怖い伽藍とバザール

このエントリはFOSS4G Advent Calendar 2020の一部である。

エリック・レイモンドによる「伽藍とバザール」の電子書籍は esrオープンソース三部作EPUB/Mobi版から入手できる。この論文に課された、当時の文脈の制約を解きほぐして、技術的な本質を抜き出してみると、次のように抜書きできる。

抜書き

• みんなももっと生産的になれるはずなんだ
• よいソフトはすべて、開発者の個人的な悩み解決から始まる
• 評価してもらえるのは結果であって、そのための努力じゃない
• 白紙から始めるよりは、よくできた部分解からはじめ（る）
• どうせいやでも捨てることになる
• 解決策を実装してみるまでは、問題を完全には理解しきれない
• 有能な後継者に引き渡す
• きちんと育てれば、ユーザは共同開発者になってくれる
• バグや開発上の袋小路を避ける第六感
• 問題を理解してそれをなおす人物は、...その問題を最初に記述する人間ではない
• バグなんてほとんどは深刻な現象じゃない
• ユーザが増えると見つかるバグも増える
• データ構造さえ見せてもらえれば、コードのほうはたぶんいらない
• 自分の問題のとらえかたがそもそも間違っていたと認識することで、もっとも衝撃的で革新的な解決策が生まれることはよくある
• 自分が正しい質問をしているのかな、と考え直してみるべき
• 古びてきた機能は迷わず捨てること-有効性を下げずに捨てられる場合には。
• 飛行家で航空機設計者であったサンテグジュペリによれば、付け加えるものが何もなくなった時ではなく、何も取り去るものがなくなった時が設計の完成である【編集】
• コードがどんどんよくなって、しかも同時に単純になってきたら、それはもう絶対に自分が正しい
• ものすごく強力なデザイン上のアイデア、あとから考えると、その結果が当然きわまりなく、自然で、事前に約束されていたようにさえ思えるようなアイデアによって、...引き込まれなくてはならない
• そんなアイデアを狙うには、たくさんアイデアを思いつくしかない
• すごいツールはまったく予想もしなかったような役にもたってしまう
• 世界のために書いているんなら、顧客には耳を傾けなきゃ-かれらがお金で支払ってるんじゃなくても
• あんまり複雑にすると、それ自体がバグのもとになったりユーザの混乱を招いたりしかねない
• プロジェクトを最初からバザール方式で始めるのはすごくむずかしい
• 開発者コミュニティは、いじるために何か動いてテストできるものを必要としている
• まずなによりも実現できそうな見込みを示せなきゃならない
• 目に見える将来にはなにか本当に使える代物に発展させられると説得できること
• 絶対に必要なのは、...ほかの人たちのよいデザイン上のアイデアを認識できるということ
• ソフトの設計で、小利口で独創的になることの問題点は、それが習慣になってしまうことだ
• ソフトは堅牢でシンプルにしておかなきゃダメ
• バザールプロジェクトは、コーディネータやリーダの対人能力やコミュニケーション能力が優れていないとダメ
• 自分のやっていることに興味を持たせて、各人のやっている仕事量についてみんなが満足しているように気を配る必要がある
• 技術的な先進性...だけではぜんぜん足りない。その人が発する個性も大事だ
• 人を魅了する能力が少しくらいでもあると、きわめて役に立つ
• 群衆は、突破口となるような洞察なんか持てない
• ボランティア集団でさえ、まともなオリジナリティは発揮できない。ましてやなにか現状に生存が係っているような人々からなる、企業委員会なんかからそんなものは絶対に出てきやしない。
• 洞察は個人からくる
• 開発グループこそが高品質の結果を生み出すために不可欠だ
• そういうグループ開発もすべて出発点は...だれか一人が思いついた、いいアイデア一つ
• 社会的な機構...が命令して着想を生み出したりはできない
• 技術革新の根本問題...は、...アイデアをどうやってつぶさずにおくか、ということだ-でも、もっと根本的には、そもそも洞察を持てるような人たちをたくさん育てるにはどうしたらいいか、ということだ
• これはもう不動の真実だ。最高のハックは、作者の日常的な問題に対する個人的な解決策として始まる。そしてその問題が、実は多数のユーザにも典型的なものであるために広まる。
• おもしろい問題を解決するには、まず自分にとっておもしろい問題を見つけることから始めよう
• コーディングは基本的に孤独な活動だけれど、真に偉大なハックはコミュニティ全体の関心と能力を動員することで実現される
• Linux 形成期が、World Wide Web の誕生と同時期なのは偶然ではない
• 命令と規律という原理にしたがって活動するのと、共通の理解という原理に基づいて行動するのとの差
• 重なり合う意思による真剣な努力（「共通の理解という原理」）
• 個人のビジョンと才能を出発点としつつも、それをボランタリーな利害・興味コミュニティの構築によって増幅する
• システムを設計する組織は、その組織のコミュニケーション構造の複製であるような設計を生み出すように縛られる
• 手段が目的を決定する
• プロセスこそが成果物となる
• 真のコミュニケーションは対等な者同士の間でしか成立しない
• 創造的なチームワークは、まさに真のコミュニケーションに依存していて、だからそこに権力関係が入り込むと、かなり深刻に足を引っ張られる
• 下位の者たちには、問題を隠し、無視して、過小評価する強いインセンティブがある。このプロセスが製品となったら、ソフトウェアは悲惨なことになる。
• 法的に縛って責任をおわせ、...損害賠償金も得る相手ができる、ということ...は幻想でしかない
• ソフトが期待性能に達しない場合に、損害賠償を勝ち取れたケース（は）...ほとんどない
• 訴える相手がいるから安心なんていうのは、そもそもがピントはずれだ。きみは訴訟がしたかったのか？ちゃんと動くソフトがほしかったんだろうに。
• 限られている唯一のリソースというのは、才能ある人々の関心だけだ
• 伝統的なソフトウェアプロジェクトの60%から75%は、結局完成せずに終わるか、あるいはその予定顧客に拒絶される
• 半分以上のプロジェクトは、現実的に達成不可能か、あるいは単純にひたすらまちがっている目標を目指してすすんでいる
• 人間は仕事をするとき、それが最適な挑戦ゾーンになっていると、いちばん嬉しい
• 楽しみが能率をあげる

関連

• Ben Balter の言う「オンラインコミュニティは、単にオンラインになったオフラインコミュニティである」（Online communities are offline communities, just online）に通じるところがあると感じる。
• Ben Balter の関連文書として、The technology’s the easy partがあると思う。

感想

• この文書のあと、KHTML → WebKit → Safari というエピソードがあったことを想起した。
• 業務ソフトウェアが悲惨なことになる可能性が主観で99%を超えている理由の説明がこの文書で与えられている気がする。
• 国連ベクトルタイルツールキットへの示唆は何だろう。この抜書きはあまりに本質的すぎて、即物的な Next Action には繋がらない。でもなぜか、このメモを作ったことによって、UNVT は Rails に関して DHH が言う omakase experience を提供するべきなのではないかと思った。

ソース

このメモのソースは https://github.com/hfu/noteworthy/issues/111 である。