一、概要
- faker.js 是一個用於 JavaScript/Node 環境中，生成假資料（例如姓名、地址、頭像、電子郵件、公司名稱等）用於開發、測試的庫。
- 該專案由 Marak Squires（通常稱 “Marak”）維護。
- 在 2022 年 1 月初，Marak 對該專案的 GitHub 倉庫進行突發刪除／破壞性操作，導致眾多依賴該庫的項目出現構建／部署故障。該事件引起整個開源社群對「依賴鏈」「軟體供應鏈穩定性」「開源作者維護動機」等問題的大量討論。
二、時間線與關鍵事件
| 時間 | 事件 | 備註 |
|---|---|---|
| 約 2012 – 2020 | faker.js 積累極高下載量與廣泛使用。 | 在許多開發／測試流程中被採用。 |
| 2020 年 4 月25日 | Marak 在推特發佈其公寓火災、個人損失的訊息。 | 引出其個人處境與後續心態變化。 |
| 2020 年（10月左右） | Marak 在 faker.js 倉庫發佈 commit，暗示無法「免費為大公司」繼續維護。 | 顯示其對開源維護者資源／補償的困境。 (JavaScript in Plain English) |
| 2021 年 4 月25日 | Marak 發表部落格〈Open-source 變現是有問題的〉。 | 他談及自己嘗試「Faker Cloud」商業化、但未達可持續模式。 (JavaScript in Plain English) |
| 2022 年 1 月 4 日（左右） | Marak 對 faker.js 倉庫強制 force-push，刪除大量程式碼、留下只一句「What really happened with Aaron Swartz?」於 README。 | 倉庫幾乎清空，導致大量依賴中斷。 (TheGingerViking) |
| 2022 年 1 月 5日（左右） | 同時 Marak 於另一個其維護庫 colors.js 推出「惡意」版本（如無窮迴圈列印 “LIBERTY”）破壞依賴生態。 | 此事件與 faker.js 同時造成供應鏈風險。 (revenera.com) |
| 2022 年 1 月 12 日 | 開源社群迅速響應：新維護團隊成立，於 GitHub 組織 @faker-js/faker 接手。 | 倉庫公告指出「由社群維護」並提供透明資金／治理路線。 (fakerjs.dev) |
三、主要原因與背景
1. 維護者的資源壓力與補償困境
- Marak 曾指出：他長年維護該庫、被大型科技公司（如 FAANG）無償使用，但自己幾乎沒有收入。 (TheGingerViking)
- 他嘗試推出 Faker Cloud（線上假資料產生服務）以期變現，但遭遇挑戰。 (JavaScript in Plain English)
- 在 2020 – 2021 年間，他公開質疑「為何我免費工作，而你們用我的成果賺錢卻不付我」。 (TheGingerViking)
2. 版權、授權與控制權問題
- 雖然 faker.js 採用 MIT 許可證（允許商業使用），但這也使得 Marak 覺得自己對商用大公司沒有談判能力。 (JavaScript in Plain English)
- 當他嘗試要求收費、或轉讓專案時，並未得到明確回應，導致其情緒變化。 (TheGingerViking)
3. 開源依賴鏈脆弱性暴露
- 此事件如同 2015 年的 left‑pad 事件，暴露出大量應用程式高度依賴少數開源模組、維護者變動即可觸發大規模 “斷鏈” 效應。 (TheGingerViking)
- 多家安全分析機構將該事件列為 “供應鏈攻擊／破壞” 案例。 (sysdig.com)
四、影響與後續發展
影響：
- 大量 JavaScript/Node 專案因為 faker.js 的突變／刪除而構建失敗。 (Stack Overflow)
- 開源社群重新檢視「依賴別人模組但未自備備份／快照」的風險。 (TheGingerViking)
- 對開源維護者的補償方式、持續維護機制、社群治理機制引起更廣泛討論。
後續發展：
- 新維護團隊在
@faker-js/faker組織下迅速恢復專案運作，發布舊版所有功能、遷移至 TypeScript 、建立官方文件 fakerjs.dev。 (fakerjs.dev) - 舊的 資金 (Open Collective) 被標註為 “legacy”，並將新維護團隊的資金與舊贊助分離，提升透明度。 (fakerjs.dev)
- 安全／風險社群將 faker.js/colors.js 事件納為“供應鏈脆弱性”教材，並強調需對 npm ／ GitHub 等平台模組做版本鎖定與快照。 (sysdig.com)
五、爭議點與討論焦點
- 維護者的權利 vs 社群責任：開源作者理論上可對其代碼做任何操作，但當該代碼被廣泛依賴時，其單方面決策，是否應承擔更大責任？ (TheGingerViking)
- 商用大公司使用開源但未補償：Marak 提出的質疑是：為什麼大型公司使用其成果卻很少回饋？這觸發對「開源經濟模型」的檢視。 (JavaScript in Plain English)
- 版本鎖定、備份與替代方案的重要性：許多受影響的專案在新版 faker.js 出問題後才發現自身依賴鏈沒有做好防禦。 (Stack Overflow)
- 社群維護 vs 個人維護的可持續性：該事件凸顯長期由個人單打獨鬥維護熱門庫所面臨的燃盡風險。
六、教訓與建議
- 對重要依賴做快照／鎖版本：不要一味使用最新版，自動升級的風險不容忽視。
- 評估依賴的維護者／治理機制：熱門模組是否由社群團隊維護、是否有活躍治理與資金支持。
- 為開源貢獻者提供補償途徑：公司應該重視其使用的開源軟體背後的維護者，考慮贊助、捐款、商業授權等模式。
- 當維護者退出或行為異常時，社群應迅速建立替代路徑：例如 faker.js 的 fork / 新維護團隊就是正面範例。
- 對供應鏈攻擊／破壞風險保持警惕：即便看似可靠的依賴也可能被惡意變動／刪除。
七、補充資訊 & 參考連結
- 官方公告：「An update from the Faker team」 – fakerjs.dev (2022-01-14) (fakerjs.dev)
- StackOverflow 問答：What happened with faker.js? (Stack Overflow)
- TheGingerViking 分析文章：「The right to delete … faker.js」 (TheGingerViking)
- Revenera Blog：The story behind colors.js and faker.js (revenera.com)
發佈留言