开发者如何从开放许可的软件中赚到钱？

清晰地认识开放式软件的资金、障碍和可能性，有助于开发者更容易地从开放许可的软件中赚到钱。

“但你过说我可以使用此软件”

如果你想借助开放的软件开发赚钱，有三个比较合适的选择：

1、选择一个开放的许可证，包含几类：完全开源、非商业化的、受限且关闭广告和商务内容的许可、或者是不限制销售条款的许可证。这也就是 License Zero。

2、选择一个宽松的许可证，并积极地将您的付费消息传递给那些不愿意付费的用户。我们所看到的 OpenCollective、Tidelift、托管、技术支持，等等就是这个模式。

3、不要再发布这么多软件，而是把多出来的时间花在社交网络和在线展示上，然后通过这些方式告诉每个受众，你提供的开放技术是需要付费才能获取的。这样一来，你就可以很容易地跨过盈亏平衡。

但很大的可能是，选择一个宽松的许可证，注册一个支付账户，注册一个融资平台，或者在 README 中提供许可证交易合同，诸如此类的这些方式都是行不通的。很少有人会忽视你的许可证而去关注付款信息，那些少数关注你的付款信息的人才是真正会付钱的用户。一段时间后，你会越来越失望，怨恨，而且在金钱上也会一无所获。

鱼与熊掌不可兼得。我们没有找到一个有效的解决方案，既不用强迫授权用户接受他们不喜欢的信息或改变，又能推出更多授权许可证的软件。我们也无法内部 100%开放代码而不用承担被追责的风险。

但实际上我也看到过例外，这个例外是非常特殊的。它们也被过度宣传，就像宣传乐透彩票中奖者一样。这个例子既作为软件项目，也是作为投资产出。机会留给有准备的人，但是一个让你走运的计划又不是一个你可以遵循的计划。

这是怎么回事呢?

失败的沟通

对于支付开放式软件开发者的最强烈的争论归结为公平和自身利益。用户应该付费，他们也应该愿意付费。毕竟，一个开放的许可证并不是一张脱离道德的免费卡。“实在的工作对应等值的报酬”这条黄金法则仍然适用，基本的公平也仍然适用。但是我们并没有在很多贡献者身上看到这些基本的公平。如果这些不公平的言论开始在贡献者当中四处传播，那么针对新颖而又有趣的软件，用户就更难获得宽松的许可证。

最有力的反驳是“但你说过我可以使用”。“实在的工作可以换取等值的报酬”本来也应该是普适的规则，但是开放的开发人员曾经对他们实际上所做的工作授权过使用许可证，明确地放弃了等值交换中的报酬部分。这好比说，邀请乘客免费乘车，然后又因为乘客不付钱而叫屈，这也是不公平的。如果所有授权使用许可证的软件开发人员都开始迫切地要求归还报酬，用户也会不太愿意欣然使用获得开发者许可证的工作成果。

结合常理来看，失败的沟通将同时反映在几个层面上。

许可证并不能表达许多开发人员的全部情况，这也不是许可证出现的初心。许多开发者选择了 MIT、BSD 或 Apache，允许他们的代码最大程度地被采用，因为他们已经了解了这些开发语言的代码可以走多远，他们不希望在这种方面受到限制。但是标准化的许可证并没有为开发者提供一个填写他们需求的地方，包括他们是否需要一份工作、是否需要捐赠、或者是否需要销售产品或服务来继续他们的工作。用户会继续假设以上这些开发者都不需要，因为开发者都不需要的话对用户来说是最好的，他们宁愿不考虑这些。

当开发人员在其他地方表达他们的需求时，比如在 README、项目网站或文档中，他们依赖的消息传播渠道的可靠性要低得多。许可证是 TCP，用户需要知道他们拥有正确的许可证条款。因此，平台、软件包管理器、创建工具和其他工具都在努力工作，以确保许可证消息通过。其他的都是 UDP，一些用户可以通过它满足特殊需求，但这不是使用软件的必要条件。

要使用您在网上找到的代码，许可证信息实际上是必要的，也是充分的。而开发商的融资模式广告则既不必要也不充分。

如何博关注又不被反感

信息传递主要有几种形式：开发者强制用户看的比较突出的信息，比如广告；用户被强制去搜寻的信息，比如许可证条款；以及属于用户自愿观看的信息，或用户偶然看到的信息，像 README 提示里面的。

OpenCollective 消息、core-js 的 postinstall 和 Feross 的 funding 强制给用户发消息，像贡献门户、维护人员信息或赞助商的广告一样。通常，降低广告干扰比较常见的做法是要求开发者将广告放在 README 或其他不起眼的位置上。也就是说，用户希望这些信息成为无效的广告。

License Zero 启动了许可证条款。用户必须验证许可证条款，如果他们在可见的许可证条款中没有找到他们想要的，他们就会被提示去更深入地寻找可用的付费许可证。命令行界面能够将查找、获取和操作该信息的过程自动化。

几个月前，我为 npm package.json 文件创造了一个 sustainability field，调用资金行为的数据对 JSON 端点进行编码。但这种标准的结果是非常狭隘的。

标准化的资金元数据将使得在企业中（那些决定资助开发者编制相关数据的企业）的开发者们稍微容易一些。无论用户是否决定付费，总体来说，它几乎不会引起用户对资金需求的关注。

我最近向我的 PR 提交了委托，要求在开始安装 npm 时自动报告资金需求。用户将收到所有与他们选择的服务相关的资金需求的报告，以及已安装软件包的摘要和任何已知的安全漏洞。与其监督安装后脚本打印出什么，不如将注意力保留到安装生命周期的结尾，并规范其内容呈现的形式。

借助赞助商的影响力

我越来越多地听到一种新的值得提及的新方法。但据我所知，在很大程度上仍是理论上的。从本质上说，我们现在做的思考有点本末倒置了，与其担心如何把你的请求、商品或目标摆在人们面前，不如先抓住用户的眼球，然后再从这些用户关注点上获取资金。关于这点的应用，twitch.tv 是一个很好的例子。

我觉得这个角度很有趣，我想，很大程度上是因为这个角度很新颖，至少在软件领域是这样。我们已经看到了从捐赠模式向赞助模式的演变，开始在 README 和项目网站上出现了 LOGO 字段，特别是通过 OpenCollective 和 Patreon 宣传赞助商。我们可能还会看到开发者穿着赞助商的 T 恤，在他们的 GitHub 简介中添加赞助商的资质，以更系统的方式在项目中分发赠品。

这意味着软件在模仿其他领域，而不是一种新的软件创新。以飙车为例，许多业余骑手喜欢在他们的摩托车上添加来自知名零件制造商和其他供应商的贴纸。随着时间的推移，成功的本地赛车手会得到小规模的赞助，通常还会有折扣和特定时间段的免费配件。从那时开始，顶级的赛车赛事为厂商车队吸引了职业的商业合作伙伴，并在任何相机有可能捕捉到画面的时候佩戴许多商标。在最高级别的赛事中，赞助商的业务与赛事根本没有任何直接联系。比如 Repsol 是一家石油公司，Red Bull 和 Monster Energy 是制造饮料的，但他们都是 2020 年摩托车大奖赛的赞助商。

如果突出强调软件的特性，这就会看着是在制造开放软件，实则是在销售其他东西的同质化陷阱中。吸引眼球和开发优秀的软件需要不同的技能，往往需要突出不同的特性，而且存在不可避免的相互竞争。用赞助商的话来说就是——软件生产只是赞助商主线业务的副产品或催化剂。最受欢迎的游戏主播很少是最好的游戏玩家，更别说游戏设计师了。

现实意义

最后，我们做改变的起点必须是对当前状态的清晰评估。独立开发者通过开发开放软件而获得丰厚的收入并不是一种常态。目前，制度政策、社会规范和惯例都与这一结果背道而驰。几率这么低，战胜几率意味着改变几率。想在开发者-用户关系方面尝试新想法的独立开发者可能会遭到抨击。但他们仍然需要坚持下去，无论结果是积极的还是消极的，因为这不仅有助于提高他们的个人收入，也能为改善所有开发者对此问题的认知水平。

原文链接：

https://blog.licensezero.com/2019/08/26/but-you-said.html