当我让 Internet 决定哪些 code 被 merged 时会发生什么（第 1 周）

Source: Dev.to

一个仓库让互联网决定哪些内容会被发布——随后发生了什么。

2026 年 1 月 5 日，23:12 UTC – 我推送了一个提交：一个带有倒计时计时器和拉取请求列表的简单 Next.js 应用。

规则

• 任何人都可以提交 PR。
• 社区通过 👍 表情投票。
• 获得最多投票的 PR 将在每个星期日合并。
• 一切都可以被更改——包括规则本身。

我把它称为 OpenChaos。

六天后，它登上了 #1 on Hacker News。

这是 第 1 周 的故事。

The Numbers

Day 1 – Bootstrap

MVP 只用了一个晚上：倒计时计时器、打开的 PR 列表，以及从 GitHub 的 reactions API 获取的投票计数。

我自己提交了第一个 PR：dark‑mode toggle ——因为每个项目都需要一次暗模式的讨论。

几个小时后，我不再是唯一的提交者。

第2天 – 虚无主义者的到来

PR #2: “投票关闭它”
@Salman‑Sali 提交了一个会删除所有内容的 PR（共删除 7,108 行）。描述为空。

“投赞成票的人可能是特朗普的支持者”

Salman‑Sali 回复道：

“嘿，先生，这不是我选择混乱的”

该 PR 未通过 CI。民主有了护栏。

但故事并未结束。

第3天 – 领跑者出现

PR #6: “Calculate +1 and -1 reactions”
@yokeTH 提交了一个功能，能够同时统计负赞（down‑votes）和正赞（up‑votes）。净分数将决定获胜者。

这确实是一次实质性的改进——也是一把武器。一旦负赞被计入，“Vote to shut it down” PR 的支持度就开始下降。

第 4 天 – 我打破了自己的规则

站点显示的投票数不正确。PR #1 实际有 147 票，却只显示 30 票。GitHub 的 API 对响应进行分页，而我没有考虑到这一点。

我面临两个选择：

1. 等待有人提交修复，让社区对其进行投票。
2. 直接推送修复，使投票能够正常工作。

我选择了后者。

在第一次修复后，我遭遇了速率限制（未认证情况下每小时 60 次请求），于是不得不再推送一次修复。

你不能对是否正确计票进行投票。那是循环论证。

投票系统必须先正常工作，民主才能运作。每一次干预都像是对前提的微小背叛。

第 4 天 （第 2 部分） – 示范

@Kl0ven 开了 30 个标题相同的 PR，标题为 “should have use proper pagination :(”。我认为这是垃圾信息，全部关闭了。

Kl0ven 通过了一个：PR #45 “F, At least I tried”（当前投票数：–4）。

事实证明这是一场漏洞演示：GitHub 的 API 默认返回 30 条结果。通过向仓库大量提交 PR，Kl0ven 把较早的提交推到了该限制之外，使它们完全从排行榜中消失。他们并不是在刷屏，而是揭示了我之前未曾意识到的缺陷。

第 5 天 – 戏剧性的退出

随着差评开始计入他的记录，@Salman‑Sali 关闭了自己的 PR 并留下了这条信息：

感谢所有支持我的人。
我非常遗憾地宣布，我将退出这场竞争。
那些大额资金支持的 PR 已经对我下了阴谋。他们也想算上负面投票。巨额金钱已经影响了这次选举。我不能容忍这种不公。
因此，我决定退出这场竞争。

有人回复：

“停止计数！”

一个 GitHub PR 竟然变成了政治讽刺。

第 5 天 （第 2 部分） – 创作者的牺牲

我的 暗色模式 PR #1 正在领先（228 赞），本应成为第一个被合并的 PR。但我感觉有些不对劲，于是撤回了它：

“撤回是为了让首个合并完全由社区驱动。让混沌来决定。”

当被问及原因时：

“赢得自己的游戏感觉不妥。”

首个合并必须属于社区。

第 6 天 – 梗变成现实

PR #13: “Rewrite it in Rust”
每个项目最终都会收到这条评论。@wvanlit 决定真的去做：一次完整的 Rust 重写，编译为 WASM，准备发布。

唯一的问题是——Vercel 构建一直失败：

Module not found: Can't resolve '@/wasm/pkg/openchaos_wasm'

梗已经成真，但它编译不出来。

社区反应：

“一旦完成，我们就可以把它放进 Linux 内核”

第 6 天 – Hacker News

350 + points, 70 + comments – 首页第一。

评论很精彩：

• “Twitch plays GitHub”
• “Like Reddit but Nomic”
• “Codified Dadaismus”
• “它是一个荒诞主义艺术软件项目，缺乏任何一致的意图或目的，

  超出其运作原则。”

有人问这有什么意义。

最佳回复：

“我认为没有意义。你随时可以提交一个意义；如果它被投票通过，你就拥有了你的意义。”

第一次合并

2026年1月12日星期日 · 09:00:37 UTC

我合并了 PR #6: “Calculate +1 and ‑1 reactions”，作者是 @yokeTH。

最终得分： 903 upvotes

OpenChaos 的第一次社区驱动的更改让 downvotes 计数。这个最初以纯 up‑vote 民主制启动的项目现在首次对权力进行检查。讽刺的是，我并没有忽视这一点。

第 2 周开始

排行榜已重置。出现了新的竞争者：

Rust 重写在第 2 周领跑。如果有人修复了构建，这个梗就会成为现实。

我学到的

1. 人们想要为混乱添加结构。
   获胜的 PR 添加了点踩计数。第三名的 PR 改变了合并频率。治理是社区的第一本能。

2. 梗会变成现实。
   “用 Rust 重写” 正在领跑第 2 周，可能真的会实现。

3. 每个系统都会被利用。
   在 48 小时内，大家讨论了投票操控、诱骗式提交以及机器人攻击。安全讨论在第一次合并之前就已经开始。

4. 戏剧会自行上演。
   我没有策划政治讽刺或戏剧性的撤回。混乱自行生成了叙事。

5. 维护者无法保持中立。
   我尝试保持不干预，却最终推送了修复并关闭了垃圾信息。@Kl0ven 揭露了我遗漏的一个 bug——他们没有错。

接下来

• PR #13 – 可能会给我们一个 Rust 重写（如果有人修复构建的话）。
• PR #51 – 可能会把合并改为每日。
• PR #47 – 可能会把我们送回 1999 年。

这就是重点。

规则可以改变规则。混沌就是特性。

400 + 星，Hacker News 首页，以及我见过的最棒的 GitHub 剧情。我接受它。

— Max (@skridlevsky)

openchaos.dev

∞ 的第 1 周。周日见。