“Fork 一个开源项目，下周就收钱”为什么经常翻车：10 个热门仓库背后，其实是 10 套完全不同的商业边界
源帖的标题非常诱人：10 个 GitHub 仓库，让你睡觉时也能赚钱。 它给出的逻辑大致是： 开源项目已经有人验证 → fork / self-host / white-label → 换一个垂直客户 → 每月收费。 问题是，“代码公开”与“你有权把它白标卖掉”之间，至少隔着许可证、商标、托管模式、企业功能、客户数据、支持责任和单位经济模型。 把这 10 个项目逐个重新看一遍，最重要的结论不是“哪
“Fork 一个开源项目，下周就收钱”为什么经常翻车：10 个热门仓库背后，其实是 10 套完全不同的商业边界
源帖的标题非常诱人：10 个 GitHub 仓库，让你睡觉时也能赚钱。
它给出的逻辑大致是： 开源项目已经有人验证 → fork / self-host / white-label → 换一个垂直客户 → 每月收费。
问题是，“代码公开”与“你有权把它白标卖掉”之间，至少隔着许可证、商标、托管模式、企业功能、客户数据、支持责任和单位经济模型。
把这 10 个项目逐个重新看一遍，最重要的结论不是“哪个最赚钱”。
而是：
> 它们根本不是同一种商业资产。
第一层：先区分 Open Source、Open Core、Fair-code、Source-available
源帖最后写“100% 免费，100% 开源”。
这句话对整份清单不成立。
n8n
官方明确说自己的 Sustainable Use License 属于 fair-code，不称自己为 OSI open source。更重要的是，官方 FAQ 直接举例：
- 白标 n8n 后收费：不允许；
- 托管 n8n 并向用户收费访问：不允许；
- 为客户做 n8n 咨询、搭内部工作流：允许；
- 若要超出范围，需要商业协议。
所以“开源 Zapier → 白标 SaaS”恰好是这个清单里最不能随便做的示例之一。
Cal.com
核心大量代码是 AGPLv3，同时存在 Enterprise Edition/商业许可。AGPL 的关键不是“不能商用”。
而是当你修改并通过网络向用户提供服务时，会触发强烈的源代码提供义务；再加上商标与 EE 部分，你不能把“fork”理解成“换 Logo 就结束”。
Plausible
Community Edition 是 AGPLv3。可以自托管，但托管本身意味着服务器、ClickHouse/Postgres、升级、备份、安全、可用性和支持成本。
“服务器成本 × 10 转售”不是毛利模型，只是一个没有算人工的定价口号。
Ghost
Ghost 核心当前是 MIT，商业使用相对宽松，但 Ghost 和 Logo 是商标。而且做“开源 Substack”收入绝不可能是“利润率 100%”。
支付费、邮件投递、域名、服务器、客服、退款、税、作者获客、内容生产都是真成本。
Supabase / Coolify / Medusa
这些项目许可证相对宽松：- Supabase：Apache-2.0
- Coolify：Apache-2.0
- Medusa：MIT
但许可证允许，不等于商业成立。
你仍然要回答： 谁会因为你而不是官方/云厂商付钱？
AppFlowy
这里尤其容易被一句“开源 Notion”误导。客户端/生态有开源部分，但 AppFlowy Cloud 的 self-host 商业软件有独立许可，明确涉及内部使用、按服务器授权，并限制转售/转让等行为。
商业化前必须具体到“哪个仓库、哪个组件、哪个 License”。
listmonk
AGPLv3。Penpot
MPL-2.0。MPL 的义务和 AGPL 完全不同，不能只用“开源”两个字概括。
真正的 Open-source Commercialization Gate
任何准备 fork / self-host / 二开赚钱的项目，先过 12 个问题。
1. License
具体文件和模块是什么许可？2. Network Obligation
做成网络服务后是否需要开放修改源码？3. Enterprise Boundary
有没有 EE / proprietary 模块？4. Trademark
能不能改名、用原项目 Logo、声称官方合作？5. White-label Right
许可证允许改代码，不自动等于商标和品牌允许白标。6. Hosting Right
是否允许把软件托管给第三方使用并收费？7. Customer Credentials
你会不会替客户保存 OAuth、API key、邮件、数据库凭据？8. Data Responsibility
谁负责备份、删除、泄露、跨境、隐私？9. Maintenance
上游升级后你的 fork 怎么跟？10. Support
客户半夜挂了谁修？11. Unit Economics
收入减掉： 服务器 / 邮件 / API / 支付 / 客服 / 销售 / 维护 / 安全 / 退款 / 税 还剩多少？12. Demand
为什么用户不直接买官方云？这一问最重要。
开源项目真正适合哪几种商业模式
模式 A：Implementation Service
不卖 fork，卖部署、迁移、集成、培训和维护。这是很多工具最自然的商业化方式。
模式 B：Managed Vertical
用宽松许可的核心做一个真正垂直的产品，但用户付费的是行业流程、数据、模板、合规和服务，而不是“我帮你托管同一个 UI”。模式 C：Internal Tool + Service
把开源工具作为自己的交付基础设施，客户买的是结果。例如 n8n 官方许可就明确允许很多咨询和内部业务用途。
模式 D：Plugin / Integration
围绕生态做节点、插件、模板、数据连接，而不是复制整个产品。模式 E：Open-core Complement
给开源项目补它不会做的垂直工作流、审计、数据包和运营服务。为什么融资额不能证明你的模式
源文反复使用：
“融资了 X 亿，所以这个模式可行。”
这是典型的错误证据。
融资说明投资者愿意给那家公司资金，基于它的团队、增长、技术、市场和条款。
它不能证明：
你周末 fork 一份代码 → 下周会有人每月付你 200 美元。
同样： “创始人做到几百万年收入” 也不能直接证明“白标转售”是其成功原因。
要做 Demand Evidence：
Query → Pain → Alternative → Buyer Interview → Pilot → Paid → Retained → Contribution Margin。
一个更好的周末实验
如果你真的看中某个项目，不要先 fork。
周六上午： 找 10 个目标客户，问他们现有方案、成本、最烦的问题。
周六下午： 用原项目做一个只解决单一痛点的 demo。
周日： 给 3 个客户演示，问： “如果我负责部署、迁移、维护和这个行业专用功能，你愿意付多少钱？”
有真实付款/承诺，再决定是否二开。
否则你只是给 GitHub star 做了一个本地副本。
alphahole 的产品机会
这条非常适合产品化成：
Open-source Business Readiness Auditor
输入一个仓库，输出：
- License Risk
- Trademark
- SaaS/Network Obligation
- Commercial Restriction
- Security Surface
- Maintenance
- Buyer
- Existing Official Cloud
- Differentiation
- Unit Economics
- V3 Experiment
- Stop Rule
免费：License / Business Gate Checklist 低价：单仓库商业化审计报告 会员：许可证/版本/商业条款变化监控 高阶：开源产品商业化路线和风险审计
最后的判断
开源真正给你的，是：
更低的构建成本和更快的学习速度。
它没有免费送给你： 客户、品牌、托管权、商标权、售后、增长、利润。
所以真正值得收藏的不是“10 个能睡觉赚钱的 GitHub”。
而是这一句：
> 先证明你有权卖，再证明有人愿意买，最后才讨论 fork。