一次误将仓库设为私有的操作，让HTTPie十年积累的5.4万颗星与上千关注者被GitHub永久级联删除，而平台拒绝恢复，揭示了开源项目对托管平台的脆弱依赖。

我们如何失去了54,000颗GitHub星星

背景：一个十年开源项目的辉煌

HTTPie for Terminal 刚刚庆祝了它的第一个commit十周年。如果你对这个项目不熟悉，它是一个开源的命令行HTTP客户端。HTTPie的独特之处在于，我们从零开始构建，致力于让终端中的API交互尽可能人性化。

2012年2月25日，在哥本哈根一个阴雨绵绵的日子里，我们发布了第一个公开版本，并将项目托管在GitHub上。早在几年前我就成为了GitHub的会员（还是那种会穿印着Octocat图案衬衫的忠实粉丝），那时的GitHub还在主页上自豪地宣称他们拿了$0.00的风险投资，并告诉你他们旧金山办公室有多少种美味的精酿啤酒。

当我意识到自己为了解决API测试痛点而写的工具可能对更广泛的开发者社区有价值时，GitHub显然是最自然的选择。事实也证明了这一点——我至今记得HTTPie第一次登上Hacker News头条时的兴奋感，以及看到GitHub社区逐渐壮大的激动。

多年来，随着我们持续改进项目，它获得了广泛的采用。它成为该平台上最流行的API工具，GitHub社区增长到了54,000颗星和1,000+关注者。考虑到GitHub上有2.89亿个公共仓库，HTTPie位列全站最受欢迎的公共仓库前80名——处于99.99997203百分位。

简而言之，看到这个不起眼的小工具吸引如此规模的社区，实在令人难以置信。而GitHub在其中扮演了重要角色。就像我们从GitHub的"社交编程"特性中获益一样，GitHub也因我们在其平台上托管这个流行项目而获益。过去十年间，可能有数百万开发者访问过我们的GitHub页面，这有助于巩固GitHub（微软）作为一家关心开源和社区的公司形象。这是一种共生关系。

灾难降临：54,000颗星一夜消失

然而，如果你曾是我们的55,000名加星者和关注者之一，那么从几周前开始，你不再是了💔

发生了什么？

由于一系列不幸的事件，我意外地将项目仓库设置为私有状态。GitHub随即级联删除了我们花费十年建立起来的社区。

这意味着什么？如果你是一个下游维护者，或者任何之前关注了httpie/cli以获取通知的人，你需要重新关注这个仓库。（顺便提一句，我们最近刚发布了一个安全更新。）加星也是如此——如果你曾是过去十年间给这个仓库加过星的54,000人之一，那么这个仓库已不再出现在你加星的项目列表中。

为什么会设为私有？

说得委婉一点，GitHub的一个特性是：将仓库设为私有会永久删除所有关注者和加星者。我其实知道这一点，而且显然无意将httpie/cli设为私有。

那么，原因何在？

直接原因是，我以为自己正在操作另一个不同的仓库——一个没有任何内容、零颗星的仓库。我本来的意图是隐藏HTTPie组织的profile README（我一周前创建的，还没来得及填充内容）。

让我走上错误道路的是一个完全不相关的操作：我刚刚对自己的个人主页做了同样的事情（隐藏了一个空的README），即将jkbrzt/jkbrzt设为私有。GitHub的概念模型将用户和组织在配置文件和仓库方面视为非常相似的实体。在这种情境下，因为我只是想在组织主页上重复同样无害的操作，我的大脑进入了自动驾驶模式。

当时我没有意识到，包含profile README的特殊仓库在命名上存在不一致，用户和组织的命名规则不同：用户是name/name，而组织是name/.github。这就是为什么我误将httpie/cli设为私有，而不是httpie/.github——完全没有意识到自己的错误。

确认对话框的欺骗性

你可能会问：有确认对话框，对吧？

确实有。它的设计初衷就是阻止像我这样的用户做傻事。它会告诉你："你将永久失去这个仓库的所有星星和关注者。"这听起来相当吓人。

问题在于，这个对话框在"没有任何commit和星星的仓库"与"拥有十年历史和55,000个加星者及关注者的仓库"之间看起来完全一样。它只是说："警告：这是一个潜在破坏性的操作。"

用比喻来说，这个对话框告诉你："你即将拆除一栋房子。如果里面有人，他们都会死。"但它没有包含任何具体信息来打破你的自动驾驶模式——如果你搞混了地址，以为你看到的是一个空房子。

一个价值54,000颗星的问题：下面这两个对话框中，哪个可以安全确认，哪个会删除一个存在了十年的社区？答案是：看起来一模一样，无法区分。

对话框应当更具上下文相关性。再打个比方，它应该说："你将杀死55,000人。"这肯定会让我停下来思考。

翻转开关？没那么简单

你可以想象当我回到组织页面时的困惑：我不仅仍然能看到那个空的README，我最受欢迎的仓库竟然消失得无影无踪。片刻之后，我意识到发生了什么。于是我回到仓库设置页准备翻转开关——但GitHub不允许我这么做，整整半小时。

为什么这么久？🥁 因为这就是GitHub级联删除我们十年积累的加星者和关注者所需的时间。而且没有办法停止这个过程。我所能做的就是开始给GitHub支持写邮件，刷新页面，等待星星数降到零，然后才能将仓库重新设为公开。

为什么GitHub不恢复数据？

GitHub显然有备份。事实上，意外将仓库设为私有所造成的损害是可以撤销的。GitHub团队自己就曾意外将GitHub Desktop应用的仓库设为私有过——他们在几小时内就为自己恢复了一切。前GitHub CEO曾解释过这一情况（他承认这是一个已知的悲剧性副作用，承诺未来会有更好的解决方案）。

但在我们的案例中，他们拒绝恢复，理由是不良副作用和资源成本。我们甚至主动提出为所需的任何资源提供经济补偿，但遗憾的是，他们拒绝了。他们似乎有其他优先事项，而不是去恢复其平台上最古老、最受欢迎的社区项目之一的社区。

所以，这个问题的答案不幸如下：GitHub会恢复因设为私有而受损的仓库，但仅限于他们自己的项目，而不是社区项目。后者的遭遇，最好的情况就是得到一条推文。

经验教训

永远不要浪费一场好危机。我们的选择有限，但至少有几点经验教训可能值得分享。

教训一：UI/UX设计——展示，而非告诉

确认对话框的设计应遵循"不要让我思考"的原则。当用户即将销毁某些东西时，不要用抽象的词语来描述潜在场景，因为用户需要将这些词语转化为心理图像并赋予价值——尤其当级联删除只是主要操作的副作用时。

例如，以下是我们在HTTPie for Desktop中的处理方式：对话框会直观地展示将要删除的内容，并明确说明影响范围。如果我在GitHub上看到的也是这样的对话框，"10年历史"、"54,000星"、"1,000关注者"这些具体数字清晰地摆在我面前，我绝不会继续操作。

此外，对话框应当反映副作用的严重程度。当没有副作用时，它应该保持安静。否则，我们可能会让用户对警告麻木——这是在浪费用户有限的注意力资本。试想，如果每次删除一个空文件都弹出"警告：你正在删除内容"，用户很快就会习惯性地点"确认"，等到真正危险的时刻，他们已经不会仔细看了。

教训二：数据库设计——使用软删除

人是会犯错的。对于硬删除，应该延迟处理过程。GitHub的设计在这里也存在根本性问题：为什么一个"设为私有"的操作需要立即级联删除所有关联数据？从数据库设计原则来看，正确的做法是软删除：将仓库标记为私有，但保留元数据（星星、关注者），设置一个确认期（如24小时），在此期间用户可以撤销操作。如果用户确实有意删除，再在延迟后真正清理。这样既能保护用户的误操作，也不影响有意的删除需求。

教训三：与GitHub的关系——认清平台权力的本质

这是我们这边的人为错误，GitHub也明确表示他们没有法律义务帮助我们。我们这段长达十年的互利关系基调，是由GitHub的服务条款设定的。认为这其中有更多人情味，是我们太天真了。

毕竟，GitHub有着采取有争议行动的历史，这些行动违背了开源和社区的精神，然后在这些争议发酵后又被迫改变方向或道歉。我们的遭遇并非孤例——许多开源项目主理人都曾公开批评过GitHub对社区资产的单方面控制权。作为一个开源项目，我们以为自己是平台的"公民"，但实际上我们只是"用户"。平台可以随时改变规则，而我们几乎没有谈判筹码。我们只能希望这次公开记录能让其他开源维护者引以为戒。

同时，我们也开始反思对GitHub的过度依赖。一个健康的开源项目，应该考虑在多个平台分发、建立自己的社区阵地、维护独立的邮件列表或讨论论坛，而不是把所有鸡蛋放在一个篮子里。当然，GitHub的网络效应是巨大的，完全脱离它并不现实，但至少要意识到这种依赖的风险。

结语

最终，这54,000颗星星不仅仅是数字——它们代表着成千上万开发者的认可、关注和信任，是十年开源贡献的见证。它们的消失提醒我们，在享受平台便利的同时，开源项目与托管平台之间的权力关系是多么不对等。

我们选择公开这件事，不是要博取同情，而是希望引起讨论：当平台掌握了社区资产的生杀大权时，如何保障开源项目的权益？这个问题，值得整个开发者社区一起思考。

如果你曾是我们的加星者或关注者，并愿意继续支持我们，欢迎重新访问 github.com/httpie/cli 并再次加星。我们依然在这里，继续做着热爱的事。

---

原文链接：https://httpie.io/blog/stardust