会社の OSS 活動を促すための Open Source Program Office

この記事は [株式会社ビットキー Advent Calendar 2023](https://qiita.com/advent-calendar/2023/bitkey) 9日目の記事です。

---

今年、会社の OSS 活動を進めなければと思った出来事が 2 つありました。

1 つは [Flutter にコントリビューションしたとき](https://github.com/flutter/flutter/pull/128566) の Contributor License Agreement (CLA) についてです。弊社の一部のアプリでは Flutter を利用しているのですが、開発中に不便な `assert` を見つけて修正の PR を出しました。このとき、 CLA に同意するには 2 つの方法があって、個人として署名する方法と会社の社員として署名する方法です。真面目にやるのであれば後者なのですが、会社側で Google Groups を登録するなどして体制を整える必要があったため、当時は個人として CLA に同意することにしました。

もう一つは同僚のスポンサー登壇資料の置き場が無かったことです。 [iOSDC 2023 スポンサーセッション「真似できる！実践的なプロジェクト構成 ~ bitkey流簡単レシピ ~ 」](https://fortee.jp/iosdc-japan-2023/proposal/a5870a6e-a470-4ee0-9a4b-58b6f4f5ca5d) で @arasan01 が登壇したのですが、このときのサンプルコードをどこに置こうか？という話になりました。

この 2 つのできごとをきっかけに、 GitHub に [bitkey-oss](https://github.com/bitkey-oss) を作成して OSS 活動を支援することにしました。

https://github.com/bitkey-oss

# Open Source Program Office

このような活動を行う部署は Open Source Program Office (OSPO) と呼ばれるようです。

今年の 3 月に、 GitHub が OSPO を立ち上げるためのツール・プロセス・ベストプラクティスをまとめた [github/github-ospo](https://github.com/github/github-ospo) というリポジトリを作成していた [^PK] [^GHBLOG] のを見て、参考にすることにしました。

また、 [Google Open Source](https://opensource.google/documentation/reference) も実際の例として参考にしました。非公開のドキュメントもありますが、プロセスや制度の一部が公開されています。主に "must" とか "don't" で強く書かれている部分はウチもそうした方が良いかもと思って読んでいました。

[^PK]: https://www.publickey1.jp/blog/23/githubopen_source_program_office.html
[^GHBLOG]: https://github.blog/2023-03-13-an-open-source-project-to-empower-ospos-everywhere/

# やったこと

## bitkey-oss の作成

興味がありそうな人たちに声をかけて名前を決めて Organization を作成しました。

## 社内 Slack チャンネルを作る

窓口としての Slack チャンネルを作成しました。

## 社内ドキュメントとルールの整備

### "会社の" OSS にする例

「これは会社の OSS にして良いよね」という価値観を揃える意味でも例を書くことにしました。

> - 会社がスポンサーを行うコミュニティやイベントの活動で発生したソフトウェア
> - 広く製品の利用を促進するクライアント・プラグイン・ライブラリ
> 
> これらに含まれない目的で OSS を立ち上げようとする場合も Slack でご相談ください。

会社によっては、「一般的な知識・技術の研修資料」や「会社で利用しているメンテナンスされなくなった OSS を引き継ぐ」みたいなケースも含めたりすると思います。文化や方針次第でいろいろ出てくるとは思いますが、とりあえずの v1.0 を出してみた感じです。

## bitkey-oss に対するリクエストの整備

基本的に下記の操作を受け付けられるように整えれば GitHub Orgranization を運用できると考えました。

1. リポジトリを作成したい
    a. 一旦 Private で作成してリポジトリの Admin 権限を付与
    b. 準備ができたら確認
    c. Public にする
2. 他の Public リポジトリを Fork したい
    a. 一旦 Private で作成してリポジトリの Admin 権限を付与
    b. 準備ができたら確認
    c. Public にする

このときの確認事項はいろいろと定めています。機密情報が含まれていないかというのは当然ですが、履歴に含まれている可能性も考慮して、リポジトリを作成時には原則 `git init` から作り直すように求めています。

推奨のライセンスは MIT か CC BY 4.0 が良いと思います。使い分けは [github-ospo のポリシー](https://github.com/github/github-ospo/blob/main/policies/licensing.md) を真似します。同時に著作者として記入すべき文字列も定めておいた方が良いでしょう。

また、社内のスプレッドシートではリポジトリごとの代表者を管理しています。 Issue や PR を放置してしまうとやはり会社の印象として良くないため、 GitHub の SNS 的な側面もうまくサポートしていきたいと考えています。

## CLA のサポート

OSPO を立ち上げるきっかけとなった CLA の署名やメーリングリストの管理を行うことにしました。ただ、現実的には CLA への署名が必要になるケースはなかなか無いので、やると宣言しているだけです。必要になったときに会社の法務に相談する心構えだけしています。

# 終わりに

DevRel や Advocate といった活動が盛んになる中での資料公開や、ライブラリ・ツール本体に貢献するというモチベーションで、 Open Source Program Office (OSPO) を立ち上げました。事業会社が OSS をやる合理性というのは、このあたりにある気がしています。

正直な話あまり再現性は無いかもしれません。自分が創業5年の会社の古参だったからこそできたという所も多分にあると思います。何を会社の OSS にするか？や Public にする前の確認の内容をまとめるには、会社によっては相当な労力が必要だろうなと想像します。怒られてから考えようのスタンスで進められる規模だったからこそできた（今のところ怒られてないです）のはラッキーだったなと思っています。

---

10日目の [株式会社ビットキー Advent Calendar 2023](https://qiita.com/advent-calendar/2023/bitkey) は @maruware が担当します！