1. 最優先要考慮的是需求
2. 開源專案的參考指標
   1. 1. 功能性
   2. 2. 文件完整性
   3. 3. 維護活躍度
   4. 4. 社群支持度
   5. 5. 程式碼品質與穩定性
   6. 6. 安全性
   7. 7. 相依相容性
3. 總結
4. 參考資料

在資料工程師的工作中，很常需要使用到開源工具來解決問題，像是 Apache Airflow 或 FastAPI 都是可商用且已經被泛用的開源工具，但我們該如何評估一個新的開源專案值不值得使用或研究呢？ 這篇文章我整理了網友和我自己的經驗，以 GitHub 為例，分享有哪些重點是我們在選擇 Open Source 時可以納入考慮的。

最優先要考慮的是需求

我認為所有的考量都要以需求出發，思考這個開源工具是否真的能解決目前遇到的問題，或是達成使用者提出的需求，並且這個工具的規範在公司內是合法合規的，都確認後才能繼續往下探討其他指標。

其他指標我目前把他們分成幾大類：

1. 功能性
2. 文件完整性
3. 維護活躍度
4. 社群支持度
5. 程式碼品質與穩定性
6. 安全性
7. 相依相容性

---

開源專案的參考指標

1. 功能性

• 功能完整性： 工具的功能是否完整且穩定？是否缺少關鍵功能？
• 易用性：
  • 這個工具是否容易安裝、設定和使用？是否有清晰的 API 或介面？
  • 是否可用 pip install 安裝？
  • 是否提供 Dockerfile / Docker Compose 的方式來部署？
• 效能：
  • 工具的效能是否能處理你的資料量和運算量？是否有相關的效能測試報告？
  • 這個工具在 ELT、分析、視覺化或建模方面的能力如何？

2. 文件完整性

• README：是否有清晰、完整的 README 檔案，說明專案的功能、安裝方法和基本使用方式？
• License：專案採用的是什麼開源授權、可否商用？確保授權條款符合你的使用需求（例如：MIT、Apache、GPL 等）
• Releases：是否有清楚的版本更新介紹，以及清楚的版本號（如 semver）
• 詳細文件： 是否有詳細的官方網站或教學？文件是否淺顯易懂且維持更新？

3. 維護活躍度

• Commit 頻率：
  • 最近 3 個月內是否有 commit 紀錄？如果是很久以前，可能表示專案不再活躍
  • 開發者 Commit 程式碼的頻率如何？頻繁的 commit 通常代表專案正在積極開發和改進
• Issue 追蹤：
  • Issue 數量： open 狀態的 Issue 數量是否合理？Closed Issues 數量需要領先 Open Issues，Open/Closed 比例最好是低於 0.3，若比例過高可能表示專案存在較多 Bug 或未完成的功能，或是表示該專案團隊可能短期內已無法負荷
  • Issue 回應速度： 開發者回應 Issue 的速度如何？積極回應表示社群參與度高，但也要注意現在有很多自動回應 issue 的 bot
  • Issue 關閉速度： Issue 被解決和關閉的速度如何？這表現出開發團隊的效率。
• Pull Request (PR)：
  • PR 數量： 是否有持續提交 PR？這表示有貢獻者參與專案開發。
  • PR 合併速度： PR 被審核和 Merge 的速度如何？這表現出專案的協作效率。
• 查看 Insights： GitHub 的 “Insights" 頁面提供了近一個月的 Commit 頻率、貢獻者數量、Closed issue 數量等量化數據。

4. 社群支持度

• Star 數與 Fork 數：
  • 雖然不是絕對指標，但較高的 Star 數通常表示專案的受歡迎程度和社群關注度，但要注意有少數專案可能有用誘因來吸引大家按 Star，例如「每獲得一個 Star 他們就會種一棵樹做環保」之類的
  • Fork 數則可能表示有多少人基於此專案進行二次開發。
• 社群參與度：
  • 貢獻者數量： 有多少不同的開發者參與了這個專案？
  • 討論區/社群活躍度：
    • 是否有活躍的社群可以尋求幫助或參與討論？
    • 社群是否活躍且樂於助人？例如可以加入該開源專案的 Slack 去看看有人有提問題時其他人的反應
• 支援管道： 有哪些管道可以獲得支援，例如 Issue 追蹤、E-mail list、Stack Overflow 等
• 貢獻意願： 貢獻的流程是否淺顯易懂？想想如果是自己的話，是否會願意參與這個專案的貢獻（例如：提交 Bug 報告、撰寫文件、貢獻程式碼）？
• 閱讀 Discussions： 如果專案有 Discussions，可以了解社群的討論內容和常見問題。

5. 程式碼品質與穩定性

• 程式碼風格： Coding Style 是否有規範（例如：PEP 8 for Python 或 Ruff）？
• 測試覆蓋率：
  • 是否有完善的 Unit Tests 或其他相關測試？是否有 CI/CD 流程，如 GitHub Actions？
  • 測試的覆蓋率如何？是否有 > 70%？Codecov 官網建議 75-85% 是最好。
• 程式碼複雜度： 程式碼是否過於複雜難以理解和維護？
• 程式碼註解：
  • 程式碼是否有適當的註解，方便理解和維護？
  • 是否有清楚描述每個函式的參數與回傳值？

6. 安全性

• 對於資料相關的專案，安全性很重要，是否有資安問題回報的機制？
• 是否有其他使用者或公司已經成功導入這個工具？
• 是否有相關的案例研究或使用者評價？

7. 相依相容性

• 這個工具依賴哪些其他套件或軟體？這些相依性是否容易管理？
• 是否存在潛在的相容性問題？依賴過多或過於冷門的工具的話，可能會造成問題
• 是否支援你正在用的 Python 版本？
• 這個工具是否能與其他 Python 資料科學工具的整合性，例如與 NumPy、Pandas、Scikit-learn、Airflow、TensorFlow、PyTorch 等常見工具搭配
• 這個工具支援哪些資料格式，例如：CSV、JSON、SQL、Parquet

總結

以上這幾項中，我覺得選擇一個開源專案時，最重要的就是要有滿足需求的功能，以及維護頻率與社群支持度，如果一個開源專案都沒有人願意維護，基本上就沒辦法期待他未來的發展性。

例如我早期會用 jieba 這個當時很知名也很泛用的套件來斷字斷詞，但在 jieba 的 GitHub 可以看到上一次 commit 已經是五年前（如下圖顯示的 Feb 15, 2020），且 open issues 與 closed issues 比例已經來到 2.8（open 631/closed 228），大幅超越合理的比例範圍，代表一直有很多問題都沒有被解決，這樣的開源專案在採用時就要特別小心。

而一個好的開源專案，可以參考 Kubernetes、Apache Airflow 和 FastAPI，最近一次 commit 常常是在數小時前、貢獻者數量非常多、文件介紹完整，甚至還有資安相關的回報機制，這種開源專案就是比較能放心去使用。

---

參考資料

• 如何選擇開放原始碼 How to choose open source solution
• 關於開源定義與是否可商用，可參考： 如何定義開源軟體＆套件？
• A better metric to gauge the health of an open-source project is to look at the number of issues closed vs. the number of issues currently open. As of this writing (early July 2020), we have 7,757 issues open and 32,485 issues closed. (Medium: Managing issues in a large-scale open source project)
• Although we can’t tell you what your code coverage value should be as every repository is different, we can strongly recommend aiming for somewhere between 75-85% coverage. (Codecov: The Case Against 100% Code Coverage)