Transcription
再试一次。大家好。>> 感谢，呃，感谢大家来参加这次关于开源的演讲。去年夏天我在 NDC 哥本哈根做过这个演讲的短版本，要在 15 分钟内讲完我想讲的所有内容，这确实是一个挑战。所以这次 NDC 给我一个完整时段，我非常感激。呃，在哥本哈根，呃，在哥本哈根，我实际上把这个演讲命名为“开源坏了，这是你的错！”。我忘了视频会上传到 YouTube。呃，当有人在 LinkedIn 上分享视频链接时，我鼓起勇气去 YouTube 看了大家留的评论，其中一条是“这是我的错。这些标题党纯属引人注目。”
所以，我完全接受建设性的批评。所以，对于他，上帝，我猜是个男的。我很抱歉。对于他们，呃，以及那 14 个点赞，欢迎来到更具包容性的欢迎。呃，“开源坏了，这是我们的错。” 没有感叹号。是的，你看，我可以接受批评。但无论它叫什么名字，呃，前提仍然是一样的。太多人从极少数未付费且过度劳累的个人的努力中获利。当这种责任的重担变得太重，他们开始倦怠时，正如不幸的是有些人已经倦怠一样，项目就会受到影响，而那些使用并依赖这些项目的人和公司就会意识到他们多么重视这些努力。我承认我不是在谈论所有的开源，而是一大部分。呃，YouTube 上的另一条评论来自一位维护者，他反对我说的“你必须，你需要”。我一定在视频里说了不少次。嗯，当然，我很抱歉。我可能只是因为我热衷的话题而情绪激动，充满热情。当然，呃，双方都没有义务。开源软件的维护者，那些在 MIT 许可下公开自己代码的人，没有任何义务去维护它，甚至去关心谁在使用它。但很多人确实在做。另一方面，那些消费开源软件的人，我称你们为消费者，那些使用并依赖开源软件的人，也没有任何义务。但这就是我们现在所处的局面。
所以今天我们将从一些知名的开源项目中学到东西。我们将看看维护者有哪些选择，并讨论我们消费者如何帮助纠正这种不平衡。我真的希望，如果我做得好的话，到这次演讲结束时，你将重新思考你对开源依赖的看法，因为我真的不预测开源的终结。嗯，远非如此。我是一个巨大的粉丝。呃，开源在我们世界的创新中是相当基础的。呃，它几乎无处不在，从内核到你的手机，Linux，这是显而易见的，为从云到移动的一切提供动力。呃，Git、Kubernetes、Firefox，呃，WordPress，据报道它运行着世界上大约 43% 的网站。当然，还有其他开源的 CMS 可供选择。呃，例如，这个是 Braco。呃，如果你没听说过，它是免费的。它是 MIT 许可的 .NET CMS 平台。它由一个具有商业可行性的可持续业务支持。呃，收入来源来自托管插件、培训支持。这张照片里的每个人都在围绕一个 CMS 产品工作的公司里谋生。这意味着使用核心 CMS 的人不需要花一分钱。如果你还没注意到我，我在这里。如果你之前听过我的演讲，我刚刚划掉了我的老板 Emma，她是在台上谈论 AI 的那个人。我去年在 NDC London 参加了 David Whitney 关于开源的精彩演讲，他当时说“我绝不会希望一个成功的开源项目落到任何人头上”，我感到震惊。我之所以震惊，是因为对我来说，成功的开源看起来就像我工作的 Embraco 公司，我现在是开发者关系主管。我花了十年时间作为社区贡献者为 Embraco 做贡献，然后我把它变成了我的全职工作。我是少数能靠开源谋生的人之一。但当然，David Whitney 说这句话时并不是在谈论像 Embraco 这样的公司项目。他想到的是那些由一两个人业余时间维护，却被世界各地的开发团队和公司依赖的项目。
哇，我们经历了一些备受瞩目的事件，凸显了这些依赖的程度。我环顾四周。我想你们大多数人都足够大，还记得 2014 年的 heartbeat blog 博客，它影响了 OpenSSL，一个在整个网络中使用的核心加密库。呃，它由一个小团队维护多年，资金非常少。我想在漏洞出现之前，他们每年能收到 2000 美元的捐款，漏洞出现后，每年能收到 9000 美元。呃，他们估计的成本，你可以判断这些东西的成本。据估计，该漏洞的成本高达 5 亿美元。呃，一个典型的例子是，万亿美元的产业依赖于几个报酬过低的志愿者。2021 年，一个叫 Christian Grubmire 的人去帮他儿子解决一个 Minecraft 问题。他在屏幕上发现一条消息说，“我们正遭受 log 4j 的安全漏洞。请小心并立即更新。”这就是他，log 4j 的主要维护者，发现了一个被称为 log 4 shell 的 bug。然后他改变了他的周末计划，他和他的小团队花了接下来的几天时间在周末扑火。这个被称为“破坏互联网的 bug”的 bug，他们花了周末时间修复它。我只是想知道，如果那几个人决定去度个周末，去参加一个没有科技的排毒营，世界会怎么样？不幸的是，在此之后，GitHub 开始了一项旨在改善开源安全性的计划，名为 GitHub 安全开源基金。但我们在 2024 年仍然有问题，我不得不说 XZ utils，不是吗？尽管我认为我将要说 XZ utils 后门。呃，这个我发现最可怕，因为它是一个长达两年的精心策划的社会工程。一位化名贡献者看起来是这个项目非常有帮助的维护者，为这个依赖于 OpenSSH 的库做出了合法的贡献。由于项目资源不足，不堪重负，这位看似非常有用的敬业贡献者成为了联合维护者，于是他们就有了“皇冠上的宝石”，然后他们引入了一个精心隐藏的后门，本质上是一个等待发生的供应链攻击。多亏了一位非常好奇的微软工程师，它在被广泛发布并造成全球性灾难性事件之前就被发现了。我看到一些人在点头。我们都见过这个漫画，以及之后一些精彩的变体。XKCD 漫画《依赖》展示了所有现代数字基础设施都依赖于一个项目，而这个项目却被一个随机的人多年来默默地维护着。而正是“默默地维护”这个短语，我今天想重点关注。因为很多开源库和项目之所以发布，是因为所有者需要解决一个问题。他们解决了问题，并将其免费开源，以便他人和他们自己未来的自己受益，因为那是乐趣所在。解决问题，与世界分享，看看谁能使用它。Async API 的创建者最近宣布他将卸任九年的维护工作，他承认他从未想过要发起一场运动。我只是想解决一个我遇到的具体麻烦，我认为这是许多面临风险的开源项目的非常普遍的起点。这是 Jacob Fat Thornton。据称，他就是这样被认识的。Twitter Bootstrap 的创始人之一，他有一个很棒的短语来形容开源项目的早期阶段。他称之为“可爱的小狗阶段”，因为你开始你的开源项目，它很有趣，很令人兴奋，世界各地的人们都在使用它，他们在 Twitter 上谈论你，这在当时 Twitter Bootstrap 的时代就是这样。人们说好话。他们帮助你的软件。他们给你想法。项目改进了。一切都很棒。这对你的声誉很有好处。但过了一段时间，人们就不再那么兴奋了。它就只是维护的负担，而不是乐趣。他曾经感受到的快乐被内疚和义务所取代，就像他可爱的小狗长大了。我真的应该放一张可爱小狗的照片，因为你应该总是放那些照片，但没关系。
所以是的，感谢维护，因为维护开源比编写代码的乐趣要多得多。你必须分类问题，修复 bug，审查拉取请求，真正关心安全漏洞，评估人们的功能请求并思考，这有意义吗？编写文档，回答支持问题，等等等等。而“默默地”这个词，如果因此几乎没有收入，那它就是默默无闻的。当客户要求优先修复他们的 bug 时，他们可能会非常傲慢，但项目截止日期并不是维护者的麻烦。当我研究这个演讲时，我发现有些人有多么傲慢，这简直令人震惊。就好像他们忘了他们得到的一切都是免费的。在很长一段时间里，缺乏支持和负面评论会真的让人心力交瘁。你可能会想，好吧，忽略那些负面评论。但我不知道你是不是和我一样。20 个人说好话，一个人说坏话。是那句坏话，那个批评，让我耿耿于怀。通常维护者很在意。他们真的很在意。他们确实想帮忙。在 Embraco 的世界里有一个叫 Lee Keller 的人。他是一位经验丰富的合作者。多年来，他为 Embraco 构建了许多包，比如插件。他在他流行的包 Contentment 的自述文件中解释得很好。我会尽力帮忙，但我做开源已经很久了，我经历过相当多的倦怠和同情疲劳。他因为对你所处的情况感到同情而筋疲力尽。我很抱歉这个项目在你的场景下不起作用，但说实话，我已经没有更多的同情心了。他还记录了他在业余时间花在这个项目上的时间。诚然，刚开始时，它是由一家公司赞助的，但是的，他花了两个半小时以上，2500 多个小时在这个项目上。所以对于那些现在使用它并可能认为理所当然的人来说，这有点现实的检查。但他仍然这样做，他这样做是因为他热爱它，尽管有倦怠期。他喜欢公开合作和建设，并按照他想要的方向推进项目。你可以看出他很享受，因为他在右上角放了这个小小的“Lee was here”的彩蛋。这是 Embraco 的后台管理区域。如果你安装了 Contentment，你就会看到 Lee was here。对我来说，这表明我仍然喜欢做这件事。所有双关语都意有所指。所以维护者确实会遇到一个岔路口，当他们厌倦了，当他们受够了通常在业余时间免费工作却几乎一无所获的时候。
所以我们将看看 .NET 世界里一些知名的开源项目，因为我认为我们大多数人都来自 .NET 世界。这是我最了解的世界。这是 James Newton King，大约十年。我认为他是 JSON.NET 的唯一维护者，当时几乎每个 .NET 项目都在使用它。他最终被微软聘用。现在，这不是一个可扩展的开源解决方案，而且我认为相当多的人不想被微软聘用。这取决于你。但他们确实聘用了他。他们支持了这个项目。他不再从事这项工作了。我相信他去了微软的其他部门。但另一个在 .NET 领域极其广泛使用的项目是 Fluent Validation，由 Jeremy Skinner 在英国维护了近 15 年。他选择了赞助路线。所以如果你去他的 GitHub 赞助页面，它解释说，如果你从我的工作中受益于你的商业项目，请回馈。请赞助他。商业项目，也就是说，如果你通过使用我的代码赚钱，请把一部分钱转过来，这样他就可以继续支持和改进那个帮助你的产品。如果足够多的人这样做，那么这个项目也许是可持续的。但通常这是一个很大的“如果”。你可以看到他目前有 15 位赞助者，尽管他在 Nuget 上的下载量很大。这位面带微笑的美国人是 Jimmy Bogard。我想他周五在这里演讲。他是 AutoMapper 和 Mediator 的唯一维护者，这是 .NET 世界中另外两个非常常用的包。最初，这些项目是 Jimmy 工作过的公司需要解决一个问题而开发的。就像往常一样，有人需要解决问题，他们就开发了它。他们将其开源，多年来，公司允许 Jimmy 在白天工作时维护它们，因为公司需要这些项目。所以他们实际上是在赞助这些项目。但后来情况发生了变化，Jimmy 发现他自己不再直接需要这些包了。因此，他维护它们的能力消失了。去年，Jimmy 勇敢地迈出了这一步，将维护 AutoMapper 和 Mediator 变成了他的全职工作。勇敢，因为创办一家公司来促进许可是一项艰巨的任务。你当然需要建立一家公司。你需要成为许可和法律事务方面的专家，我不知道你们怎么样，但这并不是我早上起床的原因。你需要弄清楚如何分发许可，如何执行许可，所有这些决定都没有简单的办法。你必须在开始维护代码之前就建立好所有这些。与许多走这条路的大多数维护者一样，Jimmy 保持源代码开放。他使用双重许可模式。所以是 RCL，互惠公共许可，这意味着用代码支付，也就是说，如果你要用相同的许可在公开场合发布你的代码，那么你就被覆盖了。你不需要付费。但如果你不想用 RCL/RPL 许可在公开场合发布你的代码，那么商业许可就是你需要的。有很多双重许可的开源项目确实选择了一个非常慷慨的免费套餐。他们认识到许多小型企业、慈善机构（抱歉，这是个词）使用开源软件，他们不期望他们必须购买许可证。每个人都有自己的想法，如何安排这一切，无论是团队规模、营业额还是贡献。一些开源项目选择根据营业额或使用情况提供滑动折扣。就像我说的，所有这些事情，所有这些想法，所有这些决定都必须在将你的爱好变成你的全职工作，走向商业化时考虑进去。
AutoMapper 的 15 版本是第一个获得许可的版本。我想你可以看到它。我忘了放箭头，但我想你可以看到它在哪里。你可以看到人们仍在下载它。但我也觉得有趣的是，如果你注意到在 2022 年到 2024 年之间，每年有一个版本发布，而自从商业化以来，他在过去六个月里已经发布了四个版本。所以这表明，现在的情况比以前健康得多。如果你好奇，如果你是 AutoMapper 或 Mediator 的用户，并且好奇如果升级而不配置许可证密钥会发生什么，你会看到这样的警告。你没有 Lucky Penny 软件 AutoMapper 的有效许可证密钥。这允许用于开发和测试场景，但这是一个警告。所以，如果这进入了生产环境，你的系统仍然会工作。他并没有通过设置这个许可证要求来破坏你的运营。在他关于运行时如何执行的 FAQ 回答中，最后一句是，我们信任我们的用户，因为他不会知道谁在使用它，但他会相信那些需要付钱给他购买许可证的公司，商业实体不会运行非法软件。他信任他的用户。哦，看，有个箭头。是的。[笑声] 在 LinkedIn 上，他很久以前承认，商业化使他能够重新建立与项目的关系。GitHub 的问题和支持请求曾经像一个负担压在他身上。而现在，他将它们视为机会。他现在想帮助那些使用他软件的人。因此，项目将因此而繁荣，那些建立业务并依赖于它们的人将从这些改进中受益。据我所知，AutoMapper 和 Mediator 的商业化已经尽可能公平了。我祝 Jimmy 一切顺利，只要足够多的公司达到阈值并支付他们应付的费用，这看起来就像相当可持续的开源。但当然，任何使用 AutoMapper 的人都有权坚持使用 14 版本，最后一个 MIT 许可版本。当你发布一个版本到 Nuget 时，你可能会知道，你说明了它是在什么许可下发布的。所以你不能追溯地更改许可。为了更改许可，你必须发布一个新的版本，最好是主版本，以防有人在听。所以你可以 fork 14 版本并继续自己维护它。我不是提倡这样做，我只是说你可以这样做，只要你更新你的 CSProj 文件，在版本号周围加上方括号，那么自动更新工具就不会尝试升级它。所以你只需要停留在你上次使用的版本上。
当我听到开源走向商业化时，我经常听到一句话，就像 AutoMapper 一样，是“卷款跑路”。这是我真正讨厌的一点。我认为卷款跑路意味着突然背叛了信任你的人，然后让他们陷入困境。所以，我研究过的维护者都相当清楚地提前沟通了他们的意图。他们宣布将有一个新的主版本即将发布，并且将有一个新的许可模式。所以，如果这对任何人来说都是一个惊喜，那么我想这是你的错，因为你没有关注你所依赖的开源项目的维护者。至于让他们陷入困境，嗯，我已经解释过了，你可以停留在原地，停留在 MIT 许可版本上，或者自己维护一个 fork。我认为唯一真正会感到沮丧的人是那些在 MIT 许可下为项目做出重大贡献的人。我没有证据，但我愿意相信像 Jimmy 这样的维护者会是第一个与他们沟通的人，解释他们将要做什么。我愿意相信他们可能永久拥有免费许可证来继续使用该软件。我不知道，但知道那些发布双重许可的人，他们这样做是为了项目的利益。我相当确定他们会做类似的事情。
不幸的是，并非所有项目在维护者不堪重负时都会朝着好的、积极的方向发展。这是 Nuke，一个流行的构建自动化工具。它是 C# 对令人讨厌、害怕、憎恨的 YAML 文件的替代品。去年 11 月，维护者确认他要结束了。这是对一个 GitHub 讨论的回应，当时人们在询问项目的未来，因为他已经很长时间没有消息了。他解释说，他的不活跃是由于众所周知的开源软件可持续性问题，而压垮他的最后一根稻草是，在他不活跃之后，据称对他个人进行了各种攻击。所以这是其中一个 fork。这是所有事情都出错的结果之一，现在它看起来像是未维护的、被抛弃的软件。我认为它始于 2017 年，很多人都在使用它。正如我所说，这是一个非常有趣的 GitHub 讨论。上面有人说“我们依赖这个工具。我们用它来处理超过 100 个管道。”我想他们现在是否在想，在它达到危机模式之前，他们是否可以做更多来支持这个项目，如果他们如此依赖它的话。维护者说他们不会考虑引入其他人，但它是 MIT 许可的。社区可以以新的名称 fork 它，也许可以这样建立一个新的项目。时间会证明一切。如果他们这样做了，我希望他们能找到一种可持续的方式来继续它。对于那些认为“为什么他不去商业化呢？”的人来说，我认为这并不总是关于钱的问题，我想在座的每个人都希望一天有超过 24 小时。时间是一种资源，比金钱更重要。但如果财务支持是问题，那么正如我所说，和任何开源维护者谈谈，Jimmy 周五在这里，如果风暴允许他从美国赶来。你不能只是去商业化。这样做需要大量的工作和相当大的风险。最简单的方法当然是启用 GitHub 赞助。这只需要填写一些表格，点击几个按钮。但然后这就依赖于人们是否真的选择并赞助这些项目。令人不舒服的真相是，我们中的太少人这样做了。这是一条单行道，公司节省了时间、金钱，使用了免费劳动力，却没有回馈。我确实理解赞助路线与某些公司采购流程不符，我希望我有一个解决方案，但我没有。但如果有人有，请告诉我。
所以，是的，房间里的人们提出的绝佳问题是如何提供帮助？我认为我已经解释了，我试图在这场演讲中不那么消极，但它相当艰难，但无论如何，让我们现在尝试变得更积极一些。我们如何提供帮助？作为消费者，我们可以做些什么来改善这种情况？嗯，你需要识别，因为这是一个拼写错误，不是吗？它写的是“身份”。我做得好。是的，你需要识别你的关键开源软件依赖，然后投资于风险最高的那些。当然，如果他们要求，这可能意味着投资金钱。赞助或许可就是合适的。我只想说，如果你能负担得起 Azure，你就能负担得起赞助你的开源依赖。我只是在这里说一下。你也可以投入时间和你的团队的时间来减轻维护者的负担。员工应该被允许，应该被鼓励在工作周内做出贡献。这包括分类问题。如果有人在一个开源项目上提出问题，任何人都可以去验证这个问题是否存在。他们可以帮助说“在我机器上不行。”我喜欢这句话。“这是一个重复的问题吗？”“它可能已经过时了？”“它仍然有效吗？”帮助他们分类问题列表。改进文档。文档，我认为没有人觉得它有趣。呃，显然我们是否还需要它还有待商榷，但无论如何，谢谢 AI。呃，但文档通常是人们仍然想开始的地方。所以请帮忙。提交拉取请求。当然，为开源做出贡献的经典方式就是用代码。你能自己修复一个已报告的 bug 吗？理想情况下，如果你自己发现了 bug，就自己修复它。如果你这样做了，请密切关注贡献指南，只修复那个 bug。我当时在想一个类比，作为一个英国人，我喜欢喝茶，我想到，如果有人邀请你到他们家，说“哦，你能泡杯茶吗？”你会去厨房，也许茶包放在你意想不到的地方。哦，我没想到会在这个抽屉里找到杯子，但你只是泡杯茶。你不会在泡茶的时候重新整理他们的厨房，把杯子移来移去。我认为这差不多是同一件事。如果你在为一个 bug 修复做 PR，就修复那个 bug。请不要因为你认为应该这样做而进行重构。如果你确实认为重构是个好主意，出于性能原因，维护者喜欢性能改进。如果你确实认为你找到了性能改进，就提出一个问题，先和他们谈谈。未经请求的大型重构 PR 只是增加了维护者的负担。它们确实有帮助。是的，点头。谢谢。它们确实有帮助。我真的建议人们以这种方式投资于开源。我说，我为 Embra 工作了 10 年。我经营自己的网页开发机构。我在工作日做贡献。我学到了很多。它提高了我的编码技能，真的提高了我的沟通技能。在问题上写作，与你不知道身在世界何处的人沟通，这真的能帮助你沟通，尽管我现在说话结巴。所以我认为以这种方式做出贡献实际上是一种相当自私的活动，而 Embra，这些是我们想要的贡献。我们不寻求赞助。我们希望得到这样的贡献，最好是在你的工作日。可持续的开源就是当雇主意识到其价值，并鼓励和支持员工在白天这样做，而不是工作生活失衡。你回到家，晚上还要做两个小时，而你真的应该哄孩子睡觉。这不太符合我们的期望。
那么，维护者如何帮助我们呢？因为这还有另一面。他们如何帮助我们消费者？嗯，在我看来，就是更透明地说明情况。让人们更容易理解谁在项目背后，花了多少时间，以及他们如何支持它。也许作为维护者，你很想兼职，也许每周工作四天，花一天时间维护这个项目。如果你得到了足够的赞助者，你就能做到。你算一下，你设定了一个赞助者数量的目标。如果你解释了你想要做什么，那么人与人之间，你可能更有可能获得更多的赞助者。我知道有些人，尤其是男性，抱歉，不太擅长寻求帮助，但我认为这也许是我们应该鼓励和看到的更多。这样，假设我们正在监控我们重视的开源依赖，我们就会知道事情进展不顺利，它们开始遇到困难，它们需要帮助。再说一次，我回到 XC utils 的问题，我对此感到担忧。但无论如何，这是另一个问题。人们正在开始或一直在运行各种倡议，试图帮助促进更健康的开源。这是开源维护费。我认为这只是在增加对赞助你所拥有的开源依赖的这个想法的可见性，它们正在寻求赞助。所以它鼓励维护者寻求赞助，而消费者则履行它。我认为要说你属于这个，你必须订阅你拥有的每一个要求付费的开源依赖，然后你就可以说“是的，我们是开源支持者”。有一个叫做开源星期五的东西，我喜欢这个想法。这是雇主说的，每周至少两个小时，在周五，你应该花时间为开源做出贡献。我不知道为什么他们都坐在同一辆自行车上，但我喜欢这个主意，然后当然你可以说你这样做了，而且你的营销团队可能会喜欢你加入并这样说。我最近还发现了一个我不知道存在的，当我为这个做更多研究时，是 pkg store package store.io。这实际上是一个所有商业上可用的 Nuget 包的综合列表。所以你会看到 AutoMapper，abalonia XPF，hangfire pro。所以，如果你意识到你实际上想支付并支持这些商业项目，你可以在这里轻松找到它们。
我当然不能不提 AI，不是吗？AI 时代下的开源。AI 当然有影响。我想我看到 cull 项目的维护者报告说，他现在不得不清理多少 AI 垃圾作为他维护工作的一部分。最近我们从 Tailwind CSS 那里得知，它不得不裁员 75% 的员工。他们的主要收入来源是文档广告。现在，当然，AI 已经基于这些文档进行了训练，人们使用 AI 工具来回答他们的问题。因此，他们网站的流量下降了。然后我们听说他们被 Versel 所救，因为事实证明他们是它的忠实用户，所以他们救了它。有趣的是，他们等到危机模式才介入并这样做。我看到一位开源维护者说，他们不想要代码的拉取请求。他们想要提示，然后他们会用这些提示来运行，他们自己运行它们来生成代码。我希望这不会成为常态。这让我感到不安。因为开源项目和库，它们提供了我们代码之上所需要的“人性化”元素。AI 会给你代码，但我们仍然需要治理。我们仍然需要安全方面的考虑。我们希望软件是安全、可维护和值得信赖的。所以是的，当然，AI 正在帮助我们生成代码来解决问题，但我看不到它会取代开源库。我看到有人炫耀他们花了三个小时让 AI 重写了 AutoMapper 之类的东西，就像，嗯，它有开源的 14 版本。你本来可以直接 fork 它。嗯，[嗤之以鼻] 顺便说一句，说到 AI，有一件事我还没谈到，那就是如何计算你最高风险的依赖。AI 的评论一会儿就会有意义。你需要计算“巴士因子”。这是一个糟糕的短语，因为我的意思是，我不是巴士司机，但我住在伦敦。我看到很多巴士。我从未见过巴士事故，但无论如何，这是“巴士因子”这个短语。意思是，为了让你的项目失败，有多少人必须被巴士撞倒并死亡？巴士因子。所以，我不是自己发明的，但这是一张可爱的照片，而且实际上就在离我们不远的地方。如果你的一个关键依赖项的巴士因子是 1，那么这意味着如果那个唯一的维护者不注意看路就过马路，你的依赖项就处于风险之中。所以，这是公平的，相当明显地说，那里应该是你投资的第一个地方。
那么，你如何计算一个开源项目的巴士因子呢？你如何计算这个项目的风险有多大？嗯，一个关键因素是存储库是否由主要贡献者拥有？在这方面，这是一个相当危险的信号。有多少人拥有提交权限？你知道你看不见吗？这不是公开信息。除非你对该存储库有实际权限，否则你无法看到有多少人拥有公共存储库的提交权限。你可以去找出答案。你可以去，嗯，你可以猜测。你可以去查看所有最近合并的提交，看看是谁合并的。如果你能合并，那么你显然拥有权限。也许自述文件对项目的支持和融资方式有清晰的解释。在 GitHub 上还有其他你可以去查看的东西，去看看贡献图。有多少贡献是由一个人或一两个人完成的。然后还有其他事情，我在这里放了点，因为我开始对思考所有可以做到这一点的方式感到相当厌倦。然后我跟我同事 Seb 谈了谈，他坐在这里，我说你知道吗，这实际上相当复杂，很多繁重的工作，那个神奇的短语“繁重的工作”，他说，他不是这样说的，抱歉，但他当时说，“嗯，我们可以自动化这个。”所以几个小时后，我“黑客式地”让他帮忙，几个小时后，他给了我一个代码技能，可以为我们做到这一点。和他一起研究这个技能比制作幻灯片更有趣。所以，这发生了。我制作了演讲，我发现了一些无聊的事情来解释，所以我构建了一个工具来自动化它，然后我最终在演讲中谈论这个工具而不是那些事情，欢迎来到最近发布的 OSS health skills 存储库，它在我的 GitHub 上。我们有三个技能，我们已经上线，所以你可以尝试它们并给我们一些反馈。祝福你。你可以安装它。这是 claw code。你可以直接从 GitHub URL 安装它，然后当它安装完成后，它会确认已安装三个技能。现在有三个技能可供使用。依赖提取器，它提取依赖项。依赖项资金分析技能，它分析依赖于它的存储库，然后对于单个项目，项目资金配置文件为单个项目生成详细的资金配置文件。然后，当它安装完成后，现在可以了。好的，我正在考虑时间。我不喜欢做现场演示。它从来没有顺利过。只是为了调整你的期望，但我们认为看看是否能让它工作是值得的。为了做到这一点，我是一个。所以，我在这里 claw code。你好。欢迎来到 claw code。今天我能帮你什么？太棒了。呃，有没有人知道一个开源的存储库，项目，他们想知道这个技能看起来是什么状态？有人吗？Serial log。Ser，你知道所有者吗？我需要知道 GitHub 组织。可能是 serog，不是吗？是的，试试 serial log。好的。我现在最害怕的事情是有人看着我打字。如果你们能暂时闭上眼睛就好了。好的。那么，Siri log 的资金情况是什么？它会起作用吗？你觉得呢？>> 也许吧。>> 好的吗？嗯，你知道我一直被告知要少告诉 AI。少告诉克劳德叔叔。我们曾经有过一个可怕的习惯，称它为克劳德叔叔。每次少告诉克劳德叔叔一点。所以，它找到了技能。它找到了一个叫做“项目资金配置文件”的技能。听起来不错。嗯，现在我们要看看会发生什么。我很高兴互联网还在工作。这相当，我想在接下来的三天里，有很多做演讲的人都非常庆幸互联网还在工作。它将找到 Siri log 的资金配置文件。查找贡献者。它需要一些时间。所以，我告诉你，我们可能会怎么做。嗯，据称，别担心那个错误。没关系。我之前在 Embraco CMS 上运行过这个，如果你还没听说过的话。我在那里工作。嗯，所以 Embraco CMS 询问我们开源产品的依赖项，这些依赖项的资金状况如何？它找到了 15 个，15 个。技能已经设置为忽略微软的东西。至少微软不需要我们的钱。所以它列出了那些，并给出了一个资金缺口状态和一些关键信号，然后按优先级顺序逐一列出。如果我能找到我的翻页键。好了，这样更容易。所以，例如，Mark Dig 据称是高优先级。它有一个维护者，非常高的巴士因子。你可以使用 GitHub 赞助，所以他们愿意接受。Open PR4，这其实相当不错。但也许这有点过时了。Swashbuckle 由 Martin Costello 维护，我相信。里面有一些信息。资金缺口严重，极其受欢迎但资金不足。HTML Agility Pack 我们将一一介绍，最后它会确认哪些没有资金基础设施。所以，>> 哦，好的。所以，嗯，好吧，我们可能需要再次运行它，一个更有趣的。嗯，从分析中排除，确认微软的东西，当然，如果你有自己的不想一直调查的东西，你可以把它添加到你的技能版本中，但它给了我们一个推荐的资金策略。现在，我们是一个开源 CMS 产品，但我们实际上已经赞助了 Examine。但这对我们来说确实是有效的信息。我们有一个开源可持续性计划，所以我们有数据。我的意思是，请不要字面理解，你知道，自己也做一些调查，但它会给你一个很好的开端，说明你的时间和金钱应该投资在哪里。嗯，让我们看看“高关注度”发生了什么。据称，它是危机的。零正式资金渠道。所以，好吧，我们可能需要告诉它，如果你不要求钱，那么我们就不需要钱。但无论如何，但这也许不完全正确，因为也许他们只是没听说过求助。有人有别的想法吗？好的，这里有一个我之前做的，而且是真正的蓝彼得风格。我之前谈到过 Nuke 这个构建自动化工具被放弃了，我想知道这是否会在我们开始计算巴士因子之前给我们一个提醒。是的。所以 90% 的贡献者贡献来自一个人，风险等级为危机，单一维护者占所有提交的 90%，18 位赞助者，资金渠道，它是生态系统中被广泛使用的构建系统之一。总下载量 3000 万次，是的，嗯，无论如何，哦，倦怠信号，正在寻找维护者。所以正如我所说，我们周日晚上开始做的，所以我相信它可以改进。但肯定可以改进的是开源存储库上的贡献指南，因为正如我所说，当我试图弄清楚如何手动解释给你听时，这太乏味了。所以，希望这能给你一些启发，你可以自己尝试一下。现在我只需要回到演示文稿。很棒。所以，我有点早，但那是你们的错，因为你们没有想出更多你们想做的演示。只是说一下。请试试这个工具。正如我所说，我们很想听听你们的使用情况。拉取请求当然是受欢迎的。最后，请重新思考你如何看待花费时间和金钱在你的开源依赖上。这更多的是一种为你自己降低风险的投资，而不是慈善。你也可以说谢谢。你知道吗？我不知道，我的意思是，这没有那么有帮助。这不会养活你的孩子。但有时我们非常擅长说，“哦，这个不行。”你知道吗？最初的“我喜欢你的项目。它真的帮到我了。”然后你报告 bug。我的意思是，我不是说只有我作为英国人需要把赞美放在一些东西周围，但你知道，我没有放幻灯片，但有一个人有东西，它是 MIT 许可，除了你承诺每年说一次谢谢，或者别的什么。你提出一个问题只是为了说谢谢，这是一个可爱的想法，但当然你必须关闭那个问题，但无论如何，多说谢谢。我坚信涟漪效应，在 Embraco 的世界里，我们经常看到它。你看到有人做出贡献。它激励其他人也这样做。无论我们谈论的是财务还是时间贡献，当你被看到这样做时，其他人就可以说，“哦，我也可以这样做。我可以帮助那个项目。”所以，你的投资将激励他人也这样做。所以你可以在 linktree 上找到我，lotty picture。我喜欢批评，如果它是建设性的。所以请告诉我。不过，最好是 Embraco 在楼上 5 楼有一个展位，就在 NDC 最好的咖啡旁边。来和我们谈谈，因为，让我们在展位上试试这个工具。我们不会卖给你 Embraco。顺便说一下，它是免费的。所以我不需要卖给你任何东西。但我很想听听我低估了什么。如果你认为我有什么地方错了，如果我忘记了什么。让我们当面聊聊。我们在这里直到周五晚上。非常感谢。