ゲスト |タン・ジョンイー

編集：Tu Chengye

企画 |徐潔成

「オープンソース」は近年非常に人気の高い言葉となっていますが、多くの企業は、オープンソースとは何か、オープンソースをどのように使用するのか、オープンソースに参加するにはどうすればよいのか、オープンソースについてどのように決定を下すのか、オープンソースをどのように管理するのか、そしてオープンソースを活用してどのように競争力を高めるのかを理解するのに依然として困難を感じています。

51CTO主催のWOTグローバルテクノロジーイノベーションカンファレンスにおいて、4Paradigmのアーキテクトであり、Open Atom FoundationのTOC副会長でもあるTan Zhongyi氏が、「大規模および中規模テクノロジー企業におけるオープンソース戦略の策定と実行方法」と題した基調講演を行いました。氏は、エンタープライズオープンソース戦略とは何か、なぜ企業にオープンソース戦略が必要なのか、エンタープライズオープンソース戦略の内容、そしてエンタープライズオープンソース戦略の策定と実行における実践的な経験について紹介しました。講演内容を以下に要約し、皆様の参考になれば幸いです。

この記事は 2 つの部分に分かれています。

最初の部分では、企業のオープンソース戦略とは何か、なぜそれが必要なのか、そしてそれには何が含まれるのかについて説明します。

第 2 部では、企業のオープン ソース戦略を策定し、実装する方法について説明します。

1. エンタープライズオープンソース戦略の定義

企業のオープンソース戦略は、テクノロジー戦略の一部です。

主にオープンソースソフトウェアとコラボレーションに関する内容で、外部のオープンソースコミュニティをどのように使用、管理、コラボレーションするか、利益を得るために独自のオープンソースプロジェクトを作成するかどうか、オープンソースコミュニティのコラボレーションモデルを学習して内部の効率と品質を向上させるかなどが含まれます。

重要なのは、それを企業のビジネス戦略と一致させることです。

企業にとって、単にオープンソースについて語るだけでは意味がありません。企業は営利組織であり、あらゆる活動においてROI（投資収益率）を考慮する必要があります。したがって、オープンソース技術戦略は企業のビジネス戦略と整合していなければなりません。

オープンソース戦略は主にどのような問題に対処しますか?

• 膨大な数のオープンソース コンポーネントを、安全に、コンプライアンスに準拠して、効率的に使用するにはどうすればよいでしょうか?
• どの企業も数多くのオープンソースプロジェクトを活用しています。どのプロジェクトに投資を集中すべきでしょうか？その理由は？どのように投資すべきでしょうか？そして、その成果はどのように評価されるのでしょうか？
• オープンソースを活用して社内の R&D 文化を構築するにはどうすればよいでしょうか?

2. エンタープライズ オープンソース戦略が必要な理由は何ですか?

企業はオープンソース ソフトウェアなしでは機能できなくなり、総合的かつ一貫性のある長期的かつ明確な戦略が必要になります。

• 一貫性のあるオープンソース戦略は、組織内の優先順位を明確にするのに役立ちます。
• オープンソースの運用に関するガイダンスを提供し、従業員に明確で一貫したガイダンスを提供します。
• オープンソース管理のプロセスとポリシーには、より高レベルの法律が必要です。

企業のオープンソース戦略の詳細に入る前に、オープンソースの基礎知識と根底にあるロジックを見てみましょう。

オープンソースとはいったい何でしょうか?

「オープンソース」という言葉は、オープンソースソフトウェア、オープンソースビジネス、オープンソースコラボレーション、オープンソースコミュニティなど、現在では様々な解釈がされています。オープンソースの核となる概念は、オープンであることを通して知的財産を生み出すことです。オープンソースソフトウェア＝公開されているソースコード＋OSI認定ライセンス。オープンソースのビジネスモデルは、オープンソースソフトウェアを基盤として構築されたビジネスモデルです。

現在では、オープンソースはオープンな共同作業モデルであり、その成果はオープンソース ライセンスの要件に準拠していると考えられています。

オープンソース ソフトウェアを使用するということは、企業にとって無料であることを意味するわけではありません。

オープンソースソフトウェアの利用は企業にとって無料ではありません。導入、学習、保守など、様々なコストがかかります。一般的に、保守コストが最も高くなります。オープンソースソフトウェアのライセンスには通常、免責事項が含まれています。ユーザーによるソフトウェアの使用に起因する問題は、元の作者の責任ではなく、作者には実稼働環境で発生した問題を修正する義務はありません。そのため、企業がオープンソースソフトウェアの使用中に問題に直面した場合、商用企業からのサポートを受けるか、自社のエンジニアを雇用して対応する必要があります。

一般的なオープンソースビジネスモデル

OSI定義に基づいてライセンスされたソフトウェアには商業的価値はなく、誰でも無料でダウンロード、改変、配布できます。オープンソースソフトウェアには主に2つのビジネスモデルがあります。

（１）羊毛は豚から採れます。

これはインターネット業界で働く人にとって非常に馴染みのあるモデルです。製品Aは無料、製品Bは有料です。例えば、GoogleのAndroidオペレーティングシステムは無料ですが、そこにインストールされているGoogleモバイルサービス（GMS）は有料です。これは典型的なビジネスモデルです。

（２）オープンソースソフトウェアをベースとしたエンタープライズサービス

要約すると、この点に関しては主に 4 つのパターンがあります。

• デュアルライセンス（例：MySQL、X264）
• オープンコア（Kafka、Elasticに代表される）
• サービス（担当者：Red Hat、IBM）
• SaaS（代表：AWS、テンセント、アリババ）

エンタープライズオープンソースの基礎ロジック

• 利他主義 + 自己利益

まず、企業が自社のソフトウェアを無料で公開し、知的財産を公開することは、本質的に利他的な行為です。しかし、企業はオープンソースから利益を得たいという欲求があり、これは利己的な側面もあります。したがって、利己心と利他心のバランスをうまく取る必要があります。オープンソースの恩恵を享受しつつ、オープンソースコミュニティと企業の長期的な利益を損なう可能性のある過度な商業化は避けなければなりません。そのためには、綿密に設計されたビジネスモデルが不可欠です。

• 競争＋協力

オープンソースの世界には、「協力」という言葉があります。これは「競争」と「協力」を組み合わせたものです。オープンソースの世界には、競争と協力の両方が存在します。例えば、2つのベンダーがオープンソースプロジェクトAでは競合相手になる一方で、オープンソースプロジェクトBではパートナーになることもあります。オープンソースはゼロサムゲームではなく、利益の分配と利益の分配が重要なのです。例えば、同じ商業セクターに属する2つのオープンソースソフトウェア企業は、同じ顧客を相手にしている場合にのみ激しい競争相手となるかもしれません。しかし、投資家、メディア、上流・下流のパートナー、あるいはユーザーといった他の分野においては、彼らは本質的に互いの成功が密接に絡み合ったパートナーなのです。

• オープン性、透明性、そしてコラボレーション

オープンソースは「オープン性、透明性、そしてコラボレーション」という価値観に基づいて運営されており、これらはApacheプロジェクトが推進するApacheソフトウェア財団の最も基本的な原則でもあります。オープンソースにおけるコラボレーションには信頼の構築が不可欠であり、コミュニティの運営は信頼に基づいています。信頼の構築はこれらの価値観を遵守しなければなりません。

• ドライブフォース3.0

ソフトウェア開発に携わる知識労働者にとって、オープンソース・コミュニティへの貢献は、主に自己動機付けから生まれます。彼らは、自分のソフトウェアがより多くの人々によって使用され、より大きな価値を生み出すことを望んでいます。作業量に基づいて報酬を決定する従来の「アメとムチ」アプローチは、近視眼的で非効率的であり、オープンソース・プロジェクトの長期的かつ健全な運営には適していません。オープンソースは、モチベーション3.0のインセンティブモデルを活用する必要があります。

3. 企業内のオープンソースソフトウェアサプライチェーンを管理する方法

企業のオープンソース戦略の一側面:オープンソースソフトウェアのサプライチェーン管理

オープンソースソフトウェアは膨大に供給されており、企業はオープンソースソフトウェアのサプライチェーンの信頼性を確保する必要があります。企業がオープンソースソフトウェアを導入し、コンパイル、再開発、そして社内での再展開を行うプロセスは、一連のプロセスです。このプロセスにおいて最も重要なのは、サプライチェーンの安全性、コンプライアンス、そして効率性を確保することです。そうでなければ、企業にとって直接的なビジネス損失につながる可能性があります。以下は、企業によるオープンソースソフトウェアの不適切な使用によって引き起こされたビジネス損失の実例です。

ソフトウェア会社のサプライチェーン管理能力の測定

オープンソースソフトウェアコミュニティにおけるセキュリティ脆弱性へのパッチ適用は驚くほど迅速です。一般的に、今日脆弱性が発見された場合、対応するパッチは3日以内にリリースされ、遅くとも1週間以内には新バージョンがリリースされます。オープンソースを導入する企業にとって重要な課題は、第一に脆弱性の特定、第二にパッチの影響です。これは企業が考慮すべき典型的な問題です。オープンソースを輸出する企業にとって、一部の厳格なベンダーは準拠ソフトウェアコンポーネントのリストを要求するため、これは困難な場合があります。オープンソースの輸入と輸出の両方をうまく管理することによってのみ、企業は信頼性と効率性に優れたサプライチェーン管理を実現しているとみなされるのです。

サプライチェーンの構築には、ポリシー、プロセス、ツール、法務部門、セキュリティチームの連携が必要であり、全社的な取り組みとなります。国内外のオープンソースソフトウェアガバナンスの事例に基づくと、コスト削減のためには、このプロセスを全社的な実践へと変革する必要があります。

実践的なケーススタディ：

• 法務、セキュリティ、ツールチームを含む、部門横断的な多機能チームを編成します。
• ツールを使用して可能な限り自動化します。
• 大規模かつ多層的なトレーニングと支援が必要です。

Fastjsonにおける高リスクCVEバグに関して、ソフトウェアサプライチェーン管理機能を構築する以前は、セキュリティ部門が全従業員にメールを送信し、特定のソフトウェアバージョンに高リスクの脆弱性があり、すぐに修正が必要であると通知していました。しかし、6ヶ月後には、バグの影響を受けた事業ラインがいくつあるのか、またバグが修正されたかどうかを把握することは不可能でした。オープンソースのソフトウェアサプライチェーン管理機能を活用することで、同社は30分以内に影響を受ける事業ラインを特定し、関係者にセキュリティ作業指示書を正確に送信して状況と修復方法を通知できるようになりました。すべての問題は3日以内に修正可能です。

次に、企業のオープンソース戦略における社内のオープンソース関連コンテンツを見ていきます。

エンタープライズオープンソース戦略パート2：社内オープンソース

企業が大規模になると、部門間に深刻なサイロ化、つまり「部門の壁」が容易に生じます。これはまた、複数部門にまたがる開発の重複につながります。私はかつて、ある大企業で15の機械学習プラットフォームと10を超えるKubernetesクラウドデプロイメントプラットフォームを目にしましたが、そのほとんどは低レベルで反復的な、初歩的なソリューションでした。グループ全体でこのような状況が見られるのは、人材の大きな無駄遣いです。さらに、エンジニアは技術的な向上心が低く、製品の迅速な開発とリリース、収益の創出、そして他の業務へのスムーズな移行を目的とした昇進のみに集中しているケースが多く見られます。これは企業の技術革新を遅らせ、多大な技術的負債と、不適切なデプロイメント環境や監視を含む極めて脆弱なインフラストラクチャを残します。オンラインシステムは頻繁に障害に見舞われ、常に対応に追われることになります。

上記の問題に対して、社内オープンソースは効果的な解決策となります。社内オープンソース（InnerSource）とは、オープンソースソフトウェア開発の経験を活かし、それを社内に適用するソフトウェア開発モデルです。主なメリットは以下のとおりです。

• コード品質の向上
• 人材能力の向上
• 従業員満足度の向上
• 部門間の障壁を打破する
• 再発明を減らす
• イノベーションを奨励する

企業が社内オープンソースを導入すると、関連するプロジェクトのコードが社内で公開されるため、エンジニアは当然のことながら、コードの可読性を考慮しながら作業を進めることになります。さらに、オープンソースコミュニティの運営方法上、提出されたコードは必ずコードレビューを経る必要があります。厳格なコードレビュープロセスによって、コードの品質は自然に向上します。

InnerSourceは、過去10年間で企業に導入されてきたDevOpsと深い関係があります。どちらも効率性の向上を目指しており、効率性を向上させるための最も重要な2つの手法は、再利用と自動化です。InnerSourceは再利用を重視し、DevOpsは自動化を重視しています。これらは相互に補完し合い、適切に実装されたDevOpsプロジェクトは、社内運用やオープンソース化においてより有利になります。また、InnerSourceの充実したインフラストラクチャは、DevOpsツールの迅速な導入にも役立ちます。

オープン性、透明性、そしてコラボレーションという価値観に基づいた社内の信頼文化を確立することによってのみ、DevOpsを積極的に推進することができます。DevOpsにおいては、CI/CDプラットフォームを導入し、プロセスを実行するだけでは、ビジネスがうまく機能しているとは言えません。下の図は、InnerSourceとDevOpsの関係を示しています。

現在、社内オープンソースを活用している主な国際企業としては、マイクロソフト、グーグル、ボッシュなどがあり、国内の主要企業としてはファーウェイ、テンセント、バイドゥなどがあり、いずれも関連する社内ソース開発を行っています。

エンタープライズオープンソース戦略パート3：オープンソースを一般公開する

Linux Foundationは、企業のオープンソース・イニシアチブは、消費者、参加者、貢献者、そしてリーダーという4つの段階から成ると提唱しています。企業のオープンソースには、アップストリーム（既存プロジェクトへの貢献）と、自ら立ち上げたオープンソース・プロジェクトの2つの主要な形態があります。自ら立ち上げたオープンソース・プロジェクトは、常に強い商業的目的を持ち、ビジネス主導型です。

企業がソフトウェアをオープンソース化する主な目的、あるいはメリットは次のとおりです。第一に、社内バージョンの保守コストの削減です。社内で使用するオープンソースソフトウェアを外部のオープンソースソフトウェアのバージョンと長期的に同期させる必要がある場合、ローカルパッチの数を減らす必要があります。これは、一部のパッチを外部に提供することで実現できます。これにより、ローカルパッチの数が自然に削減され、継続的なバージョンアップと保守のコストが削減されます。

第二に、オープンソースコミュニティの成熟したディストリビューションチャネルを再利用したいという願望があります。例えば、MicrosoftのLinuxカーネルへの貢献は重要ですが、主にカーネルとMicrosoft Hypervisor関連部分に焦点を当てています。これらのパッチは、Microsoftのオペレーティングシステム上でLinuxディストリビューションを実行する仮想マシンが正常に動作するために不可欠です。そのため、Microsoftはこれらのパッチをアップストリームコミュニティ、つまりLinuxカーネルに直接提供し、さまざまなディストリビューションの新しいバージョンに自動的に含まれるようにしています。アップストリームのLinuxカーネルコミュニティに貢献しなければ、Microsoftは各商用Linuxディストリビューションベンダーと個別にコミュニケーションを取り、協力する必要があり、膨大なコストが発生します。

最終的な目標は、重要なソフトウェアに対する制御を維持することです。一部の大企業は、事業にとって重要なプロジェクトに人材を投入することで、これらのプロジェクトの反復が自社の利益と目標と一致することを目指しています。

近年、多くの企業、特に大企業が、社内技術のオープンソース化を継続的に進めています。しかし、オープンソース化を進める前に、3つの根本的な問いに答える必要があります。第一に、なぜオープンソース化が必要なのか？第二に、その成功をどのように証明するのか？そして最後に、その効果をどのように測定するのか？これらの問いに答えられなければ、オープンソース化はエンジニアの突発的な行動としか捉えられず、プロジェクトは失敗に終わる可能性が高いでしょう。

オープンソース化にはいくつかの理由があります。

• 事実上の標準を構築し、オープンソース実装を提供することで、標準の進歩を加速できます。
• 競合他社への攻撃。たとえば、企業と製造業者が異なる事業重点分野を持つ競合他社である場合、競合他社の重点分野を実装してオープンソース化することは、競合他社への攻撃の一形態です。
• Mozilla と Internet Explorer の競争のような競争上の差別化では、IE がソフトウェアのプリインストールを選択し、Mozilla がオープン ソースを選択することで、競争上の差別化が実現しました。
• Android などのプロモーション用のエコシステムを構築します。
• LinkedIn のオープンソース Kafka などの雇用主ブランドと技術的評判。
• サポート コストを削減し、さまざまなクラウド ベンダーのクラウド SDK などの独自のサービスを顧客が維持できるようにします。

もちろん、次のような否定的な理由もあります。

• 責任を回避するために、維持されることが望まれないプロジェクトがコミュニティに引き渡されます。
• 彼らは社内で人員を増やすつもりはなく、無料の労働力を見つけたいのです。
• 社内エンジニアまたは部門のKPI
• フォローアップサポートプランのない純粋なPR

プロジェクトをオープンソース化する前に、徹底的な評価が必要です。

プロジェクトの潜在能力を評価するには、業界セクター、カテゴリー、市場ポテンシャル、競合他社との差別化、上流・下流プロジェクトを明確にする必要があります。これらは本質的に製品設計と製品戦略に関わる問題です。さらに、企業がプロジェクトをオープンソース化する場合、以下のレビューを実施する必要があります。

• 法的レビュー：プロジェクトにはどのようなライセンスが使用されましたか？どのような条件が適用されましたか？法的リスクはありますか？
• 技術レビュー：プロジェクトにはセキュリティ上の脆弱性はないか？不要なコードが含まれていないか？
• 市場調査: プロジェクトではどのようなブランディングが使用されていますか? また、市場競争戦略は何ですか?
• ガバナンス モデルの見直し: 独立した開発モデルを採用するか、財団によって管理されるか、あるいは財団のインキュベーション プロジェクトになるか。

4. エンタープライズオープンソース戦略の策定と実装方法

どのように策定するか

企業のオープンソース戦略は、それぞれの状況を考慮しながら段階的に策定する必要があります。例えば、海外事業を展開する企業はコンプライアンスの確保から始めることができます。社内でアイデアの重複が深刻な企業は、社内でのオープンソース化から始めることができます。また、クラウドコンピューティングを主力事業とし、インテリジェントクラウドB2B事業の拡大を目指す企業にとっては、社外へのオープンソース化は非常に有効なアプローチとなり得ます。

計画および策定プロセスでは、BLM (ビジネス リーダーシップ モデル) 方法論を参照できます。

オープンソース戦略の実装方法

オープンソース戦略を実行するための簡単な方法は、オープンソースマネジメントオフィス（OSPO）を設立することです。OSPOの役割は、組織がオープンソースプロジェクト戦略を策定・実行し、リーダー、開発者、マーケティング担当者、その他の従業員がオープンソースプロジェクトを成功裏に運営できるよう支援することです。OSPOの主な責任は以下のとおりです。

• 会社のオープンソース戦略を社内外の関係者に明確に伝えます。
• オープンソース戦略の実施と実行を監督する
• 企業内でのオープンソースソフトウェアの効果的かつ安全な使用を促進する
• オープンソースライセンスのコンプライアンス維持のレビューと監視
• オープンソース コミュニティへの高品質かつ頻繁なコードリリースを保証します。
• 開発者コミュニティと提携して、他のプロジェクトへの会社の効果的な貢献を促進します。
• 組織内でオープンソース文化を育む

業界で最初にOSPOを設立した企業はサン・マイクロシステムズでした。サンは1999年に最初のオープンソースオフィスを設立し、その最初の任務はJavaのオープンソースの推進でした。Javaが今日まで生き残り、活気に満ちているのは、オープンソースの好影響のおかげです。

OSPOを設定するための一般的なパターン

業界におけるOSPOの設置モデルは3つあります。1つ目は、法務部門の傘下にOSPOを配置し、知的財産問題の解決に重点を置く方法です。ハードウェア企業は、OSPOを法務部門の傘下に置くことがよくあります。2つ目は、R&D部門の傘下にOSPOを配置し、主にエンジニアのオープンソースソフトウェア利用を支援する方法です。これはソフトウェア企業に適しています。3つ目は、マーケティング/開発者リレーションチームにOSPOを配置し、販売促進のための広報に重点を置く方法です。

現在、国内大手企業ではOSPO導入事例が多数あり、ファーウェイはグループ戦略研究所標準産業発展部傘下にOSPOを設置している。テンセントは研究開発管理部傘下にOSPOを設置している。アリババはCTOオフィス傘下にOSPOを設置している。百度は技術管理部傘下にOSPOを設置している。

ゲスト紹介:

Tan Zhongyi氏は、4Paradigmのアーキテクトであり、Xingce Community（企業のインテリジェント変革のためのオープンソースコミュニティ）の創設者、China Open Source Promotion Allianceの副事務局長、Open Atom FoundationのTOC副会長を務めています。Sun、Baidu、Tencentで20年以上の勤務経験を持ち、以前はBaiduのオープンソース技術委員会の委員長を務めていました。エンタープライズオープンソースガバナンスの計画と実装において豊富な経験を有しています。また、Apache、Mozilla、Gnome、InnerSourceCommons、OpenChainなど、複数のオープンソース財団のコミッター/メンバーでもあります。