文章核心观点 - Linux内核社区创始人Linus Torvalds反对为“AI生成代码”制定专门的提交规范文档，认为文档无法解决AI垃圾代码问题，并强调应将AI定位为“工具”，避免在文档中进行态度性表述，真正的解决方案在于代码评审机制、维护者判断力和社区文化 [1][3][5][6] Linux社区关于AI生成代码的争论 - Linux内核社区近期激烈讨论是否应为“工具生成代码”制定专门的提交规范，以应对AI编程助手和LLM自动生成补丁带来的“AI垃圾代码”涌入问题 [1] - 社区中存在两种极端声音：一派认为AI会毁掉软件工程，另一派认为AI将彻底革命化编程并实现自动化 [5] Linus Torvalds的立场与理由 - Linus Torvalds认为文档应聚焦“工具”本身，而非直接针对AI，因为无论是否编写文档，AI辅助提交都会持续存在 [1] - 他批评讨论AI垃圾代码“毫无意义”且“愚蠢”，因为提交低质量AI代码的人根本不会主动标注“这是AI生成的” [3] - 他指出试图通过强制标注AI辅助情况或更严格审核流程的文档来解决问题是“天真”的，文档只能约束“守规矩的人”，无法约束投机者 [3][4] - 他反对在内核文档中加入对AI的态度性表述，坚持AI的唯一定位就是“工具”，以避免社区卷入无谓的站队 [5] 对问题本质与解决方案的看法 - Linus Torvalds认为AI垃圾代码问题“绝对不可能靠文档解决”，寄希望于此是“自我安慰”，制定此类文档的动机要么太天真，要么只是想“表个态” [5] - 他指出这场争论本质上是Linux社区对未来的“集体焦虑”，反对将复杂的治理问题简化为“加一条规则就好了” [5] - 他强调AI参与内核开发是“不可逆的趋势”，真正重要的是代码评审机制、维护者判断力和社区文化本身，这些无法通过文档自动生成 [6]

事件概述 - 非营利组织Ruby Central在未提前通知的情况下，分两次移除了RubyGems和Bundler项目的长期维护者对GitHub组织的访问权限，引发社区强烈争议 [1][5][6] - 事件核心是开源项目管理权的冲突，Ruby Central以加强安全和治理为由进行接管，而长期维护者则认为这是“恶意接管”和“敌意行为” [1][6][7] Ruby Central的行动与理由 - 2024年9月9日，一位RubyGems维护者单方面将GitHub企业账户重命名为Ruby Central，并添加Marty Haught（Ruby Central开源总监）为维护者，同时移除了所有其他维护者 [4][5] - 在遭到质疑后，相关操作大部分被撤销，Marty Haught称首次移除维护者是一个“永远不该发生的错误” [5] - 2024年9月18日，Marty Haught再次在没有解释的情况下，撤销了所有RubyGems、Bundler以及RubyGems.org维护团队管理员的GitHub组织成员权限 [6] - Ruby Central于9月19日发布官方声明，称此举是为了履行其“维护供应链和生态系统长期稳定的受托责任”，在咨询法律顾问并进行安全审计后，正在加强治理流程 [11] - Ruby Central董事会成员解释，行动源于对软件供应链攻击风险的担忧，为确保安全，今后只有其雇佣或签约的工程师才能拥有RubyGems.org服务的管理权限 [11][12] 维护者的反应与影响 - 长期维护者Ellen Dash（网名duckinator）发布PDF文件实名举报此事，称自己从13岁起参与Ruby社区，作为RubyGems维护者已超过十年 [2][5] - Ellen Dash决定立即辞去在Ruby Central的职务，以抗议其“单方面撤销访问权限”的行为 [9][10] - 另一名核心维护者André Arko也已告别社区，对失去社区驱动的控制权表示遗憾 [20] - 维护者Ellen Dash指出，Ruby Central的行为“已经越过了底线”，并且“对整个Ruby社区构成威胁” [6][7] 社区与行业的反响 - 事件在Ruby社区引发巨大争议，Apache CouchDB开发者等社区成员公开质疑Ruby Central的做法 [1][14] - 社区开发者批评Ruby Central的“受托责任”说法是对“换取控制权”行为的美化，并质疑其受到企业赞助者的影响 [14] - 有观点指出，Ruby Central并不拥有RubyGems源代码的版权，其角色本是管理基础设施和支付维护费用，无权单方面决定维护团队组成 [16] - Homebrew项目负责人Mike McQuaid曾尝试调解但未成功，并批评Ruby Central处理此事“非常糟糕” [19]