For Japan Technical Jamboree 61 http://elinux.org/Japan_Technical_Jamboree_61

1. 2017.6
ソニーネットワークコミュニケーションズ株式会社
関 康治 <Yasuharu.Seki@sony.com>

2.  学生時代
 1995年：internet に魅力を感じて入学 (SFC WIDE)
 学部生の頃 Eric Raymond の OSS ３部作を読んで感銘を受ける
 Linux PC 組んで遊んでた (Free BSD より Linux 派)
 卒論で NFS などを弄ってた
 社会人
 音楽系 PC アプリケーションの設計実装
 動画編集ソフトウェア開発
 PC/モバイルアプリの開発基盤整備
 現在のOSSとのかかわり
 部内PJに対してOSSライセンスについて助言 (上田さんご指導の下)
 アプリ開発基盤として Cordova や Electron を利用
 Cordova へのコントリビューション
 10bytes 位だけど(笑)

3. はじめに

4.  オープンソースの運営法に関するエッセイ
 Eric S Raymond(ESR) 著
 1997年の Linux Kongress で発表された。
 GPLでライセンスされていたらしい
 現行は Open Publication License, version 2.0
 山形浩生さんが日本語に翻訳している。
 http://cruel.org/freeware/cathedral.html
 ３部作※の１作目
 これに続いて下記がリリースされた
 ノウアスフィアの開墾
 魔法のおなべ
※ 実は４部作らしい。が、最後の１作はどうなってるんだろう？

5.  Linux 開発モデルを明文化・優位性を説明した
 このモデルが社会的に注目されるように
 Netscape が無料化・オープンソース化した一因
 バザールモデルがビジネスになり得ることを説明
 ３部目の「魔法のおなべ」で詳しく議論されている
 RedHatやTurboLinux 等の有料サポートモデルが出てきた
 大成功とは言い難いけど...
 IBM 等これを B2B で発展させた例も
 近年のオープンソース隆盛の起源はこの論文と言う説も

6. 1997:「伽藍とバザール」公開

7.  Windows 95
 ブラウザの主流は Netscape Navigator.
 Internet Explorer が徐々にシェアを伸ばしつつある
 UNIX
 商用UNIXがメイン。Solaris や SGI などが有力。 news などもまだ現役。
 PC向けには FreeBSD/NetBSD も使われていた
 実は Netscape も有料だった (1998年に無料化)
 動画再生のためにプレイヤーを買う必要があった。
 一太郎/Lotus 1-2-3 などが現役
 (一太郎まだ現役ともいえるけど... '一太郎2017'(!!))
ソフトにお金を払う時代
⇒ 「大規模なアプリは、専門の開発チームがオフィスに籠って書くモノ」
という common sense
http://blog.so-net.ne.jp/aret_blog/2011-09-04

8.  Linux のリリース
 1991/8/25 linux のリリースメッセージが minix newsgroup にポストされる
Hello everybody out there using minix -
I'm doing a (free) operating system (just a hobby, won't be big and
professional like gnu) for 386(486) AT clones. This has been brewing since
april, and is starting to get ready. I'd like any feedback on things people
like/dislike in minix, as my OS resembles it somewhat (same physical layout
of the file-system (due to practical reasons) among other things).
I've currently ported bash(1.08) and gcc(1.40), and things seem to work. This
implies that I'll get something practical within a few months, and I'd like to
know what features most people would want. Any suggestions are welcome,
but I won't promise I'll implement them :-)
Linus (torvalds@kruuna.helsinki.fi)
PS. Yes - it's free of any minix code, and it has a multi-threaded fs. It is NOT
portable (uses 386 task switching etc), and it probably never will support
anything other than AT-harddisks, as that's all I have :-(.
- Linus Torvalds

9.  1995 年頃から「使える」レベルの Linux ディストリビューション
が出始めた
 Slackware や RedHat が主流。 Debian/Turbo Linux 等が出始めた
 ビンボ学生だった私は Slackware の CD-ROM を500円くらいで買ってた
 "Good year" by Tim Bird
 多数のデベロッパが寄ってたかって Linux の品質向上
 各種書籍・雑誌も出てくるようになった
 Linux Magazine : 1994
 ASCII の Linux Magazine 創刊は 1999年
 日経Linux も 1999年
⇒ 「こんな大規模で高品質なソフトが無料で使えるなんて！」
※ 大いに誤解を招く表現ではありますが

10.  (企業の立場から)「無料で使えるソフトウェア」への魅力
 (ソフトハウスから) 価格破壊・仕事喪失への恐怖からの反発
 双方の言い分を反映した議論が発生した
 ⇒ 金にもならんのにナンデあんな開発ができるのだ？
 それに対する一つの答えが「伽藍とバザール」

11. 「伽藍とバザール」

12.  Linux の開発方式は面白そう
 これを「バザール方式」と名付けて体系立ててみた
 それに則って筆者のプロジェクトを進めてみた
 fetchmail
 上手くいった
 お前ら見習え
 とはいえ、気を付けることもあるぞ
 上手く運営するために大切なものは これこれ だ

13. Walter Watzpatzkowski

14.  「大規模な宗教施設」
 詳細な設計図 or 理念を基に細かい作業を繰り
返して最終的に人を圧倒するような大規模な
建築になる
 中央集権型の建築現場
http://d.hatena.ne.jp/hyoshiok/20140519/p1
「大聖堂とバザール」の方が適訳？
《(梵)saṃghārāmaの音写「僧伽藍摩」の略。僧園・衆園と訳す》
１ 僧が集まり住んで、仏道を修行する、清浄閑静な場所。
２ 大きな寺・寺院の建物。「七堂伽藍」 デジタル大辞泉 「がらん ×伽藍」

15.  所謂 proprietary ソフトウェア。
 設計図をきちんと描き、それに沿って構造を
構築してゆく。
 理想的には、想定通りの仕様・品質のソフト
ウェアが想定通りのタイミングでリリースで
きる。 が、現実は？？？

16.  バザール：市場。緩い制約が参加者を呼び、
相互補完と活気を促す。
 ex) 当初 誰かが物を売り始め、市場ができ、人が集まり始める
初期 人が集まるのにメシ屋が足りないと思った人が
蕎麦屋を出す
中期 人が集まるのにラーメン屋が足りないと思った人が
札幌ラーメン屋を出す
後期 人が集まるのにトンコツラーメン屋が足りないと思った人が
家系ラーメン屋を出す
... 市場が取り扱う商品が高度化してゆく

17.  (プロジェクトに対して) たくさんの参加者が、自律的
に其々の気になるところを開発することで、結果とし
て高度なソフトウェアが提供できるようになる
 "Given enough eyeballs, all bugs are shallow." (目玉の数
さえ十分あれば、どんなバグも深刻ではない)
 Linus's Law
 誰もソフトウェアの機能や完成時期にコミットはしな
い。しかしふと振り返ると、「充分な品質のソフト
ウェア」が出来上がっている。
自由な開発行動がソフトウェアを高度化してゆく

18.  Linux Torvalds による公開から6年(エッセイ執筆時点)
 様々なディストリビューションが作成され、ユーザー
ベースも相当に大きくなった
 当初1万行だったコードは 80万行 (1997年) に
 (2015年時点では 2000万行)
 巨大なユーザー数
 開発コミュニティも大きくなった
 SunSITE のツリーとか
 多くの人から patch が提供されるように
 UNIX Like OS として成功しているのは疑いようもない

19.  積極的にコントリビューションを受け付ける
体制を作ったことで、良いものができた
 Eric Raymond の自画自賛気味？
 具体的には「伽藍とバザール」を読め！
 何を考えて、何をしたら、どうなったか。が山の
ように書いてある

20. バザール形式は有効である！！
 オープンソースを運営するためのポイント19条
 玉石混交ではあるけれど
1. よいソフトはすべて、開発者の個人的な悩み解決から始まる。
2. 何を書けばいいかわかってるのがよいプログラマ。なにを書き直せば（そして使い回せば）いいかわかってるのが、すごいプログラマ。
3. 捨てることをあらかじめ予定しておけ。どうせいやでも捨てることになるんだから（フレッド・ブルックス『人月の神話』第11章）
4. まともな行動をとってれば、おもしろい問題のほうからこっちを見つけだしてくれる。
5. あるソフトに興味をなくしたら、最後の仕事としてそれを有能な後継者に引き渡すこと。
6. ユーザを共同開発者として扱うのは、コードの高速改良と効率よいデバッグのいちばん楽ちんな方法。
7. はやめのリリース、ひんぱんなリリース。そして顧客の話をきくこと
8. ベータテスタと共同開発者の基盤さえ十分大きければ、ほとんどすべての問題はすぐに見つけだされて、その直し方もだれかにはすぐわかるはず。
9. 賢いデータ構造と間抜けなコードのほうが、その逆よりずっとまし。
10. ベータテスタをすごく大事な資源であるかのように扱えば、向こうも実際に大事な資源となることで報いてくれる。
11. いいアイデアを思いつく次善の策は、ユーザからのいいアイデアを認識することである。時にはどっちが次善かわからなかったりする。
12. 自分の問題のとらえかたがそもそも間違っていたと認識することで、もっとも衝撃的で革新的な解決策が生まれることはよくある。
13. 「完成」（デザイン上の）とは、付け加えるものが何もなくなったときではなく、むしろなにも取り去るものがなくなったとき。
14. ツールはすべて期待通りの役にたたなきゃダメだが、すごいツールはまったく予想もしなかったような役にもたってしまう。
15. ゲートウェイソフトを書くときはいかなる場合でも、データストリームへの干渉は最低限におさえるように必死で努力すること。
そして受け手がわがどうしてもと言わない限り、絶対に情報を捨てないこと！
16. 自分の言語がチューリング的完成からほど遠い場合には、構文上の甘さを許すといろいろ楽になるかもね。
17. セキュリティシステムのセキュリティは、そこで使われてる秘密の安全性にかかっている。見かけだけの秘密は要注意。
18. おもしろい問題を解決するには、まず自分にとっておもしろい問題を見つけることから始めよう。
19. 開発コーディネーターが、最低でもインターネットくらい使えるメディアを持っていて、圧力なしに先導するやりかたを知っている場合には、
頭数は一つよりは多いほうが絶対にいい。
山形浩夫訳より

21.  Linux/fetchmail の例から明らか

22.  何でも公開すりゃ上手くいくってもんでもない

23.  多数の有能なデベロッパを惹きつける必要がある
バザール方式成功要件５箇条

24.  新しいこと・すごいこと・必要とされていること
を実現するソフトウェアであること
 既存のOSSがあるところに競合を公開するのは嫌われる
 実用されること(実際に使われること)
 ユーザーベースの大きさが「目の数」を保証する
 コントリビュータへの「報酬」になる

25.  「みんなで寄ってたかって」開発できるようになっていること
 あまりに複雑な構造は NG
 多少冗長でも、「この領域の普通のエンジニアならこう考える」とい
う構造を取るべき
 KISS 原則
 どういうものをどのように作ろうとしているかが明白であること
 「動いてテストできること」が最低要件
「そのソフトは特によく書けてなくてもいい。雑で、バグだらけで、不完全で、ド
キュメント皆無でもいい。でも絶対不可欠なのが、開発者候補たちに、それが目に見
える将来にはなにか本当に使える代物に発展させられると説得できることだ。」
「伽藍とバザール」 山形裕生訳 "9 バザール方式の前提条件とは"

26.  「はやめのリリース、しょっちゅうリリース」
 バグはリリースされないと見つけてもらえない
 自分の貢献が素早く反映されることはコントリ
ビュータのモチベーションになる

27.  コントリビュータの個別の記録が反映される
 コントリビュータリストに名前が載るとか
 copyright に反映されるとか
 コントリビュータが自分で書くのではなく、メイ
ンテナが貢献に対してきちんとメンテナンスでき
ることが重要

28.  ほかの人たちのよいデザイン上のアイディアを認
識できる
 過度な独創性は障害になる
 堅牢でシンプルな構造をキープしつつ、良いアイディア
を組み込む「第六感」を持つこと
 対人能力やコミュニケーション能力に優れる
 自分のやっていることに興味を持たせられる
 各人の仕事量にみんなが満足しているように気を配れる
 他人を魅了する個性が少しくらいでもある

31.  得手
 既存のソフトウェアの品質向上・機能向上
 不得手
 新規アイディアの創出
 リファクタリング (根本的なデザインの変更)
設計の指針がはっきりしている
Big Problem を解決している
それをコミュニティに説明できる
OSS化が有効なソフトウェアの性質 OSS化が有効でないソフトウェアの性質
ごく少数の限られた人が対象のソフト
guruが書いたスゴすぎるコード
既存のOSSと同じ問題だけを解決する
ソフト

32. fight!
「伽藍とバザール」の20年後

33.  gcc の例
 FSF(伽藍)の gcc と EGCS(バザール)
 いまや EGCS がメジャー
 FSFのgcc開発チームは解散
 node.js と io.js
 joyent がハンドリングしていた node.js は io.js でほぼ上書きされた
 Netscape
 1998年に無料化＆オープンソース化
 FireFox に受け継がれる
 現在は chrome にやられているが、これもバザールモデルだよね。
 Microsoft がオープンソース企業に
 VSCode や C# 等がどんどんオープンソース化
 Linux foundation のプラチナスポンサーに

34.  Officeソフト
 OpenOffice が作られたが解散
 Libre Office 等にフォークされている
 シェアで MS Office などを上回ったことはない
 描画ソフト
 Gimp などが公開されたが...
 やはり Adobe tools が最も使われている

35.  Android
 確かに下回りは Linux
 だけど Android を形作るレイヤは伽藍スタイル
 Apple products
 ライブラリや Framework としてOSSとして公開しているものも多い
 iOS / MacOS を形作るレイヤは伽藍スタイル
Delivery support for the innovation
としてのバザール方式活用
How to Contribute to the Linux Kernel, and Why it Makes Economic Sense
(James Bottomley, Novell; LinuxCon/Japan 2009)

36.  誕生から26年
 未だに OSS として活発に開発されている
 コミュニティも活発
 ex) The Linux Foundation: Japan Technical Jamboree
 Linux の高度化と利用者の大幅な増加
 Android (!!)
 各種 IoT 機器
 組み込み機器のデファクトに
 スパコンランキング「TOP500」の97%はLinuxが独占
 http://japan.zdnet.com/article/35056772/

37.  「国内大手」ソフトウェア企業は OSS 専業部署を設立する傾向
 商用ソフトウェアにおける OSS の割合
Delivery support for the innovation としての OSS が定着しつつある
日立 2015: OSSソリューションセンタ設立
NTT OSSセンタ
富士通 2013: OSSインテグレーションセンター
BLACKDUCK (2016)

38.  GitHub
 非常に簡単に自前のツールを OSS 化可能に
 JavaScript による mini tools の氾濫
 玉石混交... というより石が多すぎ
 優秀な人材の分散希薄化
 短命な frameworks
 backbone – Ember – Angular – React – vue.js ...
 新しい風潮が出てきては直ぐに世代交代する
 厚い資産・コミュニティが醸成される前に世代交代
 世間を賑わせるのは平均1年位？
 作り捨て文化が産まれつつある

39.  Wikipedia
 OpenSource Hardware
 Arduino
 RepRap
 ...
 その他の OSS マインドに関するキーワード
 シェアードコミュニティ
 Hack-a-thon 等によるアイディア公募・協創
 オープンイノベーション

40. 必ずしも「バザール常勝」とは言えないかもしれない
しかし注目すべき成果は大きい
バザール方式の利用法が
Delivery support for the innovation としての位置づけ
に進化してきた
これからは、適切に目的に適うOSSを発見し、
ハンドリングしていく能力が必要となってくる

41. Eric Raymond 著作

42.  OSS のコントリビューションの仕方と、OSSの生態系
 OSS の「所有権」の話
 なぜ本質的に改造自由であるはずのものに、土地所有権の
構造に似た「所有権」の仕組みが息づいているのか
 「評判」を報酬として形成されたモデル
 「贈与文化」の表出
 ハッカーの職人的な美を他人から賞賛されることが報酬と
なる仕組み。評判。
OSSコミュニティ参加者に望まれる振る舞いを示唆したもの

43.  OSSとお金の話
 クローズドソースソフトウェアの販売価値は思っ
てるほど高くない
 OSS にしちゃっても誤差だよ
 OSSで稼ぐには？
 ７つの例示 (とはいえ眉唾なものも...)

44. end of session

46.  ESR が Linux モデルを見て新しい開発法 「バザールモデル」が有
用だと感じたため、自らのプロジェクト fetchmail に適用してみ
た成果を文書化したもの。
 旧来の(Windows や FSF成果物を作ってきたような)開発手法を
「伽藍(Cathedral)モデル」として、どちらの手法が得られるもの
が大きいか比較している。
 結論は...
 バザール形式でも大規模なプロジェクト(Linux や fetchmail) を運営可
能である。また、伽藍形式よりもさらに大規模なプロジェクトを成功に
導ける可能性を持っている。
 バザールモデルを成立させるための条件についても論じている。

47.  フリー
 「無料の」「自由に扱える」 Free hug
 ヒッピー的な自由さを求めることを追及
 → FSF の理念に色濃く染まった語になってきたため、
一部の OSS コントリビュータに嫌われた
 オープンソース
 フリーソフトという語の代替
 フリーソフトという語から「自由」という文脈を薄めた
 大勢がこっちの語に乗り換えた

48.  1983: FSF設立
 すべてのソフトウェアをフリーにすることが目標
 → OSを作ろうとした
 シェル(bash)、コンパイラ(gcc)やエディタ(emacs)などを提供し
ている
 カーネルの実装(GNU Hurd)も目指したが、遅々として進まな
かった
 1991: Linux誕生
 Unix like なカーネルが、「一学生の興味」で生まれた
 このカーネル上で GNU ツール群が動作したことで、GNUの事実
上のカーネルは Linux となった
 → FSF は Linux でなく GNU/Linux と呼べと主張している

49.  Richard M Stallman(RMS): FSF創始者
 商用ソフトだいっきらい
 世の中のソフトウェアがすべてフリーにするにはどうすればいいか考える思想家
 GPL の書き出し (正確には２文目) はこんな文章
 "take away your freedom" (!!)
 Eric S Raymond: 一介のエンジニア
 RMSと親交あり
 FSFのソフトに対するコントリビューションもしている
 但し、必ずしも FSF の思想に共感しきっているわけではない
「The licenses for most software and other
practical works are designed to take away your
freedom to share and change the works.」

50.  多様な才能を仲間に引き入れよう
 謙虚であれ。他人の成果は尊重せよ。
 人の話を聞け。自分の能力を超えたアドバイスは得てし
て魅力的に見えないものだ。
 ユーモアと人当たりのよさは大切
 任せられるものは人に任せる
 引き入れるためのコツがある
 方向性を示すのに充分な設計(方針)は必要
 早めにリリース、しょっちゅうリリース
 議論も含めてなんでもオープンにする。記録も残す。
いろんなシーンで適用できそう。LEAN start up とか