开源不是商业模式：五条收入路径与一张 1,949 美元的收入表

4,200 个 star 不会自动变成 4,200 美元。

一、4,200 个 star 与一张 1,949 美元的月表

许砚的仓库叫 syncwell，一个把本地目录同步到对象存储的命令行工具。2026 年 10 月，仓库有 4,200 个 star、月下载 18,000 次，配套的托管服务有 180 个付费账号。他把当月收入打印出来贴在显示器边上：托管服务 1,620 美元，个人赞助 129 美元，企业赞助 200 美元，合计 1,949 美元。

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

这张表最容易被误读的地方，是把它当成「开源赚到的钱」。它其实是「一个开源项目加一个闭源服务」的收入结构：1,620 ÷ 1,949 = 83.1% 来自托管，329 ÷ 1,949 = 16.9% 来自赞助。前者卖的是「不用自己运维」，后者买的是「这件事值得继续存在」；两者混在一起看，就会得出「star 越多收入越高」的错误结论。

更麻烦的是分母。同一个月里，他花在仓库与托管上的时间是 51 小时：issue 分类 17.5 小时、PR 评审 8 小时、依赖与安全 6.2 小时、发版 4.8 小时、文档 7.7 小时、社区问答 5.2 小时、商务 1.7 小时。七个数字相加是 51，乘以 12 是 612 小时。把 1,949 美元除以 51 小时，毛时薪是 38.2 美元；扣掉服务器、邮件与支付通道费 309.8 美元之后，净时薪是 32.1 美元。

开源不是商业模式，它是一个分发方式。 分发方式决定谁看得见你，商业模式决定谁付钱、为什么付、付多久。把两者当成一件事，最常见的后果是：star 涨了，收入没动，维护时间却按比例涨。

2026 年的三个月可以说明这个错位。3 月仓库被一个技术周刊收录，star 从 3,100 涨到 3,900，当月赞助只多了 2 人；6 月他在文档里加了一页「什么时候该用托管版」，付费账号从 142 涨到 171，star 几乎没动。两次变化的方向相反，说明 star 与收入由两套机制驱动。

这一年里，18,000 次下载只转化出 180 个付费账号，转化率 1.0%；4,200 个 star 只转化出 23 个个人赞助，转化率 0.55%。两个数字都低得让人不舒服，但它们才是可以拿来排期的基数——你可以决定把下个月的 20 小时投在下载页还是赞助页，但不能决定 star 什么时候涨。

下载数据还有一层结构：18,000 次里，macOS 与 Linux 合计占 71%，Windows 占 24%，容器镜像拉取占 5%。前两类用户更可能自己运维，也更可能只 star 不付费；托管付费账号里，Windows 用户却占 46%。如果只看总量，会误判「谁在付钱」。

二、五条收入路径：谁在付钱，为什么付

开源项目能收钱的地方不多，但每一处都对应一个具体的付款人。把这一年的流水按付款人分组，得到五条路径；五条路径里只有两条当月有收入，另外三条是「有入口但没有持续流水」。

托管服务是唯一按月复购的路径，也是唯一能预测下个月现金流的路径。它的定价逻辑不是「代码值多少钱」，而是「替客户省下多少运维时间」：180 个账号、每人每月 9 美元，换算成一年 19,440 美元，正好覆盖一台中型服务器加一个人的零散值班。

9 美元这个价格有三个参照：一台云主机的月费、一份同类托管服务的起步价，以及用户自己搭一套 cron 加监控的周末成本。前两个是市场锚点，第三个是心理锚点；当用户算出「自己搭要花半天」时，9 美元就不再需要解释。

个人赞助的 129 美元由 23 个人构成：12 人付 3 美元，8 人付 6 美元，3 人付 15 美元，36 + 48 + 45 = 129。这个结构说明一件事：赞助档位的分布是长尾，中位数落在 6 美元，而不是最高档。把档位设计成 25、50、100 美元，看起来很专业，实际会把绝大多数愿意付 3 美元的人挡在门外。

3 美元档还有一个隐性作用：它让赞助变成一件可以被重复的小事。一个人这个月付了 3 美元，下个月取消的心理成本很低，但继续付的心理成本同样低；实际数据是，3 美元档的年留存率 78%，高于 15 美元档的 67%。

企业赞助的 200 美元来自两家公司，各 100 美元。它们的动机和个人不同：个人买的是「我用得上」，公司买的是「我的工程师在用，出问题我要能找到人」。所以企业赞助页必须写清两件事：能不能开发票，以及赞助是否包含支持义务。不写清楚，第一封邮件就会变成工单。

两家企业赞助都选择了年付，一次性 1,200 美元。年付的原因不是折扣，是审批：月付 100 美元在很多公司要走「订阅采购」，年付 1,200 美元可以走「小额采购」，后者通常少两道签字。

双许可与支持咨询当月都是 0，但前者本年成交两家、合计 4,800 美元，后者一单没接。这个对比值得记住：有明确报价与合同的路径，即使低频也能成交；只有「欢迎咨询」四个字的路径，一年也不会有一次。 第 8 篇会把双许可的九家询价拆开讲。

「有入口但没有流水」通常有三种原因：没有价格（对方不知道预算）、没有合同（法务无法审）、没有边界（你不知道要承诺什么）。三者里最容易补的是价格，最难补的是边界；第 8 篇会把边界写成三条。

三、一小时的两种算法：38.2 与 32.1

同一份收入，配上不同的成本口径，会得到两个都能用、但不能混用的时薪。毛口径回答「这个项目每分钟产生多少收入」，净口径回答「扣掉直接成本之后还剩多少」，年度口径回答「这件事占掉你多少产能」。

309.8 美元的成本由三项构成：服务器与对象存储 210 美元、邮件与监控 35 美元、支付通道费按托管收入的 4% 计 64.8 美元。赞助没有平台费，这是教学假设；如果你用的平台抽成，把它加进这一项，净时薪会再降一点。

成本还有季节性。服务器费用在每年 11 月与 12 月会涨 18% 左右，因为用户的同步频率上升；支付通道费随收入线性变化，不构成风险；邮件与监控是固定项，可以按年付压低 15%。三项里只有第一项需要提前在现金流里留位置。

612 小时占全年 1,920 小时的 31.9%，接近三分之一。这个比例比时薪更重要：它意味着你不只是在「顺便维护一个开源项目」，而是把三分之一的产能押在了一条月收入 1,949 美元的线上。如果这 612 小时拿去做别的，比如接两个小项目或做一个新产品的 MVP，收入未必更低。

换个读法：31.9% 的产能换来 1,949 美元月收入，相当于每 1% 产能换 61 美元/月。这个比值可以用来和别的项目比：如果你的另一个产品每 1% 产能能换 200 美元/月，把时间挪过去就是理性的，即使那个产品没有 star。

时薪低不低，要和替代用途比，不要和工资比。 32.1 美元/h 看起来不高，但如果这 612 小时本来会花在刷信息流和无效社交上，它就是净增量；如果它挤掉了每周两天的产品开发，那它就是在用最贵的时间换最便宜的钱。

还有一层没有算进去：这 612 小时里，有 210 小时是 issue 分类，属于「不做就会积累」的工作。它不像功能开发那样有明确产出，却决定了别人愿不愿意继续用。把它算成零成本，是开源项目最常见的自欺。

issue 分类还有复利效应：今年回的 1,180 个问题里，有 132 个最后变成了文档条目；文档越全，明年的重复问题越少。这条曲线不会在一年内显现，但第三年会出现明显差别——同样规模的项目，有文档沉淀的 issue 增速通常低 20% 到 30%。

四、三个误判与一次复算

第一个误判是把 star 当线索。4,200 个 star 里有 23 个付费赞助，比例 0.55%；而 18,000 次下载里有 180 个付费账号，比例 1.0%。下载比 star 更接近「真的在用」，因为它需要一次主动安装。做增长实验时，优先改安装页与首次运行体验，而不是追 star。

star 的来源也需要拆。4,200 个里，约 1,100 个来自两次技术社区首页推荐，900 个来自一个精选列表，其余来自搜索与转发。前两类是一次性脉冲，不会重复；只有搜索与转发带来的 star 才有持续转化，占比不到一半。

第二个误判是把一次性赞助当月收入。赞助里有一部分是一次性打赏，第二个月不会重复。把 129 美元当成稳定的月度收入，会让年度预测多出 12 倍误差；正确做法是只把连续三个月都出现的赞助计入基线，其余记为一次性。

识别一次性赞助有个简单办法：看付款方式。年度一次性付款、备注里写「谢谢」、没有留下联系方式的，大概率不会重复；月度订阅且填了用途备注的，留存率明显更高。把两类分开统计，基线会稳定很多。

第三个误判是忽略维护时间的机会成本。612 小时里有 96 小时花在 148 个外部 PR 上，合并了 61 个，合并率 41.2%。未被合并的 87 个 PR 同样消耗了评审时间，它们不会带来收入，却会带来「这个项目还活着」的信号。这个信号有价值，但不能折算成美元。

复算：
托管：180 × 9 = 1,620/月
个人赞助：12×3 + 8×6 + 3×15 = 36 + 48 + 45 = 129/月（23 人）
企业赞助：2 × 100 = 200/月
收入：1,620 + 129 + 200 = 1,949/月；1,949 × 12 = 23,388/年
结构：1,620 ÷ 1,949 = 83.1%；129 ÷ 1,949 = 6.6%；200 ÷ 1,949 = 10.3%
成本：210 + 35 + (1,620 × 4% = 64.8) = 309.8/月
净收入：1,949 − 309.8 = 1,639.2/月；× 12 = 19,670.4/年
工时：612 ÷ 12 = 51 h/月；612 ÷ 1,920 = 31.9%
毛时薪：1,949 ÷ 51 = 38.2 美元/h
净时薪：1,639.2 ÷ 51 = 32.1 美元/h
转化：23 ÷ 4,200 = 0.55%；180 ÷ 18,000 = 1.0%

复算里最值得盯的是 309.8 这一行。它只占收入的 15.9%，却决定了净时薪比毛时薪低 6.1 美元；如果托管账号涨到 300 个而服务器不扩容，这一项会被摊薄，净时薪反而上升。

五、行动清单与复算验收

• 把上个月收入按「托管、个人赞助、企业赞助、双许可、支持」五栏列出，写出每栏金额。
• 标出哪几栏是月度复购、哪几栏是一次性，分别算年度基线。
• 把维护时间按 issue、PR、安全、发版、文档、问答、商务七类记满一周。
• 用七类时间乘以 12，得到年工时，再除以 1,920 得出产能占用。
• 用毛收入与净收入各算一次时薪，写下差额。
• 算清 star 到赞助、下载到付费两个转化率，不要混用。
• 把一次性赞助从基线里剔除，重算年度收入。
• 用净时薪和你的替代用途比一次，写下结论。

验收标准：任取一个月，都能说出五条路径各收多少、哪些会重复、这一小时净赚多少。

前四条是「把账记全」，后四条是「用账做决定」。如果只有一小时，先做第一条和第五条：没有五栏收入与两个时薪，后面所有讨论都是感觉。

清单里最容易被跳过的是第七条。一次性赞助在账上很好看，但它会让年度预测虚高；把它剔出去，剩下的才是可以拿去覆盖固定支出的钱。

使用边界与实操验收

五条路径不是并列选项。 托管服务是复购收入，赞助是信号收入，双许可是低频高单价，支持咨询是时间换钱。它们的时间投入与现金流形态完全不同，不能简单相加成一个「开源收入」。

1,949 美元是教学基线。 4,200 个 star、18,000 次下载与 180 个付费账号都取自本组统一口径，不代表任何真实项目的转化水平。换一个品类，比例会差一个量级。

时薪不是净利。 32.1 美元/h 没有扣税费、没有扣退款、没有扣你自己的社保与设备折旧，也没有扣这 612 小时的机会成本。它的用途是排序，不是报税。

star 不是资产。 star 不能变现、不能抵押、不能在项目停更后保留价值。它可以作为分发信号，但不能作为估值依据；把 star 写进商业计划书的那一刻，就开始自欺了。

不要用这套账去证明「开源值得做」。 它只能回答「这条路径现在赚多少、占多少产能」。值不值得，取决于你想用它换什么：用户、声誉、招聘、还是一条能养活自己的现金流。

关键参考与核验范围

• OSI 许可证目录 ：用于核对「开源」的许可证定义与清单，不用于推导本文的收入结构。
• SPDX License List ：用于核对依赖清单里的许可证标识符写法。
• Open Source Guides：获取资金 ：用于核对赞助、托管与咨询三类资金来源的组织方式。

以上链接于 2026-10-26 实测可公开访问；未核验版本、功能范围与政策更新。核验日期：2026-10-26。

范围上只讨论一个人的开源项目如何形成收入结构、如何计算时薪与产能占用，不讨论融资、估值、商业计划书与团队管理。

系列导航

• 下一篇：许可证选择：四个问题、214 个直接依赖与 12 个 copyleft
• 回到目录：一个人的开源产品：4,200 个 star、一百八十个付费与一年 612 小时的维护
• 相关阅读：开源仓库作为入口