做免费软件和开源项目的人，大概都收到过很多这样的反馈：「真的很好用，感谢大佬！」然后呢？然后就没有然后了。点赞的人很多，捐助的人很少，提需求的人倒是源源不断。这篇文章想聊聊这种「为爱发电」的无奈——它很好用，但我不一定捐助支持，以及它背后更现实的两个问题：免费的东西到底靠什么活下来，而面对它，我们又该不该出手。
一、两个小项目的真实困境：它很好用，但你不一定捐
先从我最近看到的一段聊天记录说起。清风输入法是一款提供 Linux、macOS、Windows 三端统一体验的输入法，主打本地词库、不联网、不收集隐私。在一个用户群里，有位用户分享了自己的使用感受：
「QQ输入法停更好几年了，一直没找到适合的输入法，搜狗、百度、手心，包括后来各家新出的输入法都不行。万万没想到，被一个不联网的输入法吸引了，目前已经正式使用了1天多，感觉非常顺手。而且清风默认的词库就比较清爽，导入我的QQ输入法用户词库后更是起飞，感觉比用了多年的QQ输入法都要顺手。」
夸得很真诚。群里另一位用户顺口问了一句：「那你给作者捐点没？」接下来的回答，可以说是整个免费软件困境的浓缩：
「没有，目前还处于试用期，转正了也不一定捐。」后面还跟着一个笑脸。我没有任何指责这位用户的意思——他的夸奖是真心的，试用期没结束不想捐也合乎他自己的逻辑。但这两张截图放在一起，恰好就是绝大多数免费应用作者每天面对的现实：价值被认可了，价值却变不成支撑开发持续下去的资源。
再说说我自己。微微CMS 是一款不开源、但免费的建站系统，几年下来也收到过不少类似的评价：
「vvcms真的挺不错，速度快，不臃肿。」另一张图则是日常的另一半：
用户建议支持一个简单商城，不要求支付中台，只要多SKU统一结算，最后补了一句「如果只是搞搞博客企业站，完全没前途的」。每一条需求单拎出来都合理，但实现每一个都要耗费大量精力，做完之后真正用到的用户可能不到一成。免费软件最难的地方就在这里：你说「不」，显得傲慢；你说「好」，就是给自己的待办清单上加了一座山，而山上没有工资。一个夸它的人，和一个拼命提需求的人，常常是同一个用户。
二、免费软件的商业化，到底有几种活法
那么问题来了：既然捐助撑不起开发，免费软件到底靠什么活？答案并不浪漫。摆在每一个免费应用作者面前的变现路径，其实就那么几条，而且每一条都有代价。
广告弹窗：最稳，也最伤
把一个免费工具装上后，开机弹窗、右下角资讯、捆绑安装——这是早年很多桌面软件的活法，迅雷、各类优化管家都曾在这条路上走得很远。收入稳定，但代价是口碑：用户一边用一边骂，骂着骂着就卸了。更有甚者，为了变现把产品做歪，原本清爽的工具塞满商业化模块，最后连作者自己都认不出它。广告模型的问题不是「不道德」，而是它和用户利益天然对立：广告越多，体验越差，愿意留下来的人越少。
云端训练：用你的数据当燃料
另一种更隐蔽的变现叫「云端训练」。像搜狗、百度这类输入法，免费背后是用你每天敲下的每一个字去训练个性化词库和模型——你的输入习惯就是它们的燃料。这未必是坏事，很多人确实换来了更聪明的联想，但它本质上拿用户数据换了服务。清风输入法偏偏选了相反的路：本地词库、不联网、不收集隐私。它因此「清爽」，也因此它失去了这条最顺手的变现通道。一个不收集数据的免费输入法，靠什么赚钱？几乎只能靠你主动的那句「我捐」。这恰恰是它最尴尬的地方——它把隐私还给了你，却把自己的饭碗让了出去。
open-core、订阅与周边：体面，但门槛高
还有几条相对体面的路。其一是「开源核心、商业增值」的 open-core 模式，基础功能免费，企业级功能、支持、托管收费，Redis、Elasticsearch 都走过这条路；其二是服务和订阅，像 Red Hat 那样卖的是「有人替你兜底」的安心；其三是付费周边和课程，tailwindcss 的作者 Adam Wathan 就是把框架免费、靠配套 UI 组件和教程赚钱，再反哺开源；Vue.js 的作者尤雨溪则通过赞助公司化，带着一小队人全职维护；SQLite 靠企业 consortium 供养，Let's Encrypt 靠 ISRG 的赞助机构提供免费证书——这些都不是「靠爱发电」，而是把爱变成了合同。
赞助：最理想，也最脆弱
最直接的一种是赞助，GitHub Sponsors、爱发电、Patreon，靠愿意付费的用户养着。理想很美，现实很骨感。据 Tidelift 2023 年对开源维护者的调查，60% 的维护者自认为「无酬的爱好者」，而在这群没拿到钱的人里，高达 77% 其实希望被付费——所谓「大家就是图个乐子才做开源」是个彻头彻尾的误会。更扎心的是，很多维护者即便开通了赞助，每月收到的钱也只够买一杯咖啡。赞助能续命，却几乎从没能让人过上体面的生活。
三、为爱发电的两难：有本质工作，却没收入
这就引出了为爱发电最难的那个结：两难。几乎每个个人项目的作者，都还有一份「本质工作」——白天上班、写代码、开会、还房贷；下班后剩下的那点精力，大部分又填进了开源和需求里。全职做吧，没有收入，社保医保自己扛，下个月房租从哪来；兼职做吧，没有时间，issue 越堆越高，用户的「+1」越攒越多，你看着心里发慌却腾不出手。开源占用了他绝大部分的业余时间，而全职又意味着没有收入——两头都够不着，这就是为爱发电最真实的艰难。
更残酷的是「巴士系数」（bus factor）。据同一份 Tidelift 调查，44% 的开源项目只有一个人维护——行业里叫 bus factor of 1：只要这个人病一场、离职、或者 simply 累了，项目说没就没。没有团队兜底，没有交接文档，没有接班人。你以为用的是一款成熟产品，背后可能只是一个人在用业余时间硬扛。Tidelift 的 Donald Fischer 还提出过一个更贴切的词叫「老板系数」（boss factor）：很多人不是被累垮的，而是换了份新工作、有了新老板，便再没时间碰自己的开源项目，于是项目悄悄荒掉。这恰好印证了那句最现实的话——真正能杀死一个开源项目的，往往不是用户的冷漠，而是维护者自己的生活变了。
于是倦怠几乎是注定的。调查显示 36% 的维护者认真考虑过退出，22% 已经真的退出了；ITPro 2023 年的研究更指出，高达 73% 的开发者正处于职业倦怠中，其中开源维护者占了很大比例。他们倦怠，不只是因为没钱，更因为「明明在做一件对全世界都有用的事，却没人觉得该为它买单」。
四、大项目也救不了自己
如果你觉得「小项目没人捐也就罢了，大项目总该有钱吧」，那可能是对开源世界最大的误解。开源已经赢了——今天全球 96% 的代码库都包含开源组件，平均 76% 的代码本身就是开源的（Synopsys 2023 开源安全报告）。但开源的作者，并没有赢。下面这些名字，你几乎每天都在用，它们的故事一个比一个心酸。
OpenSSH / OpenBSD：差点因为几千美元停摆
OpenSSH 保护着全球大半服务器的远程登录，它和所在的 OpenBSD 由志愿者「到处找赞助」维护了二十多年。2014 年，OpenBSD 基金会账上只剩几个月的运营费，连电费和开发者聚会的差旅都快付不起——全网最关键的安全基础设施，差点因为几千美元的缺口停摆。后来靠一次社区募捐勉强续命，但这种「命悬一线」的状态，二十年来从未真正远离过它。
wangEditor：一个人维护到 burnout
国内开发者熟悉的 wangEditor，曾是使用最广的开源富文本编辑器之一，作者一个人维护多年，2023 年宣布停止维护，理由朴素得让人难过：没有收益，精力有限。仓库里堆积的需求和一长串「+1」，从此再没有人处理。一个被无数公司用在产品里的编辑器，它的终点不是被收购，而是被默默地关上灯。
core-js：全球互联网跑在他代码上，他却养不起自己
core-js 更极端。几乎所有现代 JavaScript 项目都依赖它，周下载量以千万计，作者 Denis Pushkarev 常年一人维护，收入全靠捐助且远低于正常工资。他曾在文档里直言自己接近 burnout，也放过的筹款横幅被社区抱怨「广告太多」。全世界互联网都在跑他写的代码，而他连全职维护自己的项目都做不到——这是开源世界最荒诞也最真实的画面。
faker.js / colors.js：最激烈的一次抗议
2022 年的 faker.js 和 colors.js 事件，把窗户纸彻底捅破。作者 Marak 让两个被无数项目依赖的库开始输出乱码和死循环，只想要一笔六位数年薪，否则不再碰开源。没有人赞成这种破坏行为，但很多人承认，他只是用最激烈的方式说出了那句没人愿意明说的话：用爱发电是发不久的，而靠愤怒讨来的关注，终究不是可持续的商业模式。
log4j：漏洞爆发时，维护者是志愿者
2021 年底 Log4Shell 爆发时，log4j 的维护者们第一时间被全世界的运维催着修复。他们后来在社交媒体上说的那句话让很多人愣了一下：我们是没有报酬的志愿者，用业余时间维护着全球无数系统都在用的基础库。一个由志愿者维护的组件出了安全漏洞，损失和压力由整个互联网分摊，成本却只压在那一两个人身上。
left-pad：11 行代码，一个人，拖垮半个前端世界
最戏剧性的例子是 2016 年的 left-pad 事件。开发者 Azer Koçulu 因为一个包名纠纷，一气之下从 npm 撤下了自己账户里的 273 个包，其中一个只有 11 行代码的字符串补位小工具，恰好被 Babel、React 等无数项目间接依赖。结果一夜之间，成千上万的构建纷纷报错，「差点搞崩了互联网」。这件事撕开了开源供应链最脆弱的底牌：一个你从没听过、只有 11 行代码、由一个人凭兴趣维护的模块，竟能卡住半个前端世界的脖子。而那个人，没有任何人付过他一分钱。
反例：那些走通了的
当然也有活下来的。除了前面提到的 tailwindcss、Vue、SQLite、Let's Encrypt，还有 Mozilla 用基金会模式养着 Firefox，Blender 靠动画基金会让一款免费 3D 软件活成了行业标准。它们的共同点不是「作者更努力」，而是早早把「靠爱发电」换成了「靠组织、靠合同、靠生态」——这恰恰说明，纯靠热情和捐助，本来就不该是一个关键基础设施该有的活法。
五、为什么我们总是不捐？「免费乘客」困境
把视角转回用户这边。既然作者这么惨，为什么我们还是不捐？这背后是一套很古老的心理机制，经济学里叫「搭便车困境」（free-rider problem）：一项公共好处只要别人也在享受，理性个体就有动机自己不出力，反正「我不捐，总有人捐」。放到开源上，就是「这个库这么多人用，作者不差我这几个钱」——可每个人都这么想，结果就是没人捐。
还有「旁观者效应」的变体：issue 区里一百个人点「+1」，没人觉得自己那一份很重要；以及一种微妙的心理错位——因为免费，所以「理所当然」，一旦作者提钱，反而觉得对方「变了、不纯粹了」。企业则把这种外部化做到极致：用着免费的开源组件赚得盆满钵满，却把维护成本悄然甩回给那一个志愿者。开源赢了，账单却寄在了一个最没议价能力的人手上。
六、该不该出手？我的分情况答案
所以回到那个问题：该不该出手捐赠？我的答案不是道德绑架，而是一句分情况的话。
如果你是学生、刚毕业、手头紧，不捐完全没问题，没人有资格道德审判你。但如果你把某个开源项目用在了工作上、靠它赚了钱、或者它只是你公司技术栈里一个看不见的依赖，那一点点赞助就不是「施舍」，而是你本来就该付、却被免费掩盖掉的成本。对普通用户，五块钱、一杯奶茶钱、甚至只是在 issue 里认真写一句「谢谢，帮了我大忙」，都是真实有效的正反馈——维护者最怕的从来不是穷，是「我做的事情好像没人需要」。
对公司，尤其那些靠开源盈利的公司，赞助你依赖的项目不是善良，是风险管控；log4j 的教训早就写在那里：你赖以为生的地基如果塌了，没人会先来救你。捐不捐是自由，但在多数商用场景里，「该不该」的答案是肯定的——而且比起事后救火，平时那点赞助便宜得可笑。
七、给作者：在烧干之前，先想清楚活法
最后，想对同行说几句实在话。为爱发电之所以难，是因为它要求你既要当产品经理、又要当客服、又要当运维，还要倒贴钱，而且没有下班时间。能做的自救其实有迹可循：趁早设边界，学会说「不」，不是每条需求都接；把项目「公司化」或「基金会化」，让收入从一个人扛变成一份合同（Sentry、HashiCorp、MongoDB 都走过这条路）；接受「老板系数」的现实，别把个人生活押在业余时间上；找雇主资助、找 Tidelift 这类平台、找愿意为依赖付费的客户。
但最重要的只有一句：把项目当植物养——按时浇水就好，别把它养成必须日夜照看的事业，更别把自己烧干。免费不等于廉价，更不等于该被白嫖；它只是把账单，悄悄寄到了另一个人手上。而那个人，今天可能还在用业余时间，为你敲着下一行代码。