Wikipedia FOSS 清單變工具地圖

我把 Wikipedia 的 FOSS 清單拆成一套可直接拿來選工具、比工具、收斂工具堆疊的方法。

我用 Wikipedia 這類清單一陣子了，老實說，通常只會先把我搞更焦慮。你點進 Wikipedia 的 List of free and open-source software packages，滿版分類一路往下滑，心裡只會冒出一個問題：所以呢？它告訴你 AI、CAD、安全、媒體、辦公都有一堆開源選項，但它不會告訴你該挑哪個、該跳過哪個、也不會幫你把工具堆疊收斂到能真的上線的樣子。我以前就很愛在這裡失控，收藏一堆替代品，最後花一晚在比 license 和文件，然後什麼都沒交出去。

後來我才想通，這頁不是推薦榜單，它是分類學。你一旦不把它當購物車，而是當地圖，它就開始有用了。分類告訴你生態哪裡成熟、哪裡碎、哪裡你最好只選一個笨但穩的預設值。這就是我今天要拆的重點。

這次我看的是 Wikipedia 原始頁面本身，還有它旁邊連出去的 GNU Free Software Definition、Open Source Definition、以及 FOSS 總覽。我不是在重貼目錄，我是在把它翻成你選工具時真的用得到的判斷框架。

這不是推薦引擎，是分類地圖

“This is a list of free and open-source software (FOSS) packages, computer software licensed under free software licenses and open-source licenses.”

白話一點，這句話先把事情講死了：它是按類別整理，不是按品質排行。這很重要，因為開發者很容易把這種清單讀成「第一個就是最好」。通常不是。它要回答的是「有什麼存在」，不是「你該用什麼」。

我以前找內部工具替代品時就踩過這個坑。我一開始想問的是「哪個開源版最好？」這句話本身就很蠢。最好是對什麼最好？小團隊？離線？嵌入式？企業登入？Wikipedia 這頁其實在提醒你：軟體是有家族的。你不是從整個宇宙挑，你是從符合任務的那一小塊挑。

實操寫法很簡單：讀這頁時，先把跨類別比較的衝動壓下去。只在同一類裡比，而且前提是你先定義好工作。你要的是文字編輯器，就別拿資料庫來湊熱鬧。你要的是機器人堆疊，就別拿 Markdown app 來比。這聽起來像廢話，但我累的時候還是會犯。

我現在會把這頁當成領域地圖。某個類別如果完全缺席，代表你可能在那塊沒配齊。某個類別如果塞了二十個東西，代表你需要更窄的篩選規則。對我來說，這個規則通常是：維護活躍、文件正常、license 我能接受、社群真的會回問題。

大分類密度，直接告訴你哪裡成熟

先看目錄本身就很有戲。Wikipedia 把頁面切成像 Artificial intelligence、CAD、Cybersecurity、Data storage and management、Operating systems、Programming language support 這種大區塊。這不只是排版，這是在暗示哪些地方已經有足夠厚的生態，可以支撐真實工作流。

也就是說，開源不是平均分布的。有些類別特別擁擠，因為痛點大家都有：作業系統、編輯器、瀏覽器、版本控制，選項多到爆是正常的。其他類別比較薄，因為問題太冷門、成本太高、或根本難以標準化。你看到很胖的分類，就要預期選擇過載；你看到很薄的分類，就要預期取捨很硬，搞不好只剩一兩個能打的。

我很愛把分類密度當成生態壓力的代理指標。某區塊如果很多項目，通常代表競爭激烈、分支多、還有一堆「我們團隊用這個，因為遷移成本已經付了」的歷史包袱。某區塊如果很少，可能是預設值很明顯，也可能是這個領域還很亂。兩種都不壞，只是你評估工具的方式要變。

• 密集分類：預期功能重疊、差異細、邊界案例多。
• 稀疏分類：預期取捨更硬、整合成本更高。
• 超大分類有子類：真正的決策通常要往下一層看。

實操上，我每次進分類前都先問三件事：這個類別大，是因為問題本身很常見嗎？我是在找核心工具，還是特化外掛？我需要的是工具本體，還是它周邊的生態？最後這題很重要，像 Emacs、Vim、Firefox 這種，真正的價值常常一半在社群、一半在周邊。

最值錢的是那些無聊分類

大家一看到 AI、安全、圖形就想點進去，我懂，這些比較像會議上拿得出手的東西。但真正省時間的，常常是那些很無聊的分類。Wikipedia 裡面有辦公軟體、檔案管理、備份、資料庫、建置自動化、靜態分析、文件產生器、組態管理。這一層才是在撐團隊，不是靠幾個炫砲專案撐場面。

翻譯一下就是：所謂 open source stack，不只是你的 app code。它還包括讓資料能流動、版本能重現、錯誤能回復的那些膠水。很多團隊會花很多時間在前端框架，結果備份是靠一支沒人敢碰的 shell script。這順序整個反了。這頁有用，是因為它把那些不性感、但真的決定系統能不能活下來的類別攤在你面前。

我自己在 production 被這件事打過很多次。app 本身沒事，出事的是支援層：沒有像樣的備份策略、觀測性很弱、build 流程只在某台筆電上能跑。Wikipedia 這種清單提醒我，成熟的軟體生態一定有一堆看起來很 boring 的東西。你不能因為它不適合 demo，就假裝它不存在。

實操寫法：把堆疊分層。先放儲存、備份、版本控制。再放 build 和 test。最後才放面向使用者的應用層。如果你在挑開源方案，不要只看 shiny package，還要問它旁邊有沒有 export、recovery、automation、monitoring。沒有的話，你其實是在幫未來的自己加班。

• 核心層：OS、shell、editor、version control、package management。
• 安全層：backup、encryption、password management、recovery。
• 營運層：monitoring、deployment、logs、automation。

License 比截圖重要多了

頁面一開始就把 free software 和 open source 劃開，這不是裝飾。它直接連到 GNU Free Software Definition 和 Open Source Initiative 的 Open Source Definition。Wikipedia 也有提到，有些軟體從 GNU 的角度看其實更適合叫 free software。這提醒你：license 不是註腳，它就是產品的一部分。

也就是說，你不能把「open source」當成單一大桶。license 決定你能不能重用、散布、修改、整合。你如果是在做內部工具、要出貨、或想把 library 嵌進產品，license 常常比功能表還重要。我看過團隊愛上一個工具，結果開會才發現 license 跟預計用法卡住。那種場面很難看。

我現在看這種目錄，第一眼先看 license，再看截圖。聽起來很不浪漫，但很省時間。漂亮專案如果 license 不能用，對我的情境就是死路一條。反過來，長相普通但 license 乾淨、維護正常的專案，常常才是比較好的選擇。

實操寫法：把 license 變成第一層過濾器。如果只是內部使用，你的標準跟要對外散布、或賣給客戶，會完全不同。我的做法是先替團隊列一份可接受 license 短名單，然後在還沒被 UI 迷住之前就先篩掉。只要專案對 license 說不清楚，我就直接跳過。

把清單拿來找預設值，不要拿來集郵

這頁裡面有整個家族的軟體：像 Debian、Ubuntu、Fedora、openSUSE、NixOS 這些 Linux 發行版，還有 Firefox、Emacs、Vim，以及一堆分散在網路、儲存、部署的基礎工具。這種廣度很容易讓人陷入收集癖，今天存一個、明天存一個，最後變成維護債。

翻譯一下就是：這頁最適合拿來挑可重複工作的預設值。預設 OS 一個、預設 editor 一個、預設備份路徑一個、預設影像工具一個、預設資料庫一個。你當然可以例外，但預設要能扛住大部分工作。你標準化的分類越多，團隊就越少在同樣的決策上反覆吵架。

我自己的規則很無聊，但很管用：每個重複任務只留一個工具，除非有很明確的理由換。新工具要進堆疊，得在某個具體指標上打贏預設值：部署時間、維護成本、相容性、團隊熟悉度。光是「感覺比較順手」不算，從來都不算。

實操寫法：把 Wikipedia 頁面變成 shortlist 產生器。一次只選一個類別，先列三個候選，再寫任務描述，然後才看文件。對 browser 來說，你可能在乎 extension 和 sync。對 database 來說，你在乎 migration 和 backup/restore。對 distro 來說，你在乎 package availability 和 upgrade behavior。重點是不要把整張目錄當自助餐。

結構本身就在告訴你整合痛點會在哪

你只要看子分類，就大概能猜到整合痛點會長在哪裡。頁面裡有 containers and orchestration、documentation generators、testing、static analysis、configuration management、remote access、monitoring and observability、web-related tools。這其實就是在列出軟體系統變髒的地方。

也就是說，這份目錄默認承認了一件事：一個工具幾乎不會單獨活著。code generator 需要 build tooling。service 需要 monitoring。deployment tool 需要 configuration management。testing framework 需要 CI。這頁的結構其實很像真實系統的組裝方式，所以它比亂湊的「最佳工具榜」更有參考價值。

我在設計內部平台工作時，這點特別有用。如果產品團隊要加一個新工具，我不會只問「能不能用」，我會問「它會碰到誰」。如果它要碰 auth、backup、logs、storage、deployment hooks，那它就不是一個工具了，它是一整條鏈。Wikipedia 這頁很像在提醒你：真正的成本都藏在鏈上。

實操寫法：評估一個 package 的時候，把鄰近分類也一起看。你在看 database，就順手看 backup、admin、monitoring。你在看 robotics package，就一起看 simulation、control、hardware support。你在看 browser，就看 privacy、extension、sync。整合才是 review 的起點，不是結尾。

把清單當過濾器，不要當目錄本身

巨大的軟體清單有更好的用法，不是拿來逛，而是拿來過濾。Wikipedia 已經幫你把軟體切成 AI、education、media、networking、office、science、programming support 這些桶子了。你的工作，是把它變成你自己的工作環境過濾器。

翻譯一下就是：你要問的是，我在解什麼類型的問題？我有哪些限制？我拒絕維護什麼？最後這題很重要。很多工具在 demo 的時候都很酷，等你變成 on-call 才知道自己在接什麼爛攤子。像這種目錄的價值，就是把搜尋空間打開，但也同時逼你正視：軟體選型其實很多時候是在選你願意承受多少營運成本。

我現在會用一個很短的 pass/fail checklist。維護不行、文件不行、license 不合，就停。過了，再拿到我真的在乎的情境裡測。這樣才不會把巨大的清單玩成個人專案收藏夾。這頁有用，正是因為它夠完整，逼你做決定。

可抄的模板

# FOSS 工具選型模板

## 1) 先定義工作
- 我到底在解什麼問題？
- 這屬於哪個分類？
- 我現在的預設工具是什麼？

## 2) 先設硬門檻
- License：
- 維護狀態：
- 平台支援：
- 部署模式：
- 資料匯入 / 匯出需求：

## 3) 只挑 3 個候選
- 候選 A：
- 候選 B：
- 候選 C：

## 4) 只比真正重要的項目
- 安裝時間：
- 文件品質：
- 升級路徑：
- 備份 / 還原：
- 驗證 / 安全：
- 團隊熟悉度：
- 和鄰近工具的整合：

## 5) 決定預設值
- 最終工具：
- 它贏在哪裡：
- 什麼情況下我會換掉它：

## 6) 寫下操作規則
- 什麼情況用它：
- 什麼情況不用它：
- 誰負責：
- 怎麼備份：
- 怎麼監控：

## 7) 留逃生門
- 遷移計畫：
- 要保留的資料格式：
- rollback 路徑：
- 退出條件：

這就是我最想早點有的版本。它把一張巨大的目錄變成決策流程，而不是一個週末的分頁地獄。你可以直接貼進團隊文件，針對每個分類一格一格填，別再假裝軟體選型是靠感覺就能過關。

我講白一點：Wikipedia 這份清單有價值，不是因為它在賣你什麼，而是因為它沒在賣你什麼。它只是在告訴你現場有什麼，而這就夠了，前提是你知道怎麼讀。把它當起點，縮到一個具體決策，別把自己困在蒐集工具的循環裡。

來源致謝：原始目錄在 Wikipedia。我這篇的拆解、選型框架和模板是原創整理，衍生自該來源，但不是原頁面的逐條重製。