開源無處不在，虛假的開源也無處不在

技術編輯：芒果果丨發(fā)自 思否編輯部

SegmentFault 思否報道丨公眾號：SegmentFault

---

問題不再是一個項目是否開源，而是這個項目有多開放。

開源無處不在，虛假的開源也是如此。最近，越來越多的開源項目轉變?yōu)榉情_源項目的案例，同時也有一些非開源項目(按照 OSI 定義)將社區(qū)建設為開源項目的例子。

開源并不是黑白分明的，它包含了開放、透明、協(xié)作和信任的多個維度。

對于一些人來說，開放源碼是 Github 上的任何項目，對于一些人來說，它必須通過 OSI 的定義，對于一些人來說，它必須遵守不成文但普遍接受的開放源碼規(guī)范。如何看待評估開源項目呢，我們首先看看一些業(yè)務和技術方面，然后探索社區(qū)管理習慣。

知識產(chǎn)權

關于“開放源碼”項目的第一個問題是關于知識產(chǎn)權的所有權。即時不了解這些法律含義，也可以通過一個簡單的問題找到答案：這個項目是否屬于一個你信任的著名的開源基金會？

例如，如果一個項目屬于 ASF、 LF 或類似的基金會，他們通常擁有版權，是項目的商標，你可以放心，他們將作為好的管理者，不會在一夜之間改變一個項目的未來方向。如果一個項目不屬于一個有信譽的軟件基金會，而是由一家公司支持，那么問題就是你是否相信擁有該權利的公司是軟件供應鏈的合作伙伴。

如果這些問題的答案是肯定的，那么就進入下一部分。如果答案是否定的，那么你最好調(diào)查并找出誰是這個項目的所有者，他們對項目的長期意圖是什么，以及對你的潛在風險。

許可證

商標出現(xiàn)在許可之前的原因是，軟件的權利持有者(通常是作者)通過許可授予最終用戶使用一個或多個軟件副本的權限。自由軟件許可證是授予源代碼或其二進制形式的接收者修改和重新發(fā)布該軟件的權利的通知。如果沒有許可，這些行為將被版權法所禁止。這里重要的一點是，權利持有者可以改變他們的想法，改變許可證。

權利持有者可以決定在多個許可證下分發(fā)軟件，或者在任何時候將許可證更改為非開源許可證。也有可能軟件是在公共領域，在這種情況下，它不受版權法的限制。公共領域并不等同于開放源碼許可證，這是一種我們可以忽略的不太流行的方法。

這里有一個外行的試金石測試許可證：項目是根據(jù) OSI 批準的許可證列表許可的嗎？如果答案是肯定的，那么您可以依靠這些基金會的盡職調(diào)查來審查、分類許可證并指出任何限制。如果答案是否定的，請您的公司律師審閱并解釋許可證上的每個單詞以及可能的許可證兼容性含義。

治理

通過剩下的檢查，我們正從更多的業(yè)務和法律方面，轉向與開源項目相關的技術和社區(qū)領域。

假設對商標持有者方（您未來的合作伙伴）、許可證（您使用開源軟件的條款）沒有任何顧慮，下一個問題是治理。治理是一種規(guī)則或習慣，項目根據(jù)這些規(guī)則或習慣決定誰可以做什么、應該如何做以及何時做。

它定義了與不同項目角色相關聯(lián)的職責、特權和權限，以及人員如何被分配和從角色中移除。這里的例子是一些小型的日常活動，比如誰有權批準一個拉請求、投票給一個發(fā)布候選人、商定項目架構、定義項目路線圖以及選舉項目治理委員會。

如果您正在評估一個對您的組織具有戰(zhàn)略意義的項目，那么您希望知道誰是負責人。不僅如此，你甚至有雄心壯志讓你的開發(fā)人員對項目的方向有發(fā)言權。

這里還有一個簡單的檢驗標準: 對于開源基金會的項目，有明確的規(guī)則規(guī)定誰可以對重要決策進行投票，以及如何成為決策委員會的一員。在一些基金會，如 ASF，它是基于個人社區(qū)成員的價值，在一些基金會，如 CNCF，它開始是一個付費成員組織的雇員。在基于塊區(qū)塊鏈的開源項目中，它是基于令牌持有者的投票。

其他基金會有不同的規(guī)則，但它們都爭取在多個參與者之間保持中立和權力下放。如果一個項目由一個公司或單個個人管理，那么您將信任他們?yōu)轫椖亢蜕鐓^(qū)的利益做出最佳決策。

其中一些項目可能已經(jīng)寫下了它們遵循的治理規(guī)則，有些項目可能根本不寫。您可以自行確定治理動態(tài)及其對項目參與的重要性。除了具有治理透明度和公開作出決定外，這里的另一個方面是理事機構的信任和聲譽水平。

當你看一個項目的治理委員會時，是否有一個領導者或一組具有經(jīng)驗證的技術和社會技能的領導，讓你相信他們可以把項目提升到下一個層次？或者你看到一個在政治斗爭中不斷爭論的團體嗎？這些都是衡量一個開放源碼項目是否會成功和長期增長的指標，或者是否會令人頭疼和停滯不前的指標。

基礎架構

擁有開源許可證可以從技術上將一個項目定義為開源項目，但這并不意味著一個項目是以開源方式構建的。有許多例子表明，軟件是在 OSI 許可下發(fā)布的，但卻是在封閉的基礎架構下開發(fā)的。說到基礎架構，這里指的是供用戶快速提問的聊天頻道。在論壇和郵件列表中進行更深入的開發(fā)人員討論。源代碼管理系統(tǒng)，在其中審查拉請求，并構建運行測試和每晚創(chuàng)建二進制文件的服務器。

對于關注開源項目的商業(yè)人士和律師來說，這些可能并不重要，但對于將要使用開源項目的技術人員來說，這些是一些假定的好處。這里要做的檢查是探索軟件是否是使用開放基礎設施而不是閉門造車的開源方式開發(fā)的。以下是幾個問題示例：

• 用戶可以在項目聊天中提出問題，然后在沒有中間人的情況下從其他用戶那里得到答案嗎?
• 開發(fā)人員可以聯(lián)系項目提交者并得到深層次的技術問題的答案嗎?
• 您能運行最新版本并確認所報告的錯誤已修復嗎?
• 架構師能否每周進行一次社區(qū)電話會議，從而確定項目的未來發(fā)展方向嗎?

在封閉的基礎設施中，您必須創(chuàng)建一個支持案例，并付費獲得類似問題的答案。有了開放的基礎設施和開放的參與，那些知道如何以開源方式工作的人就可以得到答案。

社區(qū)和采用

開源軟件的主要好處之一是它允許偉大的想法得到開發(fā)，并像病毒一樣傳播開來。你可能擁有最好的技術，最寬松的許可證，和開放式開發(fā)，但是如果軟件沒有一個不斷增長的社區(qū)和不斷增長的采用率，那就是一個調(diào)查的信號。不同的項目會有不同的采用率。有些人可能很快成為主流，或者被其他這樣做的人所取代。一些項目可能有一個小但持續(xù)的增長率和一個持續(xù)數(shù)十年的利基社區(qū)。社區(qū)規(guī)模和采用率是開源項目的最終壽命指標。以下是您可以問的一些示例問題：

• 項目中有多少活躍開發(fā)人員（提交者），平均提交率是多少？
• 用戶論壇訂閱用戶數(shù)，上月問了多少個問題？
• 軟件最新穩(wěn)定版本下載了多少次？
• 其他項目和服務依賴于和使用該項目？
• 有多少商業(yè)組織支持這個項目？
• 是否有商業(yè)組織在其周圍提供產(chǎn)品、支持和服務？
• 關于這個項目有多少個 StackOverflow 問題？
• 有多少本書、會議討論和工作描述提到了這個項目？

運行這些問題將告訴您項目是否正在增長，并成為其領域中的事實標準或停滯，并且很可能被下一個重大的事情所取代。

通常，開放源碼與快節(jié)奏的開發(fā)和創(chuàng)新有關。與此同時，開源也是一種創(chuàng)建廣泛采用和創(chuàng)建非官方標準的機制。許多開源項目已經(jīng)變成了標準，比如用于容器編排的 Kubernetes，用于流媒體的 Apache Kafka，用于 web 服務器的 Apache httpd 等等。在軟件行業(yè)，最昂貴的事情之一就是找到擁有合適技能的人。使用采用率高的開源項目將使您有更好的機會找到有技能的人員，并允許他們在更長的時間內(nèi)重復使用自己的技能。

結論

根據(jù)開放源碼項目的關鍵程度，有不同的風險和評估標準。對于戰(zhàn)略性的、難以替代的、將成為 IT 基礎設施基礎的項目，您需要已經(jīng)成熟的項目，這些項目已經(jīng)在各自領域成為事實上的開放源碼標準。在這里，確定誰擁有該項目的商標以及誰將成為您的長期合作伙伴非常重要。

通常，這些合作伙伴將是項目所屬的軟件基金會的成員組織或持有項目知識產(chǎn)權的單一公司。對于后者，您可能需要考慮長期風險，例如核心開發(fā)人員分擔項目的可能性、將項目作為服務提供的超級擴張者、公司收購等。

對于交付速度最為重要的非戰(zhàn)略性、戰(zhàn)術性、短期項目，您可以讓開發(fā)人員驅動選擇，并基于開放性、社區(qū)協(xié)作和熱門性(對于某些前端技術來說很重要)選擇項目。在這里，短期到中期的風險，例如定期的安全修復、開發(fā)人員支持和許可證兼容性檢查可能就足夠了。

無論哪種情況，都沒有適合所有情況的單一評價標準。你必須在長期商業(yè)風險、技術穩(wěn)定性、最新熱點、創(chuàng)新和開發(fā)者滿意度之間找到平衡。這里的框架將為您提供需要探索的領域的概述以及需要考慮的一些風險。

原文鏈接：https://hackernoon.com/open-source-is-everywhere-but-so-is-fake-open-source-jh8a33fi

---

- END -