衡量你的開源軟體使用情況的 8 個方法

想知道如何為你的開源軟體項目收集使用指標？考慮一下使用這些替代方案的利弊。

我們這些支持開源項目社區的人經常被問到很多有關使用指標的問題。這些指標通常是為了通過用戶量和知名度來衡量軟體的重要性。我們一般都想知道有多少人使用該軟體，有多少次安裝，以及有多少人生活接觸過它。

但簡而言之，我們尚無法直接回答上述問題。

如果你想要尋找一個明確的解決方案，那很抱歉要讓你失望了。有關使用指標的問題，沒有人有完美的答案，至少沒有準確的答案。

好消息是，有一些近似的和替代指標至少能夠部分地滿足你對軟體使用情況了解的渴求。本文探討了這些替代方案以及它們的優點和缺點。

下載量

當你瀏覽提供軟體的網站時，你通常可以看到軟體的下載次數。映入我腦海的一個例子是 Firefox ，它曾經有一個下載計數器。Firefox 的下載量是一個印象深刻的數字，給人的印象是 Firefox 是一個流行的瀏覽器，在一段時間內確實如此。

然而，個人行為會直接影響這一數字的準確性。舉例而言，當一個人定期重置他們的設備時，每一次重建都會引發一次獨立的下載。考慮到這一現實，需要設計一種方法從下載量中去除幾十次（或許是幾百次）的下載次數，因為那是一個人。

下載量不僅會高估使用量，還會低估使用量。例如，一個系統管理員可能會下載一個新版本的 Firefox 一次並將其拷貝到 U 盤上，然後安裝到數百台設備上。

下載量指標是易於收集的，你可以在伺服器上記錄每一個下載請求。問題在於你不知道在這些軟體下載以後會發生什麼。下載它的人是否如預期的那樣使用軟體，還是遇到了問題而放棄了它。

對於開源項目而言，你可以考慮各種下載量指標，比如來自以下途徑的下載指標：

• 項目官網
• 包管理器，比如 npm、PyPi 和 Maven
• 代碼倉庫，如 GitHub、GitLab、Gitee 等

你可能還對源代碼的下載量感興趣，因為下游項目更可能使用源代碼形式（參見 《如何衡量你的開源項目的影響》一文）。相應的下載指標包括：

• 從代碼倉庫克隆的數量，比如 GitHub、GitLab 和 Gitee
• 從官網下載的歸檔文件（tar、zip）的數量
• 通過像 npm、PyPi 和 Maven 這樣的包管理器下載的源代碼數量

源代碼的下載指標比二進位代碼的下載指標更不可靠（雖然尚無相關研究表明如此）。試想一下，一名開發人員想要你的最新版本的源代碼，並將他們的構建管道配置為每次構建都克隆你的倉庫。再想像一下，一個自動構建過程失敗了，它試圖重新構建而不斷地克隆你的版本庫。你還可以考慮這樣一個下載量低於預期的場景——源代碼倉庫在某些地方緩存了，下載來源是由這些緩存所提供的。

相關閱讀：跟蹤你的開源社區的 5 個指標

總而言之，下載量指標是用於提供當前使用情況和探測趨勢的很好的指征。我們無法明確地定義一次下載是如何轉化為使用的。不過我們可以認為增加的下載量是更多潛在用戶的標誌。舉例而言，如果你為你的軟體做了廣告並在活動期間得到了更高的下載量，可以合理地假定廣告推動了更多人下載該軟體。下載行為的來源與元數據還可以提供額外的與使用行為相關的內容。你的軟體的哪些版本仍在使用中？什麼操作系統或者特定語言的版本更加流行？這有助於社區決定將哪個平台的軟體作為支持與測試的優先選項。

議題

作為一個開源項目，你可能有一個議題追蹤器。當某個人提出一個議題時一般有兩個目標，報告一個漏洞或者請求增加一項功能。提議者很可能已經使用過你的軟體了。作為一名用戶，他可能發現了一個漏洞或者發現了對一個新功能的需求。

很明顯，大多數用戶不會執行額外的步驟來提交議題。提議者是我們的忠實用戶，我們對他們表示感謝。此外，通過提出議題，他們已經成為了非代碼貢獻者，他們也有希望成為代碼貢獻者。經驗法則是大約每 10000 名用戶中，可能有 100 名提議者，以及 1 名代碼貢獻者。當然取決於用戶類型，上述比例可能有出入。

回到指標問題，你可以將提議者數量作為評估使用量的下界。相關的指標包括：

• 提議者數量
• 活躍提議者的數量（在過去 6 個月內提出議題的提議者）
• 同時有代碼貢獻的提議者的數量
• 尚未解決的議題的數量
• 對議題發布的評論數量

郵件列表、論壇和問答網站

很多開源項目都擁有用戶郵件列表、論壇，並且出現在類似 Stack Overflow 的問答網站上。與提問者一樣，在這些地方發帖的人可被視作用戶的冰山一角。與郵件列表、論壇和問答網站上的社區活躍程度相關的指標也可用於反映用戶數量的上升或下降。相關指標可以集中於以下地方的活動，包括：

• 用戶郵件列表的訂閱量
• 論壇用戶的數量
• 問題的數量
• 答案的數量
• 發布信息的數量

上報功能

為了獲得精確的用戶數量，一個方案是讓軟體在使用時上報信息。

這是令人毛骨悚然的。想像一下，系統管理員的防火牆報告了一個非預期的到你的伺服器的網路連接，你不僅無法再收到軟體報告（被防火牆攔截了），恐怕連你的軟體也可能在未來被禁止使用。

負責任的設置上報功能的方式為設置一項可選服務來檢查更新並讓用戶知道使用最新版本。另一項可選功能可以集中在使用遙測上，你可以通過該功能詢問用戶是否允許匿名上報軟體使用情況。如果經過深思熟慮的實施，這種方式可以允許用戶通過他們使用軟體的方式幫助優化軟體。用戶可以持有這樣的意見：我一般不允許這種使用信息的分享；但對於一些軟體，因為希望開發人員在長期內將軟體優化得更好，我願意這樣做。

星標與復刻

星標與復刻是如 GitHub、GitLab、Gitee 等社交化編程平台的功能。這些平台上的用戶可以給一個項目加星標。為什麼他們要給項目加星標呢？GitHub 的文檔作出了解釋：你可以給一個倉庫和主題加星標，以跟蹤感興趣的項目，和在你的新聞訂閱中發現相關的內容。給一個項目加星標與將其加入書籤的效果一樣，並且還提供了一種向項目倉庫的維護者展示讚賞的方式。星標的數量已經成為了項目流行程度的標誌。當一個項目發布重大公告並獲得相當的關注時，項目的星標數量會呈上升趨勢。星標的數量指標並不反映軟體的使用量。

在社交化編程平台上的 復刻 Fork 是將項目倉庫複製一份在自己名下。倉庫的非維護者可以在他們自己的克隆倉庫中做修改，並將修改通過 拉取請求 pull request （PR）的方式提交審核。復刻比星標更能反映軟體社區的規模。開發者也可能為了保存一份代碼副本而克隆一個項目，以便在原始倉庫消失後他們仍能訪問代碼。因為復刻功能在代碼貢獻工作流中的應用，復刻量是衡量開發社區的良好指標。復刻量通常也不反映非開發人員的使用，因為非開發人員一般不創建復刻。

社交媒體

包括 Facebook、Instagram、LinkIn、Reddit、Twtter 等社交媒體平台提供了相同興趣的人們聚集的平台。採用社交媒體策略，開源項目可以通過在平台上設置相應的聚集空間來吸引對項目感興趣的人們。通過這些社交媒體途徑，開源項目可以分享項目新聞、更新，指出貢獻者和用戶。這些社交媒體途徑還可以用於認識那些本不會通過其他途徑與項目互動的人。

我在猶豫是否建議關注以下指標，因為它與軟體的真實使用量沒有清晰的聯繫，並通常需要分析其中的積極、消極和中性的情緒。人們可能因為很多不同的原因對你的項目感到激動而關注它，但並不實際使用它。然而與之前已經討論過的指標一樣，能夠在社交媒體上吸收人群本就是項目受關注的整體指標。不同社交媒體平台的指標包括：

• 關注者與訂閱者的數量
• 消息的數量
• 活躍的消息作者的數量
• 喜歡、分享、回復以及其他交互的數量

網站分析與文檔

網站流量也是一個有用的指標。這一指標主要受到你的服務範圍以及市場營銷活動影響，而不是用戶量。然而，我們還有一張王牌：我們的用戶文檔、教程、手冊以及 API 文檔。我們可以發現我們的網站以及文檔中的什麼主題更引人注意。文檔的訪問者數量應當大致隨著軟體的使用者數量增長而增長。因此我們可以通過網站的訪問量探知對項目的普遍興趣，並進一步通過觀察文檔的訪問者來觀察用戶風向。這些指標包括：

• 網站訪問者數量
• 文檔訪問者的數量
• 訪問者在你的網站與文檔上所花的時間

活動

活動的指標可以在你主持與項目相關的活動時使用。這是建立社區的很好的方式。有多少人提交摘要想要在你的活動中發言？有多少人出席你的活動？不論是在線下活動還是線上活動這可能都很有趣。當然，你如何推廣你的活動在很大程度上決定有多少人到場。同時你可以將自己的活動與人們出行的大型活動放在一起以方便人們參加你的活動。只要你使用一貫的活動策略，你可以通過演講者提交的材料與參會者註冊的增加來表徵軟體受歡迎程度與用戶群的增加。

你並不需要舉辦你自己的活動來收集有用的指標。如果你在開源活動中主持有關你項目的討論，你可以衡量有多少人出席主要關注你的項目的會議。像 FOSDEM 這樣的活動，一些討論特別聚焦於開源項目的更新與發布，會議室中都擠滿了人（像 FOSDEM 的所有會議一樣）。

你可以考慮如下指標:

• 以你的項目為中心的活動的出席人數
• 提交到以你的項目為中心的活動的演講數量
• 以你的項目為中心的演講的出席人數

關於估算開源軟體使用的結論

正如我們已經如上展現的，有很多指標可以反映軟體使用的趨勢，沒有一個指標是完美的。在大多數情況下，這些指標可能被個人行為、系統設計和噪音所嚴重影響。因此，考慮到每一個指標的相對不確定性，我們建議你不要孤立地使用任何一個指標。但是如果你從不同的來源收集了一系列的指標，你應當能夠探測到用戶行為與軟體使用的趨勢。如果你有辦法在多個具有共性的開源項目中比較同一組指標，例如類似的功能、強大的相互依賴性、在同一基礎設施上託管，以及其他特徵，你就可以提升你對用戶行為基線的感知。

需要注意的是，在這篇概述中，我們選擇突出能夠評估直接使用情況的指標。而大多數軟體都依賴於其他各種軟體包，如果我們不提及作為軟體依賴鏈的一部分而被間接使用的嚴重影響，這就是我們的疏忽。因此，我們建議將上下游依賴的合計數量作為你的分析中的另一層內容。

最後，作為數據與指標的使用者，我們鼓勵你認識到你的利益相關方的權利與責任。你發布的任何指標都有可能影響用戶行為。最好的做法是經常一同分享你的背景信息——基礎、來源、估算方法和其他關鍵上下文信息，這有助於其他人解釋你的結果。

感謝 CHAOSS 社區在愛爾蘭都柏林舉行的 CHAOSScon EU 2022 上的富有洞察力的對話，上述對話激發這篇博文的想法。我們還要感謝 CHAOSS 社區的成員審閱並幫助優化本文。

via: https://opensource.com/article/22/12/open-source-usage-metrics

作者：Georg Link 選題：lkxed 譯者：CanYellow 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive