いいねが燃料! 「自分のOSS」で1億ダウンロード突破の開発者が語る OSS 開発のリアル

by jsakamoto

Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

Slide 3

Slide 3 text

• OSS プロダクトの使い方の話… は、しません • 有名 OSS にコミットする話... は、しません • 「自分の OSS」を開発し世界へ公開することをお話します 3

Slide 4

Slide 4 text

What Kind of OSS Am I Developing? 4

Slide 5

Slide 5 text

• つまり、一定規模のアプリケーションやミドルウェアとかではない • 小粒な機能セットの、ライブラリや単発のコンポーネント • 2019 年頃からは Blazor 向けが中心 5

Slide 6

Slide 6 text

• Blazor の公式ドキュメントにも掲載 https://learn.microsoft.com/aspnet/core/blazor/c omponents/prerender?#prerendering-guidance 6

Slide 7

Slide 7 text

• Storybook を 100% Blazor で再実装 • 過去のオープンソースカンファレンス Hokkaido でも紹介 • 最近 MCP サーバー機能を追加しました https://github.com/jsakamoto/BlazingStory/ 7

Slide 8

Slide 8 text

1億超 13 https://www.nuget.org/profiles/jsakamoto 95 8

Slide 9

Slide 9 text

• すごいと思った? • でも実は裏 (?) があるんです 9

Slide 10

Slide 10 text

ChromeDriver, 67,325,743 IEDriver, 11,942,413 GeckoDriver, 7,761,313 GeckoDriver Win64, 2,676,651 その他, 29,103,485 “~Driver” だけで 75% 以上 95 パッケージのうち、この4パッケージだけで4分の3を占める WebDriver バイナリを収録しただけのパッケージ Selenium の開発に関与している訳ではない WebDriver バイナリを NuGet パッケージに仕立てているだけ 10

Slide 11

Slide 11 text

1年 2年 3年 4年 5年 6年 7年 8年 9年 10年 11年 12年 13年 0 80,000,000 160,000,000 240,000,000 320,000,000 自分 x 95 パッケージ著名OSS x 1 パッケージ 11

Slide 12

Slide 12 text

• 少しだけある • 古いですけど NPOI とか • 自分のアイディアを通すのが面倒 • 英語の壁 • そもそものスキルの課題 12

Slide 13

Slide 13 text

What Motivates Me to Develop? 13

Slide 14

Slide 14 text

• SNS でいいねをもらうこと • YouTube チャンネルでの紹介 • Microsoft 公式の ASP.NET Community Standup とか 14

Slide 15

Slide 15 text

BlazorWasmPreRendering.Build Blazing Story Blazor Gamepad Blazor i18n Text Find Razor Source File Awesome Blazor Browser 15

Slide 16

Slide 16 text

ユーザーは @jsakamoto をおだてておけば、ライブラリが手に入る @jsakamoto は、おだてられたらドーパミンが分泌される 16

Slide 17

Slide 17 text

• 日本語文化も大事にしたいです • しかしソフトウェア界隈は英語話者の数が圧倒的に多い • たくさんいいねをもらうには、英語で発信したらいいのでは... ! • 幸い、近年の機械翻訳は秀逸 17

Slide 18

Slide 18 text

• 言い訳心の安寧が得られる • 金銭での対価は払っていないが、 OSS コミュニティに貢献してるから、という免罪符 • OSS は、消費するだけだと枯れてしまいかねない • OSS の “フリーライド” それ自体には罪悪感を感じる必要はない • ただし、Issue 報告して保守してもらうばかりだと作者の心が折れる • 何の解決にもならないが、自分で OSS を開発・公開するようになって、他 OSS への不具合報告にめっちゃ気を遣うようになった 18

Slide 19

Slide 19 text

Choosing an OSS License 19

Slide 20

Slide 20 text

利用者側には制約を求めたくない • ソースコードの開示不要 • 商用利用可派生物はソース開示を強制したい • Fork されてもオープンソースであることを堅持したい • 放棄された OSS を fork しクローズドで配布するビジネスを許したくない 20

Slide 21

Slide 21 text

• 利用者側には制約を求めたくない • GPL ではいいねがもらえなく利用者がいなくなってしまう心配 • 派生物はソース開示を強制したい • そこで LGPL を採用 • LGPL は利用している側のソースコードの開示不要… と理解していた • .NET 向けライブラリなので基本的に動的リンクなので • しかし、利用者側のリバースエンジニアリングを許可する必要があった • 静的リンクしていないことを証明するため、らしい 21

Slide 22

Slide 22 text

• MIT License • オープンソースであることにこだわらない場合 • それよりも利用しやすさを優先する場合 • The Unlicense • 独自性・独創性がなさすぎなもの • Selenium WebDriver のパッケージに採用 22

Slide 23

Slide 23 text

Honestly, Is It Profitable? 23

Slide 24

Slide 24 text

• お金もらうと責任が大きくなりそう • いいねが欲しいだけで個人の “楽しみ” としてやっているので • “金払ってるんだから” という理由で態度でかい人が出現しそうで怖い • でも最近、README に Banner を掲載する系の広告モデルが気になってはいる 24

Slide 25

Slide 25 text

• OSS 活動により Microsoft MVP Award を受賞 • Microsoft MVP Award の特典がなかなかによい 25

Slide 26

Slide 26 text

Challenges in OSS Development 26

Slide 27

Slide 27 text

• 調子にのって本数を作りすぎた • 95 パッケージ • 保守が大変 • Issue 登録されても数ヶ月着手できないとか • 既存のパッケージの改善も遅々として進まず • 新しいものを学んだり作ったりする時間が削られる • 作りたいパッケージのアイディアはまだ湧いてくる 27

Slide 28

Slide 28 text

構想・リサーチ 7% 本体機能の実装 14% テスト開発 21% README の作成 57% ※体感上のイメージです 28

Slide 29

Slide 29 text

• README の作成がいちばんしんどい • しかもこだわりで英語で書かなくてはならない縛り • 生成系 AI のおかげでだいぶん楽にはなってきた • でもここを一番がんばらないといいねが使ってもらえない • このライブラリで何ができるのか・何を解決するのかを冒頭ではっきりさせる 29

Slide 30

Slide 30 text

• 「あなたのライブラリを使ったら、エラーになりました」 • ビルド時のエラー? 実行時のエラー? • 何をどう操作したのか? • エラーメッセージとスタックトレースは? • ブラウザやプラットフォームのバージョンは? • 普通には自分の手元で再現しない • 再現用のサンプルプログラムが添付されていれば、解決が早くなる 30

Slide 31

Slide 31 text

• 「我が社の製品はあなたのライブラリを使用しています。あなたのライブラリにセキュリティ上の脆弱性があるかどうか、 1 営業日以内に返答してください。」 • そういう厳格さが求められる界隈があるのはわかる • けれども責任持てないですよ • 多くの OSS およびその利用許諾では、利用者が責任を持つ 31

Slide 32

Slide 32 text

• 本質的な変更に加えて、あらゆるファイルのコーディングスタイルを変更 • this を付ける/付けないとか、静的メソッドを拡張メソッドにするとか、そういうレベルの変更を含む • 迂闊に Merge すると何が紛れ込むか恐ろしい • 個人活動の OSS なので変更内容の把握に時間を割きたくない 32

Slide 33

Slide 33 text

• スキマ時間で開発してるので、自分の書いたコードや設計を忘れる • 95 パッケージもあるし • バグ修正や機能追加でデグレーションが容易に発生し得る • 自動化テストの整備は必須 • 自動化テストがあるおかげで、安心してコードの変更ができる • コードが腐らない • 継続したソフトウェアの維持発展に欠かせない • テストを書くのも楽しいよ 33

Slide 34

Slide 34 text

The Rise of AI and the Future of OSS Development 34

Slide 35

Slide 35 text

• チャットアプリ • ChatGPT • Google Gemini • Claude • GitHub Copilot Pro+ • よく使うモデルは GPT-4.1 と Claude Sonnet 4 • Agent モードはあまり使った実績がない • コード補完を常用 35

Slide 36

Slide 36 text

• README を書くのがずいぶんと楽になった • 機能追加部分の書き足しの草稿とか • バージョン移行用のガイドの作成とか • とくに英語で書いてもらえるのがうれしい • ドキュメントコメントを書くのが劇的に楽になった • おおむね手放しで任せられる感じ 36

Slide 37

Slide 37 text

• コーディング作業は結局、おおむね今までどおり • コード補完で、若干の作業効率の向上はある • ChatGPT の Web 検索で調べ物の効率は向上した • コーディングをまるごと任せられる感じがしない • Vibe Coding とか流行っているようではありますが... • 待ち時間ばかりかかって生産性を感じない • コーディングは “楽しみ” なので AI に押しつけたい動機が低い • “自分だけが取り残されるのではないか” の不安から試してはいるけど 37

Slide 38

Slide 38 text

• 正直、未来のことはわかりません • いまはまだダメな感じにみえるコーディング技能だって、ここ数年の進化をみると、数年後、数ヶ月後にはどうなっているかわからない • UI コンポーネントライブラリは、AI にCSS生成を任せるヘッドレスタイプが流行るのではという記事を見た覚え • でも自分の観測範囲では、まだまだ旧態依然としたライブラリが元気な印象 • 何かは変わっていくんでしょうけど、無くなることもなさそう 38

Slide 39

Slide 39 text

Conclusion 39

Slide 40

Slide 40 text

• 自分の OSS を開発・公開する、という関わり方もある • 使うだけでもない • 既存の著名 OSS に貢献するのでもない • 不純な動機でも構わない • 世界のどこかの誰かのためになれば Win-Win • その手段としての OSS 開発活動 • もちろんマネタイズも • いかにして持続可能にするか 40

Slide 41

Slide 41 text

• 「自分の OSS」作りに挑戦したいあなたに • 実際に歩を進めるきっかけ、または今後の指針の参考になれば幸いです • OSS を使いつつ、様々な製品開発で価値創造しているあなたに • ユーザーへの貢献、ありがとうございます • いっぽうで OSS を開発・公開している人たちにも励ましの一言を • 不具合報告の際はできれば再現サンプルの提示を 41