本工作室手上同時有開源跟閉源專案。哪個專案該開源？哪些該保留？這個決定影響長期收益、社群關係、自由度。這篇分享實際的決策邏輯。
常見誤解
很多人以為「開源 = 不能賺錢」或「閉源 = 比較專業」。實際上：
- 開源跟商業化不互斥（GitLab、Sentry、Gitea 都是雙模式）
- 閉源專案如果沒人用，跟沒寫一樣
- 開源帶來的「行銷效益」常常超過授權收入
我的決策框架
3 個問題決定一個專案開源還是閉源：
Q1：誰是使用者？
| 使用者 | 傾向 |
|---|---|
| 開發者（用我的工具寫程式） | 開源 |
| 消費者（玩遊戲、看內容） | 閉源 |
| 企業（用我的服務） | 看情況 |
邏輯：開發者期待能讀程式碼、能 fork、能 contribute。對消費者來說程式碼是無關的。
Q2：差異化來自哪裡？
| 差異化來源 | 傾向 |
|---|---|
| 技術實作（演算法、效能） | 閉源（技術是護城河） |
| 內容、設計、品牌 | 開源 OK（程式碼複製不出品味） |
| 運營、社群、資料 | 開源 OK（運營是護城河） |
Q3：你想要怎樣的關係？
| 關係 | 傾向 |
|---|---|
| 個人作品集、招牌 | 開源（讓人讀程式） |
| 純收入來源 | 閉源 |
| 學習與分享 | 開源 |
| 有 NDA 限制 | 強制閉源 |
本工作室的實際分布
| 專案 | 狀態 | 原因 |
|---|---|---|
| 遊戲大廳官網 | 閉源 | 內容資產、品牌 |
| 14 款瀏覽器遊戲（合輯） | 閉源 | 商業內容 |
| worker.js 後端架構 | 計畫開源 | 適合做為「教學模板」 |
| web-sfx npm package | 開源（MIT） | 開發者工具 |
| iframe game SDK | 計畫開源 | 有 community 價值 |
| 客戶接案專案 | 強制閉源 | NDA |
License 選擇
決定要開源後，選哪個 license？
| License | 適合場景 |
|---|---|
| MIT | 「隨便你拿去用」 — 工具、library、模板 |
| Apache 2.0 | 跟 MIT 類似，但有專利條款，企業友善 |
| BSD-3-Clause | 跟 MIT 接近，學術界偏好 |
| GPL v3 | 修改版必須也開源（copyleft），希望防止別人閉源 fork |
| AGPL v3 | 連 SaaS 都必須開源（最嚴格） |
| BSL（Business Source） | 4 年後轉 open，期間限制商業競爭 |
| CC-BY-NC | 內容類（非程式碼），允許 attribution + 禁商用 |
本工作室預設 MIT。要防止商業競爭時用 BSL（如 Sentry 的選擇）。
開源的隱藏成本
很多人以為開源 = 把程式碼丟上 GitHub。實際上要做：
- README：5 分鐘讓陌生人理解專案
- LICENSE 檔：法律保障
- CONTRIBUTING.md：怎麼提 PR
- CODE_OF_CONDUCT.md：行為準則（避免社群衝突）
- 持續回 issue：使用者問題、bug 回報
- review PR：別人的貢獻
- release note：每次發版的清楚說明
1 個熱門開源專案 ≈ 0.3 個全職工作。
什麼時候該停掉開源
不是所有開源都該維護到底。停止的訊號：
- 每週收 5+ issue 但都沒時間回
- 使用者期待 vs 你的願景開始衝突
- 原作者已經沒興趣，但社群還在催
- 影響本職工作 / 健康
解法：明確 archive，標 README 為 unmaintained，鼓勵 fork。誠實比拖延好。
開源的真實收益
除了「貢獻社群」這種抽象價值，實際的：
- 招聘訊號：履歷上一個 1k+ star 的 repo > 三年工作經驗
- SEO：GitHub repo 在 Google 排名很好
- 網路：認識其他開發者的最佳途徑
- 學習 forcing function：知道有人會看，自己會更認真
- 潛在贊助：GitHub Sponsors、Open Collective
結語
「開源還是閉源」不是道德選擇，是策略選擇。重點是跟你想要的關係跟收入模式對齊。本工作室的混搭策略 — 商業內容閉源、開發者工具開源 — 在過去一年運作得很好。