-
Notifications
You must be signed in to change notification settings - Fork 0
DNET_OSSMethodology
-
ソフトウェアのソースコードを
公開・共有する「開発の方法論」 -
ザックリ言うと、
- 垂直統合（オープン・アーキテクチャの該当節を参照）の事業スキームの中
- あまり、やる気のない人間と一緒に、
- 工業、製造業的なソフトウェア開発を行い、
- 最後、品質保証部が帳尻を合わせる開発では、
「あまりイイものが出来ないんじゃないの？」
と言う事ではないか？などと思ったりした。
エリック・レイモンドによる
OSS開発のソーシャルワーキング
についてのエッセイから。
ソースコードを常時公開して多くの利用者・開発者が
ソフトウェア開発に携わるバザール方式のメリットを主張
-
カテドラル方式（トップダウン設計）
GNU Emacsの開発スタイル -
バザール方式（ボトムアップ設計）
- Linuxカーネルの開発スタイル
- Fetchmailのマネージメント経験
-
エリック・レイモンドによるリーナスの法則
-
「十分な目ん玉があれば、全てのバグは洗い出される」
（"Given enough eyeballs, all bugs are shallow"） -
「十分なベータテスターと共同開発者がいれば、
ほとんど全ての問題は、すぐさま明らかになり、すぐさま修正される」
（"Given a large enough beta-tester and co-developer base,
almost every problem will be characterized quickly
and the fix will be obvious to someone."）
-
-
本人によるリーナスの法則
- ただ楽しいからやる
- マズローの欲求段階と似る
- 「生きること」（"Survival"）
- 「社会における生活」（"Social life"）
- 「享楽・娯楽」（"Entertainment"）
- 全ての良いソフトウェアは開発者の個人的な希望から始まる。
- 良いプログラマは何を書けば良いか知っている。
凄いプログラマは何を書き直せば・何を再利用すれば良いか知っている。 - 破棄する計画を立てる。いずれにせよ、そうすることになる。
- 適切な取り組みをしていれば、おかしな問題は自発的に主張してくる。
- ソフトウェアに興味がなくなった時には、
ソフトウェアを手放して優秀な後継者に引き継ぎする。 - 利用者を共同開発者として扱うことは
迅速な実装改善と効率的なデバッグの最短ルートである。 - 素早く頻繁なリリースを実施し、顧客の話を聞く。
- 十分なベータテスターと共同開発者の基盤があれば、
大半の問題はすぐに特定されて誰かが直す。 - 賢いデータ構造と愚かなソースコードは、
その逆であるよりずっと良い成果を出す。 - あなたがベータテスターを最も有益な資産として扱うなら、
彼らは最も有益な資産となり応えてくれる。 - 次の最適案は
利用者による良いアイディアに気付かされる。
後から出たアイディアの方が良いこともある。 - 大半の衝撃的で革新的な解決策は
自身の問題の捉え方が間違っている
ことに気付くことから始まる。 - 完璧な設計は
それ以上の追加することがなくなった時ではなく、
それ以上の削減することがなくなった時である。 - 全てのツールは想像通りに便利であるべきであるが、
本当に凄いツールは作者の想像を越えた便利さを与える。 - どんなゲートウェイソフトウェアを実装する場合でも、
データストリームへの影響は可能な限り最小限に抑え、
受け手が強制しない限りはデータを決して破棄しない。 - 自分の書き方がチューリング完全から外れているなら、
シンタックス・シュガーは手助けになる。 - セキュリティシステムのセキュリティは
それが秘密である時だけ意味を成す。
見掛けのセキュリティには注意すること。 - おかしな問題を解決することは、おかしな問題を探すことから始まる。
- 開発コーディネーターが少なくともインターネットと同等に
良質な交流手段を持って圧力をかけない先導手法を知っているなら、
必然的に頭数は多い方が良い。
この論文では、
-
まず、
- 大成功したフリーソフト/オープンソースプロジェクト fetchmail を分析する。
- このソフトは、Linux の歴史から導かれる、
ソフト工学についての意外な理論を試すという意図で実施されたプロジェクトである。
-
本論では、
- その理論を、二種類の根本的にちがった開発スタイルという形で論じている。
-
一つは FSF やそのまねっ子たちの「伽藍」モデルで、
それに対するのが Linux 界の「バザール」モデルだ。 -
この2つのモデルが、
ソフトのデバッグ作業の性質に関する、
正反対の前提からそれぞれ生じていることを示す。
-
- その理論を、二種類の根本的にちがった開発スタイルという形で論じている。
-
続いて Linux 体験に基づき、
- 「目玉の数さえ十分あれば、どんなバグも深刻ではない」という仮説を支持する議論を展開し、
- 利己的エージェントによる自己修正システムとの有益な対比をしてみる。
-
そしてこの洞察がソフトウェアの未来に対して
持つ意味について、いくつか考察を行って結論としている。
「伽藍とバザール」（1997）に続く。
-
このエッセイでは、プロジェクトのオーナーシップと移転の問題を調査し、
- クローズドソースソフトウェアの交換文化
- オープンソースのギフト文化
の人類学的な可能性のあるルーツの調査をしている。
-
OSSがノウアスフィアと呼ぶアイデアの手付かずのフロンティアへの広がりの性質を調査し、
- 時間よりはるかに先の範囲にあるプロジェクトは荒野に行き過ぎているために失敗し、
- 成功したプロジェクトは傾向があると仮定している。
-
OSSの目的と観察された行動との対比を掘り下げている。
- OSS運動に関与する人々の根底にある動機を探る。
- OSSの実践者が「部族」の中で大きな評判を得る
ことが重要な動機付けの特徴であるという考えに落ち着いている。
-
以下には矛盾が観察される。
- OSSのライセンスで定義された「公式」イデオロギー
- ハッカーたちの実際の行動
-
これをふまえて、OSSのオーナーシップと移転をめぐる実際の慣習を検討する。
-
そこで明らかになったのは、そうした慣習の根底にあるのが、
ロックの土地保有に関する理論と類似した、オーナーシップの理論。 -
これと関連づけるかたちで、ハッカー文化を「贈与文化」として分析する。
-
-
つまりそこの参加者たちは時間とエネルギーと創造性をあげてしまうことで、名声を競う。
-
さらにこの分析が、ハッカー文化における紛争解決にとって
どのような意味を持つかを検討し、いくつかの処方箋的な示唆を得るものとする。
「ノウアスフィアの開墾」（1998）に続く。
オープンソース現象に生じ発展しつつある、経済的な地層を分析したもの。
-
まずはプログラム開発費用の手当について、よく主張される神話をいくつか論破
-
さらにオープンソースでの協力体制の安定性についてゲーム理論分析を提出
-
さらにオープンソース開発の資金手当を維持するビジネスモデルを 9 種類提出
- 2 つは非営利のモデル
- 7 つは営利目的のモデル
-
続いて、クローズドであることが経済的にみて
合理的な場合について、定性的な理論を展開 -
そして、営利目的のオープンソース開発に費用手当をするために、
- 市場が開発しつつある斬新な追加メカニズムを検討
- ここにはパトロン制の再発明とタスク市場が含まれる。
-
最後に、将来についてとりあえずの予測をいくつか行う。
- 伽藍とバザール(The Cathedral and the Bazaar)
https://cruel.org/freeware/cathedral.html - ノウアスフィアの開墾(Homesteading the Noosphere)
https://cruel.org/freeware/noosphere.html - 魔法のおなべ(The Magic Cauldron)
https://cruel.org/freeware/magicpot.html
-
Homesteading the Noosphere
https://en.wikipedia.org/wiki/Homesteading_the_Noosphere -
The Magic Cauldron
https://en.wikipedia.org/wiki/The_Magic_Cauldron
Tags: 移行, OSS, 開発方法論, 開発基盤
このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。