开源并不意味着开放社区

Source: Hacker News

早期的开源实践

开源软件早在（分布式）版本控制系统（(D)VCS）出现之前就已经存在。
作者可能只是在一个简陋的 HTML 页面或纯文本文件中描述项目。可能在某处有一个 FTP 服务器存放 tar 包，作者可能可以通过电子邮件联系到。如果运气好，还会有一个用于公告和讨论的邮件列表，甚至可能有一个以软件名称命名的非官方 IRC 频道。

这就是且仍然是开源。

没有正式的“社区”，没有政治，没有行为准则，没有拉取请求或议题，没有 wiki，没有核心团队。

后来，像 SourceForge 这样的网站提供了 CVS/SVN 托管和邮件列表，基本上是“免费”的，使得在公开环境中构建变得更容易。分布式版本控制工具的兴起——尤其是 Git——导致了向 GitHub 的集中。

GitHub 把大量开源工作变成了维护者的无偿工作。贡献者现在需要处理工单、会议、路线图、办公室政治、截止日期、指标、关键绩效指标（KPI）、站会、一对一、敏捷或瀑布式流程，以及不断涌来的通知、议题和拉取请求。一个“社区”往往会出现，维护者会觉得自己对其负有责任，即使他们从未签约加入。这可能导致倦怠以及对自己项目的控制权丧失。

并非必须如此

有些项目规模庞大、复杂，需要团队协作，但这属于例外，而非常规。

如果你对大量新贡献者和 AI 机器人感到沮丧，可以考虑回归更简单的做法：

• 关闭议题跟踪和拉取请求系统，或部署一个仅用于发布的裸 Git 服务器。
• 与一小群可信的合作者合作，或单独开发。
• 不必觉得必须让陌生人进入你的空间。
• 若行为准则或大语言模型（LLM）政策对项目没有帮助，可跳过这些表面功夫。

开源并不需要在公开环境中开发才能称为“开源”。写代码，构建你喜欢的东西，使用你偏好的任何工具——无论是圣诞节凌晨 2 点提交，还是任何适合你的时间安排。避免把项目变成半技术孵化器、半托儿所，给缺乏社交技巧的人提供“日托”。