10.18 オープンソースプログラムオフィス(OSPO)とアップストリームへの貢献

概要と動機

あなたの組織はすでにオープンソースソフトウェアの上で動いています。プロダクトを運ぶオペレーティングシステム、言語、データベース、ライブラリは、ほとんどが、あなたのために働いていない人々によって書かれています。10.3章は調達とライセンスのコンプライアンスを、10.12章はオープンかクローズドかの決定を扱います。この章は、そのすべてを一貫させる機能についてです。オープンソースプログラムオフィス(OSPO)、つまり会社がオープンソースをどう消費し、貢献し、公開するかを所有するチーム。OSPOは、そうでなければimportと打つすべてのエンジニアに広がっている関係の、重心です。

ほとんどの組織は、一度に一つの依存関係ずつ、オープンソースになし崩しに入り込み、それから蓄積された露出を一度に発見します。買収のデューデリジェンスの間のライセンスの問題、疲れ果てた一人のメンテナーしかいない重要なライブラリ、誰も出荷していると知らなかったコードのセキュリティ勧告。OSPOは、その大慌てを管理された能力に変えます。ブロックするのではなく可能にする消費の方針を設定し、アップストリームへの貢献が事業に仕えるのはいつかを決め、公開するプロジェクトのスチュワードを務め、InnerSourceを通じて会社の内側でオープンな協働を適用します。これはコンプライアンスのチェックボックスではなく、ソフトウェアエンジニアリングの価値(1.1章)とつながる戦略的な機能です。

企業にとって、駆動要因は規模です。数千の依存関係、法域にわたる輸出とライセンスの義務、毎日小さなオープンソースの決定を下す数百人のエンジニア。単一のオフィスは、その広がりに背骨を与えます。政府にとって、駆動要因は方針と公的な信頼です。「既定でオープンソース」と「公金には公開コード」はますます法律になっているので、公的機関には、コードを安全に公開し、機関間で再利用し、ベンダーをオープン標準に縛れる人が必要です。どちらの設定でも、OSPOは、見えず値段のつかないリスクを、意図した予算のある仕事に変えることで、元を取ります。

主要原則

オープンソースは無料の倉庫ではなく、双方向の関係である。 消費し、貢献し、公開し、OSPOはその三つすべてを所有します。
貢献は慈善ではなく戦略である。 アップストリームへの貢献は私的パッチを抱えるコストを減らし、影響力を買います。
速い道を可能にし、門を守らない。 コードをコピーするより遅い方針は無視されるので、準拠した道を最も速くします。
依存するメンテナーに資金を出す。 共有地は自ら維持されず、最も重要なライブラリには無給の作者一人しかいないかもしれません。
公開するものはスチュワードを務める。さもなければ公開しない。 放棄されたプロジェクトは、プロジェクトがまったくないより評判を傷つけます。
改善できるよう、関与を測定する。 プレスリリースではなく、貢献、依存関係の健全性、承認までの時間を数えます。
政府では、既定でオープンにし、既定で公開する。 オープンさが規範で、閉じることは文書化された例外です。

推奨事項

現実に合う規模でOSPOを立ち上げる

始めるのに大きなチームは必要ありません。スタートアップでは、OSPOは、書かれた使命を持ち、週に数時間を割く一人のエンジニアでありえます。企業では、小さな中央グループに、プロダクトチームに埋め込まれた推進者の連合ネットワークを加えたものです。規模にかかわらず、四つの責任をカバーする明確な憲章を与えます。消費の方針とコンプライアンス、アップストリームへの貢献、自社プロジェクトの公開とスチュワードシップ、コミュニティと資金の関係。エンジニアリングと法務の両方が見える場所に置きます。しばしばCTOあるいはエンジニアリングのVPに報告し、法務とセキュリティへの点線を伴います。失敗の様式は、完全に法務の内側に住んでブレーキになるOSPOです。修正は、出荷するエンジニアを配置し、その指針が、仕える相手のチームで信頼性を持つようにすることです。

責任を持って消費し、安全な道を容易な道にする

消費はリスクの大半が入ってくる所なので、良い行動を労力なしにします。審査済みコンポーネントの選り抜きの内部カタログ、パイプラインでの自動のライセンスと脆弱性のスキャン、開発者がチケットを出さずに従える明確な既定を提供します。10.3章のライセンスの規律と、2.18章のサプライチェーンと依存関係の健全性の実践に頼ってください。バージョンを固定し、ソフトウェア部品表を生成し、侵害された、あるいは放棄されたパッケージをソフトウェアサプライチェーンで見張り、移行を強いられる前に寿命の終わりを追跡します。OSPOの仕事は、すべての依存関係を手作業で承認することではありません。選択の95パーセントが自動的に安全であり、本当に変わったケースだけが人間に届くように、ガードレールを築くことです。

良いことだからではなく、元が取れるからアップストリームに貢献する

アップストリームへの貢献を経済的な決定として扱います。依存関係に対して抱えるすべての私的パッチは、変更がアップストリームに着地するか、フォークが乖離して完全に自分のものになるまで、あらゆるアップグレードで永遠に払う税です。修正を還元することは、その税を削除します。アップストリームへの貢献はまた、方向への影響力を買うので、頼るコンポーネントのロードマップがあなたのニーズに向かって曲がり、採用したいエンジニアに能力を示します。開発者に、速く文書化された道を与えます。事前に承認された貢献者ライセンス契約あるいはDeveloper Certificate of Origin、変更が共有して安全であることを確認する軽量な承認、仕事のために予算が付けられた管理者の時間。代替案が、制御できないプロジェクトの恒久的なフォークを保守することなら、還元することはほとんど常により安いのです。

本物のガバナンスで自社プロジェクトを公開する

築いたソフトウェアをオープンソース化するときは、意図して行うか、まったく行わないかです。まず、コードが共有する価値のあるコモディティか、閉じておく価値のある差別化要因かを、10.12章の推論で決めます。公開するなら、意図に合うライセンスを選び(採用を最大化するなら寛容、エコシステムを互恵に保つならコピーレフト)、誰が何を決めるかを書かれたガバナンスのモデルで文書化し、コードを自由に保ちながら誤用から守れるよう、プロジェクト名に商標を登録します。本物のスチュワードシップにコミットします。公開の課題トラッカー、貢献ガイド、行動規範、報告者があなたに連絡する方法がわかるよう協調された開示を伴うセキュリティ方針(4.2章)。メンテナーを名指しし、その時間に予算を付けます。盛大に立ち上げて1年で放棄するプロジェクトは、一度も出荷しなかったプロジェクトより、評判に大きな損害を与えます。

InnerSourceを適用して会社の内側で協働する

オープンソースを機能させる習慣(公開リポジトリ、明確な貢献ガイド、実力によるレビュー、最初のパッチへの低い障壁)は、ファイアウォールの内側でもまったく同じように機能します。InnerSourceとは、どのエンジニアも社内のどのプロジェクトも見つけ、使い、改善でき、チケットを出して待つ代わりに、チームの境界を越えてプルリクエストを送れることを意味します。これはサイロを壊し、コードの再利用を広げ、外部に貢献するときに使うまさにそのワークフローで人々を訓練します。OSPOは、すでにツールと文化の手引きを所有しているので、InnerSourceの自然な住処です。価値の高い少数の共有ライブラリから始め、その貢献ガイドを社内に公表し、外部のパッチを気持ちよく受け入れるチームに報います。

依存するメンテナーに資金を出し、支える

本番システムは、余暇に一人が保守するライブラリの上に乗っているかもしれません。それはサプライチェーンのリスクで、誠実な対応は、荷を担う手助けをすることです。部品表から最も重要な依存関係を特定し、メンテナーの基盤が薄いものを見つけ、それぞれについて対応を選びます。メンテナーを直接スポンサーする、エンジニアリングの時間を貢献する、プロジェクトに資金を出す財団に加わる、あるいは最後の手段として、フォークあるいは置き換えを準備する。共有地への資金提供は、その崩壊に続く緊急事態より安く、頼るコンポーネントを健全に保ち、影響を及ぼせる方向に動かし続けます。

速く承認する貢献方針を設定する

貢献方針は、遅くノーと言うためではなく、素早くイエスと言うために存在します。エンジニアが尋ねずに貢献してよいもの(バグ修正、文書、すでに使っているプロジェクトへの小さな機能)、軽いチェックが必要なもの(差別化要因や特許に触れるもの)、知的財産と貢献者の合意が貢献ごとではなく一度に中央で扱われる方法を明記します。退屈な部分を自動化します。ライセンスのチェック、事前に署名された企業の貢献者合意、人間の目が必要なまれな提出に旗を立てるボット。承認までの時間を測り、遅いキューを方針のバグとして扱います。

トレードオフ: 長所と短所

アプローチ	長所	短所
中央のOSPO	一貫した方針、深い専門性、明確な所有	門番になるだけで可能にしないとボトルネックになりうる
連合型のOSPO(チームの推進者)	スケールする。決定をエンジニアの近くに保つ	強い調整がなければ方針がずれて離れる
アップストリームに貢献	私的パッチの税を削除。影響力。採用に役立つ	継続的な労力、IPレビュー、他者のスケジュールでの仕事
私的なフォークを抱える	完全な制御、自分のタイムラインで出荷	恒久的な保守の税。アップストリームのセキュリティ修正から乖離
自社プロジェクトを公開	エコシステム、評判、共有の保守	本物のスチュワードシップのコスト。放棄は評判を傷つける
メンテナーに資金を出す	重要な依存関係を守る。善意を買う	直接のコスト。誰に資金を出すかを選ぶのは政治的
OSPOなし(その場しのぎ)	立ち上げコストゼロ	見えない法的、セキュリティ、持続可能性の負債

中心的な緊張は、制御と可能にすることの間にあります。すべての依存関係とすべての貢献を手作業でレビューするOSPOは安全に感じられますが、エンジニアが迂回するものになり、防ごうとした見えない影の依存関係を生みます。自動の徹底なしに陽気な指針を公表するだけのOSPOは、期限が迫った瞬間に無視されます。解決は、10.3章を貫くのと同じものです。準拠した道が最も速い道になるよう一般的なケースを自動化し、人間の判断は本当に新しいものに取っておく。そのバランスが正しければ、オフィスは力の倍増装置で、どちらかの方向に誤れば、ブレーキか飾りです。

チームで議論すべき問い

今日、オープンソースとの関係を誰が所有していて、明日、難しい問いに答えられますか。 買収を考える側の弁護士が、ライセンスの目録を求めたり、記者が、支払いの経路のどの保守されないライブラリがあるかを尋ねたりしたら、答えに名前は付いていますか。ほとんどの組織にとって、誠実な答えは「誰もいない」で、それは、すべてのエンジニアが静かに方針を作り、合計に説明責任を負う人がいないことを意味します。証拠を会議に持ち込んでください。承認済みライセンスの一覧、ソフトウェア部品表、デューデリジェンスの間にコピーレフトの質問を受ける人を出してみます。それらの成果物が存在しない、あるいは誰も指さないなら、最初のOSPOのタスクを見つけたのです。下すべき決定は、機能を持つかどうかではなく、誰がそれを所有し、どんな使命を負うかです。オフィスが週に1日の一人であっても。
アップストリームできる私的パッチを抱えていて、それは何を代価にしていますか。 多くのチームは、依存関係に対する局所的な変更の静かな山を保守し、アップグレードのたびに手作業で再適用し、マージの苦痛を自然の法則のように吸収しています。それらのパッチのそれぞれが繰り返される税で、それぞれが税が消えるよう還元する候補です。具体的に持ち込んでください。ビルドが実際に抱えるフォークと局所的なパッチを一覧にし、それぞれが年間に費やすエンジニアリングの時間を見積もり、どのアップストリームのプロジェクトが変更を受け入れそうかに注意します。相反する考慮は本物です。アップストリームへの貢献は今労力を要し、メンテナーのスケジュールで動きますが、比較は永遠にパッチの税を払い続けることに対してです。答えは、「いつも単に再適用する」を、エンジニアが使うほど速い貢献の経路を伴う、意図した選択に変えるべきです。
メンテナーが去ったら最も痛手となる依存関係はどれで、それについて何をしますか。 スタックのどこかに、壊れれば収益や使命に不可欠なサービスを止めるコンポーネントがあり、それはあなたが資金を出したことも感謝したこともない一人か少数の人が保守しています。共有地は、そうでなくなる瞬間まで無料に感じられ、その教訓の高価な版は、放棄の後の慌てや、パッチの当たっていない脆弱性です。部品表を持ち込み、依存関係を影響範囲で順位づけ、上位数個のメンテナーの数と資金の状況に注意してください。重要で人員の薄い各依存関係について、スポンサーする、時間を貢献する、財団に加わる、置き換えを準備するかを事前に決めます。それは潜在的な単一障害点を、他のあらゆる運用上のリスクと同じ基準で扱われる管理された関係に変えます(2.18章)。
次の社内ツールをオープンソース化する前に、何年もスチュワードを務める準備はできていますか。それとも、ローンチと最終的な謝罪を出荷しようとしていますか。公開リリースは常設のコミットメントです。誰かがトリアージしなければならない課題トラッカー、誰かが見張らなければならないセキュリティの受信箱、誰かが守らなければならない名前。チームは採用や善意のためにオープンソース化に手を伸ばし、それから、古い課題を抱えて放棄されたプロジェクトが、何も出荷しなかった場合より、築こうとした評判を傷つけると発見します。証拠を持ち込んでください。すでに公開したプロジェクトを一覧にし、それぞれについて、課題の古さ、名指しされたメンテナーが予算の付いた時間を持つか、ガバナンスのモデル、登録された商標、協調された開示の方針があるか、コードが共有する価値のあるコモディティか閉じておくべき差別化要因か(10.12章)を示します。相反する考慮は、本物のスチュワードシップがプロダクトに使えるはずのエンジニアリングの時間を費やすので、誠実な選択はしばしば、より少なく公開してきちんとスチュワードを務めることです。企業にとってこれは、ローンチ前の法務とブランドのレビューを意味し、政府にとっては、リポジトリが公開される前に、商標、開示の経路、既定で公開からの免除のプロセスが決着していることを意味します。
エンジニアが依存関係の承認や貢献の許可を得るのに実際にどれだけかかり、それはあなたを迂回するより遅いですか。 オープンソースの方針は、エンジニアが見つけられる最速の回避策と直接競合し、コードをコピーするより遅いプロセスは迂回されて、オフィスが防ぐはずだった見えない影の依存関係を生みます。緊張は制御対可能にすることです。すべての手作業のレビューは監査証跡を加え、まれな本物の問題を捉えますが、中央値のケースを準拠した道から押し出す遅延も加えます。数字を会議に持ち込んでください。標準の依存関係と標準の貢献の測定された承認までの時間、自動的に扱われた決定と人間が扱った決定の割合、先四半期に本当に判断を要した例外の数。毎日小さな決定を下す数百人のエンジニアがいる企業では、2日のキューが静かに数千の迂回されたレビューになります。政府では、同じ遅延が、回避策が飛ばす証跡を要求する調達と監査の義務と衝突するので、修正は、より大きな門に人員を置くことではなく、一般的なケースを自動化することです。
どの社内プロジェクトがInnerSourceから最も恩恵を受け、今日、他のチームがあなたにプルリクエストを送るのを何が妨げていますか。 オープンソースを機能させる実践(公開リポジトリ、貢献ガイド、実力によるレビュー、最初のパッチへの低い障壁)は、サイロを壊し、再利用を広げ、外部に貢献するときに使うまさにそのワークフローで人々を訓練するので、ファイアウォールの内側でも元を取ります。相反する考慮は、社内のプロジェクトを開くには、貢献ガイド、予備のレビュー容量、セキュリティや規制上の理由でどのコードを制限したままにするかの決定が必要なことです。具体的に持ち込んでください。価値の高い共有ライブラリを名指しし、すでに社内の貢献ガイドを公表しているものに注意し、チーム間のプルリクエストが今日どう扱われるか、歓迎されるか、キューで失われるかを説明します。企業にとって見返りは、多くのチームにわたって避けられた社内の重複した構築で測られ、政府にとっては、同じ習慣が機関の境界を越えた機関間の再利用へと広がり、既定での公開と共有のコンポーネントが、公的支出の重複を増やすのではなく減らします。

セクター別の視点

スタートアップ。 オフィスを委員会ではなく、1ページの憲章を持つ、週に数時間を割く名指しされた一人のエンジニアに与えてください。既定で寛容なライセンスにパイプラインのスキャナーを付け、アップグレードのたびに本当に痛む少数の私的パッチだけをアップストリームし、本当にそれなしでは生きられない一人が保守するライブラリに小さな月次のスポンサーシップを設定します。ここではカバレッジより速度が重要です。誰も従わない徹底した方針より、コードをコピーするより速い準拠した道のほうが勝ります。

小規模事業者。 専任のOSPOに人員は置けないので、すでに動かしているツールに組み込まれた能力を買ってください。ライセンスと脆弱性の問題に旗を立てるスキャナーと、審査済みコンポーネントの選り抜きのカタログ。仕事をプログラムとしてではなく、ライセンスのコンプライアンスと依存関係の健全性の衛生として枠づけます。ソフトウェア部品表に何があるか、各ライセンスが何を義務づけるか、消えたら痛手となる単一メンテナーの依存関係はどれかを知る。自前で築くより、スキャンとカタログ化を買うことを好みます。

大企業。 方針は一貫し、決定はエンジニアの近くに保たれるよう、小さな中央のオフィスに、プロダクトチームに埋め込まれた推進者の連合ネットワークを加えて運営してください。ライセンス、脆弱性、輸出のスキャンを自動化し、すべてのエンジニアを初日から事前承認された貢献者合意でカバーし、承認までの時間を報告される指標として追跡します。重要な依存関係の背後の財団に資金を出し、多くのリポジトリにわたってInnerSourceを運営し、全体の資産群を、個々の決定の寄せ集めではなく、健全性と関与の指標を伴うポートフォリオとして管理します。

政府。 既定でオープンソースと、公金には公開コードのもとで運営してください。文書化されたセキュリティあるいはプライバシーの免除が適用されない限り、新しいサービスを公開リポジトリに公表します。チームが築く前に再利用するよう、政府横断のカタログを運営し、ベンダーが権利を保持した再利用可能なコードを届けるよう、オープンソースとオープン標準の要件を調達に書き込み、公表するものについて協調された開示を扱います。複数の機関が依存する共有ライブラリの保守に資金を出し、どの単一のチームも、政府全体が頼るコンポーネントを静かに所有しないようにします。

事例

スタートアップ。 20人のスタートアップは、主力のプラットフォームエンジニアを、1ページの憲章を持つ兼任のOSPOオーナーにします。彼女は単純な消費の方針(寛容なライセンスは事前承認、コピーレフトはレビュー、パイプラインにスキャナー)を設定し、チームがオープンソースのキューライブラリに対して三つの私的パッチを抱え、アップグレードのたびに苦労して再適用していることに気づきます。彼女は三つすべてをアップストリームし、二つは1か月以内に受け入れられ、アップグレードの税を永遠に削除します。主に技術者を引きつけるため、きちんとしたREADME、ライセンス、セキュリティの連絡先を備えた小さな社内ツールを一つオープンソース化し、プロダクトが依存する一人が保守するパーサーに月次のスポンサーシップを設定します。これに人員は要らず、名指しされた所有者と明確な使命だけです。

大企業。 世界的な銀行は、6人の中央のOSPOに、各プロダクトグループに埋め込まれたオープンソースの推進者の連合ネットワークを加えて運営します。中央チームは、方針、自動のライセンスと輸出コンプライアンスのスキャン、すべてのエンジニアが初日からカバーされる貢献者ライセンス契約を所有します。推進者は局所的なレビューを扱い、チームに貢献を指導します。銀行は、取引システムを支えるプロジェクトの財団にいくつか資金を出し、フォークの保守をやめるために広く使われるデータフレームワークにアップストリームで修正を貢献し、どのチームも他のどのチームにもプルリクエストを送れるよう、200の社内リポジトリにわたってInnerSourceを運営します。標準の貢献の承認までの時間は2日未満で、OSPOが四半期ごとに報告する指標として追跡されます。

政府。 国のデジタル機関は、「既定でオープンソース」と公金には公開コードの義務づけのもとで運営されます。そのOSPOは、セキュリティあるいはプライバシーの文書化された免除が適用されない限り、新しいサービスを公開リポジトリに公表し、機関が築く前にコードを再利用するよう政府横断のカタログを運営し、ベンダーが政府が権利を保持した、再利用可能でよく文書化されたコードを届けるよう、オープンソースとオープン標準の要件を調達に書き込みます。オフィスはまた、公表するコードの協調されたセキュリティの開示を扱い、いまや複数の機関が依存する共有のアイデンティティライブラリの保守に資金を出すので、どの単一のチームも、政府全体が頼るコンポーネントを静かに所有しません。

ビジネスケース: 動機、ROI、TCO

最も明確な見返りは、避けられる高価な驚きの排除です。管理されないオープンソースは、自分のスケジュールで到来する危機を生みます。買収のデューデリジェンスで表面化するコピーレフト違反、死んだコンポーネントからの緊急移行、どの目録にも載っていなかった依存関係にたどれる侵害。OSPOは、それらの低確率で高コストの出来事を、安定して予算化された仕事に変えます。アップストリームへの貢献からの繰り返される節約を重ねます。退役させるすべての私的パッチは、将来のすべてのアップグレードへの課税を止め、大きな資産群では、それがプロダクトの仕事に戻される本物のエンジニアリングの容量へと複合します。

総所有コストの帳簿では、オフィスは守るものに比べて安い。そのコストは、小さなチーム、いくらかのスキャンとカタログのツール、控えめなメンテナーへの資金提供です。それをなくすコストと比べてください。法的責任、失敗あるいは遅延したデューデリジェンス、セキュリティインシデント、すでにオープンソースとして存在するものの社内での重複した構築、誰も保つと選ばなかったフォークの緩やかな出血。評価しにくいが本物の上振れの見返りもあります。依存するコンポーネントの方向への影響力、信頼できるオープンソースの存在感からの採用と評判の優位性、エンジニアが再構築ではなく再利用するためのより速いデリバリー。リーダーシップに論拠を示すときは、OSPOを、コードベースの大半のためのサプライチェーン管理に、戦略的な配当を加えたものとして枠づけてください。政府では、コンプライアンスの次元を加えます。オープンさはしばしば義務づけられており、うまく行えば、不遵守と重複した公的支出の両方を避けられるからです。

アンチパターンと落とし穴

門としてのOSPO。 レビューしてブロックするだけで決して可能にしないオフィスは迂回され、防ぐはずだった影の依存関係を生むこと。
貢献の劇場。 オープンソースの戦略を告知しながら、承認のプロセスを誰も実際には貢献しないほど遅くすること。
放棄されたリリース。 ローンチのブログ記事とともにプロジェクトを公開し、それから課題を一つもトリアージせず、沈黙より評判を傷つけること。
フォークして放置。 一つの修正のために依存関係をフォークし、それから永遠に抱え、アップストリームのセキュリティパッチから乖離すること。
脆いメンテナーへのフリーライド。 重要な単一メンテナーのライブラリに依存しながら、その背後の人に資金を出さず、感謝せず、助けないこと。
商標の放置。 プロジェクトの名前を守らずに公開し、フォークやベンダーがあなたの評判を利用するのを眺めること。
法務だけの所有。 OSPOを完全に法務に置くので、その指針がエンジニアリングの信頼性を持たず、チームが聞き流すこと。
虚栄の指標。 依存関係の健全性、承認までの時間、退役した私的パッチではなく、スターの数やプレスの言及を数えること。

成熟度モデル

レベル1、開始: エンジニアは方針も所有者もなくオープンソースを追加し、パッチを当て、時折公開します。消費、貢献、公開は反応的でその場しのぎで、個人の主導に駆動されます。私的なフォークは気づかれずに蓄積し、誰も上流のプロジェクトに資金を出さず、デューデリジェンスの間にライセンスの問いに答えられる人はいません。
レベル2、発展: 基本的な実践が現れますが、チームごとに異なります。大まかな消費の方針と承認済みライセンスの一覧が存在し、誰かが緩やかに責任を負いますが、貢献は遅くケースごとで、一部のグループは他よりはるかに多く行います。少数の重要な依存関係は知られていますが、持続可能性、公開、スチュワードシップは一貫していません。
レベル3、標準化: 憲章を持つOSPOが、消費、貢献、公開、コミュニティを所有し、実践は文書化されて組織全体で徹底されます。スキャンとソフトウェア部品表は自動化され、事前承認された貢献者合意と速い承認の経路が存在し、公開されたプロジェクトは本物のガバナンス、商標、セキュリティ方針を持ち、InnerSourceが広がっています。政府のチームは既定で公開します。
レベル4、管理: オープンソースの機能が、ベースラインに対して測定され制御されます。承認までの時間が目標に対して追跡され、貢献量とアップストリームでの受け入れ率が報告され、依存関係の健全性とメンテナーの数のダッシュボードが単一障害点に旗を立て、最もリスクの高い依存関係の資金のあるメンテナーのカバレッジが監視され、私的パッチとフォークの目録が四半期ごとに減っていきます。公開したプロジェクトは測定された課題への応答時間を持ち、例外は周期的にレビューされ、スターのような虚栄の指標はこれらを優先して捨てられます。
レベル5、オーケストレーション: オープンソースは、エンジニアリング、法務、セキュリティ、調達の計画と統合され、継続的に適応される、管理された戦略的能力です。貢献は日常的で、重要なメンテナーと財団に資金が出され、組織はよく運営されるプロジェクトのスチュワードを務め、依存するエコシステムを導き、InnerSourceが規範です。関与と健全性の指標が継続的な改善に供給し、ポートフォリオは、依存関係、リスク、義務づけが移るにつれて再均衡されます。

議論のためのアイデア

可能にするOSPOと門番のOSPOの線はどこにあり、外から見て、どちらを築いたかをどうやって知りますか。
必要性ではなく習慣で抱えている私的パッチやフォークはどれで、上位三つをアップストリームするには何が必要ですか。
重要な依存関係の一覧が予算より長いとき、どのメンテナーと財団に資金を出すかをどう決めますか。
次のリリースを、本物のガバナンス、商標、初日からの協調された開示の方針とともに公開しなければならないとしたら、何が本当に変わりますか。
公共部門の読者へ。原則を静かに侵食せずに、既定での公開からコードを免除する擁護できるプロセスは何ですか。
どの社内ライブラリがInnerSourceから最も恩恵を受け、今日、他のチームがあなたにプルリクエストを送るのを何が妨げていますか。

要点

OSPOは、オープンソースとの関係全体を所有します。責任を持った消費、アップストリームへの貢献、自社プロジェクトの公開、依存するメンテナーの維持。
アップストリームへの貢献は慈善ではなく戦略です。私的パッチの繰り返される税を削除し、方向への影響力を買い、採用を助けます。
自動化と選り抜きを通じて準拠した道を最も速い道にし、オフィスがエンジニアを門で止めるのではなく可能にするようにします。
自社プロジェクトは、本物のガバナンス、選んだライセンス、保護された商標、協調されたセキュリティの開示を伴ってのみ公開し、さもなければ公開しません。
本番システムが乗っている重要なメンテナーに資金を出し、助けます。共有地は自ら維持されないからです。
InnerSourceを適用してオープンソースの協働を会社の内側に持ち込み、政府では、既定でオープンにし、既定で公開し、築く前に再利用します。

参考文献とさらなる読み物

Nadia Eghbal, Working in Public: The Making and Maintenance of Open Source Software
Nadia Eghbal, Roads and Bridges: The Unseen Labour Behind Our Digital Infrastructure
Karl Fogel, Producing Open Source Software: How to Run a Successful Free Software Project
Danese Cooper and Klaas-Jan Stol (editors), Adopting InnerSource: Principles and Case Studies
The Linux Foundation and TODO Group, OSPO guides and Open Source Program Office resources
The Linux Foundation and TODO Group, State of OSPOs and Open Source Management (annual survey series)
Heather Meeker, Open (Source) for Business
Open Source Initiative, The Open Source Definition and approved-licence list
Free Software Foundation Europe, Public Money, Public Code campaign materials
U.S. Federal Source Code Policy and Code.gov guidance