我們是不是常常把「辦了一場成功的研討會、一場盛大的年會」當成「我們有一個健康的社群」？

最近讀到一篇文章，讓我把這個問題又翻出來想了一遍。作者 Jr Conlin 在 Mozilla 待了超過 15 年，離開前寫了一封很長的告別文〈Leaving Mozilla〉。表面上他在談一家瀏覽器公司的內部問題，但讀到後面我發現，他真正在寫的是另一面。一個組織如何把真正撐起它的「社群」，誤當成「顧客」、誤當成「一場可以反覆操辦的大活動」，然後一步步離棄那些持續投入的人。

說明：以下前半段是我自己讀完後的重點整理與編譯，加上一點個人的理解，不是逐字翻譯。內容很豐富，強烈建議直接點原文讀完整版，我這裡只整理摘要與觀點。

Jr Conlin 如何看 Mozilla

離職信留給同事的三句話

他離開時留給同事一封信：

• 你比你想的還重要：他講的就是「正在讀這封信的那個你」，不是什麼「企業體」或「組織」。他長年在公司裡推動 mentoring（師徒制、指導），本質就是「找到另一個可以對話的人」。無論你的資歷深淺，你都同時能學、也能教。
• 你是更大整體的一部分：在 Mozilla 領薪水的人，是幸運的少數。真正的 peers（同儕）是外面那一大群「沒有 badge、沒有 @mozilla.com 信箱」、卻一起想打造一個「把使用者利益擺第一」的瀏覽器的人。對這群人，公司有「傾聽」的義務，因為如果不為他們做事，他們會去找別人。
• 我們其實很小：Firefox 是一個 niche（小眾）瀏覽器，只是運氣好，取得了足夠的資金。他用了一個很傳神的比喻：想像你住在一個只有麥當勞、漢堡王、溫蒂漢堡的地方，而 Mozilla 是那間溫暖的「夫妻經營的小餐館」：客人會彼此打招呼、互相倒咖啡、幫忙收桌子。人們是特地繞過手邊現成的大廠瀏覽器、忍受各種「你的瀏覽器過期了」的警告，才來找 Firefox 的。

最後他把這封信收束成三句 TL;DR：尊重你自己、互相幫助、記得你到底是為誰工作。

離職之後的真心話

離職信寫得客套，那些「困擾他很久」的事，他在文章後續另外寫下來（原文內容很豐富，有時間建議閱讀）：

• 領導層不是功臣：業界常說「Mozilla 是『靠著』它的領導層存活下來的，而不是『因為』領導層」，他說這句話「最近聽起來特別真實」。
• 使用者「極度不正常」：Firefox 的使用者是「deeply abnormal（極度不正常）」的一群人，你得主動去找、去下載、無視所有要你改用 Chrome 的廣告。而問題在於，領導層不知道該如何面對這種「不正常」。Mozilla 本來就是不正常的，幾乎每一行程式碼都是開源公開的、關鍵漏洞常常 24 小時內修掉。
• 把開源透明當火星人：從傳統科技業挖來的領導者，多半來自「黑色高領毛衣之神」（暗指賈伯斯那套）信奉的世界，奉行「什麼都別告訴任何人」。對他們來說，「把東西免費送出去、而且透明到不可思議」這件事，簡直像火星人在做的事。
• DAU 焦慮：日活躍使用者數（DAU）掉了好幾年，新的領導者每次進來都帶著大想法，而那些大想法幾乎都是「我們應該抄大廠在做的東西」。但這註定沒用。如果使用者真的想要那個功能，他們手邊的大廠瀏覽器早就有了，何必特地來用你？
• 假裝成新創：每個新領導者都覺得「我們要像新創一樣思考！」可是 Mozilla 是一家 30 年的老公司，是新創的反面。結果他們「假裝成新創」假裝了 15 年，換來史上最低的 DAU。他的建議是，回頭看看 30 年歷史裡 DAU 最高的時候在做什麼。而那答案，從來都跟潮流無關：做自己擅長的事、保持那份「不正常」、幫人們做出他們真正想要的東西。
• 追企業合約的諷刺：Mozilla 一度想去賺「企業財」，得通過一堆 ISO 標準與資安認證、證明自己的程式與基礎設施夠安全。諷刺的是，企業客戶用的 curl、Linux 和一大堆開源工具，全是「網路上隨便一些人」寫的。而那些資安認證體系所要求的「金鑰妥善保管、建置環境安全、有可稽核的軌跡」，其實正是 Mozilla 這種「全部開源、公開修漏洞」的做法在示範給大家看的。
• 倖存者偏差：推出爭議功能（DRM、AI、推播通知……）後，「聽使用者的意見」其實很難，因為會留下來告訴你想法的人是少數，多數人不爽就直接走了。於是你的資訊來源永遠是「留下來的那群人」，得到的滿意度自然虛高。他用了二戰那張著名的轟炸機彈孔圖當比喻。原文只一句帶過，這裡補充一下典故：你以為該補強中彈多的地方，但真正該補的是「沒中彈」的部位，因為中那裡的飛機根本沒飛回來。一個功能如果熱度過了新鮮期就掉下去，那大概就是你猜錯了，Reddit 上抱怨的人可能才是對的。
• 最痛的一點，離棄社群：過去五年，Mozilla 由上而下地背離了它最大的後盾：社群。領導層認定「Mozilla 是靠自己走到今天的」。但它不是。他們說服自己「社群只是顧客、頂多是粉絲」，這激怒了非常多無償貢獻者。這些人付出了好幾年的時間，因為相信自己屬於一件更大的事，結果換來一句「你們只是顧客」，覺得被背叛了。

「如果讓我當 CEO，我會做什麼？」

他說，這是他面試時最愛問別人的問題，現在反過來問自己，答案有四個：

1. 無聊一點：Mozilla 什麼都想做，做過購物樞紐、做過手機作業系統，然後一再發現自己不擅長。他們真正擅長的就是做瀏覽器。那就專心把核心功能顧好，讓那台「高速亂噴的義大利麵砲」先冷卻一下。
2. 少一點登月計畫：Firefox 都存在這麼多年了，會用它的那群「怪人」要的很樸實，把累積已久的舊 bug 和技術債修一修、把東西做得更好用、更不煩人，而不是再來一個一年後就棄坑的花俏新功能。而且重大改動要預設 opt-in。他提醒、你的使用者不是你的粉絲，他們只是「勉強忍受你」，你得每天努力才留得住他們。這話聽起來消極，卻很務實。謙虛才會逼你進步。
3. 重建你的社群：鼓勵外部貢獻，鼓勵到他們能「參與決定下一步要做什麼」的程度。他要的是真的會去修正 bug、做翻譯、回答海量問題的那些人，而不是用 Amazon 禮券把人圈進來坐一小時的焦點團體。（Firefox 曾經幾乎支援所有語言，靠的就是這群志工。）
4. 別丟掉好東西：Mozilla 有個很糟的習慣、把成功的東西丟掉。Thunderbird 被晾在一邊、Rust 被丟出去（明明可能是金雞母）、Servo 說不定哪天會反過來打敗你、Bugzilla 才是原版好東西（Jira 不過是從它腐化出來的那場惡夢）。這些其實都可以重新邀請回來、一起把事情做得更好。

他真正的願望，是 Mozilla 能重新和社群連結，靠「有用」而不是靠「製造聲量」來成長，當生態系裡有活力的一分子，而不是吞掉一切的黑洞。

文章最後，他把自己這一年反覆問自己的問題攤開來：「我到底是為誰在做這些？」他得到的答案讓人很難過：「我做這一切，是為了讓某個人在下一份履歷上，多得一顆星星。」

反觀台灣：社群，不是研討會

讀完上面那段，我一直在想一件事。Mozilla 真正的問題，是忘了自己一直靠社群撐著，把那群無償投入的人慢慢當成顧客、當成一場可以反覆操辦的大活動。

那我們呢？台灣的開源圈、技術圈，犯的是一個方向相反、結果卻一樣的錯。Mozilla 是忘了社群還在，我們是把「辦了一場研討會」直接當成「我們有一個社群」。一個是遺忘，一個是替換，最後那群真正持續投入的人，同樣沒有被關注！

什麼才叫「社群」

社群，是「除了辦大型活動之外，平常還持續在一起做事」的那群人。一場一年一度的研討會，本身不是社群。

研討會頂多是社群的「年度高峰」，而且前提是，它背後真的有一個平常就在運作的社群。如果一年就那一場、辦完就散、隔年再重來，那它是個「活動」，不是個「社群」。

這跟 Jr Conlin 講的是同一件事，只是換了詞，對他來說，社群是那些「沒有 badge、沒有薪水，卻一直回來」的人。研討會是一個「事件」，社群是一段「持續的關係」。事件結束後，關係才開始累積。

正面的樣子：把社群做對的例子

台灣其實有把「社群」做對的例子，特徵都一樣，大會落幕後，它們仍在運作：

• g0v 零時政府：嚴格說，g0v 比較像一場運動、一個協作平台，不是單一個社群。真正在一起做事的，是各專案頻道裡平常持續協作、持續推進的那群人。每兩個月一次、由「揪松團」籌辦的「大松」（g0v 的大型黑客松）持續在辦，雙年會 Summit 只是其中一個節點而已，g0v 不是「靠 Summit 才存在」的。
• 各語言、技術的 meetup 與讀書會（Python、Ruby、前端、資安……）：定期小聚、定期分享、定期動手做。這些聚會通常不大，但它們是「持續的」。這才是讓新人能一直走進來、讓關係能一直長出來的入口。
• COSCUP：嚴格說，COSCUP 是一場研討會、一個交會點，不是社群本身。它辦得好，是因為背後有眾多平常各自持續運作的社群，而不是大會那幾天本身。
• 我自己在 Devconnect ARG 2025 也看過這種「對的設計」：大會給社群一塊空間（Community Hub），讓社群在活動週裡自己持續長出小議程、自己佈置、自己招呼人，而不是「一桌兩椅、講完就收」。給空間讓社群自己長，跟「把社群當成一個攤位節目」，是兩種完全不同的思路。

反面的樣子：辦完一場大會，就說自己有社群

對照之下，台灣也有不少這樣的型態：

• 「我們辦了一場 XX 高峰會、XX 論壇、XX 年會，所以我們有社群」，但大會結束後，沒有持續的聚會、沒有持續的協作、也沒有讓新人持續加入的入口。明年再用同一套模板辦一次，中間 11 個月一片安靜。
• 由上而下、由主辦方、政府、企業掛名的「社群」：名義上是社群，實際上缺了 grassroots（草根）那一層持續性。沒有人在「不辦大活動的日子」也願意一起做事。
• 把參加者當「人次、KPI、觀眾」，而不是「會回來一起做事的夥伴」：這其實就是 Mozilla 把社群當顧客的台灣版，你關心的是「今年來了幾個人」，可惜不是「這些人會不會再回來」。

為什麼說台灣「面臨一樣的處境」

把 Mozilla 的狀況拿來對照，會發現問題幾乎一模一樣：

• 一樣的倖存者偏差：我們只看得到「來參加大會的人數」，看不到那些默默離開、不再回來的貢獻者。活動報告裡只會寫「今年破紀錄、來了多少人」，不會有人記下「去年那批熱情參與的人，今年一個都沒回來」。
• 一樣的「製造聲量」勝過「真的有用」：把資源和注意力都壓在一年一度的曝光與人次上（很像 Mozilla 追 DAU、追潮流），而不是去經營那種「能持續產出、能持續投入的夥伴」的關係。
• 於是社群空心化：因為所有力氣都花在「大型活動」這個事件上，平常該持續運作的小聚、協作、新人招募反而無人承接。久了，大會還在，但大會背後那個「社群」已經被掏空了。

所以呢？

辦一場研討會、辦一場盛大的年會，當然是好事。但我想提醒自己，研討會是社群的「果」，不是「因」。沒有平常持續的活動撐著，一場大會就只是一次性的展演，熱鬧兩天，然後呢？

Jr Conlin 為 Mozilla 提出的那幾條建議，其實放到台灣的社群也成立。他說要「無聊一點」、別一直追新花樣，換成社群的話，就是別每年都想辦一場更大、更炫的活動，把心力放回每個月的小聚、每次的協作上。他說「別丟掉好東西」，就是別讓那些長期默默運作的老專案、老聚會自生自滅，它們往往才是社群真正的命脈。他說要「重建社群」、讓貢獻者能參與決定下一步，換成我們，就是讓平常一起做事的人有真正的位置，而不只是在大會那幾天被當成觀眾。

借用他那句話：社群，是那些「沒有 badge、沒有薪水，卻一直回來」的人。今年的大會來了多少人，其實沒那麼要緊。比較能說明一個社群還活著的，是大會結束三個月後，你還叫得出名字、還願意約出來一起做事的人，到底剩下幾個。

大會結束之後，還有多少人，願意持續一起做事？

這個問題我沒有標準答案，丟給你，也丟給我自己。如果你也在經營或參與某個社群，歡迎從一件小事開始：在下個月不辦大活動的那些日子，找幾個人一起動手做點什麼 🙂

---

本文前半為 Jr Conlin〈Leaving Mozilla〉的重點整理與編譯（非逐字翻譯，僅為評論性引用），原文連結：https://blog.unitedheroes.net/5751。後半的台灣社群觀察為個人觀點。

滿喜歡用 Material for MkDocs 來產生文件網站，嚴格來說，這是一個建構在 MkDocs 之上的一個樣式套件，只是又加入了滿多設計樣式，相對於原始 MkDocs 來說在文件閱讀排版上更清晰。

以前常用 Sphinx 寫 rst 格式的純文字內容，後來 Markdown 成為主流，延伸出許多靜態網頁套件或是對應 Markdown 轉換其他文件格式的應用。我記得我是在使用 FastAPI、Pydantic 的技術文件注意到為什麼有一套很美的文件產生樣板，使用後就決定採用在當時做的專案，建構文件資訊給予其他貢獻者參與、閱讀。

以往所建立 Material for MkDocs 的文件專案，大部分都會將建立好的靜態網頁上傳到 AWS S3 存放，直接透過 AWS S3 的網站設定或是透過 nginx 路徑轉址合併到原有的網站中（如：/docs）。反而發現從來沒嘗試過直接用 Github Pages 來建立 Material for MkDocs 文件專案。

在 Github Actions 中有三種方式可以實現 Github Pages 的發佈，可以參考這份 yaml 檔案的描述。這裡用的套件管理是 uv。

MkDocs 有整合 Github Pages 的發佈，可以透過 mkdocs gh-deploy 來佈署，直接一行指令就可以完成。

- name: Build MkDocs
  run: |
      uv run mkdocs gh-deploy -b gh-pages -d ./docs

直接將產生出來的靜態檔案 ./docs 內的檔案上傳到 gh-pages 分支的頂層位置。

第二種方式是每次都從 main 建立一個新的分支 gh-pages 然後產生靜態文件後，強迫上傳覆蓋遠端原有的 gh-pages，這樣的方式是只會看到最新的文件提交紀錄。

- name: Build MkDocs
  run: |
      uv run mkdocs build -d ./docs
      git checkout -b gh-pages main
      git add -f ./docs
      git commit -m 'Deploy MkDocs to GitHub Pages'
      git push -f origin gh-pages

第三種方式是用 worktree 的方式將 gh-pages 建立在 ./docs，然後把靜態文件產生到 ./docs 中完成提交與推送。

- name: Build Mkdocs
  run: |
      git worktree add ./docs gh-pages
      rm -rf ./docs/*
      uv run mkdocs build -v -d ./docs
      cd ./docs
      if [ -n "$(git status --porcelain)" ]; then
        git add .
        git commit -a -m 'Deploy on ${{ github.ref_name }} ${{ github.sha }}'
        git push origin HEAD
      else
        echo "No changes to commit."
      fi

歷史紀錄

如果有使用 mkdocs-git-revision-date-localized-plugin 套件，應該會發現每次產生出來的文件建立日期與修改日期都會是一樣的，那是因為 Github Actions 在使用 actions/checkout 的時候不會擷取過往的 git 歷史提交，需要指定參數來提示擷取完整的 git 紀錄。

- uses: actions/checkout@v5
  with:
      fetch-depth: 0

以上，透過三種方式來建立 Material for MkDocs 靜態文件，看起來多行的指令是可以保留一些彈性操作的可能，例如在最後更換 og 預覽圖，當使用免費版本，都只能呈現預設的樣式。

Material for MkDocs 是一個很好快速建立靜態文件或是針對專案類型的說明網站，建立在 Github Pages 上也不用擔心主機安全性或流量問題，覺得這是一個值得投入瞭解與應用的靜態文件套件！