1991年，一個芬蘭大學生在網路上發布了一則訊息：「我正在寫一個（免費的）作業系統，只是興趣使然，不會像 GNU 那麼大那麼專業。」[1] 這個學生叫林納斯・托瓦茲（Linus Torvalds），這個作業系統後來被稱為 Linux。三十多年後，Linux 運行著全球 96.3% 的頂級伺服器、100% 的超級電腦、以及超過 70% 的智慧型手機（透過 Android）。[2] 微軟的 CEO 薩蒂亞・納德拉（Satya Nadella）曾宣稱「微軟愛 Linux」——這句話在二十年前會被視為異端邪說。[3]

開源軟體（Open Source Software）用「免費」這個不可思議的定價策略，徹底改變了軟體產業的版圖。但「免費」從來不是真正的免費——它只是將成本轉嫁到了別處。當這個轉嫁機制失靈，危機就會浮現。

一、免費的經濟學：為什麼「零元」可以打敗「天價」

1.1 軟體的邊際成本革命

要理解開源軟體為何能以免費姿態席捲市場，必須先理解軟體產業的成本結構。

傳統實體商品的生產遵循邊際成本遞增的規律：製造第一百萬台汽車的成本，不會比第一台便宜太多（原料、人工、物流都要錢）。但軟體不同——開發第一份程式碼需要投入大量人力和時間（固定成本極高），但複製和分發的成本趨近於零（邊際成本極低）。[4]

這種成本結構意味著：軟體的「自然」定價傾向於免費。一旦開發完成，多賣一份的成本幾乎是零，所以理論上價格可以無限下探。微軟之所以能維持高價，靠的是「人為稀缺」——透過專利、著作權、授權協議等法律工具，創造出不存在的稀缺性。[5]

開源軟體打破了這種人為稀缺。當程式碼公開、任何人都可以複製和修改，「稀缺」就消失了，價格自然回歸到邊際成本——也就是零。

1.2 網路效應與標準之戰

免費策略之所以有效，還因為軟體市場存在強大的「網路效應」（Network Effects）：使用某個軟體的人越多，它對每個用戶的價值就越高。[6]

以程式語言為例：Python 之所以強大，不只是因為語法簡潔，更因為它擁有龐大的套件生態系（PyPI 上有超過 50 萬個套件）。[7] 這些套件是全球開發者貢獻的結果。一旦 Python 建立了這種生態系優勢，後進者幾乎不可能追上——即使設計出更好的語言，也缺乏配套的套件和社群。

開源軟體特別擅長利用網路效應。因為程式碼公開，任何人都可以貢獻改進、開發外掛、撰寫文件。這種「群眾外包」式的開發模式，讓開源專案能夠以遠低於商業軟體的成本，累積起龐大的功能和生態系。[8]

1.3 克里斯・乍德森的「免費經濟學」

《連線》雜誌前總編輯克里斯・乍德森（Chris Anderson）在其著作《免費》（Free: The Future of a Radical Price）中，系統性地分析了數位時代的「免費」商業模式：[9]

  • 交叉補貼（Cross-Subsidies）：A 產品免費，B 產品收費。例如：Gillette 送刮鬍刀、賣刀片。
  • 廣告模式（Advertising）：內容免費，廣告商付費。例如：Google、Facebook。
  • 免費增值（Freemium）：基本版免費，進階功能收費。例如：Spotify、Dropbox。
  • 禮物經濟（Gift Economy）：創作者無償貢獻，獲得聲譽或其他非金錢回報。例如：維基百科、早期開源軟體。

開源軟體的商業模式，通常結合了「禮物經濟」（核心軟體免費）與「交叉補貼」或「免費增值」（服務、支援、企業版收費）。這種混合模式曾經運作良好——直到雲端時代的來臨。

二、開源的商業模式演化史

2.1 紅帽模式：賣「帽子」不賣軟體

紅帽公司（Red Hat）是開源商業化的經典案例。它的核心產品是 Linux 發行版——一個完全免費的作業系統。那它靠什麼賺錢？

答案是「訂閱服務」。紅帽銷售的不是軟體本身，而是：[10]

  • 技術支援：企業客戶遇到問題時可以獲得專家協助。
  • 安全更新：定期的漏洞修補和安全補丁。
  • 認證與合規：確保軟體符合企業和法規要求。
  • 培訓與諮詢：協助企業導入和優化開源技術。

這個模式非常成功。2018年，IBM 以 340 億美元收購紅帽，創下開源公司收購的最高紀錄。[11] 這證明了開源軟體可以創造巨大的商業價值——至少在某些條件下。

2.2 開放核心（Open Core）模式

另一種流行的模式是「開放核心」（Open Core）：核心軟體開源免費，但進階功能（通常是企業需要的功能）則需要付費。[12]

GitLab 是這種模式的代表。它的核心版本（Community Edition）完全免費且開源，但企業版（Enterprise Edition）包含了額外的安全、合規和管理功能，需要訂閱付費。[13]

MongoDB 在早期也採用類似策略，核心資料庫引擎免費，但提供付費的管理和監控工具。這種模式的邏輯是：個人開發者和小型專案使用免費版本（擴大用戶基礎和市場占有率），企業客戶則為進階功能付費（創造營收）。

2.3 雲端服務（Cloud/SaaS）模式

隨著雲端運算興起，許多開源公司轉向提供託管服務。邏輯很簡單：軟體是免費的，但維運是有價值的。[14]

以 MongoDB 為例，企業可以自己下載、安裝、維護 MongoDB（免費但耗費人力），也可以使用 MongoDB Atlas——官方提供的託管服務，按用量付費。對於大多數企業來說，付費使用託管服務比自己維護更划算，因為維運需要專業人才，而人才成本遠高於訂閱費用。[15]

這三種模式——服務支援、開放核心、雲端託管——曾經支撐起一個蓬勃的開源商業生態系。但問題來了：當雲端巨頭也開始玩這個遊戲，規則就完全不同了。

三、雲端巨頭的「合法掠奪」

3.1 AWS 的「分叉」戰術

2019年，Amazon Web Services（AWS）推出了 DocumentDB——一個「與 MongoDB 相容」的資料庫服務。[16] 注意這個措辭：「相容」而非「基於」。AWS 並沒有使用 MongoDB 的程式碼，但它的 API 與 MongoDB 完全相容，意味著用戶可以無痛切換。

這是完全合法的。API（應用程式介面）通常不受著作權保護，只要不複製原始碼，任何人都可以開發一個「相容」的替代品。[17] AWS 利用其龐大的雲端基礎設施和客戶關係，直接提供 MongoDB 的功能，卻不需要向 MongoDB 公司支付任何費用。

類似的情況在 Elasticsearch 身上也發生了。AWS 推出了 Amazon Elasticsearch Service，直接使用 Elasticsearch 的開源程式碼，提供託管服務並收費。Elasticsearch 的開發公司 Elastic 抱怨：「我們寫程式碼，他們賺錢。」[18]

3.2 公地悲劇的數位版本

經濟學家加勒特・哈丁（Garrett Hardin）在1968年提出了「公地悲劇」（Tragedy of the Commons）的概念：當資源是共有的、任何人都可以使用，人們傾向於過度使用，最終導致資源枯竭。[19]

開源軟體正在經歷一場數位版的公地悲劇。程式碼是「公地」，任何人都可以使用（這是開源的本意）。但當使用者中出現了 AWS 這樣的巨頭，它可以從公地中獲取巨大利益，卻幾乎不回饋社群，這個生態系統就會失衡。

根據統計，AWS 每年從開源相關服務中獲取的營收超過 50 億美元，但其對開源社群的貢獻（以程式碼提交量計算）微乎其微。[20] 這種「提取」大於「貢獻」的不對稱關係，是許多開源公司改變授權的根本原因。

3.3 搭便車問題

更深層的問題是「搭便車」（Free-Rider Problem）。在經濟學中，搭便車指的是：享受公共財的好處卻不承擔成本的行為。[21]

開源軟體是一種公共財：它具有「非排他性」（無法阻止任何人使用）和「非競爭性」（一個人使用不會減少其他人使用的機會）。[22] 理論上，公共財應該由政府提供，或透過某種集體機制融資。但開源軟體的「生產」高度依賴個人和企業的自願貢獻。

當貢獻者看到巨頭搭便車獲利，而自己卻在為生計掙扎，貢獻的動機就會下降。這就是為什麼開源專案的「倦怠」（Burnout）問題日益嚴重：核心維護者承擔了不成比例的責任，卻得不到相應的報酬。[23]

四、許可證戰爭：圍牆的再起

4.1 MongoDB 的 SSPL 爭議

2018年，MongoDB 做出了一個震驚開源界的決定：放棄 AGPL 許可證，改採自創的「伺服器端公共許可證」（Server Side Public License, SSPL）。[24]

SSPL 的核心條款是：如果你將 MongoDB 作為服務提供給用戶（例如像 AWS 那樣提供 MongoDB 託管服務），你必須公開你整個服務的原始碼。這個要求極為嚴苛——等於要求 AWS 公開其整個雲端平台的程式碼，這在商業上是不可能的。[25]

開源倡議組織（Open Source Initiative, OSI）拒絕承認 SSPL 是「開源」許可證，認為它違反了開源定義中的「不得歧視特定使用方式」原則。[26] 但這恰恰是 MongoDB 的目的——它就是要歧視雲端巨頭的「掠奪性」使用。

4.2 Redis 的授權變革

2024年3月，Redis 宣布放棄 BSD 許可證，改採雙重授權：Redis 源碼可用許可證（RSALv2）和伺服器端公共許可證（SSPLv1）。[27]

這個決定引發了社群的強烈反彈。Redis 是全球最受歡迎的鍵值資料庫，被無數專案依賴。授權變更意味著：雲端服務商不能再免費提供 Redis 託管服務，必須獲得商業授權或使用其他替代方案。

Linux 基金會迅速響應，宣布支持一個名為「Valkey」的 Redis 分叉專案，由 AWS、Google、Oracle 等公司共同維護。[28] 這個舉動頗具諷刺：被批評「搭便車」的雲端巨頭，現在聯手「分叉」了要收費的專案，繼續提供免費版本。

4.3 HashiCorp 與 Terraform 的 BSL 之爭

2023年8月，HashiCorp 將其旗下所有產品（包括廣受歡迎的 Terraform）從 MPL 2.0 改為「商業源碼許可證」（Business Source License, BSL）。[29] BSL 允許檢視和修改程式碼，但禁止用於與 HashiCorp 競爭的商業用途。

這同樣引發了分叉運動。Linux 基金會支持的 OpenTofu 專案，繼續維護 Terraform 的開源版本。[30] HashiCorp 則控告 OpenTofu 的程式碼涉嫌抄襲其 BSL 版本的新功能，將爭議升級到法律層面。[31]

這些案例揭示了一個殘酷的現實：開源世界正在分裂成兩個陣營——試圖建立商業護城河的原創公司，與堅持「純粹開源」的社群和雲端巨頭聯盟。

五、Tailwind CSS 的生存之道：一個另類案例

5.1 從 Side Project 到百萬美元事業

在這片許可證戰場的喧囂中，Tailwind CSS 提供了一個頗為不同的案例。

Tailwind CSS 是一個「功能優先」（Utility-First）的 CSS 框架，由亞當・瓦桑（Adam Wathan）於2017年創建。[32] 它的核心庫完全免費且開源（MIT 許可證），但 Tailwind Labs 透過銷售 UI 元件庫（Tailwind UI）和開發工具賺取收入。

根據 Wathan 的公開分享，Tailwind Labs 在2023年的年營收已超過 1,000 萬美元，而團隊只有不到20人。[33] 這是一個驚人的效率——相比之下，許多獲得大量創投資金的開源公司，員工數百人卻仍在虧損。

5.2 Tailwind 的商業模式分析

Tailwind 的成功基於幾個關鍵策略：[34]

  • 核心永遠免費：CSS 框架本身維持 MIT 許可證，不設任何限制。這確保了最大的採用率和社群支持。
  • 互補品收費：Tailwind UI 是一套精美的預製元件，節省開發者大量時間。它不是 Tailwind CSS 的「進階版」，而是建立在 Tailwind 之上的獨立產品。
  • 價值定位清晰：免費的 Tailwind CSS 解決「如何寫 CSS」的問題；付費的 Tailwind UI 解決「如何設計漂亮的介面」的問題。兩者有關聯但不重疊。
  • 個人品牌與社群經營：Wathan 積極參與社群、公開分享經驗、建立個人品牌。這種透明度贏得了開發者的信任和支持。

從經濟學角度看，Tailwind 的策略是：將「公共財」（CSS 框架）與「私有財」（UI 元件庫）結合。前者建立市場地位和用戶基礎，後者捕獲商業價值。這避免了「核心功能收費導致採用率下降」的陷阱，也避免了「全部免費導致無法營利」的困境。[35]

5.3 Tailwind 的潛在危機

然而，Tailwind 的模式並非沒有風險。

2024年，Wathan 在一次播客中坦承，維護開源專案的壓力非常大：社群的期待不斷提高、競爭者（如 UnoCSS）持續湧現、而團隊的時間和精力有限。[36] 他提到，如果沒有 Tailwind UI 的商業收入支撐，他很可能早已放棄這個專案。

更深層的危機是「價值脫鉤」。Tailwind CSS 的巨大成功為整個網頁開發產業創造了價值，但 Tailwind Labs 只能捕獲其中一小部分。數以百萬計的開發者使用 Tailwind 建立網站，這些網站創造的經濟價值遠超過 Tailwind Labs 的營收。這種「創造價值」與「捕獲價值」之間的落差，是所有開源專案的共同困境。[37]

另一個隱憂是「分叉風險」。Tailwind CSS 使用 MIT 許可證，意味著任何人都可以合法地複製、修改、重新發布它。如果有人（例如一家大公司）決定「分叉」Tailwind，投入更多資源開發，理論上可以取代原版。這種情況在開源世界屢見不鮮——Node.js 分叉出 io.js、MySQL 分叉出 MariaDB、Redis 分叉出 Valkey。[38]

5.4 生成式 AI：互補品策略的終結者？

然而，Tailwind 面臨的最大威脅可能不是競爭對手或分叉，而是生成式 AI 的崛起。

Tailwind UI 的價值主張是「節省開發者設計和編寫 UI 元件的時間」。但在 2024 年，這個價值主張正在被 AI 編程助手侵蝕。[50] 使用 Claude、GPT-4、Cursor 或 v0.dev 等工具，開發者可以透過自然語言描述，在幾秒鐘內生成完整的 Tailwind CSS 元件——包括響應式設計、深色模式、動畫效果，品質足以媲美 Tailwind UI 的付費元件。

這種轉變的經濟學意涵深遠。Tailwind Labs 的商業模式建立在一個前提上：「設計精美的 UI 元件需要大量專業知識和時間，因此值得付費購買。」但當 AI 可以在幾秒鐘內生成同等品質的元件時，這個前提就崩潰了。[51]

諷刺的是，Tailwind CSS 的開源性質反而加速了這個困境。因為 Tailwind 的語法完全公開，數以百萬計的開源專案使用 Tailwind，這些專案的程式碼都成為了 AI 模型的訓練資料。AI 從免費的開源程式碼中學習，然後免費生成與付費產品品質相當的輸出——這是一種新型態的「價值提取」，比 AWS 的雲端服務更加徹底。[52]

實際案例已經出現。Vercel 推出的 v0.dev 可以根據文字描述生成完整的 React + Tailwind 元件；[53] Cursor IDE 整合的 AI 可以直接在編輯器中生成 Tailwind 程式碼；甚至免費的 ChatGPT 也能產出堪用的 Tailwind 元件。開發者不再需要購買 Tailwind UI，只需要描述「我想要一個帶有漸層背景的定價卡片」，AI 就能生成。

這揭示了「互補品策略」的一個致命弱點：當互補品（UI 元件）可以被 AI 自動生成時，它就不再是有效的收入來源。Tailwind Labs 面臨一個兩難：

  • 如果維持現狀：付費用戶可能流失到 AI 生成的免費替代品。
  • 如果轉向 AI 服務：他們必須與 OpenAI、Anthropic、Google 等 AI 巨頭競爭——這些公司的資源和技術遠超過一個20人的小團隊。

Tailwind 的案例可能是一個預警：在生成式 AI 時代，任何建立在「設計模式」或「樣板程式碼」之上的商業模式，都可能被 AI 的自動生成能力瓦解。這不僅影響 Tailwind，也影響所有販售元件庫、模板、設計系統的開源公司。[54]

六、開源經濟學的核心困境

6.1 價值創造與價值捕獲的脫鉤

開源軟體的根本經濟困境，可以用一個簡單的公式表達：

社會總價值（由開源軟體創造） ≫ 創造者捕獲的價值

哈佛商學院教授曼紐爾・乍曼（Manuel Cebrian）等人的研究估計，開源軟體為全球經濟創造的價值高達數兆美元，但開源開發者獲得的報酬僅佔其中的極小比例。[39]

這種脫鉤導致兩個問題：

  • 投資不足：如果創造者無法獲得合理報酬，就會減少投資和貢獻，導致軟體品質下降或停止維護。
  • 不公平分配：價值流向那些善於「提取」而非「貢獻」的參與者，破壞生態系統的合作基礎。

6.2 科斯定理與產權的缺失

諾貝爾經濟學獎得主羅納德・科斯（Ronald Coase）提出，當產權明確且交易成本夠低時，市場可以透過談判達到效率的資源配置。[40] 但開源軟體的「產權」是模糊的——它刻意放棄了部分排他性權利。

這種產權模糊在早期是優勢（促進廣泛採用和協作），但在商業化階段成為劣勢（難以捕獲價值）。許可證變更潮的本質，就是試圖重新界定產權邊界——允許「用」但限制「賣」。

6.3 集體行動的困境

政治學家曼瑟・奧爾森（Mancur Olson）在《集體行動的邏輯》中指出，大型群體難以組織集體行動，因為每個成員都有搭便車的誘因。[41]

開源社群正面臨這個困境。數以百萬計的用戶從免費軟體中獲益，但願意付費支持的只是少數。眾籌平台（如 GitHub Sponsors、Open Collective）雖然提供了捐款管道，但實際籌集的金額遠不足以支持全職開發。[42] 大多數用戶的心態是：「別人會捐的，我不用。」結果是所有人都不捐。

七、可能的出路

7.1 公司贊助與基金會模式

一種解決方案是透過「受益者付費」的機制。Linux 基金會、Apache 基金會等組織，向從開源獲益的大公司收取會費，用於支持開源專案的維護。[43]

這種模式的邏輯是：將「自願捐款」轉變為「付費會員」，透過提供專屬服務（如技術支援、品牌使用權、決策參與權）來激勵付費。但這種模式更適合基礎設施級的大型專案，小型專案難以獲得同等關注。

7.2 政府與公共資金的介入

鑒於開源軟體的「公共財」性質，有學者主張應由政府提供資金支持。歐盟的「下一代網際網路」（Next Generation Internet）計畫已經開始資助開源專案。[44] 德國政府也設立了「主權科技基金」（Sovereign Tech Fund），專門支持關鍵開源基礎設施。[45]

這種模式將開源軟體視為數位時代的「公共基礎設施」，如同政府資助道路、橋樑和公共衛生。但它也面臨挑戰：政府如何判斷哪些專案值得資助？如何避免「挑選贏家」的問題？如何維持開源的中立性和獨立性？

7.3 新型許可證與「公平程式碼」運動

SSPL、BSL 等新型許可證代表了一種「第三條路」：既不是完全開源，也不是完全閉源，而是「有條件開放」。[46]

「公平程式碼」（Fair Code）運動試圖為這類許可證建立一個新的類別和敘事：程式碼是公開的（可閱讀、可學習、可貢獻），但商業使用有限制。[47] 這種模式試圖在「社群價值」和「商業可持續性」之間找到平衡。

批評者認為這是「假開源」或「開源背叛」，但支持者反駁：如果純粹的開源無法讓創造者生存，那這種理想主義最終只會導致專案被放棄，對誰都沒好處。

7.4 互補品策略的深化

Tailwind 的案例顯示，「核心開源 + 互補品收費」是一條可行的路。但這需要創造者具備商業頭腦，能夠識別和開發「互補品」。[48]

對於不擅長商業化的技術創造者，一種選擇是與商業夥伴合作：創造者專注於核心技術，商業夥伴負責包裝、銷售和支援。這種「分工」模式在傳統軟體產業很常見，但在開源世界還不普遍。

八、結語：免費的代價

「免費」從來不是真正的免費。它只是意味著成本由其他人承擔。

開源軟體的「免費」，長期以來由開發者的熱情、企業的贊助、以及社群的協作所支撐。但當這些支撐機制不足以應對雲端巨頭的規模化提取，系統就會失衡。

我們正在見證開源運動的一次重大轉折。從1990年代的理想主義烏托邦，到2000年代的企業級採用，再到2010年代的雲端化爆發，如今進入了「後純粹開源」時代。[49] 在這個時代，「開源」不再是二元選擇（開或不開），而是一個光譜——從完全開放到完全封閉之間，有各種灰色地帶。

對於開發者而言，這意味著需要更加審慎地思考：使用一個開源專案時，我是否也在「搭便車」？我能否以某種方式回饋社群？對於企業而言，這意味著需要將「開源支持」納入成本結構——如果你的整個技術棧都建立在免費軟體上，你是否應該為此付費？

而對於開源創造者，最務實的建議或許是 Wathan 的經驗：不要只創造免費的東西，還要找到可以賣的東西。理想主義可以是動力，但不能是商業模式。在這個意義上，開源軟體的危機，也是一次成熟的契機——從「免費」的浪漫，走向「可持續」的現實。

參考資料

  1. Torvalds, L. (1991, August 25). comp.os.minix newsgroup posting. Google Groups Archive
  2. W3Techs. (2024). Usage statistics of operating systems for websites. w3techs.com; Top500. (2023). Operating system share for supercomputers. top500.org
  3. Foley, M. J. (2014, October 20). Microsoft's Nadella: 'Microsoft Loves Linux'. ZDNet. zdnet.com
  4. Shapiro, C., & Varian, H. R. (1998). Information Rules: A Strategic Guide to the Network Economy. Boston: Harvard Business School Press, Chapter 1.
  5. Lessig, L. (2001). The Future of Ideas: The Fate of the Commons in a Connected World. New York: Random House, pp. 53-58.
  6. Katz, M. L., & Shapiro, C. (1985). Network Externalities, Competition, and Compatibility. American Economic Review, 75(3), 424-440. jstor.org
  7. Python Package Index (PyPI). (2024). Package statistics. pypi.org
  8. Raymond, E. S. (1999). The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary. Sebastopol: O'Reilly Media.
  9. Anderson, C. (2009). Free: The Future of a Radical Price. New York: Hyperion.
  10. Red Hat. (2023). Annual Report 2023. redhat.com
  11. IBM. (2018, October 28). IBM to Acquire Red Hat, Completely Changing the Cloud Landscape. Press Release. ibm.com
  12. Riehle, D. (2012). The Commercial Open Source Business Model. In Technology Innovation Management Review, 2(1), 8-17. https://doi.org/10.22215/timreview/506
  13. GitLab. (2024). GitLab Features by Tier. gitlab.com
  14. Cusumano, M. A. (2004). The Business of Software. Communications of the ACM, 47(5), 20-21. https://doi.org/10.1145/986213.986226
  15. MongoDB. (2024). MongoDB Atlas Documentation. mongodb.com
  16. Amazon Web Services. (2019, January 9). Introducing Amazon DocumentDB (with MongoDB Compatibility). aws.amazon.com
  17. Google LLC v. Oracle America, Inc., 593 U.S. ___ (2021). supreme.justia.com
  18. Elastic. (2021, January 14). Doubling Down on Open, Part II. elastic.co
  19. Hardin, G. (1968). The Tragedy of the Commons. Science, 162(3859), 1243-1248. https://doi.org/10.1126/science.162.3859.1243
  20. Delfino, M., & O'Grady, S. (2022). The Open Source Sustainability Crisis. RedMonk Research Report.
  21. Samuelson, P. A. (1954). The Pure Theory of Public Expenditure. The Review of Economics and Statistics, 36(4), 387-389. https://doi.org/10.2307/1925895
  22. Ostrom, E. (1990). Governing the Commons: The Evolution of Institutions for Collective Action. Cambridge: Cambridge University Press.
  23. Eghbal, N. (2020). Working in Public: The Making and Maintenance of Open Source Software. San Francisco: Stripe Press, Chapter 5.
  24. MongoDB. (2018, October 16). MongoDB Issues New Server Side Public License for MongoDB Community Server. mongodb.com
  25. SSPL License Text. mongodb.com
  26. Open Source Initiative. (2019). The SSPL is Not an Open Source License. opensource.org
  27. Redis. (2024, March 20). Redis Adopts Dual Source-Available Licensing. redis.com
  28. Linux Foundation. (2024, March 28). Linux Foundation Launches Open Source Valkey Community. linuxfoundation.org
  29. HashiCorp. (2023, August 10). HashiCorp adopts Business Source License. hashicorp.com
  30. OpenTofu. (2023). OpenTofu: The Open Source Infrastructure as Code Tool. opentofu.org
  31. Claburn, T. (2024, April 4). HashiCorp accuses OpenTofu of copying BSL-licensed code. The Register. theregister.com
  32. Tailwind CSS. Official Documentation. tailwindcss.com
  33. Wathan, A. (2023). Full Time Open Source podcast interview. Syntax.fm Episode 678. syntax.fm
  34. Tailwind Labs. (2024). Tailwind UI - Beautiful UI components. tailwindui.com
  35. Shapiro, C., & Varian, H. R. (1998). 前引書, Chapter 7 (Networks and Positive Feedback).
  36. Wathan, A. (2024). On open source sustainability. Twitter thread. twitter.com/adamwathan
  37. Nagle, F. (2019). Open Source Software and Firm Productivity. Management Science, 65(3), 1191-1215. https://doi.org/10.1287/mnsc.2017.2977
  38. Wheeler, D. A. (2015). Why Open Source Software / Free Software (OSS/FS)? Look at the Numbers! dwheeler.com
  39. Hoffmann, M., Nagle, F., & Zhou, Y. (2024). The Value of Open Source Software. Harvard Business School Working Paper 24-038. https://doi.org/10.2139/ssrn.4693148
  40. Coase, R. H. (1960). The Problem of Social Cost. The Journal of Law and Economics, 3, 1-44. https://doi.org/10.1086/466560
  41. Olson, M. (1965). The Logic of Collective Action: Public Goods and the Theory of Groups. Cambridge: Harvard University Press.
  42. Open Collective. (2024). Platform Statistics. opencollective.com; GitHub Sponsors. github.com/sponsors
  43. Linux Foundation. (2024). Members. linuxfoundation.org
  44. European Commission. Next Generation Internet Initiative. ngi.eu
  45. Sovereign Tech Fund. sovereigntechfund.de
  46. Perens, B. (2023). What Comes After Open Source? perens.com
  47. Fair Code. Definition and Principles. faircode.io
  48. Nagle, F., Wheeler, D., & Lifshitz-Assaf, H. (2024). Report on the 2024 Census of Free and Open Source Software. Linux Foundation Research.
  49. O'Reilly, T. (2023). The End of the Open Source Era? O'Reilly Radar. oreilly.com
  50. GitHub. (2024). GitHub Copilot Research Recitation. github.blog
  51. Mollick, E. (2024). Co-Intelligence: Living and Working with AI. Portfolio/Penguin, Chapter 5.
  52. Henderson, P., et al. (2023). Foundation Models and Fair Use. arXiv preprint. https://arxiv.org/abs/2303.15715
  53. Vercel. (2024). v0 by Vercel - Generative UI. v0.dev
  54. Eloundou, T., et al. (2023). GPTs are GPTs: An Early Look at the Labor Market Impact Potential of Large Language Models. arXiv preprint. https://arxiv.org/abs/2303.10130

← 返回洞見列表