国産 OSS 立ち上げの事情

2017/08/19(⼟) Open Developers Conference 2017 Tokyo ࠃ࢈ 044্ཱͪ͛ͷ࣮৘ 0OTFO
6*͕ (JU)VCͰελʔΛ֫ಘ͢Δ·ͰͷಓͷΓ ຢ઒ ঘथ !O@NBUBHBXB

ࣗݾ঺հ •⼜川尚樹 (24) • アシアル株式会社（2016年4⽉〜） • Web エンジニア 2年⽬
•Onsen UI （2015年10⽉〜） • Web 系のオープンソース UI ライブラリ • https://onsen.io/

σϞʢ0OTFO 6*ͷ঺հʣ https://tutorial.onsen.io/

もっと⽇本から OSS が出るといいな OSS を⽴ち上げて何のメリットがあるの？ ͜ͷൃදͷ໨ඪ 発表後 OSS を⽴ち上げたとして、
どうやって伸ばすの？⾃分も OSS を⽴ち上げてみようかな？

ࠓճ͓࿩͢͠Δ಺༰ I. OSS ⽴ち上げのメリット II. OSS の⽴ち上げ⽅ III. OSS の良い⽴ち上げ⽅
1. OSS の成⻑指標の洗い出し 2. OSS の成⻑指標のフル活⽤ 3. 他 OSS の成⻑指標の調査 4. OSS の公開＆成⻑施策の実⾏開始 IV. まとめ

044্ཱͪ͛ͷϝϦοτ

044্ཱͪ͛ͷϝϦοτ •OSS の開発元は個⼈, 中⼩企業, ⼤企業など様々

044্ཱͪ͛ͷϝϦοτ •(1) 広告効果 Google が開発しました個⼈（Zaharia ⽒）が開発しました

044্ཱͪ͛ͷϝϦοτ •(2) テスト⼯数削減 • 欲しいライブラリを⾃作しようと思った時... • 閉じた環境で開発: • 全てのテスト・修正を⾃分たちで⾏う必要がある •
⼿が回らない → そこそこの品質にしかならない • 開いた環境で開発: • ユーザがテスト・修正してくれる → 品質向上

044্ཱͪ͛ͷϝϦοτ • まとめ • 個⼈や中⼩企業、⼤企業がこぞって OSS を⽴ち上げる理由は、 (1) 広告効果
と (2) テスト⼯数削減でほぼ説明できる • 欲しいライブラリは⼿に⼊るし、広告にもなる、だから開発する • 純粋なボランティアは少数派。みんな⾒返りを求めている!!

044্ཱͪ͛ͷϝϦοτ •（↓以前と違った⾒え⽅がしませんか？）

࣍ͷεςοϓ • 実際に OSS を⽴ち上げて、伸ばす!! 新OSS

044ͷ্ཱͪ͛ํ

ࢥߟ࣮ݧ •偉い⼈「OSS のメリットは分かった。ウチも公開だ！」

ࢥߟ࣮ݧ •偉い⼈「OSS のメリットは分かった。ウチも公開だ！」 ↓ 内製していたライブラリを思い切って GitHub に公開

ࢥߟ࣮ݧ •結果: •誰も使ってくれない！ • ダウンロード数は 1桁、ユーザからの反応はゼロ • 何が起こったのか？

ࢥߟ࣮ݧ Կ͕ىͬͨ͜ͷ͔ • OSS は公開するだけでは使われない • なので誰も使ってくれなかった • なので
OSS ⽴ち上げのメリットも得られなかった • 個⼈や中⼩企業での OSS ⽴ち上げでは「開発がうまく進まない」問題よりも「⽴ち上げの時点でコケる」問題の⽅が圧倒的に⼤きい • これは悪い⽴ち上げ⽅。では良い⽴ち上げ⽅とは？

044ͷѱ্ཱ͍ͪ͛ํɺྑ্ཱ͍ͪ͛ํ 1 10 100 1000 10000 100000 ユーザ数の伸び 1 10
100 1000 10000 100000 ユーザ数の伸び • メリットが最⼤化される（＝ユーザ数が増え続ける）ことが良い⽴ち上げ⽅として定義できる広告効果テスト⼯数削減

044ͷྑ্ཱ͍ͪ͛ํ

⾠ ஫ҙ ⾠ •ここからお話しする内容は個⼈的な経験則です • 確⽴された定⽯ではありません • 他の OSS の⽅々が
どうやっているかは分かりません

044ͷྑ্ཱ͍ͪ͛ํ •Onsen UI で⾏っているユーザ数増加施策: 1. OSS の成⻑指標の洗い出し何をもって「ユーザ数が伸びた」と⾒なすか、はっきりさせる 2. OSS
の成⻑指標のフル活⽤「1⽇1回⼿動でチェック」はやめよう 3. 他 OSS の成⻑指標の調査成⻑した OSS が実際にどういう推移を辿ったのか確認する 4. OSS の公開＆成⻑施策の実⾏開始データに基づいて⾏動する

<044ͷྑ্ཱ͍ͪ͛ํ> ੒௕ࢦඪͷચ͍ग़͠

044ͷྑ্ཱ͍ͪ͛ํ r ੒௕ࢦඪͷચ͍ग़͠ •何をもって「ユーザ数が伸びた」と⾒なすか、はっきりさせる • 正味のユーザ数を⾒積もるのは意外と難しい • 「知っているが使う気がない」ユーザ、「知っているが今使うタイミングにない」ユーザ、などなど、
ユーザの動態は複雑 • 直感ダメ、ゼッタイ • OSS の⾒かけの伸びと実態は著しく異なります

044ͷྑ্ཱ͍ͪ͛ํ r ੒௕ࢦඪͷચ͍ग़͠ •オススメの指標（※経験則です） (1) GitHub スター数 (2) ダウンロード数 (3)
API リファレンスのユニークユーザ数 •その他 • 公式 Twitter アカウントのフォロワー数 • Twitter、Reddit、Hacker News での⾔及数

(JU)VCελʔ਺ • 性質 • バズり具合と相関 • 実際のユーザ数との相関は⾮常に弱い • 取得⽅法
• GitHub の stargazers API を使⽤する • Accept: application/vnd.github.v3.star+json フィールドを付加すると各 star がいつ付けられたのかも取得できる • 備考 • スター数をリポジトリの UU で割ることでスター率も取れる

(JU)VCελʔ਺ https://github.com/tensorflow/tensorflow

10 100 1,000 10,000 100,000 1,000,000 (JU)VCελʔ਺ ૬৔ײ
伝説世界的に有名世界的に少し有名駆け出し解説記事が出始める ※分野によってスターの付きやすさは異なります（Web 系は付きやすい）

μ΢ϯϩʔυ਺ •性質 • たった今使ってくれているユーザの数と相関 •取得⽅法 • ダウンロードカウンタを仕掛ける • パッケージマネージャが提供する統計情報を使⽤する
• 例えば NPM の場合は npm stats microservice を使⽤する •備考 • ⾃動 DL & バージョンアップによるノイズが混⼊する

μ΢ϯϩʔυ਺

"1*ϦϑΝϨϯε ͷ ϢχʔΫϢʔβ਺ •性質 • たった今使ってくれているユーザの数と相関 •取得⽅法 • アクセス解析ツールで取得する
•備考 • ダウンロード数がうまく取れない場合に有効

<044ͷྑ্ཱ͍ͪ͛ํ> ੒௕ࢦඪͷϑϧ׆༻

044ͷྑ্ཱ͍ͪ͛ํ r ੒௕ࢦඪͷϑϧ׆༻ • 成⻑指標を洗い出しても、そのままでは「たまに GitHub でスター数を確認して終わり」「たまにダウンロード数を確認して終わり」のようになってしまう
• 短期的な変化は分かるが、⻑期的な変化が分からない • 直感ダメ、ゼッタイ

044ͷྑ্ཱ͍ͪ͛ํ r ੒௕ࢦඪͷϑϧ׆༻ • ⻑期的な変化を客観的に把握するために: • 掟 1 必ず時間推移をプロットする •
掟 2 累積値ではなく差分の時間推移を⾒る（＝累積値の時間推移は微分する） • 掟 3 移動最⼩値を使う

0 500 1000 1500 2000 2500 3000 3500 4000 4500
2014/1/1 2015/1/1 2016/1/1 2017/1/1 GitHub 044ͷྑ্ཱ͍ͪ͛ํ r ੒௕ࢦඪͷϑϧ׆༻ •掟 1 必ず時間推移をプロットするグラフ1. Onsen UI の累積 GitHub スター数ここで何かが起きたことが分かるなぜか stargazers API から得たデータでは star 数が 5000 に満たなかった…

0 2 4 6 8 10 12 14 16 18
20 2014/1/1 2015/1/1 2016/1/1 2017/1/1 GitHub (N=18) 044ͷྑ্ཱ͍ͪ͛ํ r ੒௕ࢦඪͷϑϧ׆༻ •掟 2 累積値ではなく差分の時間推移を⾒るグラフ2. Onsen UI の⽇別 GitHub スター数（＋指数移動平均）バズったタイミングがすべて分かる

044ͷྑ্ཱ͍ͪ͛ํ r ੒௕ࢦඪͷϑϧ׆༻ •掟 3 移動最⼩値を使うダウンロード数のデータはノイズが多くて分かりにくい

044ͷྑ্ཱ͍ͪ͛ํ r ੒௕ࢦඪͷϑϧ׆༻ •掟 3 移動最⼩値を使う単に平均を取るとノイズの影響を受ける

044ͷྑ্ཱ͍ͪ͛ํ r ੒௕ࢦඪͷϑϧ׆༻ •掟 3 移動最⼩値を使う移動最⼩値を取るときれいにノイズが消える

044ͷྑ্ཱ͍ͪ͛ํ r ੒௕ࢦඪͷϑϧ׆༻ •掟 3 移動最⼩値を使うデータによっては対数軸を使うと効果的

<044ͷྑ্ཱ͍ͪ͛ํ> ଞ 044ͷ੒௕ࢦඪͷௐࠪ

044ͷྑ্ཱ͍ͪ͛ํ r ଞ 044ͷ੒௕ࢦඪͷௐࠪ •例として、⾊々な OSS の⽇別 GitHub スター数の時間推移を分析

044ͷྑ্ཱ͍ͪ͛ํ r ଞ 044ͷ੒௕ࢦඪͷௐࠪ • 最初は理想的な伸び⽅をしているが、途中で崩壊 • 各バズりはリリースのタイミングとは無関係に発⽣ ※とある OSS
の⽇別 GitHub スター数

044ͷྑ্ཱ͍ͪ͛ํ r ଞ 044ͷ੒௕ࢦඪͷௐࠪ • 最初に⼤きくバズってはいるが、その後の伸びが悪い ※とある OSS の⽇別 GitHub
スター数

<044ͷྑ্ཱ͍ͪ͛ํ> 044ͷެ։ ˍ ੒௕ࢪࡦͷ࣮ߦ։࢝

044ͷྑ্ཱ͍ͪ͛ํ r 044ͷެ։ ˍ ੒௕ࢪࡦͷ࣮ߦ։࢝ • 前準備: • Web サイトの準備
• Retention ⽤媒体（Twitter アカウント, ニュースレター, ブログRSS）の準備 • ⼀度興味を持ったユーザに「受動的に」情報を得させる媒体を⽤意する • 初期段階: • Reddit, Hacker News での告知 • Hacker News 砲 • Retention ⽤媒体への誘導 • 成⻑段階: • 品質を維持しつつバズり（virality）を稼ぐ • バグフィックスやリリースはバズりには繋がらない

·ͱΊ I. OSS ⽴ち上げのメリット • 広告効果 • テスト⼯数削減 II. OSS
の⽴ち上げ⽅ • 良い⽴ち上げ⽅と悪い⽴ち上げ⽅が存在 III. OSS の良い⽴ち上げ⽅ 1. OSS の成⻑指標の洗い出し 2. OSS の成⻑指標のフル活⽤ • 時間推移をプロットする、累積値の時間推移は微分する、移動最⼩値を使う 3. 他 OSS の成⻑指標の調査 4. OSS の公開＆成⻑施策の実⾏開始

࠷ޙʹ

(JU)VCΞΧ΢ϯτΛ͓࣋ͪͷํ͸ɺͥͻ͝ࢧԉΛʂ https://github.com/OnsenUI/OnsenUI

(JU)VCΞΧ΢ϯτΛ͓࣋ͪͷํ͸ɺͥͻ͝ࢧԉΛʂ Thank you for listening!

国産 OSS 立ち上げの事情

国産 OSS 立ち上げの事情

More Decks by Naoki Matagawa

Other Decks in Programming

Featured

Transcript