软件，就像咖啡一样，过于人为地便宜，我们需要让它变得更贵。我有一个建议可以实现这一目标。
咖啡的成本
咖啡行业的詹姆斯·霍夫曼（James Hoffmann）——或许是咖啡界最有影响力的推广者——一直在努力宣传“咖啡需要更贵”。咖啡行业臭名昭著地剥削劳工。尽管独立咖啡馆的利润率相对较低，但关于供应链中劳动力剥削甚至奴隶制的可怕故事却层出不穷。
霍夫曼先生在一系列视频和访谈中指出，部分问题可以通过监管措施解决。制造商和政府对供应链政策的执行可以帮助发现并避免此类剥削。消费者也可以通过辨别来解决一部分问题，比如尝试购买公平贸易咖啡，避开有供应链问题的品牌。
然而，即使有完美的、普遍的、零成本的供应链完整性执行，消费者最终还是必须愿意支付更高的价格。支付工资比拥有奴隶要花费更多。
软件的价格
咖啡供应链的问题值得我们单独关注。我不是说开源维护者的问题与真正的童工相比同样严重，但原理是一样的。每家科技公司都大量使用免费的开源软件。
我不想直接说这是剥削。开源维护者面临着复杂的交易：如果你创建开源软件，找工作会更容易；如果你创建开源基础设施，可以从技术角度做出更可持续的项目架构选择，但在短期商业开发计划中可能难以证明其合理性；你可以与业界更广泛的群体合作；你可以建立个人品牌。
然而，最近的xz Utils / SSH后门丑闻清楚地表明，虽然交易可能不是完全单方面的，但它并不对等，可能会导致维护者自身和社会的重大不良后果。
要解决这个问题，开源软件需要变得更贵。
开源的一大吸引力在于其隐含的许可结构，这源于零前期成本和零边际成本。零前期成本意味着你可以试试看，许多公司的软件开发者没有权力开具采购订单，甚至没有小额公司信用卡。
如果你是一名软件工程师，需要为工作购买新的开发工具或库，获得批准可能是一场官僚主义的迷宫。这可能是可能的，但你可能会得到奇怪的眼神，很可能你的经理会说：“有没有免费的选择？”最糟糕的是，这可能根本不可能。
这有其道理。处理采购订单和报销请求很烦人，只有当你处理的功能模块足够大，对整个团队或更好的是整个组织都有价值时，才值得付出额外的努力。这意味着大部分购买决策由管理层或“架构师”做出，他们有权为更大规模的团队做决定。
当个别工程师需要解决问题时，他们会特别考虑开源库和工具，因为将其纳入拉取请求既快速又简单，而专有解决方案可能会繁琐且昂贵。
假设存在解决你问题的专有解决方案。在软件经济的基础设施领域，由于这个原因，来自操作系统提供商（如苹果、微软，或许还有亚马逊，如果你在云上）和开源开发者免费选项已经边缘化或彻底摧毁了小型商业选项。
如果零前期成本是一种减少文书工作的福利，那么零边际成本几乎是一个要求。开源维护者的一个永恒抱怨是，公司拿走我们的东西，将其构建到产品中，然后赚取数十亿美元，却不给我们任何回报。他们给我们一些版税似乎是公平的吧？他们暴利的一小部分？但一旦你意识到，个别开发者没有权力在公司卡上刷50美元购买工具，他们就更没有权力做出一个技术决策，将整个核心产品的知识产权束缚起来，将公司的一部分收入赠予第三方。从结构上看，这种情况永远不会发生。
尽管存在这些障碍，保持这些依赖项的维护确实需要资金。
已有的一些解决方案
已经有各种官方渠道正在帮助支持关键基础设施的维护。如果你在大公司工作，你可能应该有企业Tidelift订阅。也许可以问问你的雇主。
但他们也会承认，有很多项目Tidelift无法覆盖，没有官方的商业支持，短期内也没有实际提供支持的方法。个体维护者，像我自己，正在努力找出如何维持他们的项目，要么靠它们谋生，要么将它们融入我们的工作中。人们有Ko-Fi、Patreon，或者可能只是一个亚马逊愿望清单，让你偶尔能对维护工作说声“谢谢”。
最重要的是，他们没有转向靠维护工作谋生的途径。对于大多数维护者来说，Tidelift提供的报酬仅相当于业余爱好的水平，甚至设置它（以及GitHub赞助商等）也是一项巨大的麻烦。所以，即使从“没有收入”转变为“一点点副业收入”也可能因官僚主义而变得不切实际。
以我自己为例。如果你是一个名义上从我的基础设施工作中获益的开发者，那么你很可能也是开源社区的贡献者，甚至你对这个社区的贡献可能比我多，对我的职业生涯成功的贡献比我对你多。我可以要求你付费，但实际上，应该是你的雇主付费。
现在该怎么做：让付款变得更简单
如果我们只需要给开源维护者更多的钱，而且应该是雇主给，那么我们该怎么办？
让我们不要把它搞复杂。雇主应该直接给维护者钱。让我们称之为“JGMM”福利。
具体来说，每个雇佣软件工程师的公司应立即实施以下福利计划：每位软件工程师每月应有一笔50美元的预算，用于以他们认为合适的方式分配给任何开源依赖项开发者。Venmo、Patreon、PayPal、Kickstarter、GitHub Sponsors，无论哪种方式都可以。用公司卡支付，项目名称写在账单上，然后就忘了它。这只用于开源维护，但金额小到不需要严格审批。你可以凭荣誉制度来做这件事。
这保留了零前期成本。开始使用依赖项时，你仍然只需使用它。它还保留了零边际成本：你的开发者根据需求和流行程度选择要支持的依赖项。这是一个固定开销，不随收入或利润增长，只随员工人数增长。
因为这里的重点是要匹配大多数公司添加依赖项的简单、隐含、无流程、无控制的方式。支付这些小费应该比首先使用软件还要容易。
这种低于1%的人力成本开销将大大降低你使用的开源项目的风险。通过把决定权交给你的工程师，你会支持那些真正挣扎且高管们直到上了新闻才知道的项目。有些钱会流向你并未使用的项目，这些是你工程师觉得有趣、未来可能使用但目前还不依赖的项目，这也没关系。考虑这是一种极其便宜、高效的R&D支出。
许多开发者支持开源基础设施的选项已经是免税的，所以如果他们资助了像Python软件基金会的财政赞助项目这样的组织，可能会比普通业务开支更有税务优势。
我也强烈怀疑，如果你是第一个这样做的雇主，你可以从科技媒体那里获得一轮正面公关，并吸引工程师，所以，比赛开始了。我不算真正的“科技媒体”，但如果你的公司采取了这种方法，请告诉我，我会为你点赞。