开源峰会活动的主题演讲环节通常难以安排详尽的讨论时间，2025年欧洲开源峰会也不例外。即便如此，curl项目的维护者Daniel Stenberg仍成功在15分钟内传递了大量信息。与众多项目维护者相似，Stenberg正承受着压力，且问题似乎正随时间推移而加剧。
他开场便指出，Curl是“影响深远的小型项目”。该项目始于1996年，最初仅有100行代码；如今已发展至18万行代码，由1400位作者共同贡献。每月约有20至25名开发者积极参与curl开发。整个项目仅有一名全职员工——即斯滕伯格本人。
该程序应用广泛，已部署于至少十亿台设备中。他指出，几乎所有偶尔连接网络的设备都依赖curl实现联网功能。但使用curl与支持其开发是两回事。他举例展示了47个在产品中使用curl的汽车品牌列表，紧接着呈现了贡献curl开发的品牌列表——不言而喻，后者是空白的。（两张幻灯片的版本可参见此页面)
企业往往认为开源软件的开发成本由他人承担，因此无需贡献资源。他强调自己已将curl发布在自由许可证下，因此这些公司的行为并无法律问题。但他建议，这些企业或许该多思考一下自身依赖的软件未来发展。
开源软件是最佳选择，但他坦言维护工作异常艰巨。多数项目仅有一名维护者，且往往在业余时间无偿承担。维护工作涵盖诸多任务：处理安全漏洞、审核补丁、编写文档、运营网站、管理邮件列表，以及其他大量事务。若偶有闲暇，或许还能进行些功能开发。这些工作量对单人而言实在难以兼顾。
企业往往会使情况雪上加霜。他展示了苹果支持团队的一封邮件摘录，其中竟将用户设备问题转介至curl项目寻求帮助。他还收到多家企业要求提供项目开发与安全实践信息的请求，且常附带紧迫的回复期限。他通常以发送支持合同作为回应，据称此举往往能让对方彻底销声匿迹。近期更出现欧洲企业索要curl项目《网络弹性法案》合规实践信息的案例。
部分邮件则毫无幽默可言——某封邮件主题赫然写着“我要杀了你”。还有人从汽车随附的许可声明中找到他的邮箱地址索要技术支持。当然，偶尔也会收到友好的致谢邮件。
问题邮件还呈现出其他形态。越来越多的人让大型语言模型“找出curl的问题，并将其描述得极其严重”，然后将错误的检测结果发送给项目组，以为这样就是在提供帮助。处理这些毫无价值的问题报告耗费的时间越来越长。
最近，curl项目组和其他网站运营者一样，正遭受人工智能公司运营的爬虫发起的分布式拒绝服务攻击。他为不了解情况的人提供了LWN相关报道链接。curl网站每月消耗海量带宽，但源代码下载仅占0.01%，其余绝大部分是机器人流量。这同样增加了项目维护难度。
简短发言的结尾处，他展示了最后一封邮件——来自一名11岁孩童，对方在某个项目中发现curl工具颇为实用。信中充满感激之情，斯滕伯格坦言这封信“令人倍感温暖”。
本文文字及图片出自 The challenge of maintaining curl
根据我的经验，大多数企业(或至少为其工作的开发者)实际上都愿意为他们所依赖的开源项目捐款或支付支持费用。问题在于——至少从我的经历来看——由于法律法规、合规要求等因素，这种捐助往往难以实现。
例如：我曾说服雇主向我们依赖的开源项目捐款。捐款完成后，数月内公司就因无法证明海外款项流向及排除资助恐怖活动的可能性，遭到监管机构的警告处分。
类似地，我曾参与某个开源项目贡献代码，确实有企业提出付费合作请求，如修复漏洞或开发功能。但问题在于他们要求提供发票才能付款，这意味着我们需要注册公司、获取税号等手续。当时我作为自由职业者，便提议使用我的商业注册信息开具发票，再将利润分给项目贡献者。然而首个付费“客户”立即抛来20页供应商评估表，要求提供SOC2或ISO27001认证、数据安全政策、员工背景调查等材料。随后我的会计师指出，将款项分配给多人会被视为变相工资，可能引发严重法律问题。
诚然，这已是数年前的事。如今随着Github赞助商、KoFi和Patreon等平台的出现，情况有所改善。但与此同时，法规也变得更加严格，与大型企业合作既困难又耗时耗资。对大多数开源维护者而言得不偿失，而对大型企业来说，此类捐赠带来的法律风险同样不值得承担。
patio11也表达过类似观点：税务部门倾向于将“捐赠”解读为“所有者个人支出”，并要求据此处理会计核算和税务申报。
https://news.ycombinator.com/item?id=10863978
通过收款服务商平台销售服务。他们为你垫付款项，你就能省去一大堆麻烦
那我们是不是该把那些胡扯的咨询项目正规化？反正这类活儿到处都是。“每日优化10万次HTTP请求”之类的。
我曾考虑以慈善机构形式运作，但作为顾问收费或许更现实——这样无需修改慈善法规就能实现。
> 越来越多的人让大型语言模型“找出curl的问题，说得天花乱坠”，然后把永远错误的结果发给项目组，以为这样就是在帮忙。
我们最糟的噩梦正在成真..
>以为自己是在帮忙
>我们最糟的噩梦正在成真
完全赞同你的观点，但多数时候这些人并非出于利他主义。
他们向维护者喷洒垃圾信息，不过是为了在简历上添上“CVE编号战利品”，或是从HackerOne上那些厂商支持的互联网漏洞悬赏计划(IBB)里捞取报酬。
https://hackerone.com/ibb
https://daniel.haxx.se/blog/2021/09/23/curl-joins-the-reborn…
最糟糕的噩梦莫过于维护者们转而使用大型语言模型来审查或应用这些补丁
我工作中已有部分流程仅由AI审核。这意味着我们被建议使用另一套AI来更快填充数据。
虽非关键环节，却令人既恐惧又荒诞。垃圾输入，垃圾输出——不过是换了更花哨的工具罢了。
阿西莫夫预言的历史将变得混乱不堪、充斥噪音，以至于无人能分辨真相与传说——这正发生在我们眼前。无需千年岁月，短短数年间，AI公司就肆意滥用那些本可免费获取的知识。
并非要炫耀，但我最恐惧的噩梦是这样的开源项目：所有维护者都是大型语言模型的复制粘贴工具，除此之外毫无真知灼见。
当然，这种灾难早已发生。前阵子在HN看到一个看似有趣的项目，结果正是如此。他们最初是另一个项目的分支，因此拥有可用的代码库。但项目负责人是个顶级混蛋，以对人摆臭脸为乐，凡非出自他本人之意的想法都斥为荒谬。他们的内核开发者简直是个白痴，产出的内容要么是(明显)LLM生成的文本，要么就是纯粹的蠢话。就连旁观贡献者也百分之百是聊天机器人复制粘贴的产物。
然后让另一个模型和第一个模型较量一番，看谁先拒绝这个补丁。这会是一场精彩的模型对决，提示语之战 :o)
这种情况越来越常见了。我见过好几个开源项目发布CVE漏洞报告，里面包含虚构的API接口。
问题在于开源维护者鲜少回应，因为多数项目已被科技巨头员工掌控。像Stenberg这样的独立作者实属例外。
若九十年代至千禧年初的叛逆精神犹存，开源社区本可在一个月内扼杀“AI”代码洗钱厂。但自2010年起，众人争先恐后讨好科技巨头。如今科技巨头用裁员和恐吓来奖赏懦夫。
多数开发者不明白企业权力平衡遵循原始法则：若显露恐惧/顺从，管理者就会把你当作 beta 公狗对待——这正是他们唯一理解的语言。
文中提及的演讲可在此处观看，仅13分钟：
主题演讲：巨人，站在巨人的肩膀上——Curl项目创始人Daniel Stenberg
https://www.youtube.com/watch?v=YEBBPj7pIKo
虽然文章写得很好，但视频中的图表和照片确实增添了更多深度。
完整报道 https://archive.fosdem.org/2024/schedule/event/fosdem-2024-1…
主权技术机构(德国联邦政府)向该项目捐赠约20万欧元。但并非品牌赞助。https://en.m.wikipedia.org/wiki/Sovereign_Tech_Agency
步骤1：创建GoFundMe众筹
步骤2：宣布在该众筹达到1000万美元前，所有curl新提交代码均采用AGPL许可
步骤3：获利
步骤3：被分叉后输掉？
步骤四：问题转嫁他人，大获全胜
若他们本就不愿持续维护，大可直接跳过步骤四，从一开始就不接手。问题在于他们确实愿意维护，况且多年来也成功做到了。在“忍受各种狗屁倒灶的事”和“彻底放弃”之间，存在着“设法减少狗屁倒灶的事以专注重要部分”的广阔空间，而大多数方法恐怕无法浓缩成几步精炼的步骤塞进一条(原始尺寸的)推文里。
若有能力者愿接手我的重要工作项目(部署系统、核心代码维护等)，我必欣然移交。我本可立即以处理紧急任务为由弃之不顾，但不愿将无人维护的代码强加给团队。开源维护者想必责任感更强，毕竟他们视工作为社区服务。或许放弃项目正是触发资金充足的分叉或吸引企业关注的契机，就像Heartbleed漏洞影响OpenSSL那样。
大型语言模型可用于识别漏洞、开发功能等流程，但_必须_验证结果。未经测试、检查和验证就采信LLM输出是懒惰行为，极易引发错误或增加代码维护难度——例如当LLM生成的内容不符合项目开发规范/格式标准，或导致其他代码部分变更时。
通常而言，当你意识到某项技术/流程/事物存在硬性要求——即个人必须独立承担责任或自我约束，且自身无法获得明显即时收益时，该技术/流程/事物在现有形态下几乎注定无法挽救。
这是普遍情况。但大型语言模型的核心卖点恰恰在于将“推理”任务卸给它们。这正是它们向你兜售的核心价值。因此对于LLM而言，上述规则中的“几乎可以肯定”可直接替换为“毫无疑问绝对如此”。这甚至无需假设——已有实验证据表明LLM会降低人类的思考/推理能力。所以你_至多_是从劣势起点开始的。
但更重要的是，这使得使用大型语言模型的整个前提变得毫无意义(至少从营销角度而言)。如果我需要验证一台思考机器，它还有什么用？尤其当你告诉我它很快就会成为一台“超级推理”机器时。难道我还需要一个人类“超级验证者”来匹配吗？事实上这根本不是未来问题，而是当下困境：大型语言模型被明目张胆地宣传为“口袋里的博士学位”。我没有博士学位。若让我“审核人类博士的研究成果”，多数人会觉得荒谬可笑——那么凭什么我就能审核自己的机器人博士学位？我付费购买它，正是因为它比我更博学！难道现在还得雇个人类博士来验证我的机器人博士？若非如此，难道只有人类博士才有资格使用机器人博士？换言之，LLM是否只能用于操作者已掌握的领域？这似乎很荒谬。这就像一个只能回答你已知答案的魔术八球。可笑的是，你甚至可能看到有人得出结论：“当然啦，curl专家应该验证我提交的补丁。提交补丁不就是为了这个吗？curl的专家们会验证的！还有谁比他们更合适？” 如此这般，我们又回到了原点！
需要明确的是，每个问题都有诸多反驳观点/变通方案等。重点并非提出针对LLM使用的哲学陷阱论证，而是揭示LLM的价值主张与其理论上的“正确使用”之间存在根本性错位，从而说明它们被正确使用的可能性为何微乎其微。
我将编程LLM用于以下混合场景：
1. 更优的自动补全——尽管模型可能出错，但总体而言我发现这很有用，尤其在构建测试、生成结构化输出等场景；
2. 更高效的搜索/查询工具——通过描述需求即可获得答案，而传统搜索需预先掌握精准关键词。若需进一步帮助/信息，我仍会查阅文档或进行搜索；
3. 创意碰撞助手——当不熟悉API或配置时尤为实用。这仍需通过测试代码验证可行方案，我将其视为阅读技术博客等行为：文章可能过时、存在问题或与需求不符。但它能提供足够信息让我获得所需答案——例如某个具体方法，我可进一步查阅文档(如API的注释说明)等。或者它能提示我该在谷歌搜索什么等。
换言之，我将LLM作为流程中的一环，如同使用搜索引擎、Stack Overflow等工具。
> 更智能的代码补全
这完全符合我使用GitHub Copilot的场景。
当我输入函数名时，AI已能预判传入参数。有时仅输入“somevar =”，它便能精准推测函数名称，甚至预判后续数据处理逻辑。
我曾遇到这样的情况：只需输入一句描述代码功能的注释，它就能自动生成十行代码实现该功能，几乎完全匹配我原本要编写的代码。
程序员们对AI代码生成的负面评价实属冤枉。它完美吗？当然不是。至少半数情况下会出错。但凭借我的技术水平，几乎能瞬间识别出错误。
如今GPT-5 Pro发现我代码中的错误比我自己还要多，它确实非常出色。
大型语言模型在擅长与不擅长的任务类型上表现相当稳定，这意味着人们能学会何时使用它们、何时避开它们。其实不必如此非黑即白地看待它。只要你对LLM的结果进行复核，就无需担忧。
需要验证结果并不影响时间效率——当验证速度远快于从零开始编写时，时间节省依然显著。
自从让GPT-5 Pro审查所有代码变更，再由我亲自复核后，我的代码质量确实提升了。在我看来，只要你用心，LLM就能助你编写更优质的代码。一如既往，只有懒惰者才会吃亏。若你追求卓越代码，LLM正是绝佳工具——通过协助研究、规划和审查，助你以更短时间达成目标。
我认为这并未真正回应当前争论的核心问题，甚至可以说你的观点与我的论点根本不存在冲突(或许你本无意如此！)。但姑且用这个词来说，你描述的是一种“封闭式体验”。你(在某种程度上)承担了自己选择的责任。你将工具应用于_自身工作_，因此在评估工具适用性及验证结果方面都具备“资格”。本质上，验证工作与你使用工具的程度成正比。很好。
原帖提出的问题在于：与你的使用场景不同，这种“开源”模式下的验证负担并未由“贡献者”承担，而是被“外部化”转嫁给了维护者。这导致维护者无法获得你那种“线性”体验，他们的处境充满不对称性——如今他们被大量PR淹没，而这些PR(至少目前)比人工提交更难审核。更不用说，与你的情况不同，他们若发现该工具不适合项目，根本没有“选择”不使用LLM的余地。当你发现某项技术不适用时，只需轻描淡写地说“好吧，看来LLM还未准备好应对这个场景”即可。但维护者们并不具备这种选择权。PR的涌入取决于创建门槛的低易度，而非其实际价值。因此验证负担不会随维护者使用频率线性增长，而是随所有决定让LLM“协助”的人数累积而膨胀——这个规模既庞大又超出其掌控。
我评论的核心观点在于：这种状况不仅在所难免，而且在我看来是此类应用的本质特征且不可分割——其原因恰恰直接源于你的帖子所述。当你处理自有项目时，将LLM操作者视为具备验证模型输出资质是完全合理的。但当应用于他人项目时，情况恰恰相反。
> 需要验证结果并不否定时间节约——尤其当验证远比从零开始完成任务更快捷时。
当然，这仅因你对所参与项目已有_现有认知基础_才成立。这绝非贡献行为的普遍属性。对我而言，在不熟悉的项目中验证生成的补丁绝非“小事”——原因从简单如_完全不知晓_代码贡献规范(我凭什么确定自己是否遵循了风格指南)，到复杂如_甚至可能不熟悉项目使用的编程语言_。
> 若你正在检查大型语言模型的输出结果，则无需担忧。
正是如此。这才是问题的症结所在——我指的是在代码贡献场景中，关键不在于你是否核查结果，而在于你实际上根本无法有效核查结果(除非你投入的工作量几乎等同于从头编写代码)。
有人可能会反驳：“但这与LLM的讨论无关吧？提交自己创建的PR不也是同样情况吗？”不！两者存在本质差异。任何向陌生项目提交过实质性补丁的人，都经历过“必须熟悉相关代码才能创建补丁”的过程。单是_编写修复方案_这一行为本身，就会自然而然地推动你掌握代码的专业知识。即便没有其他收获，你至少会对所选方案形成见解，从而能在提交后_参与讨论_。作为PR提交者的_你_，将变得_值得投入时间交流互动_。我当然知道可以构想出AI代理参与PR讨论并形成长期“记忆”或“观点”的系统——但这种体验若真实现，我们再另行探讨，因为这_绝非_当前维护者的真实处境。这不过是低质量单向垃圾信息的洪流。即便那些专门为内部流程实施此类体验的企业，其协作体验也难以称得上…怎么委婉表达呢，“令人满意”——而这还是在远比“向所有项目建议有价值的修复方案”更受限的环境下。
我绝非主张验证责任应由维护者承担。贡献者/提交者必须尽最大努力确保提交内容的准确性——这点毋庸置疑。
无论报告者是自行发现漏洞，还是通过Coverity等静态分析工具、模糊测试工具、Valgrind类工具、大型语言模型或其他机制识别问题，此原则均适用。
在每种情况下，报告者至少需要确认其发现的问题确实存在，并最好能提供可复现的测试案例(如“该文件导致应用程序崩溃”等)、相关日志等信息。
我反对你否定大型语言模型(LLMs)的价值主张。我并非针对开源维护者被低质量问题和PR轰炸的情况(这方面我们观点基本一致)。
你认为LLM价值主张毫无意义的论点，实则对现代AI抱持极端非黑即白的看法。事实上存在大量任务，即使在非专业领域，验证也比亲自完成更容易。关键在于实际执行验证工作(这正是开源维护者遭未验证者骚扰的核心症结)。
例如近期我为工作编写代理程序时，虽对网络架构并不熟悉，但借助LLM最终实现了覆盖所有用例的稳健方案。我无需成为网络专家。凭借计算机科学其他领域的经验，结合LLM辅助研究，我成功让代理运行起来。或许存在某些细节疏漏，但能验证代理正确捕获流量并能判断其流向，这已足够推动项目进展。
在利用LLM拓展技术边界时，确实会牺牲部分学术纯粹性。这种做法存在显著弊端，例如让经验不足者能编写极不安全的软件。但我认为更多情况下，只要验证结果有效且不超出知识边界，LLM能为人们创造巨大价值。换言之，使用LLM完成任务无需成为专家，但至少掌握相关领域知识能提供坚实基础。因此我认为LLM能极大拓展人类能力边界，其价值无可估量(即便它们无法确保所有任务都成功完成)。
此外，像Claude Code这样的编程助手在帮助理解现有代码库运作机制方面表现卓越。这实为LLM最惊艳的应用场景之一——它能解析海量代码并为你拆解要点，让你迅速找到切入点。当尝试为他人仓库贡献代码时，这将带来_巨大帮助_。LLM还能协助定位修改点、编写补丁、搭建测试环境验证补丁、查找项目规范/风格指南、根据规范审查补丁，甚至撰写Git提交信息和PR描述。它们在开源贡献中能发挥作用的领域实在太多。
在我看来，主要问题在于那些为获取“贡献者信誉”而参与项目的人——他们提交PR只为付出最小努力却收获最大回报，而非真正为项目修复漏洞或添加功能。前者纯属噪音，而后者至少能让某个人受益(比如你)。
根据我的经验，程序员的大部分工作其实并不复杂。大型语言模型完全能胜任这类任务。
这与需要持续监护的自动驾驶汽车存在相似性。
我同意，但更进一步：若你对成熟和/或复杂的软件不甚熟悉，就假设自己错了。无论你如何验证，都应认为其存在错误。
Curl是极其可靠的老牌软件，其底层语言允许实现各种“邪恶”功能。
若发现疑似漏洞或缺陷，很可能并非如此。由于十五年前特定的开发背景，代码在实际运行中根本不会触发该问题。
若他心怀不满，为何不主动卸任？这正是我作为 libxslt 维护者所做的选择，也是我即将卸任 libxml2 维护者时将采取的行动。
不满程度本就存在差异。我们无权将工作态度简化为“热爱一切”或“恨之入骨”的二元对立，更不该假设放弃工作就能获得幸福。
需要明确的是，这并非对你选择退出多个项目维护工作的批评；我的观点是，这些选择具有高度个人化特征，权衡取舍之道往往并非显而易见。完全有可能他们已精疲力竭，此刻卸任反而能获得长远幸福；但也可能放弃心爱的事物会让他们更加痛苦，甚至愿意忍受那些不那么有趣的部分。以你的经验，想必能为这类决策提供宝贵见解。但即便是我这样，在维护曝光度远低于你项目的小型项目时也曾面临类似抉择，深知分析此类情况需要极多细致考量——尤其当观察者身处局外时。
我认为他只是在指出当前问题，这已非首次。作为项目维护者，他热衷于通过演讲和宣传推广项目，包括这类“项目现状说明”的发言。
我不认为他心怀不满。坦率地说，我认为他做得很对——作为一个从未这样做过却如今意识到应该这样做的项目创始人，我这么说。这正是吸引贡献者/捐赠/宣传的关键所在。
他并不感到不快乐
我认为，对于使用这些工具的亿万级企业而言，赞助维护工作并非过分要求。
有趣的是，这种现象在Perl时代就已存在。
我认为Perl并未获得应有的认可，尤其考虑到直到最近，几乎所有重要工作都是用Perl完成的。说真的，互联网的诞生正是得益于Perl。
> 我认为，对于使用这些工具的十亿美元级公司而言，赞助维护工作并非过分要求。
要求确实不高，但难点在于：1)找到合适的赞助对象；2)让对方跳出短期思维和预算框架，真正关注长期发展。
在幻灯片上点名表扬某家汽车制造商支持curl，成本极低却能博得大量关注。
真能吗？
有多少购车者会因企业对开源项目的捐赠而改变选择？
我——通常购买旧破车的群体。
我常询问公司如何支持开源项目。多数人听不懂这个问题，懂的人只会说我可以提交代码修改——虽然我确实提交过，但频率很低，因为我们只选择符合需求的优质项目：很少有漏洞或功能值得我们为此中断常规工作。
理想状态是存在非营利组织能接收资金并分配给我们使用的项目——可能需要法律审核确保其合法性(具体标准另议)。目前我只知道自由软件基金会(FSF)从事通用开发，但他们的理念普遍遭到企业反对，因此无法合作。
许多开源维护者不善于募资，而多数企业若无正式协议也难以随意拨款。
若您供职于资金充裕的企业，可尝试以下变通方案：
联系您所用软件的维护者，邀请他们通过Zoom向工程团队进行演讲，并支付讲演费。
贵公司熟悉支付顾问费用的流程，且很可能设有可调用的培训预算。
请注意：这并非要求维护者进行正式演讲——演讲需要耗费时间准备且需具备公开发言经验。
建议采用问答或炉边谈话形式。从团队中选派擅长主持/提问的成员主持。
时长控制在一小时，支付四位数报酬。
每月为其他依赖的项目重复此流程。
我_非常_赞同企业主动联系维护者，以丰厚报酬换取轻松远程咨询的常态化做法。这或许是让企业将资金导入关键技术贡献者口袋的隐性途径。
这个方案极具创意，我认为可行。
但确实存在副作用——会浪费1+n名工程师的这一个小时。首月或许能凑齐人手，但无法持续每月操作。
坦白说，只要建站平台提供“支持合约”选项就足够了。
需要补充的是：理解商业运作机制对他们支付报酬大有裨益。我曾提议支持某个项目(其官网有“赞助商”标识，可从营销预算中支出)，但对方仅接受PayPal付款(我们无法使用该渠道)，最终交易告吹。
更糟的是，该项目主页充斥着讽刺语气，充满对抗性——我推测这源于维护者不得不应对的种种无谓纷扰。最终资金未能到位。
我乐于支持开源项目，但能投入的社会资本终究有限。给维护者的建议是：若想获得赞助，请着力打造专业的沟通渠道，这确实大有裨益。
许多项目都有可合作的基金会或财务赞助机构。
若你关心Python，可支持Python基金会，或雇佣/赞助Python开发者；若关注Rust，则可支持Rust基金会，或雇佣/赞助Rust开发者。若您关注可重复构建、QEMU、Git、Inkscape、开源许可未来或其他各类项目(https://sfconservancy.org/projects/current/)，请支持软件自由保护协会。
若您关注的小型项目尚未建立赞助机制，可鼓励其通过现有渠道接受赞助，或加入Conservancy等财政赞助伞组织。
另一个此类伞式组织是公共利益软件基金会(SPI)。其资助的知名项目包括Arch Linux、Debian、FFmpeg、LibreOffice、OpenSSL、OpenZFS、PostgreSQL以及systemd。
主页：https://www.spi-inc.org/
Linux基金会(LF)也属于此类。作为非营利组织，其面向企业会员资助约900个开源项目。
希望GitHub能提供便捷的计费选项，自动向活跃仓库中的开源项目捐款。
为所有开源软件建立“库影响力”指标会很酷。首先收集所有部署软件系统在各平台的使用数据，并结合其他维度(如该系统与其他系统的关联性——是否为其他部署软件的常见依赖项或平台)。以此为基础生成部署软件单元的“影响力”值。通过二进制签名比对或开源构建系统识别其中编译的开源库。库的“影响力”值由其使用项目的综合影响力构成。
该影响力评分可用于指导非营利组织对关键开源软件的投资决策。但数据收集与需求校准仍具挑战性。
本质上是建立严谨的评分体系，以追踪https://xkcd.com/2347/中提出的直觉模型。
不过已有专注安全领域的评分体系：https://openssf.org/projects/criticality-score/
听起来像Tidelift
只需制定政策：凡向curl提交AI生成垃圾内容的“安全研究员”一律解雇。
从哪里解雇？他们海得拉巴理工学院的本科生身份？Daniel根本无权这么做。
确实存在疏漏环节，我也不敢说能在一个HN帖子里重塑社会，/但/我的意思是，当个烂学生必须承担现实后果。那封邮件是发自EDU邮箱吗？
向大学提交投诉。直接套用邮件模板反击。花一分钟就能找到学生事务处或院长的邮箱。整个机构里总该有一个人在乎吧。
每天浏览HN时，我总能找到理由回去继续开发PrizeForge
您尽管去吧，长官，我完全不介意。