Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
open source 2
Search
sakakendo0321
June 18, 2019
Technology
0
50
open source 2
科学技術史 中間発表
オープンソース・ソフトウェアの起源に関する調査
sakakendo0321
June 18, 2019
Tweet
Share
More Decks by sakakendo0321
See All by sakakendo0321
meister chapter4
sakakendo0321
0
30
Introducing static site
sakakendo0321
0
35
inner study
sakakendo0321
1
65
pass the test
sakakendo0321
1
220
meister 2018 final
sakakendo0321
0
38
Other Decks in Technology
See All in Technology
E2Eテスト設計_自動化のリアル___Playwrightでの実践とMCPの試み__AIによるテスト観点作成_.pdf
findy_eventslides
2
600
社内お問い合わせBotの仕組みと学び
nish01
1
570
ComposeではないコードをCompose化する case ビズリーチ / DroidKaigi 2025 koyasai
visional_engineering_and_design
0
110
能登半島地震において デジタルができたこと・できなかったこと
ditccsugii
0
110
ACA でMAGI システムを社内で展開しようとした話
mappie_kochi
1
310
Adminaで実現するISMS/SOC2運用の効率化 〜 アカウント管理編 〜
shonansurvivors
4
440
神回のメカニズムと再現方法/Mechanisms and Playbook for Kamikai scrumat2025
moriyuya
4
720
AIツールでどこまでデザインを忠実に実装できるのか
oikon48
6
3.3k
能登半島災害現場エンジニアクロストーク 【JAWS FESTA 2025 in 金沢】
ditccsugii
0
510
Git in Team
kawaguti
PRO
3
350
Geospatialの世界最前線を探る [2025年版]
dayjournal
1
220
Simplifying Cloud Native app testing across environments with Dapr and Microcks
salaboy
0
140
Featured
See All Featured
For a Future-Friendly Web
brad_frost
180
9.9k
Visualization
eitanlees
149
16k
Building a Modern Day E-commerce SEO Strategy
aleyda
43
7.7k
Why Our Code Smells
bkeepers
PRO
339
57k
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
333
22k
Making Projects Easy
brettharned
119
6.4k
Automating Front-end Workflow
addyosmani
1371
200k
Practical Orchestrator
shlominoach
190
11k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
54
3k
RailsConf 2023
tenderlove
30
1.2k
Principles of Awesome APIs and How to Build Them.
keavy
127
17k
Transcript
科学技術史 発表第⼆回 Open Source ⽂化はいかに⽣まれたのか
テーマ open source の開発⽂化がどのように⽣まれ、根付いたのかについて知 りたい そのために権威とされるESR ⽒の発⾔から⾃⾝がopen source 開発に移 ⾏した経緯について調べる。
Eric Steven Raymond 通称ESR という名前で活動しているプログラマ、作家。 GNU/Linux の開発に携わっており、彼⾃⾝もオープンソースソフトウェ アであるfetchmail の開発に携わった。 代表作である「伽藍とバザール」はその時の経験をもとに執筆した。
経歴 1957 年 Boston で⽣まれる 1980 年~1985 年 私有ソフトウェアの開発。 1996
年 Open Source でfetchmail を開発 1997 年 「伽藍とバザール」を発表
論⽂・テクニカルライティングの推移
open source に関する代表的な⽂献 伽藍とバザール 従来の開発モデルとopen source 開発に関する考察 魔法のおなべ open source
の資⾦⼿当を受けるためのビジネスモデルについて ハロウィーン⽂書 Microsoft のopen source に対するリアクションについて
伽藍とバザールとは 伽藍建築⽅式 中央集権的でコアな部分は少⼈数によって慎重に組み⽴てられる形 式。 e.g. FSF,Emacs のコア部分 バザールモデル コードや開発をオープンにして、良いものならば誰からでも受け⼊ れる⽅式。
e.g. Linux, Lisp
「伽藍とバザール」での発⾔ 法則 ユーザを共同開発者として扱うのは、コードの⾼速改良と効率よい デバッグのいちばん楽ちんな⽅法 はやめのリリース、ひんぱんなリリース。そして顧客の話をきくこ と ベータテスタと共同開発者の基盤さえ⼗分⼤きければ、ほとんどす べての問題はすぐに⾒つけだされて、その直し⽅もだれかにはすぐ わかるはず。 「⽬⽟の数さえ⼗分あれば、どんなバグも深刻ではない」、「デル
フォイ効果」 “ “
「伽藍とバザール」での発⾔ 条件 最初からコードは勝⼿には⽣まれない、なにか動いて、テストでき るものが必要 バグや雑さ、ドキュメントの不⼗分さはあまり問題ではなくて、ソ フトとして⽬に⾒えて可能性を感じられるものであることが⼤事 他の⼈たちのデザインからいいアイディアを認識できること( 必ずし も⾃分でいいアイディアを最初から持っている必要はない) 、⾔い出
しっぺの⼩利⼝さで制御するのではなく、シンプルであることが⼤ 事。 リーダーが開発者を惹きつけられること
まとめ・感想 今回ESR ⽒のオープンソース開発に移⾏する経緯を調べる中で、 Microsoft やnetscape などの会社が抵抗したり、⾃社のソフトウェアを 公開しているなどのリアクションがあったことを知り気になった。
bibliography Eric S. Raymond's Home Page http://www.catb.org/~esr/ Eric S. Raymond(wikipedia)
https://en.wikipedia.org/wiki/Eric_S._Raymond 伽藍とバザール ⼭形浩⽣ YAMAGATA Hiroo 訳 https://cruel.org/freeware/cathedral.html