什麼是開放原始碼，以及 GitHub 如何成長和賺錢？

開放原始碼不只是把原始碼公開。它是在明確授權條款下，賦予他人使用、研究、修改及再散布軟體權利的一種方式。GitHub 則透過將這類協作式開發串接至單一工作流程，涵蓋儲存庫、版本控制、程式碼審查及自動化，發展為商業平台。

GitHub 的核心商業模式並非直接販售公開的開放原始碼專案。它吸引龐大的免費使用者基礎，接著針對企業所需的私有協作、存取控制、安全性、法規遵循、自動化、雲端開發環境及人工智慧功能收費。

目錄

• 開放原始碼的精確意義
• 開放原始碼運動的背景
• 開放原始碼開發的運作方式
• 開放原始碼、Git 與 GitHub 的差異
• GitHub 的起源與成長
• GitHub 的營收模式
• 為何免費開放原始碼能創造經濟價值
• 限制與評估標準

開放原始碼究竟是什麼？

開放原始碼軟體是指著作權人透過授權條款賦予使用者權利的軟體，包括執行、研究、修改及再散布的權利。關鍵不只是能否看見程式碼，而是法律上允許哪些權利。

依據開放原始碼促進會（OSI）的定義，開放原始碼授權必須允許自由再散布、提供原始碼，並允許散布修改版與衍生作品。它不得歧視任何個人、團體或使用領域。因此，即使原始碼公開，若適用「僅限非商業用途」或「不得用於競爭產品」等限制，通常仍難以將該軟體視為開放原始碼。OSI의 Open Source Definition↗

這項區別對 GitHub 上的公開儲存庫尤其重要。即使所有人都看得到儲存庫，若沒有開放原始碼授權，預設著作權法仍然適用。其他人可在 GitHub 服務內檢視或 fork 該儲存庫，但不會自動取得自由複製、修改及散布程式碼的權利。GitHub 也說明，專案必須有載明使用許可的授權，才算真正的開放原始碼。GitHub의 저장소 라이선스 안내↗

因此，下列三種說法的意思不同：

• 「你可以檢視程式碼」描述的是原始碼是否公開。
• 「你可以免費使用」描述的是價格。
• 「它是開放原始碼」描述的是授權所賦予的權利。

免費軟體不一定是開放原始碼，開放原始碼軟體也可以販售。

什麼背景促成了開放原始碼運動？

在早期的電腦研究社群中，分享軟體程式碼並協作改進的做法早已存在。然而，隨著軟體成為獨立的商業產品，著作權與使用限制也愈加嚴格，人們開始更關切使用者能否研究及修正軟體。

1980 年代，Richard Stallman 發起 GNU 計畫與自由軟體運動。在自由軟體的語境中，「free」並非指價格，而是使用者執行、研究、修改及再散布程式的自由，無論是原始版本或修改版本。GNU의 자유 소프트웨어 정의↗

「open source」一詞是在 Netscape 於 1998 年宣布計畫釋出瀏覽器原始碼後不久的一場策略會議中創造。該年，Eric Raymond、Bruce Perens 等人創立 OSI，並以 Debian Free Software Guidelines 為基礎整理 Open Source Definition。目的在於向企業與大眾更清楚說明協作開發的實務優勢。OSI 역사↗

自由軟體與開放原始碼在所接受的授權上大致重疊，但強調重點不同。

這種差異不代表任一方必然較優。它表示同一套程式可以從使用者權利的角度說明，也可以從透明開發與分散式協作效率的角度說明。

開放原始碼開發如何運作？

開放原始碼不代表「任何人都能隨心所欲修改程式碼」。參與的機會可以是開放的，但哪些變更會納入正式版本，仍由專案維護者與既定流程決定。

典型的開發流程如下：

1. 維護者公布原始碼、授權、使用說明及貢獻規則。
2. 使用者 clone 或 fork 儲存庫，建立獨立的工作空間。
3. 在獨立分支中進行錯誤修正或功能開發。
4. 貢獻者提出包含變更及其理由的 Pull Request。
5. 維護者審查程式碼、測試結果、設計方向及安全影響。
6. 只有符合標準的變更會合併至正式儲存庫。
7. 發布新版本，之後發現的問題會再次追蹤。

此流程中存在不同角色。使用者使用軟體並回報問題；貢獻者提交程式碼或文件；維護者負責審查與發布。專案指導委員會或基金會也可能負責管理商標、預算及決策規則。

換句話說，開放原始碼的「開放」不代表不存在決策權。參與機會與使用程式碼的權利是開放的，但正式專案仍有維持品質的控制架構。

開放原始碼授權有何差異？

開放原始碼授權大致可分為寬鬆型授權與著佐權授權。

寬鬆型授權

MIT、BSD 與 Apache License 2.0 是常見例子。只要遵守保留著作權聲明及授權文字等條件，這些授權通常允許將修改後的程式碼納入專有軟體。

這讓企業容易將其整合進商業產品，但並不保證改良後的程式碼會回饋至原始社群。Apache License 2.0 也包含明確的專利相關條款，因此其法律條件並不等同於 MIT License。

著佐權授權

GNU General Public License（GPL）是代表性範例。當散布修改後的程式碼，或散布與該程式碼結合的衍生作品時，它可能要求以相同授權提供原始碼。

著佐權並不禁止商業使用。軟體可以商業販售，但必須遵守授權所界定範圍內的原始碼揭露義務。LGPL 與 AGPL 等變體，則針對程式庫連結與網路服務設計不同條件。

選擇授權時，不應只是因為知名專案採用它而選擇。應檢視衍生作品的揭露範圍、專利條款、網路服務交付，以及與其他授權的相容性。

開放原始碼、Git 與 GitHub 有什麼差別？

這三個概念經常一同出現，但運作的層次不同。

• 開放原始碼是描述軟體使用權利與協作開發方法的概念。
• Git是以分散式方式管理檔案變更歷程的開放原始碼版本控制程式。
• GitHub是在線上託管 Git 儲存庫，並提供程式碼審查、議題管理、自動化、安全性及協作功能的商業服務。

Git 創立於 2005 年，當時 Linux 核心開發社群與專有分散式版本控制工具 BitKeeper 的合作關係結束。像 Linux 這樣規模龐大的專案，需要一套可處理速度、分散式工作及大量平行分支的工具。Git 공식 역사↗

透過 Git，每位開發者都能維護包含完整變更歷程的儲存庫，而不必始終連線至中央伺服器。然而，僅使用命令列 Git，不便管理誰提出變更、為何需要變更、誰會審查，以及何時合併。GitHub 正是透過網頁介面組織這種協作流程。

Git 不必搭配 GitHub 使用，儲存庫也可在 GitLab、Bitbucket 或自架伺服器上運作。反過來說，GitHub 不僅包含開放原始碼，也有私有企業程式碼及未附授權的公開程式碼。GitHub 與開放原始碼不是同義詞。

GitHub 如何起步？

GitHub 由 Tom Preston-Werner、Chris Wanstrath 與 PJ Hyett 等人開發，並於 2008 年作為公開服務推出。後來以 Pro Git 作者身分聞名的 Git 專家 Scott Chacon，也加入了早期團隊。

GitHub 內部儲存庫的第一筆 commit 於 2007 年 10 月建立，服務於 2008 年 4 月推出。大約在第一週年時，GitHub 擁有超過 20,000 個公開儲存庫與四名全職員工，且尚未接受外部投資。GitHub의 첫해 기록↗

GitHub 想解決的問題不只是檔案儲存。它希望建立一個協作環境，將分散式 Git 儲存庫中的變更視覺化，協助開發者發現彼此的工作，並讓變更提案易於審查。GitHub 於 2008 年發布的網路圖，也是試圖在單一畫面中呈現多名使用者分支與 commits 之間的關係。초기 Network Graph 소개↗

這種做法後來被稱為「社交式程式設計」（social coding）。開發者的個人檔案、活動歷程、追蹤、fork、star、issue 與 pull request 都與程式碼儲存庫相連，讓開發流程本身成為可搜尋及觀察的網路。

GitHub 為何成長得如此快速？

GitHub 的成長不能只用提供免費 Git 儲存空間來解釋。技術時機、使用者體驗、網路效應與企業商業模式共同發揮作用。

它讓 Git 複雜的協作流程能在網頁上被理解

分支、commit 與合併是 Git 的強大功能，但初學者不容易只透過指令理解。GitHub 將程式碼差異、討論、審查結果及測試狀態整合至 pull request 介面中。

開發者不必透過電子郵件傳遞 patch 檔案，而可使用單一連結分享變更。專案維護者也能降低審查成本，因為程式碼與討論流程會一併記錄。

公開儲存庫建立了開發者網路

當專案加入 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 與專有軟體為中心的形象，並建立不受作業系統或程式語言限制的開發者接觸點。它也取得串接 Azure、Visual Studio、VS Code 與 GitHub 的機會。

收購後，GitHub 從儲存庫託管擴展為涵蓋完整開發生命週期的平台。GitHub Actions 可自動化建置、測試與部署；Codespaces 提供雲端開發環境；Advanced Security 產品掃描程式碼、相依套件與機密資訊；Copilot 則提供 AI 驅動的程式碼撰寫與審查功能。

2022 年 10 月，Microsoft 宣布 GitHub 的年度經常性收入（ARR）已達 10 億美元，使用者已超過 9,000 萬，是收購時的三倍。Microsoft FY2023 1분기 실적 발표↗

GitHub 宣布，2023 年有超過 1 億名開發者使用該平台，2025 年則超過 1.8 億名。2025 年，專案總數達到 6.3 億，而 GitHub 統計約 81.5% 的所有貢獻發生於私有儲存庫。這顯示 GitHub 已同時成為開放原始碼空間與大規模企業開發基礎設施。GitHub Octoverse 2025↗

不過，這些數字是依 GitHub 自身標準統計的平台指標。註冊開發者數不應解讀為等同每月活躍使用者或付費客戶數。Microsoft 也不會每年以獨立業務單位的形式，詳細揭露 GitHub 當前營收與營業利益，因此 2022 年公布的 10 億美元 ARR 應視為當時揭露的代表性規模指標，而非當前營收。

GitHub 具體從哪些地方賺錢？

GitHub 的營收模式可概括為免費增值模式：透過免費公開平台取得使用者，再針對組織營運所需的控制與生產力收費。

每位使用者席次訂閱

免費方案讓個人與小型團隊使用核心儲存庫功能。Team 方案提供進階協作功能，Enterprise 方案則提供安全性、法規遵循、集中管理與部署選項。

依據 2026 年 9 月查閱的官方價格頁面，Team 起價為每位使用者每月 4 美元，Enterprise 起價為每位使用者每月 21 美元。實際金額可能因合約期限、地區、稅金及大型合約條件而異。GitHub 공식 가격표↗

以席次計費的優點是，隨著公司人數增加，經常性收入也可成長。一旦程式碼與工作流程在平台上建立，轉換成本也會提高，因而更可能保留合約。

AI 產品訂閱與按用量計費

GitHub Copilot 為個人與組織提供付費方案。公司可為每位使用者購買席次，若超過方案內含的 AI 使用量，可能另收額外使用費。因此，Copilot 正發展為結合傳統軟體訂閱與 AI 運算使用量計費的模式。GitHub Copilot 조직 청구 안내↗

Copilot 不僅為 GitHub 增加新的收入來源，也使 AI 在既有的儲存庫、issue、pull request 及程式碼審查工作流程中被使用。相較於銷售獨立 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 而言，免費公開儲存庫不只是成本項目，也是獲取使用者與形成生態系的核心資產。

首先，開放原始碼專案能帶來新使用者。想使用特定程式庫、回報問題或提交 patch 的開發者會建立 GitHub 帳號。GitHub 無須投入廣告費便可取得這些使用者。

其次，開放原始碼活動使 GitHub 的工作方式成為事實上的產業標準。開發者在學校或個人專案中學習 fork、issue 與 pull request，之後在工作場所也會偏好相同方法。

第三，公開生態系與私有企業開發彼此依存。企業的私有產品同樣使用無數公開程式庫與工具。GitHub 的 2025 年資料顯示，多數貢獻活動發生於私有儲存庫，但依儲存庫數量而言公開專案占多數。免費公開生態系為付費企業工作提供基礎。

第四，更活躍的公開專案會增加安全性與自動化需求。相依套件更新、惡意套件偵測、授權管理，以及大規模測試與部署都成為必要事項。

因此，GitHub 對免費開放原始碼的支持，很難只解釋為慈善行為或純粹商業活動。它一方面為開發者社群提供真實價值，另一方面也是導向付費企業市場的長期通路策略。

開放原始碼公司通常如何賺錢？

GitHub 的商業模式是運用開放原始碼的多種營收模式之一。開放原始碼公司通常不是針對可複製的程式碼本身收費，而是針對營運便利性、責任承擔、安全性與專業知識收費。

• **支援與顧問服務：**免費提供軟體，並針對安裝、事件處理、訓練與長期支援收費。
• **代管雲端：**除了讓客戶自行安裝的開放原始碼，也販售代客運作的 SaaS。
• **開放核心：**公開核心功能，並以專有授權提供企業管理、安全性與分析功能。
• **雙重授權：**以開放原始碼授權與商業授權提供相同程式碼，讓使用者依自身情況選擇。
• **託管與用量：**依儲存、網路、運算及自動化執行用量收費。
• **贊助與捐款：**個人、企業及基金會支持維護者或專案營運。
• **認證與訓練：**透過官方訓練、考試、技術認證或合作夥伴計畫取得收入。

這些模式之所以可行，是因為軟體成本不只包含授權價格。企業會考量總持有成本，包括安裝時間、停機風險、安全事件、更新、法規遵循，以及專業人員短缺。即使能免費取得程式碼，它們也可能願意為可靠的營運責任承擔付費。

開放原始碼與 GitHub 有哪些限制？

開放原始碼不會僅因為有許多參與者，就自動成為安全且可持續的軟體。

維護負擔可能集中於少數人

即使廣泛使用的程式庫，實際審查與發布也可能只仰賴少數維護者。隨著使用量增加，問題回報與安全回應的負擔也會上升，但維護者的報酬未必隨之增加。

公開審查不保證品質

原始碼公開，和有人充分審查是不同的事。供應鏈風險包括弱點、惡意貢獻、維護者帳號遭入侵，以及受污染的相依套件。

授權義務可能被忽略

開放原始碼不是無著作權的公共財。每種授權的條件都必須遵守，包括保留著作權聲明、提供原始碼、標示變更，以及採用相同授權。尤其在結合許多相依套件的商業產品中，必須審查授權相容性。

平台集中化會形成新的依賴

由於 Git 是分散式的，儲存庫可遷移至其他伺服器。然而，完整遷移 issue、pull request 討論、Actions 工作流程、存取政策、Marketplace 應用程式及安全紀錄，則困難得多。

GitHub 越便利，開發社群就可能越依賴單一公司的定價、政策、事件回應與功能變更。有必要在本機 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 並未發明開放原始碼。相反地，它將開放原始碼社群所需的發現、複製、討論、審查與合併流程，簡化為統一的網頁工作流程。公開專案建立了開發者網路，而該網路也將私有企業開發帶到 GitHub。

因此，GitHub 並非針對公開程式碼收取入場費，而是建立一種針對企業大規模協作所需控制、安全性、自動化、運算與 AI 收費的模式。它起初採用「公開免費、私有付費」的早期模式，但如今可理解為一項開發平台業務：即「基礎協作免費，解決組織複雜性的功能付費」。