一般的電腦使用者想到安裝軟體，應該不外乎是直接從網路下載檔案並執行安裝，或者是直接透過作業系統內建的應用程式商城，如 macOS 的 App Store 或者 Microsoft Store 進行安裝吧！像這樣透過 GUI（Graphical User Interface，圖形使用者介面）這種有可視的圖像並以滑鼠作為核心的作業系統，對現代的使用者而言已經是再習慣不過的事情。
但開發者卻經常用另一種方式來安裝他們在開發環境中所需要的軟體與套件。這種「套件管理工具」（Package Manager）只需要使用鍵盤與 CLI（Command Line Interface，命令列介面）終端機就可以直接完成安裝。而 Homebrew，就是 Mac 系統上很知名的開源套件管理工具之一。
為什麼開發者會需要像 Homebrew 的套件管理工具？
但不熟悉套件管理工具的人一定會感到疑惑，明明多數作業系統就有內建管理軟體的程式（如前述的應用程式商城，或是像 Windows 上的「新增／移除程式」），為什麼還需要額外使用像 Homebrew 這樣的套件管理工具？
確實，如果一款軟體能獨立運作的話，其實套件管理工具相對不那麼重要。但對開發者而言，因為程式開發中所使用的各種程式套件（Package），常常得仰賴其他的套件才能正常運作。而套件管理工具就會在下載新套件的同時，一併檢查電腦系統是否已安裝新套件需要仰賴的套件以及其版本新舊，以確保新套件在下載完成之後就能順利運作。開發者可以藉此省去自己檢查並維護套件的時間，專注於程式開發的工作即可。
用真實生活比喻的話，可以把下載套件這件事想像成在網路商店購買裝修家裡的材料與工具，而套件管理工具則像是你的管家。它會在你買新水龍頭的時候，一併檢查家裡是否有相對應規格的螺絲、起子或扳手。若發現有缺少的東西時，就會在購物時幫你一併下單。這樣才不至於等你收到水龍頭的時候，才發現家裡沒有相對應的工具或材料可供裝修，還得花費心思把工具補齊後，才能正式開工。
Homebrew：要讓管理程式套件跟釀酒一樣簡單且自由
套件管理工具的歷史，其實可以回溯到 1994 年。在最早期的 Linux 作業系統之一 Debian 中，就有內建像 dpkg 這樣的套件管理工具，而後來不同作業系統以及程式語言，也都分別推出各自的套件管理工具供開發者使用。Debian 的創辦人 Ian Murdock 認為「套件管理工具是 Linux 為電腦產業帶來的最大演進之一，」因為它模糊了應用程式與作業系統之間的界線，把每項功能都變成一個個的元件，「讓新的創新更容易進入到市場，並帶領作業系統不斷進步。」¹
而當初原始作者 Max Howell 之所以想開發 Homebrew，是因為他在音樂串流平台 Last.fm 任職並負責跨平台軟體服務開發時，發現到自己時常需要從零開始研究各套件間的依賴性，卻沒有一套好的工具可供跨平台套件的管理，因此決定要開發一套工具來解決這個問題。他主要採用程式語言 Ruby 做開發，並透過 Git 的技術來管理各個套件的改變與相關細節。
雖然在當時的 Mac 平台上，已經有 MacPorts 這款開源的套件管理工具，也有不少開發者參與維護。但 Max Howell 在 2009 年首次推出 Homebrew 的 GitHub 說明文件中有提到 ²，他認為 MacPorts 有兩個缺點：一個是 MacPorts 為了能獨立運作，會安裝自己的資料庫與 OpenSSL 憑證，Howell 認為這樣的做法一點意義也沒有；而 MacPorts 為了支援舊的作業系統，在效能上也相對沒有效率許多。
Homebrew 名稱的由來，是因為創始人 Max Howell 當時嗜啤酒如命，且他覺得 Homebrew（英文原意為自釀）很符合他希望這個工具能達成的事情：「我希望能提供一個平台給人們可以在上面管理自己的套件，並且照自己的想法客製化這些套件。」³
Howell 進而從這個點開始認真發想，Homebrew 的各個服務要如何對應到啤酒相關的名詞，像是安裝套件的指令與說明的 formula（原意為配方）曾經名為 recipe（原意為酒譜），因為 beer recipe 其實是比較正規的用法。但他後來覺得 formula 一詞比較獨特，所以最終決定還是使用 formula。其他像是 cellar（酒窖）、bottle（酒瓶）、cask＆keg（不同大小的酒桶）、tap（出酒閥）等 Homebrew 中使用的專有名詞，全都是來自與酒相關的詞彙。
便利工具的背後，仰賴的仍是工人智慧
然而，像 Homebrew 這樣好用的套件管理工具，背後都需要仰賴一大群志願者的貢獻與維護，才能夠持續營運下去。因為每一次套件與軟體的版本更新都要仰賴人力去協助確認檔案下載連結、套件間的依存關係是否有變動與能支援到 OS 版本等各種細節，並即時更新在 formula 中，確保 Homebrew 的使用者所使用的都是最新版本的套件。
然而，往往遇到較大型的版本更新，免不了會有套件版本之間不相容或互有衝突的情況會發生。像是在撰文的當下，Homebrew 上面最熱門的套件之一 Python 雖然早在近兩個月前，就釋出了 Python 3.8.0 的版本，但目前透過 Homebrew 下載的話，仍只能載到 3.7.5 的舊版本。
曾是 GitHub 上貢獻者最多的專案
因為 Homebrew 在使用 Mac 的開發圈中所累積的高知名度，以及開源套件管理工具維護所需要的大量工人智慧，根據 GitHub 的統計，在 2012 年，Homebrew 是有最多新貢獻者的專案；2013 年甚至一度成為擁有最多貢獻者的專案。至今 Hombrew 在 GitHub 站上，仍是相當活絡的開發者社群。
除了不斷擴充並更新 Homebrew 所支援的套件之外，Homebrew 在這十年間也有不少演進：在跟隨 Max 作業系統的更迭，並持續優化效能之外，比較明顯的改變像是加入對 Mac 應用程式的安裝支援（Homebrew cask），讓那些能安裝在 Mac 應用程式中的軟體也可以透過 Homebrew 進行管理；或是對 Linux 以及 Windows 10 和 Windows Server 2019 原生提供的子系統「 Windows Subsystem for Linux」的支援，讓不同平台的開發者都能享受到 Homebrew 所帶來的便利。
在 Homebrew 的數據頁面上可以看得到，在過去一年間，有 40 種以上的套件透過 Homebrew 下載超過 100 萬次。其中名列前幾名的像是 python、sqlite、openssl、readline，甚至都超過 500 萬次的下載次數。若由頁面上公開的數據回推，過去一年間透過 Homebrew 下載／更新的套件有超過 2.06 億次。可見 Homebrew 在開發者間的火熱程度。
非營利的 Homebrew 如何維持經濟自主？
隨著 Homebrew 的原始作者 Max Howell 在 2013–14 年間逐漸退出 Homebrew 維護與管理的職位，現任 Homebrew 專案領導人 Mike McQuaid 可說是讓 Homebrew 能持續經營下去的重大功臣之一。畢竟根據開源開發者 André Staltz 的一份研究統計指出，有超過八成的開源專案維護者的薪水低於業界水平，甚至有超過五成的維護者的薪水是低於美國的貧窮線以下。
（編按：本文中的開源貢獻者（Contributors），指的是僅提交程式碼與文件修改，仍需要有人批准或給程式碼建議的參與者，可以想像成公司內部的基層員工；而維護者（Maintainers）則負責檢查與核准貢獻者所提交的修改，也是開源專案中最關鍵的人物。）
雖然 Homebrew 並非商業專案，專案的維護者與貢獻者也並不會從維護 Homebrew 中獲得收入。但是像是租用自動化測試的機器或雲端空間、舉辦 Homebrew 開發者的線下聚會等等，仍需要一定的費用。因此 Mike McQuaid 等 Homebrew 的維護者，也曾透過群眾募資專案等方式，讓 Homebrew 能經營下去。
在 2013 年，Homebrew 便首次透過 Kickstarter 進行群眾募資專案「brew test-bot」，旨在募集資金購買機器來自動化測試貢獻者所呈交的 formula 是否能正常運作，進而加快整合 formula 到 Homebrew 中的速度。這項群眾募資最終募得超過 10 倍的資金，也因此能購入更多台的設備進行自動化測試。現在 Homebrew 在 Patreon 上也可以收受群眾的捐款，目前約有 1,000 名的贊助者，每月可獲得 2,500–2,600 美元（約新台幣 76,000–79,000 元）的贊助。在 GitHub 開放 Sponsor 功能之後，Homebrew 也有加入這方式讓群眾贊助。
然而，在逐漸獲得讓 Homebrew 穩定運作的資金同時，還有另一項棘手的事情要處理：雖然 Homebrew 並非營利專案，所有的貢獻者都是不支薪的，但像 Homebrew 這樣大型的自發性組織若要合法地運用募集來的資金，其實也有各種法規需要遵守，而這 對 Mike McQuaid 等不熟悉法律的 Homebrew 主要維護者，可說是一大難事。
因此 Homebrew 後來也申請加入軟體自由保存組織（Software Freedom Conservancy）這個非營利組織，並在他們的協助下能無需擁有自己的非營利組織，就合法地透過 Software Freedom Conservancy 獲得支持者的捐款，且在不影響開發工作流程的情況下，接受財務與經營上的審查與協助，維持 Homebrew 的社群運作順暢。
管理開源專案最辛苦的並非技術，而是處理人的事情
Homebrew 的專案領導人 Mike McQuaid，約在 2010 年就加入了維護者的行列，並在原始作者 Max Howell 逐漸退出 Homebrew 的行列時，接下 Homebrew 領導者的角色。他在接受訪談時表示，雖然他目前的正職是 GitHub 的資深工程師，但在他每天工作之餘，仍會花最多 2 個小時在 Homebrew 相關的事務上，內容涵蓋開發新功能、解 bug、回答使用者問題，甚至會負責指引其他貢獻者可以投入在哪些部分。⁴
他認為 Homebrew 的開源社群之所以會如此活絡，是因為 Homebrew 的使用者中有很大部分本身就是開發者，不僅更熟悉開源的概念，也對技術有更深的掌握。所以與 Firefox 這種面向消費者端的開源軟體相比，自然能吸引到更多參與者。據 McQuaid 表示，Homebrew 至今已累積超過 7,000 名的貢獻者，而每月約有數百人活躍於貢獻 Homebrew。
但或許也是因為 Homebrew 在開源圈的高知名度與高使用量，McQuaid 在訪談中提到，他認為擔任 Homebrew 的專案領導人，最累的事情並非技術層面，而是處理人的事情。不僅要對內協調與開導 Homebrew 的貢獻者，對外也要面對 Homebrew 使用者各種無理的需求甚至辱罵，以及各種行政上的事務。也因此，隨著 Homebrew 的演進，他們也制定了相對應的治理條例，以及寫給貢獻者與維護者的相關文件，供需要的時候做參考。
給開源維護者的建議：別把自己累壞了
McQuaid 的部落格中，也有許多文章在討論開源相關的議題，像是〈開源維護者沒欠你什麼〉（Open Source Maintainers Owe You Nothing），就是他從自身參與開源的經驗有感而發，提到現在許多開源專案的使用者，對開源維護者的不合理要求，導致維護者疲勞過度以致最終放棄這項開源專案，使得人們此後反而無法享受開源專案所帶來的好處。McQuaid 也針對像這樣的惡性循環提出相關解方。
此外，他也提出一套「開源貢獻者漏斗」（The Open Source Contributor Funnel）理論，以 Homebrew 的成功經驗為基礎，教導其他有志於推廣開源專案的開發者，如何吸引到更多更好的專案貢獻者。⁵
日前（2019 年 11 月），Homebrew 釋出 2.2.0 的新版本，不僅針對新作業系統 Catalina 的更新與效能提升，也進一步加強對 Linux 作業系統的整合度，持續擴展 Homebrew 在開發者中的影響力。
而當談到 Homebrew 未來的開發規畫，McQuaid 提到他希望能為 Homebrew 的使用者分眾，讓少部分的使用者可自行選擇加入 beta 版的測試，藉由這種方式讓比較不穩定但具實驗性的功能，能由更多 Homebrew 的使用者測試並回報問題，而不會只限縮在現有 Homebrew 的維護者與貢獻者。⁶這麼一來，更多的 Homebrew 功能才能更快地被部署在正式版的 Homebrew 當中，幫助更多的開發者／使用者都能持續享受大家透過 Homebrew 所釀造出的迷人開發環境。
參考資料：
- “How package management changed everything”
- Homebrew 在 GitHub 的首筆紀錄
- The Changelog — Episode #232｜Homebrew and Swift with Max Howell
- “Research Study Interview: The Work of Maintaining Open Source Software”
- “The Open Source Contributor Funnel (or: Why People Don’t Contribute To Your Open Source Project)”。「開源貢獻者漏斗」的主要概念是，所有的開源專案維護者都曾經只是專案的貢獻者，而所有的貢獻者，都曾經只是使用者。一如行銷學中的銷售漏斗（Sale Funnel），只要專案能吸引到越多使用者，會轉變為貢獻者與維護者的人也就越多。而開源專案的品質高低以及使用群眾的多寡，就會是影響貢獻者人數的重要因素。文中 McQuaid 也分享幾個吸引優質貢獻者的方法，以及當貢獻者不斷出走時，建議可以檢查的部分。
- Homebrew 在 Patreon 的募資頁面
- “User and Feature Segmentation in Homebrew”
- “Making Homebrew Financially Sustainable”
- “Open Source Maintainers Owe You Nothing”
- The Changelog — Episode #223｜Homebrew and package management with Mike McQuaid
本文依 CC 創用姓名標示 - 非商業性 - 相同方式分享 4.0 國際釋出