開源專案的商業困境

大家可以看到市面上相當多的開源專案，其中不乏由商業公司發起，並同時提供相關的商業產品的開源專案。但這些商業開源專案背後，總是會有一些困境。如何在開源與商業之中取得平衡，就是每個公司需要探討的一個問題。此議程會討論幾個知名開源專案對於這些困境所選擇的方針以及相關的結果。

Transcript

1. 開源專案的商業困境 Date Huang 黃宇強@ COSCUP 2024
2. About Me • Date Huang 黃宇強 • Speaking Experience: OpenStack Day Taiwan 2016-2017, Open Source Summit North America 2017, ISC High Performance Project Poster 2018, Hong Kong Open Source Conference 2019, OSC Tokyo 2019, COScon '19, TWNOG 4.0, COSCUP 2021, COSCUP 2023, Kubernetes Community Day 2023, OSC Nagoya 2024
3. 開始 • 我主要希望行事會有點像是討論 • 所以有想法都可以提出來 • 畢竟這主題沒有正確答案，只有你站在甚麼角度看事情而已 • 但是我們只有30分鐘
4. 開源如何商業化 • 我們來討論下開源怎麼商業 • 一直都說開源是可以商業化的 • 那實際上到底怎麼商業化？ • 從哪邊獲取營收？
5. 不外乎 • Pay for Support Service / Hosting • Pay for Upgrade • Pay for Binary • Pay for Specific Version of Source Code
6. Pay for Support Service / Hosting • 完全公開原始碼 • 也開放大家下載任何二進位檔案 (binary) • 也提供各種更新包 • 無特別區分社群或商業版軟體 • 但是如果出問題，想問官方問題幫你解決，這邊就是收費服務 • 或是提供服務主機等等的服務
7. Pay for Support Service / Hosting • 可能就會有第三方直接從原始碼端，推出更為低價的服務 • 第三方推出其他付費服務，可能會影響原專案公司之商譽 • 例如一些雲端提供商，使用一些開源軟體部署跟提供SaaS • 一般來說都會要求要移除原專案之商標 (Firefox, Iceweasel) • 或取得相關商標使用權 (SONiC)
8. Pay for Upgrade • 完全公開原始碼 • 也開放大家下載任何二進位檔案 (binary) • 不提供免費用戶任何更新包 • 可能透過區分社群版與商業版，來提供更新與升級 • 或是社群版需要自行編譯來更新 • 支援依然屬於付費服務
9. Pay for Upgrade • 可能就會有第三方推出更新與支援服務 • 當然就一樣衍伸相關的商標商譽問題 • 但通常來說，因為專案本身就有提供二進位檔案，大部分使用者 還是會直接透過原專案取得 • 可能衍伸一堆使用者就不更新，導致相關資安疑慮
10. Pay for Binary • 完全公開原始碼 • 其他一概不提供 • 也就是，請自行編譯所有東西 • 其餘部分全部屬於付費服務
11. Pay for Binary • 可能就會有第三方推出更新與支援服務 • 當然就一樣衍伸相關的商標商譽問題
12. Pay for Specific Version of Source Code • 只公開最新版本的原始碼 • 例如說指公開主要分隻或是開發中分隻，特定版本號的所有分支 則全部為不公開 • 所以免費使用者就無法取得特定版本號的原始碼來編譯
13. Pay for Specific Version of Source Code • 第三方幾乎無成本的提供軟體與支援的難度會大幅上升 • 對於免費使用者來說只能使用相對不穩定的原始碼，而且若沒有 備份，則沒辦法回滾到過去的版本號 • 需要特定版本的使用者，只能尋求付費服務
14. 來討論下為什麼有特定版本相容問題 • 有沒有用過Python套件？ • 套件相依性是不是有一堆版本大於小於？ ◦ A套件要求B套件要在哪些版本之間，C套件又要求B套件要在某個版 本範圍 • 回到Linux環境，很多商業軟體改版速度偏慢，在這情況下就會遇 到只能用在剛好擁有那個特定版本環境內執行了 • 那多數商業軟體，只會針對特定發行版測試，進而衍伸的問題
15. 你說怎麼不用容器？ 容器不就可以把主機跟執行環境分開嗎？ • 從上述的情況來說，對於滿多商業軟體，會很難透過容器來執行 • 而且容器化本身也需要固定的發行版RootFS • 依然會卡到特定發行版與版本的RootFS取得問題
16. 基本上Redhat都嘗試過了 • Pay for Support Service / Hosting • Pay for Upgrade (當年的Redhat) • Pay for Binary (當年的Redhat) • Pay for Specific Version of Source Code (現在的Redhat)
17. Redhat事件 • Redhat停止提供RHEL特定版本的原始碼 • 開始專注在CentOS Stream的維護上 • 也透過EULA，禁止客戶散步特定版本的原始碼
18. Redhat事件 • 意思是? • 你沒有辦法建置RHEL特定的版本號出來搭配你的軟體版本相依 問題 • 例如說：某軟體要求使用RHEL 8.1或8.2，8.3以上不支援 • 就不能透過CentOS來取得RHEL 8.2的相容環境了 • 現在只能取得CentOS 8-stream，意即8版最新的環境
19. 跟Rocky Linux社群聊聊 • 在OSC Nagoya 2024的時候跟Rocky Linux社群的人聊了下 • 他還是站在希望Redhat提供特定版本原始碼的角度 • 社群依然持續的有在幫忙測試修正等等的貢獻 • 認為停止這是對開源社群一種龐大傷害 • 現在的問題在於IBM態度跟Redhat自營的時候有差異導致的 ◦ 股東壓力 • Rocky Linux社群也找到一些規避EULA的方式，可以取得相關的 原始碼，但是能撐多久不知道
20. 那從商業角度來看呢? • 太多搭便車的，只是蹭Redhat的成果而已，並沒有做任何的貢獻 與回饋 • 還利用CentOS直接兜出他們自己的方案去販售，而這些生意並 沒有對軟體生態做任何的貢獻 • 就軟體健康度而言，只剩下Redhat在貢獻相關的軟體，若Redhat 因為利潤不足而停業，則相關軟體生態系會快速消退 • 最後這點，對大家來說都不會是好事 • https://www.redhat.com/en/blog/red-hats-commitment-open-s ource-response-gitcentosorg-changes
21. 然後CIQ/Oracle/SUSE就 • 合作推出了OpenELA • 開發並提供RHEL相容的Linux發行版 • 還在網站上特別表明歡迎搭便車 • We enthusiastically encourage the broader community to participate and welcome all contributors (and “freeloaders”). ◦ https://openela.org/about/
22. 不過 • OpenELA僅提供原始碼版本套件庫 • 並不直接建置可用軟體 • 目前尚未看到有建構OpenELA的發行版
23. 講者註： • Redhat也會因此喪失部分潛在客戶的機會，所以Redhat透過Free Developer Subscription來抓住相關潛在客戶 • 就目前情況來看，Rocky Linux應該還會暫時是CentOS直接的替 代方案 • OpenELA應該會隱身於各企業產品內的測試品，而非直接公開的 被大量使用
24. HashiCorp Terraform • HashiCorp提到有供應商濫用開源獲利，且不提供實質回饋貢獻 • 直接把開源授權MPL 2.0改成非開源授權BSL v1.1 • 不過一些API與SDK等等部分依然維持MPL 2.0 • https://www.hashicorp.com/blog/hashicorp-adopts-business-so urce-license
25. 社群看法 • 社群認為，Terraform的大量模組，都是來自於社群的開發，都不 是HashiCorp開發維護的 • 不應將Terraform退回非開源的授權模式 • 所以直接的建立了OpenTofu專案，並且將OpenTofu交由Linux Foundation管理 • OpenTofu目標相容過去所有Terraform模組 • 並且維持使用開源授權
26. 講者註： • 接下來就是PK兩邊的知名度，以及未來的開發能量了 • Terraform依然保持有免費使用的方案，目前使用者不太會輕易 替換成OpenTofu，畢竟多少會有一些相容性問題 • 若OpenTofu提出極具魅力的新功能，或是有相關測試提出相容性 報告，那就有可能快速更替到OpenTofu
27. 開源生意不好做 • 可能透過開源可以快速累積使用者 • 但是要透過這些使用群體變現，則有一定難度 • 或是遇到一定程度的競爭
28. Q&A