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
54
0
Share
open source 2
科学技術史 中間発表
オープンソース・ソフトウェアの起源に関する調査
sakakendo0321
June 18, 2019
More Decks by sakakendo0321
See All by sakakendo0321
meister chapter4
sakakendo0321
0
32
Introducing static site
sakakendo0321
0
38
inner study
sakakendo0321
1
69
pass the test
sakakendo0321
1
240
meister 2018 final
sakakendo0321
0
39
Other Decks in Technology
See All in Technology
Azure Lifecycle with Copilot CLI
torumakabe
3
1k
AIを共同作業者にして書籍を執筆する方法 / How to Write a Book with AI as a Co-Creator
ama_ch
2
130
AWS DevOps Agentはチームメイトになれるのか?/ Can AWS DevOps Agent become a teammate
kinunori
6
680
ハーネスエンジニアリングの概要と設計思想
sergicalsix
9
4.5k
Rapid Start: Faster Internet Connections, with Ruby's Help
kazuho
2
170
社内エンジニア勉強会の醍醐味と苦しみ/tamadev
nishiuma
0
150
Master Dataグループ紹介資料
sansan33
PRO
1
4.6k
AI駆動1on1〜AIに自分を育ててもらう〜
yoshiakiyasuda
0
120
「責任あるAIエージェント」こそ自社で開発しよう!
minorun365
9
1.8k
クラウドネイティブな開発 ~ 認知負荷に立ち向かうためのコンテナ活用
literalice
0
110
サイボウズ 開発本部採用ピッチ / Cybozu Engineer Recruit
cybozuinsideout
PRO
10
78k
データを"持てない"環境でのアノテーション基盤設計
sansantech
PRO
1
100
Featured
See All Featured
[RailsConf 2023] Rails as a piece of cake
palkan
59
6.5k
How GitHub (no longer) Works
holman
316
150k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.7k
The Illustrated Guide to Node.js - THAT Conference 2024
reverentgeek
1
340
How to build an LLM SEO readiness audit: a practical framework
nmsamuel
1
710
Java REST API Framework Comparison - PWX 2021
mraible
34
9.3k
Money Talks: Using Revenue to Get Sh*t Done
nikkihalliwell
0
200
DBのスキルで生き残る技術 - AI時代におけるテーブル設計の勘所
soudai
PRO
64
53k
GraphQLの誤解/rethinking-graphql
sonatard
75
12k
Designing for Performance
lara
611
70k
Gemini Prompt Engineering: Practical Techniques for Tangible AI Outcomes
mfonobong
2
370
How to Grow Your eCommerce with AI & Automation
katarinadahlin
PRO
1
170
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