inner source とはなにか
januswelオープンソース開発の手法を企業内開発に適用するやり方を指す。 Tim O'Reilly が作った言葉らしい。
ここでのオープンソースという言葉はゆるく「みんなに共有されているソースコード」程度の認識で良い。狭義には OpenSource Initiative が認めているライセンスが適用されたものだが、当の Tim が「ライセンスから独立した、ソースコードの共有の話だ」と発言している。
inner source をはじめるための課題として、最も大きいものは「メンテナー」の確保だろう。オープンソース開発のメンテナーは大変だ。目的や設計思想の明文化から始まり、コード規約や CI などツールの整備など地道なもの、さらに寄せられる要望やバグ報告と向き合う必要がある。さらに PR をもらったときは丁寧なティーチング / メンタリングが必要になってくる。片手間にやることは相当の無茶なはずだ。
企業内で広く使われるソフトウェアであれば専任の開発チームを充てているだろうが、そのチームにメンテナーとしての役割をあてるのが最初の一歩だろうか。
適用対象としては次がぱっと思いつく。
- DDD で言うところのコアドメイン
- 認証基盤
- 分析基盤
これらはそれぞれ事業に深く組み込まれているはずなので従業員に広く見てもらいやすいはずだ。これら以外の、例えばチームをまたいでよく使われるユーティリティなどはオープンソースとして公開すればよいだろうから、あえて inner source にする必要はないだろう。
januswelまた、チームトポロジーとの関連では、認知負荷を制御可能とするために complicated-subsystem チームなどに閉じ込めていたソースコードを公開することになるため、安易に飛びつかないこと。塩梅が難しいが、 InnerSource Commons には知見が集積されているので様子を見ながら適用していけるだろう。
januswelかなり昔からある言葉だが、なぜ最近取り沙汰されているのか？
伽藍とバザールで議論されているオープンソース開発のメリットが社会一般に浸透してきたのが今から 10 年前。緩やかにソースコードは共有したほうがいいんだという共通認識ができつつあった中で、Microsoft がオープンソース開発へ舵を切ったことは世の中の流れを一気に変えた記憶がある。この時期に開発が開始された TypeScript は Microsoft で最も成功したオープンソースソフトウェアだ。日本国内では「頻繁なリリース」を前提として置いているアジャイル開発が「普通」となったのもその後くらいのことだった。最近では、デジタル庁や経済産業省など、省庁レベルでオープンソースソフトウェアへの関与がはじまっている。
おそらくこういったメリットを企業内で実践してきた結果、「これは鉄板だ」というコンセンサスが得られたのだろう。 InnerSource Commons は 2015 年から組織されていることから推測するに、ある程度の結果がわかり、議論可能になったのが最近なのでは、ということだ。