本文轉載雲頭條，原作者：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專家太少了。軟件應該易用，而不僅僅是能用。
結論
開源不會消失；問題是，基於開源開發的公司能否繼續存活下來？
如果開源開發領域繼續要有重大的發展，就需要創建新的許可模式和資助模式。