Goにおけるインナーソースモデル構築への道のり

Transcript

1. Goにおける インナーソースモデル構築への道のり Layerx.go#4 2026/3/13 goccy
2. 自己紹介 • goccy ( ごっしー ) ◦ Twitter(新X): @goccy54 / GitHub: @goccy • Go リポジトリの総獲得 Star 数:10K+ ◦ 個人OSS: go-json / go-yaml / bigquery-emulator etc. ◦ 企業OSS: grpc-federation etc.
3. あなたの会社は 社内のOSS開発者にちゃんと報いていますか？
4. 多くの企業は OSSに支えられているけれど ... • 自社の製品がどの OSSにどれだけ依存しているか正しく 把握していますか？ • 自社が利用している OSSに貢献している社内のエンジニアを 把握していますか？ • それらのエンジニアに報いる社内制度はありますか？
5. 社内ライブラリとの向き合い方は？ • 社内で横断的に利用される内製のライブラリやフレームワークに 貢献している人を正しく評価できていますか？ • AI の台頭でエンジニアの HCを制限している場合、 これらの内製ソフトウェアの開発に貢献するエンジニア リソースを適切に用意できていますか？ • まさか...ボランティアでの開発に期待していませんか？
6. 貢献を評価や賞賛につなげる文化が必要 • ボランティア精神へ期待することの過ち ◦ 「困っている人が直してくれる」「すごい人が直してくれる」 に期待するのはやめましょう、そんな都合の良い人はいません • 組織として、誠実に評価する姿勢を示すことが大事 ◦ 貢献を定量的に評価する仕組みを用意する ◦ 定期的に賞賛したり、外部にアピールしたりする
7. 文化が育てば、貢献しやすくなる • 貢献が適切に評価される土台が整えば、貢献する モチベーションも上がるはず • インナーソースモデルはその土台があってこそ成り立つ ◦ インナーソースモデル : OSSの開発方法を内製のソフトウェアに対 して適用する試み
8. どうやって貢献を定量的に評価するのか
9. Go に限定して評価する仕組みを考える 1. リポジトリの go.mod を調べて、依存ライブラリをすべて抽出する ◦ e.g.) go mod graph 2. 「依存されているライブラリ」の方が重要だと考えてスコアをつける ◦ e.g.) 依存階層の数をそのまま加点 3. 1, 2 を社内すべてのリポジトリに対して反復操作し、モジュールごとのスコアを出す ◦ golang.org/x/sys: A repository ( 10 ) + B repository ( 20 ) = 30 4. モジュールに対応するリポジトリを見つける ◦ golang.org/x/sys: https://cs.opensource.google/go/x/sys 5. リポジトリに対する PRがマージされた数 x スコアを貢献者に加算 6. 期間を区切り、その間にマージされた PR から開発者ごとのスコアを算出 7. スコアの高い貢献者を賞賛する
10. goccy/go-modrank • Go モジュールごとにスコアを計算したり、ホストされている リポジトリを見つけてデータベースに保存するツール ◦ 前のページの 4 までを担当してくれるツール ◦ DBのデフォルトは SQLite3 だが任意のものに入れ替え可能 • Mercari ではこれを活用して依存しているモジュールを ランキング形式にして一覧できるサービスがある
11. やることは単純だが、意外と大変 • リポジトリスキャンは重い操作なので、 Org にある リポジトリが大量にある場合は考えることが多い ◦ 全部 Clone して調べる？ ◦ Go とは関係のないリポジトリも Clone する？ ◦ 並行処理する必要があるかも？ ◦ 途中で処理が中断したらどうする？ ◦ GitHub API の Rate Limit は大丈夫？
12. go-modrank がどうやって解決しているか • リポジトリクローンの最適化 • レジューム処理 • リソース最適化 • 並行処理による高速化 • モジュールのホストリポジトリの取得方法
13. リポジトリクローンの最適化 • GitHub APIによる事前フィルタリング ◦ クローン前に GitHub APIで、アーカイブ済みか go.modが存在するか を事前チェックし、不要なクローンをスキップ • GitHub Rate Limit 対策 ◦ 取得対象のリポジトリを 100件ずつチャンクに分割し、 GraphQL API でバッチリクエストを行う ◦ GraphQL の ネストが少ないため、 1 API のコストがとても軽く、 数千リポジトリあっても大丈夫
14. レジューム処理 • リポジトリを解析するたびに、ステータスを DB に保存 ◦ HEAD Commit Hash ◦ Archived Status ◦ go.mod の有無 • スキャン済み ( HEADコミットが同じ ）リポジトリは スキップできるので、途中から再開できる
15. リソース最適化 • スキャン済みの状態を DBに保存しているため、 クローンしたリポジトリは保存後に削除してディスクを節約 • CPU を使い切れるように並行処理を行う ◦ ワーカーベースの並行スキャンをサポート ◦ go.mod が 1リポジトリに複数ある場合は並行スキャンする
16. モジュールのホストリポジトリの取得方法 • Go Module Proxy (proxy.golang.org) から取得 ◦ https://proxy.golang.org/{module-name}/@latest にアクセス ◦ Response の JSON にある Origin.URL から取得 • gopkg.in の命名規則から推定 ◦ gopkg.in/{owner}/{pkg}.vN => github.com/{owner}/{pkg} ◦ gopkg.in/{pkg}.vN => github.com/go-pkg/{pkg} • go-import meta タグ ◦ https://{module-name}?go-get=1 にアクセス ◦ HTMLの <meta name="go-import"> tag の content 属性からURLを抽出 • 上から順に調べて取得
17. まとめ • インナーソースモデルを構築するためには、 貢献が適切に評価される文化が必要だと考えている • Goにおける「会社にとって重要なソフトウェアへの貢献」を定量 的に評価する仕組みを考えて OSS として提供 • goccy/go-modrank で工夫した点について紹介 • 同じ仕組みは package.json などでもできるはず、 誰か作ってみませんか？