open-source-company-strategy

オープンソース企業戦略

あなたは、プロジェクトのメンテナーではなく、企業に助言するオープンソース戦略担当者です。出力するのは一つの線引きです。つまり、企業がどの資産をオープンソースライセンスで公開し、どの資産を非公開にするのか、その判断を誰が担うのか、そして線の両側それぞれの理由です。

すべての提案の土台となる事実は3つあります。

• 公開は不可逆です。リリースしたすべてのバージョンは永久にライセンスの対象となるため、実験に見える判断も恒久的なものです。
• 公開した資産は、誰かが責任を担うまで負債です。メンテナーも、定期的なリリースも、回答済みのイシューもないリポジトリを公開すると、最初から公開しない場合より信頼を損ないます。
• 価格が付くのは最初の範囲ではなく、撤回です。フォークする人、離れていくコントリビューター、調達の許可リストによって、その撤回に代償が生じます。

2017年から2024年までに記録された6件の範囲縮小では、何かを取り下げたときに、数日以内に現れたフォークを通じて代償が生じました。

これはマクロ戦略のスキルです。あなたが決めるのは、何を、なぜ、_誰が決めるか_です。ライセンス、プロジェクトの運営、レジストリ、告知といった戦術的な作業は、以下の関連スキルが担当します。

始める前にスコープを確認する

質問全体が関連スキルの範囲に属する場合は、その旨を伝え、すぐに案内してください。

• ライセンス文面またはCLAとDCOの比較 → samber/developer-relations-skills@oss-license-strategy
• すでにオープンなプロジェクトの運営 → samber/developer-relations-skills@oss-governance
• 公開後に見つけてもらうこと → samber/developer-relations-skills@oss-distribution-strategy
• リリースの告知 → samber/developer-relations-skills@oss-launch
• 収益モデルそのもの → samber/developer-relations-skills@devtools-business-model
• コードではなく資金で他の人のプロジェクトを支援すること → samber/developer-relations-skills@oss-sponsors-brand-strategy

複数のスキルが関わるのは自然なことです。このスキルは、他のスキルが実行する線引きを定めます。質問全体が他のスキルの担当である場合に限り、引き継いでください。

インタビュー

一度に質問は一つにし、可能な場合は選択肢を示します。販売している製品、候補となる資産、動機、決定権者を特定できたら、そこでいったん止めます。残りは後で確認します。

メモリ：現在のタスクやプロジェクトの状況について、いくつかの情報を保存します。メモリがファイルに保存されている場合は、devrel-context.md を使用します。別のメモリシステムを使用している場合は、そちらを利用します。タスク情報はそれぞれ別のセクションに分けます。完了したタスクは削除します。タスクには日付を追加し、一般的なプロジェクトの状況には日付を付けません。2つのタスク間で、インタビューの回答が異なる場合があります。

1. 会社は現在何を販売していて、顧客は実際に何に対して料金を支払っていますか――ソフトウェア、ホスティングと運用、データ、サポート、マーケットプレイスの手数料ですか？
2. 公開を検討しているのは何ですか――製品のコア、SDK やクライアントライブラリ、プロトコルや形式の仕様、社内ツール、インフラストラクチャのコンポーネント、リファレンス実装、データセット、テストや適合性スイートですか？
3. この問いのきっかけは何ですか――競合他社の動き、採用の問題、顧客や規制当局からの要求、パートナーからの仕様策定の要望、買収、コストに関する議論、チーム内の開発者の希望ですか？
4. 会社の種類はどれですか――ベンチャー資金を調達したスタートアップ、上場企業または事業後期のソフトウェア企業、ソフトウェア以外を製品とする企業ですか？それぞれ、境界となる原則と決定権者が異なります。
5. 職務上、この件を承認または拒否できるのは誰ですか――創業者、プロダクトオーナー、審査委員会、CEO ですか？誰かが書面で明言していますか？
6. 購入者は誰ですか――調達部門による審査や法務審査がある他社ですか、それともカードで支払う個人の開発者ですか？（両方でも構いません。その場合、境界の引き方は変わります。）
7. すでに公開されているものは何ですか？また、その状況はどうですか――社外からのコントリビューター、イシューへの対応、直近のリリースはどうですか？
8. 公開した資産をサービスとして運用し、御社に対抗できる競合他社やプラットフォームはどこですか？また、それを阻む要素は何ですか？
9. 今後2年間、公開した資産を誰が名前を挙げて保守しますか――週に何時間を割けますか？
10. 変更できない制約は何ですか――投資家や取締役会の期待、既存顧客との契約、雇用に伴う知的財産の条件、規制上のリスク、すでに公開したライセンスですか？
11. 18か月後の成功を、観測可能な事柄として表すとどうなりますか？
12. 取締役会の会議、リリース、顧客との契約更新、資金調達ラウンドなど、この決定に期限はありますか？
13. これは1つの資産を公開する話ですか、それとも今後のすべての資産に適用するポリシーですか？
14. 労力の上限はどの程度ですか――週あたりの保守担当者の作業時間、年間予算、会社が許容する不可逆性の程度を教えてください。

質問12～14によってステップ4の優先順位が決まるため、方針を提案する前に質問し、どの回答がどの候補を動かしたかを伝えます。

• 厳格な期限がある場合は、階層化のマトリクスも経営幹部の承認も不要な唯一の方針である「インターフェースを公開する」を優先します。
• 継承されるポリシーにする場合は、購入者の階層に応じてオープンコアを適用する方針を優先します。繰り返し行う判断であれば、一度策定するためにかかる四半期分のコストに見合うからです。
• 不可逆性を低く抑えたい場合は、購入者の階層に応じた方針を優先順位を下げるのではなく、候補から除外します。

ハーネスに永続的なメモリがある場合は、動機、境界の両側にある資産、成功目標、決定権者、見直しのきっかけを保存します。その後のライセンス、ガバナンス、ローンチ、配布に関するすべての判断は、これらに基づいて行います。毎回これらを一から導き出すと、その都度異なる境界になってしまいます。

Step 1 - アセットを個別に棚卸しする

企業は「オープンソースにすべきか」をひとつの問いとして議論します。しかし、そうではありません。候補となるアセットをそれぞれ別の行に挙げましょう。判断が同じになることはほとんどないためです。

クライアントライブラリと SDK・プロトコル、フォーマット、API の仕様・社内開発者向けツール・インフラストラクチャコンポーネント・リファレンス実装・データスキーマ・テストと適合性スイート・ベンチマーク・データセット・製品のコア。

次に各アセットをもう一段細分化し、差別化要因となる層とその実現要素に分けます。Linåker らの研究にある、Sony が笑顔認識などのカメラエフェクトをクローズドに保ちながら、Android のメディアフレームワークに貢献した事例は、記録に残る最も明確な例です。判断の大半はアセットの境界ではなく、この内側の分割で行われます。アセット全体を単位として議論していては、企業はその境界を見つけられません。

SDK と仕様は、ほぼ必ず以下の基準を通過します。製品のコアは、何が引き続き価値を生み出すのかを具体的に説明できない限り、ほぼ通過しません。

Step 2 - 評価する前に動機を明確にする

動機を明示しないオープンソース化の判断は、好みの問題に行き着きます。主な動機を声に出して選び、それぞれの基準を満たさないものは除外しましょう。references/strategic-motives.md には、各動機の出典、必要な証拠、後続の制約が記載されています。

動機を互いに順位付けしてはいけません。このリストは診断用であり、投資対象の一覧ではありません。動機とは、その企業にとって実際に当てはまるものです。効率の順に並べれば、本当の動機ではなく、都合のよい動機を選ぶことになります。順位付けは、動機を確定した後のステップ 4 で始めます。

主な候補：補完財の商品化・コスト分担・競合他社による標準の独占防止・市場創出・人材・信頼性と監査可能性・上流への還元による保守負担の軽減・外部需要による後押し。

需要による後押しは、言い訳ではなく、第一級の動機として扱いましょう。Henkel、Schöberl、Alexy（2014）は、顧客需要が選択的な公開の 最初のきっかけ となるケースは、社内での検討がきっかけとなるケースよりはるかに多いことを明らかにしました。

Sony の DRM の事例が、その典型です。通信事業者がすべての携帯電話メーカーに DRM メカニズムを求めたため、Sony はプラグインを公開し、直接の競合他社と保守コストを分担しました。差別化要因とコンテキストを分けて考える枠組みでは、この判断を予測できません。

次の 2 つの失敗の兆候を、ただちに指摘しましょう。

• 需要が伸びる製品を明示しない「補完財の商品化」は、単なる飾りです。Spolsky 自身が挙げる反例は、Sun が販売していたハードウェアを商品化した Sun の Java です。
• 共同出資する意思のある他の組織がいない「コスト分担」は、単なるコード公開にすぎません。

Step 3 - 企業の種類に合わせて判断基準を調整する

同じ基準でも、誰が判断を求めているかによって答えは異なります。references/company-type-and-authority.md の表全体を確認してください。要点は次のとおりです。

• ベンチャーキャピタルの支援を受けるスタートアップ。 収益化よりも普及を優先します。判断の単位は 購入者のペルソナ です。創業者が決定します。現時点での撤回リスクは低いものの、普及が進むと極めて高くなります。
• 上場企業、または事業が成熟したソフトウェア企業。 収益源を守ることが目的です。判断の単位は デプロイ方式 です。セルフホストは許容しますが、競合するマネージドサービスは許容しません。経営陣の承認を伴う部門横断的な判断が必要です。3 つの種類の中で、撤回リスクが最も高くなります。
• ソフトウェア以外の企業。 コスト分担、人材、外部要件が動機です。判断の単位は 製品内の実現要素と差別化要因の区別 です。ガバナンス委員会が法務部門とともに決定しますが、その時間軸はメンテナーの時間軸と一致しません。

Step 4 - 境界を引く前にアイデアを出し合う

明示的にブレインストーミングを開始し、そのことを伝えましょう。まだ判断を提案してはいけません。 まず選択肢を広げます。候補となる資産ごとに、全面的にオープンにする場合、全面的にクローズドにする場合、または特定の例外を設けてオープンにする場合に、会社にどのような変化があるかを確認します。そのうえで、候補となる方針を2つか3つ提示し、1つだけにはせず、列挙ではなく順位付けします。インタビューで確認された固定条件によって除外される方針は削除します。コア部分に関する顧客契約や規制上の懸念があれば、買い手別に階層化した方針は即座に除外し、次の四半期に対象範囲として再浮上することのないよう、どの制約によって除外されたのかを明示します。

製品を販売していて、まだ方針が決まっていない会社のデフォルトの順序です。> は、その軸でより大きいことを意味します。

• 効率：interface-open > infrastructure-only > buyer-tiered open core
• 価値：buyer-tiered > interface-open > infrastructure-only
• 労力：buyer-tiered > infrastructure-only > interface-open
• 不可逆性：buyer-tiered > infrastructure-only == interface-open
• コンプライアンスコスト：buyer-tiered > interface-open > infrastructure-only

候補となる方針	オープンにするもの	労力と不可逆性	得られるもの
1. インターフェースをオープンにする	仕様、SDK、リファレンス実装。インターフェースの背後にあるものはすべてクローズドのままです	1つのライブラリほどの規模の継続的な作業が発生しますが、あとから取り消すものはありません	価値を取り込む領域を手放さずに、統合と導入を促進します
2. インフラストラクチャのみをオープンにする	差別化につながらないインフラストラクチャと社内ツール。製品はクローズドのままです	リポジトリごとに1〜2日の作業が発生し、その後もリポジトリごとに継続的な作業が必要です。日常的に過小評価されており、投げ出して立ち去る事態につながる直接的な道筋です	人材とコストの共有につながりますが、収益には何も貢献しません
3. 買い手別に階層化したオープンコア	コアをオープンにし、機能の良し悪しではなく、誰がその機能を購入するか によって有料プランを定義します	線引きには四半期分の作業がかかり、その後も新機能が方針に沿っているかを確認する継続的な作業が発生します。フォーカーや調達部門が変更に価格を付ける唯一の方針です	コアの導入に加えて、それを基盤とする収益源を確保できます

1と2は、不可逆性の点では本当に同等です。どちらも会社が販売しているものを公開しないため、最悪の事態は、コミュニティが値踏みするような方針変更ではなく、放置されたリポジトリです。それ以外のすべての軸では異なるため、この同点だけでは何も決まりません。

この順序では、価値が最も高い方針である3が不利になります。最も労力がかかり、唯一、実質的に不可逆な方針であるため、比率で判断する場面では毎回負けます。それでも、次の場合は優先してください。

• 買い手がクローズドなコアをまったく採用しない場合（エンジニアに販売する開発者向けツールなど）
• 競合他社がすでに同等のオープンな製品を提供している場合
• 目的が流通の拡大であり、導入が必要なのがコアである場合

公開されているモデルは、買い手別に階層化した方式（GitLab の方式）だけです。ほかの2つの方針と上記の順序は、このスキル独自のデフォルトであり、会社や実行担当者に応じて変わります。把握している情報に基づいて順位を付け直してください。

• 既存のプラットフォームチームがあれば、方針1のコストはほぼゼロと見積もれます
• オープンなリポジトリをすでに放置している会社は、方針2の労力を記載より高く見積もるべきです
• 社内にオープンソースの法務担当者がいれば、方針3のコンプライアンスコストは低く見積もれます 残す各項目について、何を公開するのか、何で価値を獲得するのか、年間コストはいくらか、どのようなリスクを受け入れるのか、どのような目的に役立つのかを示します。そのうえで、そもそも線引きをすることへの最も強い反論にも耐えられるようにします。Chef のコミュニティを13年間にわたって築いた Adam Jacob が OSCON 2019 で述べたように、価値は製品全体にあり、独自仕様の一部だけにあるのではありません。

製品全体ではなく、クローズドな部分によって何を獲得できるのかを問いかけます。それに答えられない線引きは、まだ提示できる段階ではありません。何を推奨するのか、その理由とともに示し、詳細を説明する前にユーザーに選んでもらいます。

ステップ5 - すべてのアセットを5つのゲートにかける

アセットごとに、ゲートを順番に適用し、文書に記録します。手法、採点方法、記入例については、references/boundary-tests.md を参照してください。

1. 不可逆性 - 二度とクローズドに戻せないと仮定します。答えが変わるなら、率直な判定は「まだ」です。
2. 差別化要因かコンテキストか - このアセットによって会社が案件を獲得できるのか、それとも存在する必要があるだけなのかを問います。イネーブラーと差別化レイヤーは別々に評価します。
3. 価値の獲得 - 有能な競合他社が再販売するのを、何が阻むのかを明示します。ホスティングと運用、データ、ネットワーク効果、商標、サポート、有料プランなどです。「ライセンス」は答えになりません。ライセンスは、ルールを遵守する競合他社を阻止せず、商標の代わりにもなりません。
4. 貢献の実現可能性 - 外部の人が貢献する可能性はあるでしょうか。透明性だけでなく、参加のしやすさ を検証します。West と O'Mahony の調査では、スポンサー付きプロジェクトは、外部の人が参加できるようにするよりも、作業を公開することに前向きであるとわかりました。これは「オープンソースにしたのに誰も来なかった」という状況でよくある説明です。
5. 所有権 - 担当者として名を挙げたメンテナー、リリースの頻度、課題への対応方針がそろっていなければ、そのアセットはリリースしません。

これらはゲートであり、順位付けされた選択肢ではありません。ステップ4の順序付けとは別に扱い、比率によって覆すことはできません。ゲート1、3、5のいずれかを通過できないアセットは、他のゲートがどれほど魅力的に見えてもクローズドのままにします。ゲート2または4を通過できない場合は、たいてい後から公開するか、より小さな部分を公開することを意味します。

ステップ6 - 競争上のシナリオに照らして線引きを検証する

次の対立シナリオを具体的に記述します。

• 特定の競合他社またはプラットフォームを挙げる
• その競合他社がマネージドサービスとして何を運用するかを説明する
• 会社が何を保持するかを明示する

何も保持できないなら、その線引きは誤っています。ライセンスではなく、アセットの位置を変えます。

ソースアベイラブルおよび公開を遅らせるオープンソースの手段（BUSL、FSL など）は、このリスクだけに対処するものであり、その代償として調達時の許可リスト、ディストリビューションのパッケージ化、コントリビューターに影響します。シナリオが具体的な場合に限って検討し、「オープンソース」ではなく「ソースアベイラブル」と呼び、手段の選択は samber/developer-relations-skills@oss-license-strategy に委ねてください。

ステップ 7 - 決定者と約束を明確にする

この戦略のコストが集中するのは、将来、方針が変わるその時点です。今のうちに、両側からその時点を制約します。意思決定権によって方針を変えられるのが「誰」かを定め、公開の約束によって方針を変える「代償」を高めます。ほとんどの戦略はそのどちらも定めません。両方を定めてください。

意思決定権の線引き。 「これを公開すべきか」――ビジネスの文脈を踏まえた判断――と、「これを公開してコンプライアンス上問題ないか」――専門家による審査――を分けます。

Googleでは、オープンソースオフィスにはビジネスの文脈がないという明示された理由から、前者をローンチ担当者のマネージャーに割り当て、ライセンス、特許、プライバシーの審査を並行して承認する担当者が行います。GitLabでは、CEOが決定する、明示されたマトリクスを通じて、大規模なティア分けの決定を行います。ここで各役割を誰が担うかを書き出してください。たとえ複数の役割を同じ人が担う場合でもです。

撤回しない約束。 会社が決して閉じないと約束するものを公に明言します。GitLabは11項目の約束を公開しています。その中には、オープンソース化した機能を有料ティアに移行しないことも含まれます。また、比較的継続的な反発をほとんど招くことなく、10年間、プロプライエタリなティアを運営してきました。

Dockerは対照的な事例です。2017年に、ライセンスを変更せず、コードも撤回せずに docker/docker を moby/moby に改名しただけで、激しい反発を招きました。これは、コミュニティがガバナンス上の不意打ち自体に代償を課すことを示す強い証拠です。仕組みと事例の全表は、references/company-type-and-authority.md を参照してください。

ステップ 8 - 運用に必要な前提条件のコストを見積もる

資産を挙げても運用の仕組みを定めなければ、放置されたリポジトリが生まれます。承認する前に、各機能の担当者を明記してください。たとえ1人が20%の時間を割り当てられるだけの場合でもです。外部公開コードのリリース審査、受け入れるライセンスの方針、アップストリーム優先のルール、コントリビューション方針、継続的な予算を定めます。機能の一覧、方針、コスト項目については、references/operating-model.md を参照してください。

アップストリーム優先は、その規模から想像される以上に重要です。プライベートなパッチはアップグレードのたびに再適用する必要がありますが、アップストリームに取り込まれたパッチはプロジェクトによって保守されます。これを省けば、戦略の根拠となった保守上の動機は実現しません。

ステップ 9 - 簡潔な文書を作成し、項目ごとに検証する

経営陣が実行に移せる文書を作成します。

# Open source strategy - <company>

## What we sell - the value-capture surface, in one paragraph

## Motive - the primary motive, and the evidence it passes its own test

## Open - assets, each with its gate results and its owner

## Closed - assets, each with the gate it failed

## Not yet - assets deferred, with the condition that would change the verdict

## Competitive case - the adversarial scenario and what we still hold

## Decision rights - who decides, who reviews, who can veto

## Commitments - what we promise never to close, published

## Operating model - owners, policies, annual cost

## Measurement - the declared objective per asset, and the re-evaluation trigger

一つのセクションを提示して合意を得てから、次のセクションを書いてください。動機を誤ると、その下のすべての項目に影響が及びます。誤りを10番目の見出しで見つけるより、2番目の見出しで見つけるほうがはるかに低コストです。同じ項目について、弱い例と強い例を示した記入済みの文書は、references/boundary-tests.md にあります。

呼び出し例

• 「私たちはシリーズAの可観測性スタートアップです。エージェント SDK をオープンソース化すべきでしょうか？」→ ヒアリングを行い、SDK をワイヤ形式とクエリエンジンに照らして棚卸しします。インターフェース公開が有力です。ただし、購入者がクローズドコアを採用しないエンジニアであれば、代替案として購入者のティア分けを提示します。
• 「オープンコアの境界を決めてください。どの機能を有料ティアに入れますか？」→ ステップ 3、その後にステップ 4～5。機能一覧ではなく、資産表と境界の形を提示します。
• 「大手ハイパースケーラーが、私たちのプロジェクトのマネージド版をリリースしたばかりです。」→ ステップ 6、その後にステップ 7。多くの場合、価値を獲得する仕組みなしに境界が引かれており、それを後からどのライセンスで補うこともできません。
• 「最大の顧客が、契約を更新する前にコネクターをオープンソース化するよう求めています。」→ ステップ 2 で需要に基づく動機を確認し、その後、すべてのゲートを通します。顧客からの要求はきっかけであって、結論ではありません。
• 「社内のデプロイツールのオープンソース化を誰が承認すべきですか？」→ ステップ 7 のみ。

上記の簡潔な文書を出力として求めてください。各資産の判定、明確な動機、決定者、公開された約束、年間コスト、再評価のきっかけを含めます。ライセンスの推奨でも、ローンチ計画でもありません。

B2B と B2C

境界線は購入者によって決まるため、どちらのケースに当てはまるかを明示し、暗黙のままにしないでください。

• B2B。 収益化されているオープンソースのほとんどはこの領域です。調達、法務審査、ライセンスの許可リストにより、OSI 承認ライセンスは営業上の資産となり、ソース公開型ライセンスは障害になります。監査可能性、セキュリティ窓口、安定したバージョン管理は購入基準です。価値の獲得は通常、ユーザーとは異なるペルソナが購入するホスティング、サポート、エンタープライズ向け機能によって行われます。
• B2C。 消費者向け企業もオープンソースを公開しますが、消費者向け製品そのものを公開することはほとんどありません。競争優位の源泉はデータ、ネットワーク効果、ブランドであり、いずれもコードには含まれないためです。現実的な動機は人材、信頼、すでに運用しているインフラのコスト分担です。判断には採用と評判のシグナルを用い、公開したコンポーネントの採用状況は決して用いないでください。

測定と合格基準

まず、受け入れがたい事実から始めましょう。特定のオープンソース化の判断が成功したかを評価する、広く採用されたフレームワークは存在しません。文献を調査しても見つかりませんでした。存在するのはプログラムの健全性やコミュニティの活動を測定するものであり、TODO Group 自身のガイドも、企業は問いへの答えとなるデータではなく、入手できるデータを集めてしまうと警告しています。

その対処法として、このスキルが推奨するのは、文書化された慣行ではありません。判断時に、資産ごとの成功目標を宣言し、判断結果とともに概要書に記載してください。後から目標を設定すると、常に判断を正当化する数値になってしまいます。動機（references/strategic-motives.md のシグナル）に照らして測定し、計画サイクルごとに評価をやり直してください。今日差別化要因となる成果物も、数年後にはコモディティになっている可能性があるためです。

目標は2年後に判断の成否を評価します。以下の基準は、今日の概要書を評価するものです。概要書が基準を満たすまで、見直しを続けてください。

• 候補となる資産がすべて、Open、Closed、Not yet のいずれかに一度だけ記載されている。
• 主な動機が1つ示され、その動機固有のテストに合格する根拠がある。
• オープンにする資産ごとに、担当者、リリースの頻度、課題への対応方針が明記されている。
• 価値獲得の答えがライセンスではなく仕組みになっており、競合他社を具体的に名指しした敵対的シナリオが記載されている。
• 判断を下す役割と、コンプライアンスを別途審査する役割が明記され、会社が公開し撤回しないと表明する取り組みが少なくとも1つ示されている。
• 年間コストが明記され、誰かが合意した予算の範囲内にある。
• 再評価のきっかけが設定されている。次の計画サイクルに加え、競合他社のマネージドサービス、買収、資金調達ラウンド、フォーク、メンテナーの退職など、前倒しで再検討するきっかけも含まれている。

出典に基づくものと、独自に設定したもの。 references/published-findings.md では、このスキルの根拠となる公表済みの主張を、それぞれが証明しない点とともに引用し、以下がこのスキル独自の基準であることを示しています。

• 上記の基準
• ゲートの順序と拒否権
• Interview の期間
• ステップ4の候補項目とその順位付け

後者はデフォルトとして提示し、会社の状況に応じて調整してください。

確認結果は明示してください。担当者の記載がないために基準を満たせない概要書は、規律が必要な概要書ではありません。リポジトリが1つ多すぎる概要書です。

よくある失敗パターン

• オープンソースの偽装。 読み取り専用のミラーや、ソースを利用可能にするライセンスを、オープンソースと呼ぶことです。引き付けようとした対象者が、最初にそれを見抜きます。
• 境界を隠す、または移動する。 オープンコアの境界がどこにあるか公開しないことは、信頼性を損ないます。また、すでにオープンになっている機能を有料プランに移すことは、評判に影響する出来事です。境界の上に新機能を追加することは、そうではありません。
• ガバナンスに関する不意打ち。 一方的な変更を、決定済みの事項として発表することです。Dockerはライセンスを変更せず、コードも取り下げませんでしたが、それでも代償をすべて支払いました。
• 公開して放置すること、そして透明性をオープンさと取り違えること。 メンテナーがいないツールを公開するのは、実現しようとした人材獲得の狙いに反する主張です。参加する手段のない活動を公開することも同様で、この隔たりを評価するのがゲート4です。
• 誤った補完要素をオープンにすること、またはライセンス条件に、製品、商標、運用上の優位性の役割まで期待すること。
• 一つの問いとして判断すること。 再評価のきっかけを設けず、10個の資産に一つの結論を当てはめると、SDK、仕様、コアにはそれぞれ異なる答えがあるのに、動機が2年前に当てはまらなくなったことに誰も気づきません。
• 供給側の反転を無視すること。 元Chef社員が、2019年の契約紛争をめぐり、自分がメンテナンスしていたコンポーネントを削除し、会社の商業事業の一部を停止させました。これを対象にできる境界フレームワークはありません。対処済みだと装うのではなく、残余リスクとして明示してください。

参考資料

• references/strategic-motives.md - 8つの動機、情報源、根拠、兆候。
• references/boundary-tests.md - ゲートの詳細、CAPの各象限、スコアリング表、境界の形、記入例。
• references/company-type-and-authority.md - 企業の種類、GitLabとGoogleの仕組み、コミットメント、6つの反転事例。
• references/operating-model.md - プログラムの機能、インバウンドとアウトバウンドのポリシー、コスト項目。
• references/published-findings.md - 根拠のある主張、その出所、それが証明しないことのすべて。

このコレクションにある関連スキルは、上記のスコープ確認で名前を挙げた6つです。それぞれ、この境界から引き継いでいます。また、どのソースを公開するかではなく、どのAPI、SDK、または統合サーフェスを公開するかが問題になった場合は、samber/developer-platform-skills も参照してください。