月下载1.3亿的库被AI重写并改了协议，开源维护者遭“网暴”后发声：我觉得大家反应有点过头，当时联系不到原作者，新版是重写
事件背景：月下载量过亿的明星项目
本次事件的核心是一个在开发者社区极具影响力的开源库，其在npm上的月下载量高达1.3亿次，被广泛应用于无数项目中。该库最初的维护者（原作者）参与了另一个开源项目，并任命了另一位开发者作为库的维护者。然而，随着时间的推移，原作者与社区的联系逐渐减少，其GitHub账号也长期处于无活跃状态。
矛盾爆发：AI重写与协议变更引发众怒
在尝试联系原作者但未收到任何回应后，现任维护者面临了一个困境：如何对一个历史遗留、无人维护且代码质量有待提升的庞大项目进行现代化改造？最终，他选择了一种颇具争议的方式——借助AI工具对整个代码库进行了彻底的重写，并将项目的开源协议从宽松的MIT协议更改为限制性更强、要求使用者必须开源修改后代码的GPL协议。
这一改动迅速在开源社区引发了轩然大波。许多开发者和公司依赖MIT协议的自由性，GPL协议的变更将严重影响他们的商业应用和后续开发。大量用户涌向维护者的社交媒体和GitHub进行指责，批评其未经社区充分讨论就擅自更改核心库的协议，甚至有人发起了恶意的人身攻击，形成了所谓的“网暴”。
维护者回应：沟通无果下的无奈之举
面对铺天盖地的指责，该维护者最终站出来发声，他直言：“我觉得大家反应有点过头了。” 他详细解释了整个事件的来龙去脉：
- 联系原作者失败：他多次尝试通过邮件、GitHub站内信等各种方式联系原作者，希望能共同商讨项目未来的发展方向，但始终石沉大海，无法建立有效沟通。
- 重写是唯一选择：由于原代码库存在大量历史问题，且无人拍板进行现代化重构，他最终决定使用AI工具从零开始重写整个库，以解决性能和可维护性问题。
- 协议变更的初衷：更改协议的目的是为了确保所有基于这个新版本的二次开发和修改也能回馈给社区，防止商业公司无限制地“薅羊毛”。他认为这能更好地促进开源生态的健康发展。
社区反思与未来影响
此次事件在开源社区引发了关于“责任感”、“社区治理”和“开发者沟通”的深刻讨论。
- 授权与治理的困境：当一个项目拥有巨大影响力但原作者却“失联”时，社区应如何建立有效的治理机制来避免项目停滞或陷入混乱？
- 沟通的重要性：维护者在采取重大变更（如修改协议）前，是否应进行更广泛、更透明的沟通以争取社区共识？
- AI在开源中的角色：AI在辅助或主导重构开源项目时，如何确保代码的可靠性和安全性，以及如何界定其生成的代码版权归属？
尽管维护者的解释缓解了一部分争议，但关于协议更改的讨论仍在继续。此事也为所有大型开源项目的维护者敲响了警钟：在技术迭代和社区期望之间找到平衡，需要的不仅仅是技术能力，更是高超的沟通和社区管理艺术。