#book #r2021 ![image](https://gyazo.com/ce380100939696daf5242b094a034627/thumb/1000) # Background [https://www.youtube.com/watch?v=r4QU1WJn9f8](https://www.youtube.com/watch?v=r4QU1WJn9f8) で紹介されてた本で PayPal でいかに Open Souce の文化を内外に適用してるかの話 [https://innersourcecommons.org/learn/books/getting-started-with-innersource/](https://innersourcecommons.org/learn/books/getting-started-with-innersource/) でも紹介されてた > InnerSource differs from classic open source by remaining within the view and controll of a single organization. The "openness" of the project extends across many teams within the organization. This allows organization to embed differentiating trade secrets into the code without fear that they will be revealed to outsiders, while benefitting from the creativity and diverse perspectives contributed by people throughout the organization. # Summary ## OSS が成功したこと - 世界中の誰もがコードを見れる、コメントできる、勉強できる、そして変更を出せる - 非公式な口頭での会話ではなく、公開された場所で行われる - 全体を把握していない人からの変更を受け入れるためにテストを重要視する ## InnerSource で気を付けること - OSS で重要なのは、1人のアイディアを外部の人が実現していくという世界観。InnerSource でもチームの外側の人が開発、テスト、ドキュメントなどで大きな役割をはたすことが可能 - Agile 開発は、前提として同じオフィスで密なコミュニケーションで早く動くことにある。OSSでは、そのスピード感は出ない。しかしこれを敵と考えるのではなく2つを分けて認識して両立させることが重要。 - 全体像を把握していない場合には、テストが重要になる。 - どういう部分が問題か、なんでそうなってるかをドキュメントにして説明することが大事 - OSSで成功してるほとんどがインフラストラクチャ層のプロジェクトになっている - UIは、ユーザーを想定しないといけないので外部の人がコミットするには難しい - また UI は テストピラミッドなどからもわかるように、テストが難しい領域なので、テストによる保護がうまくいかない ## Paypal の問題点と適用 - セールスエンジニアがお客さんの要望に合わせるための変更を行うがそれを本体に取り込んでもらうのが難しいため、ブランチを切って独自の実装を行っていた - -> InnerSouce 文化のおかげでどういう機能やモジュラリティが求められているかを知ることができるようになった - OSS への取り組みが強化され、様々なOSSを公開してる - GitHub でのコラボレーションが元々うまく行ってなかった - 大きな変更を外部から受け取ると、それをほとんどリライトして取り込むということをしていて、スクラッチから書くのと比較してそれほどの恩恵がなかった - ドキュメンテーションにフォーカスすることになって、この問題が解消され誰でもどのプロジェクトにもコミットができ学び、影響の大きい変更を提案できるようになった - InnerSource を許容できる体制を作るためにより多くテストが書かれ、コードレビューや静的解析も行われるようになった結果品質が向上した。 - コアメンテナが新しくこのリポジトリに変更を加える際にメンターとして働きかけるようになり、GitHub上でのやりとりなどが学びに変換されていった。また会話を見てるプログラマの教育にも繋がった。 - 適用の際には、外部からの変更を受け付けるためにドキュメンテーションやGitHub上でのやりとりを積極的に行っていくという環境の準備もあるが、マインドセットの変更も必要 - 外部からの変更をうけると、バグが増えると思ってる人もいるが実際はそんなに起きていないことはOSSの歴史からも明らかである - アーキテクチャのモジュラリティと well difined API も外部からの変更をうけるには重要 # 感想 - InnerSourceの世界観はたしかにいいなーと思いつつ、書いてあるように社内インフラや社内ライブラリでは効果を発揮しそうだけど、他のチームのプロダクト同士でうまくいくにはインセンティブがまだ足りなさそうだなと思いそこだけ悩んだ。 - とはいえ世界観は素敵だし、ドキュメンテーション、テストを充実させていく強い理由にはなった - 個人としてもテストが充実していないOSSにコミットするときは難しいなーと思ってしまうので経験からもこの辺は納得感あった。 - [[Adopting InnerSource]] という本もあるのでそれを今度は読んでみようかなと思った。 # Ref [https://innersourcecommons.org/learn/](https://innersourcecommons.org/learn/) - この辺の動画とかも見てみたいなと思った