在不妥协的情况下资助开源软件

# 资助开源软件而不损害其本质 来源：https://yorickpeterse.com/articles/funding-open-source-software-without-compromising-it/ 2026年7月6日 资助开源软件是一项挑战，尤其是对于那些尚未建立庞大社区的项目。尽管存在各种方式，但它们都有各自的缺点。例如，请求捐款是迄今为止最常用的方式，但效果也最差：你可以请求（几乎等同于乞求）捐款多年，但*或许*你每月能收到10美元。[Heartbleed](https://en.wikipedia.org/wiki/Heartbleed) 可能是最广为人知的漏洞，它突显了重要但长期资金不足的开源软件项目所面临的问题。 其他替代方案往往会在某种程度上损害项目。例如，创办某种副业（比如一个使用该项目本身的业务）意味着你现在必须平衡两份工作：你*想*做的开源项目，以及原本应该用来支付账单的商业产品。 另一种选择是走开放核心路线：项目本身是专有的，但存在一个功能集缩减的开源分支，试图诱使用户使用（并付费购买）专有版本。[GitLab](https://about.gitlab.com/) 就是这样一个项目/公司的例子。虽然这也能奏效，但几乎总是会以某种方式损害开源版本，比如以前存在于开源版本中的功能被改为专有，因为某个首席XX官认为这最符合股东……呃，我是说社区的利益，当然是！ 此外还有软件资助，例如 [NLnet](https://nlnet.nl/) 提供的那些。这些本质上相当于（较大额的）捐款，但有额外的要求和限制。不幸的是，这些资助通常有两种形式： 1. 仅对现有大型项目开放的资助 2. 带有高度特定要求的资助，例如你需要是特定国家/地区的居民 NLnet *曾经*是个例外，但近年来这种情况也发生了变化，如今的要求不幸地排除了许多项目。[Sovereign Tech Agency](https://www.sovereign.tech/) 是我所知道的唯一一个*确实*（不确定现在是否仍然）向尚未立足的项目提供资助的机构，但限制条件是你必须位于德国才能申请。[FUTO](https://futo.tech/) 看起来是一个有希望的替代方案，直到我发现[这个组织充其量是有问题的](https://drewdevault.com/blog/Whats-up-with-FUTO/)（我这已经是在尽量客气了），而且我不想与它有任何关联。 那么，我为什么还要老调重弹（[打死马](https://en.wikipedia.org/wiki/Flogging_a_dead_horse)）“开源资助很困难”呢？嗯，因为过去一年左右的时间里，我一直在更积极地思考如何为 [Inko](https://inko-lang.org/) 的长期发展提供资金，同时又不以某种方式损害项目。 *仅仅*依赖捐款，我认为从长远来看行不通，因为这在提供稳定收入方面不够可靠。这个月你可能幸运地收到500美元，而下个月所有人都取消了捐款，只因为你说你不介意[菠萝披萨](https://en.wikipedia.org/wiki/Pineapple_on_pizza)。我深入研究过资助，但目前没有（据我所知）任何资助项目会接受 Inko。这就引出了我关于经营副业的想法。 理论上，我喜欢经营企业的想法：没有经理在你背后盯着，没有拿着高薪却只会把数字在电子表格间挪来挪去的总监（而且他们的薪水竟然是公司最重要开发者的10倍），没有“你必须使用AI，否则就被解雇”之类的废话。当然也有挑战，比如你必须*自己*做*所有事情*，而且销售很难，尤其是像这样我倾向于低估自己工作价值的人。 不过，我有一个重要的要求：无论产品是什么，它*必须*是开源的。不是像开放核心那样的“开源”，而是真正意义上的开源。这不仅仅是哲学或政治立场，也是实际考量：我在 GitLab 工作了相当长一段时间，将一个产品拆分成专有版本和开源分支（类似于分支）会引入各种技术挑战，我不想再处理这些了。 这就引出了我想到的一个主意，一个可能行不通，但我觉得还是值得分享的主意；至少值得写下来，这样我就能把它从脑海里清空。 这个想法很简单：产品是开源的，采用像 AGPL 这样的严格许可证，并可选地采用商业许可双重授权，面向那些对 AGPL 过敏但*却*愿意为商业许可付费的公司。源代码存在于两个仓库中：一个私有仓库（所有开发都在此进行）和一个公共镜像。 公共镜像只定期更新（例如每三个月一次），除非有需要额外更新的情况（例如关键安全漏洞，此时延迟三个月不道德）。 私有仓库也是错误追踪器的所在地，用户可以在这里提交补丁（假设你愿意接受的话）。访问私有仓库需要用户以某种方式积极资助项目，例如捐款或获取商业许可。 关键的是，要获得私有仓库的访问权限，你必须“签署”（例如，这可以只是一个“我同意这些条款”的复选框）某种协议，该协议规定：*如果*你公开托管私有仓库的副本，你对私有仓库的访问权限将被撤销。 这个想法是：软件*确实是*真正开源的，并且*如果你*拥有源代码副本，你几乎可以随心所欲地使用它，只要满足开源许可证的要求，但*访问**上游仓库* 的权限仅限于拥有有效订阅的用户。如果你不想付费，并且可以接受更新延迟三个月左右，那么你可以使用延迟更新的公共镜像。 除了引导用户向项目维护者付费外，要求用户付费才能提交工单（包括错误报告）理论上也能提高这些报告的质量，因为那些连问题表单都懒得认真填写的人，很可能也懒得为了获得问题追踪器的访问权限而付钱。 当然，这种方法并非没有自身的问题。例如，将整个问题追踪器置于付费要求之后，也意味着那些负担不起订阅费用的善意用户将无法提交任何工单。第二个问题是，我怀疑如果延迟时间足够短，大多数用户会接受使用延迟镜像，但如果延迟时间太长，他们可能根本不会使用该项目。这意味着付费用户的数量很可能仍然非常低。 还有一个技术挑战：必须将仓库与某种支付系统集成，尽管在项目存在的最初几年，考虑到订阅者数量很可能保持较低水平（直到项目以某种方式站稳脚跟），这或许可以手动完成。使用 GitHub Sponsors 会让事情稍微容易些，因为你可以自动授予赞助者对私有仓库的访问权限，但这要求 GitHub *又*没有宕机。 可能剩下的最大挑战是，你仍然需要某种人们愿意为之付费的额外商业创意。例如，这种模式对 Inko 本身不起作用，因为为编程语言付费是如今开发者或公司不愿意做的事情。这意味着不幸的是，你仍然必须以某种方式损害项目：将你的一部分时间和资源投入到*另一个*最终用来支付账单的项目上。 现在，如果我能想出一个*不*需要数百万风险投资资金就能启动的商业模式，那么也许我可以尝试上述想法，看看它在实践中效果如何。如果这行不通，我想是时候开始卖我的脚部照片了。