オープンソースとは何ですか？

オープンソースソフトウェアとは、ソースコードが公開され、ライセンス条件に従って利用、改変、再配布が許可されるソフトウェアです。

GitとGitHubの違いは何ですか？

Gitは分散バージョン管理ツールであり、GitHubはGitリポジトリをホスティングし、コラボレーション機能を提供するサービスです。

GitHubはどのように収益を得ていますか？

GitHubは、企業やチーム向けの有料サブスクリプション、開発者ツール、追加利用分の料金から収益を得ています。

オープンソースとは？GitHubはどのように成長し、収益化したのか

執筆 쉬었음.com公開 2026年9月12日

オープンソースは、単にソースコードを公開することではありません。定められたライセンスのもとで、他者にソフトウェアの利用、研究、改変、再配布の権利を与える仕組みです。GitHubは、このような共同開発を、リポジトリ、バージョン管理、コードレビュー、自動化のための単一のワークフローへと結び付けることで、商用プラットフォームとして成長しました。

GitHubの中核となるビジネスモデルは、公開オープンソースプロジェクトを直接販売することではありません。大規模な無料ユーザー基盤を獲得したうえで、企業が必要とする非公開コラボレーション、アクセス制御、セキュリティ、コンプライアンス、自動化、クラウド開発環境、人工知能機能に料金を課しています。

オープンソースとは正確には何か？

オープンソースソフトウェアとは、著作権者がライセンスを通じて、実行、研究、改変、再配布を含む権利をユーザーに付与するソフトウェアです。重要なのは、コードを閲覧できるかどうかだけではなく、どの権利が法的に許可されているかです。

Open Source Initiative（OSI）の定義によれば、オープンソースライセンスは自由な再配布を認め、ソースコードを提供し、改変物および派生著作物の配布を認めなければなりません。また、個人、団体、利用分野を差別してはなりません。そのため、「非商用利用に限る」や「競合製品での利用を認めない」といった制限が適用される場合、ソースコードが公開されていても、通常の意味でオープンソースと見なすことは困難です。OSI의 Open Source Definition

この区別は、GitHub上の公開リポジトリで特に重要です。リポジトリが誰でも閲覧できる状態でも、オープンソースライセンスがなければ、デフォルトの著作権法が適用されます。他者はGitHubサービス内でリポジトリを閲覧またはフォークできますが、コードを自由に複製、改変、配布する権利を自動的に得るわけではありません。GitHubも、プロジェクトが真にオープンソースであるためには、利用許可を明記したライセンスが必要だと説明しています。GitHub의 저장소 라이선스 안내

したがって、次の3つの記述はそれぞれ異なる意味を持ちます。

「コードを閲覧できる」は、ソースが公開されているかを表します。
「無料で使える」は、価格を表します。
「オープンソースである」は、ライセンスによって付与された権利を表します。

フリーソフトウェアが必ずしもオープンソースとは限らず、オープンソースソフトウェアも販売できます。

オープンソース運動はどのような背景から生まれたのか？

ソフトウェアコードを共有し、共同で改善する慣行は、初期のコンピュータ研究コミュニティにすでに存在していました。しかし、ソフトウェアが独立した商用製品へと発展し、著作権や利用制限が強まるにつれて、ユーザーがソフトウェアを研究し修正する能力をめぐる懸念も高まりました。

1980年代、Richard StallmanはGNUプロジェクトとフリーソフトウェア運動を始めました。フリーソフトウェアにおける「free」は価格ではなく、ユーザーがプログラムをそのまま、または改変して実行、研究、改変、再配布する自由を指します。GNU의 자유 소프트웨어 정의

「オープンソース」という名称は、Netscapeがブラウザのソースコード公開計画を発表した直後の1998年に開かれた戦略会議で作られました。同年、Eric Raymond、Bruce PerensらはOSIを設立し、Debian Free Software GuidelinesをもとにOpen Source Definitionを整備しました。目的は、共同開発がもたらす実用的な利点を、企業や一般の人々により明確に説明することでした。OSI 역사

フリーソフトウェアとオープンソースは、受け入れるライセンスの多くが重なりますが、重視する点が異なります。

区分	フリーソフトウェア	オープンソース
中心となる問い	ユーザーの自由は保証されているか？	オープンな共同作業と再利用は可能か？
主な視点	倫理的・社会的な権利	開発手法と実務上の成果
「Free」の意味	無料ではなく自由	価格ではなくライセンスと開発手法
実務上の対象ソフトウェア	オープンソースと大部分が重複	フリーソフトウェアと大部分が重複

この違いは、どちらか一方が常に優れていることを意味しません。同じプログラムでも、一方の観点ではユーザーの権利に焦点を当て、もう一方の観点では透明性のある開発と分散型コラボレーションの効率に焦点を当てて説明できることを意味します。

オープンソース開発はどのように機能するのか？

オープンソースは、「誰でも好きなようにコードを変更できる」ことを意味しません。参加は開かれていても、公式版に何を取り込むかは、プロジェクトのメンテナーと定められた手続きによって決まります。

一般的な開発プロセスは次のように進みます。

メンテナーがソースコード、ライセンス、利用方法、貢献ルールを公開します。
ユーザーがリポジトリをcloneまたはforkして、独立した作業環境を作成します。
バグ修正や機能開発を別のブランチで行います。
コントリビューターが変更内容とその理由を含むPull Requestを提出します。
メンテナーがコード、テスト結果、設計方針、セキュリティへの影響をレビューします。
基準を満たした変更だけが公式リポジトリにマージされます。
新バージョンがリリースされ、その後に発見された問題は再び追跡されます。

このプロセスにはさまざまな役割があります。ユーザーはソフトウェアを使い、問題を報告します。コントリビューターはコードやドキュメントを提出します。メンテナーはレビューとリリースを担当します。プロジェクトの運営委員会や財団が、商標、予算、意思決定ルールを管理する場合もあります。

言い換えれば、オープンソースの「オープン性」は、意思決定権限が存在しないことを意味しません。参加の機会とコードを利用する権利は開かれていますが、公式プロジェクトには品質を維持するための統制構造があります。

オープンソースライセンスはどのように異なるのか？

オープンソースライセンスは、大きくパーミッシブライセンスとコピーレフトライセンスに分けて理解できます。

パーミッシブライセンス

MIT、BSD、Apache License 2.0が代表例です。著作権表示とライセンステキストを保持するなどの条件を満たせば、これらのライセンスは一般に、改変コードをプロプライエタリソフトウェアに組み込むことを許可します。

このため企業が商用製品に統合しやすい一方、改善されたコードが元のコミュニティに戻る保証はありません。Apache License 2.0には明示的な特許関連条項も含まれるため、その法的条件はMIT Licenseと同一ではありません。

コピーレフトライセンス

GNU General Public License（GPL）が代表例です。改変コードを配布する場合、またはそのコードと結合した派生著作物を配布する場合、同じライセンスでソースコードを提供することが求められることがあります。

コピーレフトは商用利用を禁止しません。ソフトウェアは商用販売できますが、ライセンスで定められた範囲のソースコード開示義務を守る必要があります。LGPLやAGPLのような派生版は、ライブラリのリンクやネットワークサービスについて異なる条件を設けています。

ライセンスを選ぶ際は、有名なプロジェクトが使っているという理由だけで選ぶべきではありません。派生著作物の開示範囲、特許条項、ネットワーク経由のサービス提供、他ライセンスとの互換性を確認する必要があります。

オープンソース、Git、GitHubの違いは何か？

この3つの概念は一緒に登場することが多いものの、異なる層で機能しています。

オープンソースは、ソフトウェアの利用権と共同開発の方法を表す概念です。
Gitは、ファイル変更の履歴を分散型で管理するオープンソースのバージョン管理プログラムです。
GitHubは、Gitリポジトリをオンラインでホスティングし、コードレビュー、Issue管理、自動化、セキュリティ、コラボレーション機能を提供する商用サービスです。

Gitは、Linuxカーネル開発コミュニティと、プロプライエタリな分散バージョン管理ツールBitKeeperとの関係が終わった後の2005年に作られました。Linuxほど大規模なプロジェクトに必要な速度、分散作業、多数の並行ブランチを扱えるツールが必要だったのです。Git 공식 역사

Gitでは、各開発者が常に中央サーバーに接続していなくても、完全な変更履歴を含むリポジトリを保持できます。しかし、コマンドラインのGitだけでは、誰が変更を提案したのか、なぜ必要なのか、誰がレビューするのか、いつマージするのかを管理するのは不便でした。GitHubは、まさにこの共同作業プロセスをWebインターフェースで整理しました。

GitはGitHubなしでも使用でき、リポジトリはGitLab、Bitbucket、セルフホスト型サーバーでも運用できます。逆にGitHubには、オープンソースだけでなく、非公開の企業コードやライセンスのない公開コードも存在します。GitHubとオープンソースは同義ではありません。

GitHubはどのように始まったのか？

GitHubはTom Preston-Werner、Chris Wanstrath、PJ Hyettを中心に開発され、2008年に公開サービスとして開始されました。後にPro Gitの著者として知られるGitの専門家、Scott Chaconも初期チームに加わりました。

GitHubの内部リポジトリへの最初のコミットは2007年10月に行われ、サービスは2008年4月に開始されました。最初の周年を迎える頃には、GitHubは2万を超える公開リポジトリと4人のフルタイム従業員を抱え、外部投資を受けていませんでした。GitHub의 첫해 기록

GitHubが解決しようとした課題は、単なるファイル保管ではありませんでした。分散したGitリポジトリにまたがる変更を可視化し、開発者がお互いの仕事を見つけやすくし、変更提案をレビューしやすくする共同作業環境を作ることを目指しました。GitHubが2008年に公開したnetwork graphも、複数ユーザーのブランチとコミットの関係を1画面で示す試みでした。초기 Network Graph 소개

このアプローチは後に「ソーシャルコーディング」と呼ばれるようになりました。開発者のプロフィール、活動履歴、フォロー、fork、star、Issue、pull requestがコードリポジトリと結び付き、開発プロセスそのものが検索・観察できるネットワークへと変わりました。

GitHubはなぜ急速に成長したのか？

GitHubの成長は、無料のGitストレージを提供しただけでは説明できません。技術的なタイミング、ユーザー体験、ネットワーク効果、エンタープライズ向けビジネスモデルが一体となって機能しました。

Gitの複雑な共同作業プロセスをWeb上で理解しやすくした

ブランチ、コミット、マージは強力なGit機能ですが、初心者がコマンドだけで理解するのは容易ではありません。GitHubは、コード差分、議論、レビュー結果、テスト状況をpull requestのインターフェースに集約しました。

パッチファイルをメールで回覧する代わりに、開発者は1つのリンクで変更を共有できるようになりました。コードと議論の過程が一緒に記録されるため、プロジェクトのメンテナーはレビューコストを抑えられました。

公開リポジトリが開発者ネットワークを作った

プロジェクトがGitHubに参加すると、そのプロジェクトのユーザーやコントリビューターもアカウントを作成する可能性が高まります。そのユーザーはさらに別のプロジェクトを作成したり、既存のプロジェクトに参加したりします。

リポジトリ数が増えるほど、開発者はコードを探すためにGitHubを訪れます。開発者数が増えるほど、プロジェクトのメンテナーはコントリビューターを集めるためにGitHubを選びます。これは両面ネットワーク効果です。

公開された活動履歴は、開発者のポートフォリオとしても機能しました。企業は応募者の実際のコードと共同作業経験を確認でき、開発者には就職機会や評価のために活動履歴を築く動機がありました。

オープンソースとエンタープライズ製品を同時に成長させた

GitHubは、初期から非公開リポジトリに料金を課す一方で、公開オープンソースリポジトリへの参入障壁を下げました。2011年には、社内サーバーで運用でき、認証、バックアップ、チーム管理などの企業ニーズに対応するGitHub Enterpriseを開始しました。GitHub Enterprise 출시 기록

この構造により、個人開発者はオープンソースプロジェクトを通じてGitHubの使い方を学び、企業に入社した後には同じワークフローのエンタープライズ版を利用できました。個人向けに別途営業しなくても、開発者が組織へ製品を持ち込むボトムアップ型の導入を可能にしました。

GitHubは、外部投資なしに有料サービスを通じて収益性と成長を達成したと述べ、2012年に初めて外部投資を受けました。GitHub의 2012년 투자 발표

無料枠を拡大し、競合サービスへ移る理由を減らした

2019年、GitHubは無料の個人アカウントに非公開リポジトリの提供を開始しました。2020年には、無料の非公開リポジトリのコラボレーター数制限を撤廃し、主要なチーム機能を無料化しました。企業が必要とする高度な権限管理、セキュリティ、サポート機能は有料のまま残されました。GitHub Free 확대 발표

無料枠の拡大は、短期的には一部のサブスクリプション収益を手放すことを意味します。しかし、より多くの個人や小規模チームをプラットフォームにとどめ、組織の成長に応じてTeam、Enterprise、セキュリティ、AI製品へ転換させる機会を作ります。

Microsoftによる買収はGitHubの成長にどのような影響を与えたのか？

Microsoftは2018年、75億ドル相当のMicrosoft株式でGitHubを買収することで合意しました。当時、GitHubは2,800万人を超えるユーザーを報告していました。Microsoftは、GitHubが独立した運営と開発者優先の性格を維持すると表明しました。Microsoft의 GitHub 인수 발표

この買収は双方の戦略的ニーズを一致させました。GitHubはグローバルなクラウドインフラ、エンタープライズ向け営業網、セキュリティおよびコンプライアンス機能を活用できました。Microsoftは、Windowsやプロプライエタリソフトウェア中心という過去のイメージを超え、OSやプログラミング言語を問わず開発者との接点を築くことができました。また、Azure、Visual Studio、VS Code、GitHubを結び付ける機会も得ました。

買収後、GitHubはリポジトリホスティングを超え、開発ライフサイクル全体をカバーするプラットフォームへと拡大しました。GitHub Actionsはビルド、テスト、デプロイを自動化し、Codespacesはクラウド開発環境を提供します。Advanced Security製品はコード、依存関係、シークレットをスキャンし、CopilotはAIを利用したコード作成・レビュー機能を提供します。

2022年10月、MicrosoftはGitHubの年間経常収益（ARR）が10億ドルに達し、ユーザー数が買収時の3倍に当たる9,000万人超へ成長したと発表しました。Microsoft FY2023 1분기 실적 발표

GitHubは、2023年に1億人を超える開発者がプラットフォームを利用し、2025年には1億8,000万人を超えたと発表しました。2025年にはプロジェクト総数が6億3,000万件に達し、GitHubは全コントリビューションの約81.5%が非公開リポジトリで行われたと集計しています。これは、GitHubがオープンソースの場であると同時に、大規模な企業開発インフラになったことを示しています。GitHub Octoverse 2025

ただし、これらの数字はGitHub独自の基準で集計されたプラットフォーム指標です。登録開発者数を、月間アクティブユーザー数や有料顧客数と同じものとして解釈すべきではありません。またMicrosoftは、独立した事業部門としてGitHubの現時点の売上高や営業利益を毎年詳細に開示しているわけではありません。そのため、2022年に報告された10億ドルのARRは、現在の売上高ではなく、当時開示された代表的な規模指標として見るべきです。

GitHubは具体的にどこで収益を得ているのか？

GitHubの収益モデルは、無料の公開プラットフォームでユーザーを獲得し、組織運営に必要な管理と生産性に料金を課すフリーミアムモデルとして要約できます。

収益源	主な購入者	顧客が料金を支払う理由	料金方式
TeamおよびEnterpriseサブスクリプション	開発チームおよび企業	権限管理、ポリシー、監査、コンプライアンス、サポート	ユーザーごとのシート型サブスクリプション
Copilot	個人、組織、企業	AIによるコード作成、質問、レビュー、エージェント機能	ユーザーサブスクリプションと一部の従量課金
セキュリティ製品	高度なセキュリティ要件を持つ組織	脆弱性、シークレット、サプライチェーンリスクの検出	ライセンスまたはアクティブユーザー基準
Actions	自動化を利用する組織	ビルド、テスト、デプロイの実行	含まれる利用枠を超えた分
Codespaces	開発環境を標準化する組織	クラウドコンピューティングとストレージ	コンピューティング時間とストレージ容量
PackagesおよびGit LFS	大容量ファイルとパッケージの利用者	ストレージおよび転送インフラ	含まれる利用枠を超えた分
Marketplace	サードパーティ製アプリの開発者と購入者	アプリの発見、インストール、決済連携	取引手数料

ユーザーごとのシート型サブスクリプション

無料プランでは、個人や小規模チームが中核的なリポジトリ機能を利用できます。Teamプランは高度なコラボレーション機能を提供し、Enterpriseプランはセキュリティ、コンプライアンス、集中管理、デプロイの選択肢を提供します。

2026年9月に確認した公式価格ページによると、Teamは1ユーザーあたり月額4ドルから、Enterpriseは1ユーザーあたり月額21ドルからです。実際の金額は、契約期間、地域、税金、大規模契約の条件によって異なる場合があります。GitHub 공식 가격표

シートベースの課金には、企業の従業員数増加に合わせて経常収益を伸ばせる利点があります。コードと作業プロセスがプラットフォーム上に定着すると、切り替えコストも増えるため、契約が継続されやすくなります。

AI製品のサブスクリプションと従量課金

GitHub Copilotには、個人および組織向けの有料プランがあります。企業はユーザーごとにシートを購入し、プランに含まれるAI利用量を超えた場合には追加利用料金がかかることがあります。したがってCopilotは、従来型のソフトウェアサブスクリプションとAIコンピューティング利用の課金を組み合わせたモデルへ発展しています。GitHub Copilot 조직 청구 안내

CopilotはGitHubに新たな収益源を加えるだけでなく、リポジトリ、Issue、pull request、コードレビューを含む既存ワークフローの中でAIを利用させます。そのため、独立したAIツールを販売するよりも、既存のプラットフォーム顧客に追加製品をクロスセルしやすくなります。

セキュリティとコンプライアンス製品

大企業は、単にコードを保存する場所に料金を払うわけではありません。アカウント制御、監査ログ、シングルサインオン、シークレット検出、コード脆弱性分析、サプライチェーン管理、規制遵守を必要とします。

オープンソース依存関係への依存が強まるにつれ、組織は脆弱なパッケージや漏洩した認証情報を継続的にスキャンしなければなりません。無料エコシステムの拡大は、逆説的にエンタープライズ向けセキュリティ製品への必要性も高めます。

コンピューティング、ストレージ、自動化の利用

GitHub Actions、Codespaces、Packagesなどのサービスには、プラン内に一定の利用量が含まれ、超過分には料金がかかります。企業の請求には、Enterpriseライセンスだけでなく、ActionsやCodespacesの超過利用、Copilotやセキュリティツールなどの追加ライセンスが含まれる場合があります。GitHub Enterprise 청구 구조

このモデルでは、開発活動が増えるほどGitHubの収益も伸びます。一方でGitHubは実行サーバー、ストレージ機器、ネットワーク、AIモデルのコストも負担するため、すべての利用収益が利益になるわけではありません。

Marketplaceの取引手数料

サードパーティ開発者は、GitHub Marketplaceを通じて有料アプリを販売できます。GitHubは決済とサブスクリプション管理を提供し、運営手数料として取引額の一部を受け取ります。公式ドキュメントによると、2021年以降のアプリ取引に適用される取り分は5%です。GitHub Marketplace 판매 대금 안내

直接的なMarketplace手数料に加え、外部ツールがGitHubを中心に利用されるようになることも重要です。利用するアプリが増えるほど、GitHubを離れる際に置き換える必要がある開発ツールも増え、プラットフォームの継続利用を強めます。

無料のオープンソースはGitHubにとってなぜ経済的価値を持つのか？

GitHubにとって、無料の公開リポジトリは単なるコスト項目ではありません。ユーザー獲得とエコシステム形成のための中核資産です。

第一に、オープンソースプロジェクトは新規ユーザーを呼び込みます。特定のライブラリを使いたい、Issueを報告したい、パッチを提出したい開発者は、GitHubアカウントを作成します。GitHubは広告費をかけずにこれらのユーザーを獲得できます。

第二に、オープンソース活動はGitHubの働き方を事実上の業界標準にします。開発者は学校や個人プロジェクトを通じてfork、Issue、pull requestを学び、職場でも同じ方法を好むようになります。

第三に、公開エコシステムと非公開の企業開発は相互に依存しています。企業の非公開製品も、数え切れないほどの公開ライブラリやツールを利用しています。GitHubの2025年データでは、コントリビューション活動の大半は非公開リポジトリで発生する一方、リポジトリ数では公開プロジェクトが多数を占めました。無料の公開エコシステムが、有料の企業向け作業の基盤を提供しています。

第四に、活発な公開プロジェクトが増えるほど、セキュリティと自動化の需要も高まります。依存関係の更新、悪意あるパッケージの検出、ライセンス管理、大規模なテストとデプロイがすべて必要になります。

したがってGitHubによる無料オープンソースの支援は、慈善活動だけ、あるいは商業活動だけでは説明しにくいものです。開発者コミュニティに実質的な価値を提供する一方、有料のエンタープライズ市場へつながる長期的な流通戦略でもあります。

オープンソース企業は一般にどのように収益を得るのか？

GitHubのビジネスモデルは、オープンソースを活用する複数の収益モデルの一つです。オープンソース企業は、複製可能なコードそのものではなく、運用の利便性、責任の所在、セキュリティ、専門知識に料金を課すことがよくあります。

サポートとコンサルティング： ソフトウェアは無料で提供し、導入、障害対応、研修、長期サポートに料金を課します。
マネージドクラウド： 顧客が自ら導入できるオープンソースと並行して、顧客に代わり運用するSaaSを販売します。
オープンコア： 中核機能を公開する一方、エンタープライズ向けの管理、セキュリティ、分析機能をプロプライエタリライセンスで提供します。
デュアルライセンス： 同じコードをオープンソースライセンスと商用ライセンスの両方で提供し、利用者が状況に応じて選べるようにします。
ホスティングと従量利用： ストレージ、ネットワーク、コンピューティング、自動化実行の利用量に応じて課金します。
スポンサーシップと寄付： 個人、企業、財団がメンテナーやプロジェクト運営を支援します。
認定と研修： 公式研修、試験、技術認定、パートナープログラムを通じて収益を得ます。

これらのモデルが成り立つのは、ソフトウェアのコストがライセンス価格だけに限られないからです。企業は、導入時間、障害リスク、セキュリティインシデント、更新、規制遵守、専門人材の不足を含む総保有コストを考慮します。コードを無料で取得できても、信頼できる運用責任には料金を支払う意思がある場合があります。

オープンソースとGitHubにはどのような制限があるのか？

オープンソースは、参加者が多いからといって自動的に安全で持続可能なソフトウェアになるわけではありません。

保守の負担が少数の人に集中することがある

広く使われているライブラリでも、実際のレビューやリリースを数人のメンテナーに依存していることがあります。利用が増えると、Issue報告とセキュリティ対応の負担は増加しますが、メンテナーの報酬がそれに比例して増えるとは限りません。

公開レビューは品質を保証しない

ソースコードが公開されていることと、誰かが十分にレビューしたことは別です。サプライチェーンリスクには、脆弱性、悪意あるコントリビューション、侵害されたメンテナーアカウント、汚染された依存関係が含まれます。

ライセンス義務が見落とされることがある

オープンソースは著作権のない公共財ではありません。著作権表示の保持、ソースコードの提供、変更の明記、同一ライセンスの適用など、各ライセンスの条件を守る必要があります。多数の依存関係を組み合わせる商用製品では、特にライセンス互換性を確認する必要があります。

プラットフォームへの集中が新たな依存関係を生む

Gitは分散型であるため、リポジトリを別のサーバーに移動できます。しかし、Issue、pull requestの議論、Actionsワークフロー、アクセスポリシー、Marketplaceアプリ、セキュリティ記録を完全に移行することは、はるかに困難です。

GitHubが便利になるほど、開発コミュニティは1社の価格設定、ポリシー、障害対応、機能変更に依存する可能性が高まります。コードをローカルにcloneし、リリースやドキュメントをバックアップし、特定プラットフォーム機能への依存を理解することが必要です。

よくある誤解は何か？

「GitHubで公開されているのでオープンソースだ」

ライセンスがなければ、通常のオープンソース利用権は発生しません。可視性とライセンスは別の設定です。

「オープンソースはすべて無料だ」

複製コストはかからない場合がありますが、運用、サポート、クラウドサービス、研修、セキュリティ機能にはコストがかかることがあります。オープンソースライセンスは有料販売を禁止しません。

「誰でも公式コードを好きなように変更できる」

誰でも自分のコピーを改変できる権利と、変更を公式プロジェクトに取り込む権限は異なります。変更を正式に含めるかどうかは、メンテナーとガバナンスルールが決めます。

「GitHub自体がオープンソースだ」

GitHubは大規模にオープンソースプロジェクトをホスティングし、さまざまなオープンソースツールを公開していますが、GitHubサービス全体が単一のオープンソース製品であるわけではありません。GitHubはMicrosoftが所有する商用プラットフォームです。

「GitHubにはユーザーが多いので、その大半は有料ユーザーだ」

GitHubが報告する開発者数には無料アカウントが含まれます。登録開発者数、アクティブ開発者数、エンタープライズ顧客数、有料シート数は異なる指標です。

「MicrosoftはGitHubを無料で運営している」

無料リポジトリは広く提供されていますが、GitHubはエンタープライズシート、AI、セキュリティ、自動化、コンピューティング、ストレージ、Marketplaceから収益を得ています。無料ユーザーは、有料顧客への転換可能性とネットワーク価値の両方を提供します。

オープンソースプロジェクトをどのように評価すべきか？

実際のプロジェクトでオープンソースを採用する際は、star数やGitHubランキングだけを見ないでください。次の項目をあわせて確認します。

LICENSEファイルと、想定する利用方法との法的互換性
最近のリリースとセキュリティ更新の頻度
中核メンテナーの人数と特定個人への依存度
Issueとpull requestのレビュー速度
テスト、自動化、脆弱性報告の手順の有無
ドキュメントとアップグレードガイドの充実度
セルフホスティングに必要な人員とコスト
GitHubまたは特定のクラウドサービスへの依存度
プロジェクトが終了した場合の代替手段と移行可能性

GitHubを作業プラットフォームとして選ぶ場合にも、同じ原則が当てはまります。無料価格だけを比べるのではなく、必要な権限管理、監査、セキュリティ、自動化の利用量、AIの利用量、データ所在地、障害対応、移行コストをあわせて評価してください。

オープンソースとGitHubの関係をどのように理解すべきか？

オープンソースは、ソフトウェアを共同で利用・改善する権利を配分するためのルールの集合です。Gitはそれらの変更履歴を分散型で管理するツールであり、GitHubはGitベースのコラボレーションを大規模に仲介するプラットフォームです。

GitHubはオープンソースを発明したわけではありません。そうではなく、オープンソースコミュニティに必要な発見、複製、議論、レビュー、マージのプロセスを、統一されたWebワークフローに簡素化しました。公開プロジェクトは開発者ネットワークを作り、そのネットワークは非公開の企業開発もGitHubへ引き寄せました。

その結果、GitHubは公開コードへの入場料を課すのではなく、企業が大規模に共同作業するために必要な管理、セキュリティ、自動化、コンピューティング、AIに料金を課すモデルを構築しました。当初は「公開は無料、非公開は有料」というモデルで始まりましたが、現在は「基本的なコラボレーションは無料、組織の複雑さを解決する機能は有料」という開発プラットフォーム事業として理解できます。