本文轉載雲頭條，原作者：Michael Stiefel是Reliable Software公司的負責人，是一名軟體架構和開發顧問。

文章要點

雖然開源開發不會消失，但商業開源廠商的未來不是很有希望。隨著全面管理的服務大行其道，生產支援、工具和諮詢等方面的機會已隨之減少。

雲提供商在採用開源軟體，並使其商業化，但未必增添價值或支援未來開發。

業界對於為開源開發提供資金的最佳方式缺乏共識。許多人仍然認為，開源軟體應該是免費的。

“開放核心”或“雙重許可”等模式似乎是支援未來商業開源的最有前景的方法。

開源許可可能會在商業使用方面變得更有限制性。

無法保證將來會複製過去的商業開源成功案例。

Redis已將部分企業模組的許可方式改為採用Apache 2.0+ Common Clause許可證。這些模組無法用作獨立的商業SaaS。此舉專門針對雲提供商。

相關的爭議引出了在開源社群已存在一段時間的問題。開源使用效果最好的地方是軟體基礎設施，而不是應用軟體專案。如果雲端計算公司成為軟體的基礎設施提供商，它們的市場控制力可能讓它們得以接管開源專案，並以低於銷售開源服務的公司的價格銷售這些軟體服務。

如果真出現這種情形，開源公司還有未來嗎？

專家小組成員

Paul Dix：InfluxData公司的創始人兼首席技術官。

Matt Klein：Lyft公司的軟體工程師和Envoy的開發者。

Heather J. Meeker：著名律師事務所美邁斯（O’Melveny & Myers）的矽谷辦事處合夥人兼OSS Capital的投資組合合夥人。

開發開源軟體背後的商業模式是什麼？換句話說，為開源開發提供資金的最佳方式是什麼？哪種軟體開發不適合開源？

Paul Dix：我認為有很多模式可以成功。首先是我所說的“開源物盡其用”（open source exhaust）。谷歌、微軟或Facebook之類的大公司就是這樣，它們開發的一些軟體被認為不是其關鍵智慧財產權的一部分。這種軟體就好比資產負債表上的一筆負債。大規模執行業務邏輯所需的基礎設施軟體就是這方面的典例。它沒有提供為貴公司帶來價值的祕訣，但沒有它你又無法運營。因此，大公司會開源，試圖讓其他大公司和開發商參與其中，以支付持續改進和修復錯誤的成本。參與的公司還可以通過讓外部的開發人員學習這些技能而受益。他們是以後可招聘的後備物件。

當然，對於試圖靠開源基礎設施軟體開展業務的任何公司來說，這種方法不是好兆頭。

如果公司希望主要的收入來源與開發某個開源軟體專案有關，它們的選擇很有限。我認為眼下唯一經過驗證的模式是開放核心：公司開發的閉源軟體為開源軟體補充或增加新功能，然後將其作為託管的SaaS產品或作為內部部署的企業軟體來賣。一些開源軟體（OSS）倡導者認為，採用這種模式的公司實際上不是開源公司。然而，我能想到的每一家採用開放核心的公司投入到OSS的預算在開發研發預算中所佔的比例都比任何大企業大得多。 Elastic、Cloudera、RedisLabs、InfluxData及其他許多公司都採用開放核心，開發OSS的人員在開發團隊中的比例遠高於谷歌、微軟、Facebook、Netflix或採用開源物盡其用模式的其他任何大公司的開發團隊。

開源基礎設施公司過去認為，可以靠生產支援和工具來實現創收。然而，雲提供商和完全託管服務的崛起對這種模式產生了負面影響，以至於我認為這種模式不可行。更多的證據表明雲在繼續影響開源基礎設施，MongoDB最近宣佈改變許可證就是個佐證。

最後，可以靠服務和支援來開展業務。這是為OSS開發提供資金的最低效方法。其創收方式如同一家諮詢機構，不過如果你打造一個諮詢團隊，希望他們的計費工時有很高比例。這直接有悖於讓你的團隊開發OSS軟體。如果他們在開發OSS，並不按時計費。任何諮詢機構選擇一個已經大受歡迎的OSS專案並提供諮詢服務會更好。

最後一種方法是藉助志願者社群的免費工作。這對大型基礎設施專案不起作用。隨著專案日益受歡迎和複雜化，管理和激勵在晚上和週末工作的志願者團隊變得非常困難。該模式適用於開發後基本上可以標記為已完成的小型程式碼庫。大專案需要某種贊助，才能存活下來並向前發展。

Matt Klein：已嘗試過諸多商業模式。它們都歸結為下列模式的某種變體（以下是簡單描述）：

開放核心：軟體的一部分是OSS，軟體的一部分在付費牆後面。

SaaS：代表客戶將OSS作為服務來執行。

服務/諮詢/支援：對客戶使用OSS所需要的各種輔助支援和開發收費。

一些商業模式結合了上述方法，所有上述模式都不乏成功案例。

實際上沒有為OSS開發提供資金的“最佳方式”，因為有效的方式通常依賴具體專案。遺憾的是，無論採用哪種方法，靠OSS實現創收並非易事，因為許多使用者從根本上認為OSS應該是免費的。哪些型別的軟體開發根本不適合OSS？首先想到的就是程式碼庫。一些庫對現代系統來說絕對至關重要，但靠OSS庫使用實現創收極其困難。比如說，多年來OpenSSL方面沒有投入開發和資源，導致整套關鍵的網際網路基礎設施建立在一款維護不善又很基礎的軟體上。

Heather J. Meeker：開源軟體方面唯一不能做的就是銷售許可證來利用它。但是在開發開源軟體的私營企業中，仍有足夠的空間來賺錢。你完全要知道自己在賣什麼、送什麼。純粹的開源公司很罕見，大獲成功的Red Hat是個例外。純粹的開源公司銷售服務，主要是維護和支援，但也銷售質量控制。客戶買的是產品，而不是許可證。如果你在質量控制和包裝方面投入大量精力，可以造就一家銷售開源軟體包的公司。但那樣的話，實際上你銷售的是對你聲譽的依賴。大多數開源公司以“剃刀刀片”模式的某種變體來賺錢：給他們剃刀，向他們賣刀片。剃刀是開源軟體，刀片有多種形式。一些是向上銷售的模組（常常名為開放核心），一些是替代權利（相同軟體的雙重許可，比如MySQL），一些是“widget frosting”（銷售在開源上執行的硬體，比如可能是iOT產品），還有一些是推先體驗（一種在公開發布程式碼之前銷售體驗程式碼這種服務的“禁運”模式）。在其中幾種模式中，你需要使用其他型別的許可證，這時候Commons Clause之類的替代許可證有了用武之地。

開源軟體是否只對企業開發商來說有意義？還是說雲供應商和開源提供商有辦法合作？

Dix：可能有，但這取決於雲供應商。並不要求雲供應商非要搞開源專案。的確，亞馬遜似乎滿足於拿來現成的開源專案，將其作為託管服務來提供，沒有商業安排或開發工作來推動OSS專案向前發展。谷歌和微軟有一些合作，但我不確定這種合作是什麼樣子。此外，如果它們認為沒必要繼續支援其他公司開發開源，會發生什麼？它們可以輕鬆僱用推動這些專案發展所需要的所有開發人員。它們這麼做的動機是，讓開發人員為託管服務付費。圍繞開源構建程式碼只是確保另外的一家雲提供商無法圍繞專有的封閉API來構建龐大開發社群的一種方法。三大雲供應商正在你爭我鬥，OSS基礎設施公司可能到頭來是間接受害者。比如說，微軟和谷歌將繼續推動Kubernetes發展，作為標準化的雲API，因為Kubernetes幫助它們將市場領頭羊AWS拉下寶座，使雲API實現商品化。那些試圖將Kubernetes變成業務的初創公司會怎樣？如果Kubernetes像OpenStack生態系統一樣發揮作用，那些初創公司會在未來三年內全部關門大吉（不過Kubernetes諮詢業務會蓬勃發展）。

Kelin：我不確信自己完全理解這個問題。流行的OSS將不可避免地被企業和雲供應商使用。此外，雲供應商可能會提供基於流行的OSS而建的託管產品，卻未必對該專案給予重大的回饋。在我看來，更大的問題是如何合理地為OSS開發提供資金，帶來社群優先的開發模式，同時仍可以從中獲取價值（通過開放核心、SaaS、服務/支援或某種組合）。遺憾的是，如何做到這一點方面還沒有達成共識。我個人認為，將來，眾多軟體基金會要在為關鍵的OSS提供中立的家園方面發揮更大的作用。基金會另外的責任是籌集資金，為開發和維護資源提供資金，在保持中立的同時，仍然支援靠開源獲取商業利益（無論是企業還是雲等）。

Meeker：我們經歷的分水嶺時刻就是雲提供商採用小公司的軟體，不增添重大價值就將軟體投入商業市場，但又沒有與支援開發的那家公司達成任何安排，這個分水嶺時刻導致了Commons Clause及其他替代許可模式。至少，這是大多數開發商對開源模式感到沮喪時表達的痛點。它們需要保持將門開啟，付錢給開發人員，其中一些在流失資源。我認為，在可預見的未來，開發適用於未經修改的雲部署的企業軟體的供應商會對採用開源許可證釋出程式碼持謹慎態度。我預計我們會看到雲提供商和企業開發商有更多的商業安排，那樣可以分攤開發成本。至少，這將是最經濟合理的結果。

谷歌、Netflix或其他公司釋出的開源專案是改進開源開發，還是說有著不純的動機？

Dix：我會說兩者都是。讓大企業公開發布採用自由許可證的程式碼對大家都有好處。但可以肯定地說，除了改善世界上自由軟體的現狀外，它們可能還有別的動機。這意味著你心裡要有準備：它們在某個專案上的目標可能並不總是與你的目標一致，但無論如何管理開源專案，情況都是如此。只要軟體是開放的，如果企業贊助商偏離了你認為專案應該走的方向，你有路子可選。

Klein：沒有哪家公司出於善意來做事。大公司釋出OSS出於諸多原因。除了打造最終與雲業務相關聯的平臺外，幾個重要的原因是便於招聘和擴大知名度。這倒不是說谷歌和Netflix等大公司釋出的軟體對行業並沒有深遠的影響，當然有影響，但重要的是牢記為什麼公司直接為OSS開發提供資金背後別有用心的動機。

Meeker：我認為結果比動機更重要。我懷疑大多數開發商會說這些公司及其他公司釋出的開原始碼大有益處。但那些公司做正確的事才做得很好。私營公司負有法律義務：做出對本公司來說正確的決策，監管股東們的資本。但這並不意味著幫助社群的行動也不利於自身業務。如今許多大公司發現，積極參與開源社群對業務有好處。軟體訪問不是零和博弈。企業可採用戰略性的手段，限制別人訪問自己開發的帶來市場優勢的技術，但可以免費發放並不帶來市場優勢的技術。從經濟意義上講，一些軟體用作公共產品最有效，而一些軟體用作專有產品最有效。共享道路但銷售在道路上行駛的汽車是明智之舉。相反的話可能意味著互不聯通的道路和糟糕的汽車。

展望未來，對開源公司來說切實可行的許可安排有哪些？

Dix：如果公司主要靠它們擁有的一個開源專案開展業務，要麼需要使用AGPL之類的限制性許可證，要麼需要讓閉源軟體補充採用自由許可證的開源核心。我青睞後一種模式，因為對於開原始碼而言，很顯然誰都可以隨意處理開原始碼。他們可以使用開原始碼，建立業務，將其作為產品的一部分來交付。我青睞MIT和Apache2之類的自由許可證用於開源。然後，公司的閉源軟體補充或增強開源專案的功能。很顯然，這是它們的商業產品。事實上，沒有什麼能阻止其他任何公司圍繞同一個開源專案開發閉源產品。

Klein：我認為我們會繼續看到許多公司試圖以各種不同的方式從OSS獲取價值。我個人認為，將來最成功的模式將是我所說的“鬆散開放核心”（loose open core）。其想法是，建立一個開放核心生態系統，主要的軟體保持由社群驅動，沒必要通過拒絕採用與收費產品競爭的補丁來疏遠潛在的貢獻者。採用這種模式的企業附件可能包括：使用者介面（UI）、審計和安全工具等，基本上是可使用眾所周知的API在核心OSS上構建的任何元件。

Meeker：我認為我們會看到諸多變化。我認為，區別就在於，非開源許可將變得更標準化。眼下，它幾乎完全是臨時性的，這對每個人來說都是淨成本（net cost）。

未來10年到20年，你認為軟體會如何開發？

Dix：繼續是結合閉源和開源的方式。我認為與現在的方式不會有很大的差異。軟體不會完全公開，因為公司仍需要客戶有令人信服的理由來購買，支援和諮詢的經濟因素不會改變。因此，公司會繼續讓閉源軟體來推動價值。自行運營資料中心的公司所佔的百分比會顯著降低，但由於規模經濟效應，仍會有公司自行運營資料中心。

Klein：可能與今天的情況沒什麼大不同。大多數基礎設施軟體將是OSS，而大多數消費者系統將是專有系統。基礎設施方面的一大問題是，各大雲提供商會“吃掉世界”？還是說獨立公司會圍繞OSS搞出一種切實可行的收入模式？在我看來，那些專注於“鬆散開放核心”模式的公司會在對付雲競爭方面做得最好，這是由於許多增值服務仍然可能在基本的雲SaaS產品上執行。

Meeker：20多年前我開始程式設計，當時和現在的區別體現在幾個方面。首先，開發工具更好了，因此人們在開發應用軟體時可以避免一些單調乏味的低階任務。其次，程式碼模組化的程度大大提高了，因此不大需要重新發明輪子。開源對這第二個方面起到了助推作用。第三，軟體是協同開發的，這是由於我們現在有了可以協同開發的工具。我預計，今後20年會更加遵循同樣的發展軌跡；更多的程式碼將實現自動化或標準化，甚至由計算機編寫，好讓人類程式設計師專注於更高階的使用者功能。此外，希望，使用者互動的質量會受到更大程度的重視。我認為眼下，UI專家太少了。軟體應該易用，而不僅僅是能用。

結論

開源不會消失；問題是，基於開源開發的公司能否繼續存活下來？

如果開源開發領域繼續要有重大的發展，就需要建立新的許可模式和資助模式。