十年积累，5.4万GitHub Star一朝清零：开源史上最大意外损失

| 2022-04-18

我们找 GitHub CEO 求助，但为时已晚。

2022 年 2 月 15 日，GitHub 通过undefined平台广播了一则消息：「我们的朋友 HTTPie 最近不小心将自己设为了私密，丢掉了所有的 Star。如果你仍然爱它，就给它一颗 Star 作为情人节礼物。」

图12: 十年积累，5.4万GitHub Star一朝清零：开源史上最大意外损失

10 年攒下的 Star 突然清零？这是怎么回事？

昨天，项目作者 Jakub Roztočil 在博客中正式回应了这一事件。

十年获得 5.4W Star 的开源项目

HTTPie 项目的第一次提交还是在十年之前。

图10: 十年积累，5.4万GitHub Star一朝清零：开源史上最大意外损失

可能一些人对这个项目不够熟悉，这是一个开源 CLI HTTP 客户端。团队从头开始构建了它，以使终端的 API 交互尽可能人性化。

HTTPie（发音为 aitch-tee-tee-pie）可用于测试、调试以及通常与 API 和 HTTP 服务器交互。http&https 命令允许创建和发送任意 HTTP 请求。它们使用简单自然的语法，并提供格式化和彩色输出。

从 2012 年 2 月 25 日在哥本哈根的第一次公开提交之后，项目作者 Jakub Roztočil 就一直在 GitHub 平台上托管该项目。他自己也是 GitHub 平台的忠实粉丝。

这些年来，HTTPie 逐渐成长为平台上最受欢迎的 API 工具，收获了 5.4W 个 Star 和 1k 的关注。

HTTPie 项目受益于 GitHub 的「social coding」功能，同时，GitHub 也受益于自身平台上托管的这个受欢迎的项目。在过去十年中，可能有数百万开发人员访问了 HTTPie 项目的 GitHub 页面。

但在几周前，HTTPie 项目积累的 5.4W Star 一夜清零。

在这篇博客中，项目作者 Jakub Roztočil 详细介绍了事情经过：

发生了什么？

我不小心将项目的 repo 设为了私有，GitHub 级联删除了我们花费 10 年时间建立的社区。

这意味着什么？

如果你是一位下游维护者，或者曾经关注过 HTTPie 以获取通知，你可能需要重新关注一下 repo。

Star 也是一样，如果过去十年里你曾为该项目加注 Star，那现在 HTTPie 应该已不再是你的 Star 项目列表中的一员。

为什么要将 repo 设为私有？

将 repo 设为私有会永久删除所有关注者和 Star，这是 GitHub 的一个特性。我知道这一点，而且我显然无意 httpie/httpie 隐藏。

最直接的原因是我认为我在另一个 repo 中——一个没有内容且 0 Star 的项目。我真正打算做的是隐藏 HTTPie 组织的配置文件 README，这是我在一周前创建但没有机会填充的。

让我走上错误道路的是一个完全不相关的操作：我刚刚在我的个人资料上做了同样的事情（即隐藏了一个空的 README），将其设为 jakubroztocil/jakubroztocil 私有。

在配置文件和存储库方面，GitHub 的概念模型会将用户和组织视为非常相似的实体。在这种情况下，由于我只是想在我们组织的个人资料上重复相同的操作，我的大脑切换到了「自动驾驶」模式。

目前我没有意识到这个包含配置文件 README 的特殊 repo 的命名存在不一致问题，并且它对于用户和组织有所不同：name/name 与 name/.github.

这就是为什么我一开始要隐藏 httpie/httpie，而不是 httpie/.github，并且没有意识到我的错误。

但是，还有一个确认流程？

确实有一个确认框，旨在阻止像我这样的情况下的用户做一些愚蠢的事情。它会告诉你「你将永远失去这个存储库的所有 Star 和关注者」。

问题在于，对于没有提交和任何 Star 的 repo ，它的提示框和具有 10 年历史及 55k Star 与关注者的 repo 是完全一样的。它说的是：「警告：这是一个潜在的破坏性行动。」

套用一句话：一个盒子告诉你「你要拆房子！如果里面有人，他们都会死。」但如果你混淆了地址并认为你正准备拆的是一个空房子，那后果将不堪设想。

实际上，此处的对话应该更加结合上下文，并且再次解释一下情况，比如说「你即将杀死 55000 人。」那肯定会让我停下来。

一番操作之后

当我回到组织页面时，你可以想象我的困惑，我不仅仍然可以看到空的 README，同时我们最受欢迎的 repo 找不到了。片刻之后，我意识到发生了什么事。所以我回到 repo 的设置来翻转开关。但 GitHub 不允许我这样做——整整半个小时。

为什么这么久呢？因为这是 GitHub 级联删除我们 10 年来的 Star 和关注者所花费的时间。而且我没有办法阻止这个过程。我所能做的就是开始发消息给 GitHub 寻求支持，刷新页面并等待 Star 数量达到零，然后才能再次将其公开。

为什么 GitHub 不给我们恢复呢？

GitHub 显然有备份，并且有恢复 repo 的方法。GitHub 团队曾经自己不小心将 GitHub 桌面应用程序 repo 设为私有，然后他们在几个小时内就恢复了一切，当时前 GitHub CEO 给出的解释是：

图11: 十年积累，5.4万GitHub Star一朝清零：开源史上最大意外损失

然而，在我们的事件中，他们拒绝这样做，理由是操作具有不良影响，并且会消耗资源成本。我们甚至提出为所需的任何资源提供经济补偿，但遗憾的是，他们还是拒绝了。相对于在 GitHub 上恢复最受欢迎的社区项目之一以外，他们还有其他优先事项。

因此，GitHub 恢复存储库的前提是他们自己的项目，而不是社区项目。

经验教训

这次危机让我们得到了很多教训，这里主要分享 3 点：

教训 1：UI/UX 设计

弹出的对话框要清晰明了，减少抽象的文字说明。以一种不需要用户思索的方式设计确认对话框。当用户要删除或损坏某些文件时，不要用抽象的语言描述，以免让用户难以了解即将发生的状况，特别是会造成级联删除的行为。例如，以下是我们在 HTTPie for Desktop 中的处理方式：

对话框需要反映操作影响的严重性。当完全没有额外影响时，对话框应该尽量简单，否则会浪费用户有限的注意力，从而降低用户的敏感度：

教训 2：数据库设计

使用软删除（soft-delete）。人非圣贤，孰能无过。人们在删除操作上可能会犯错误，因此应该尽可能使用软删除，延迟硬删除（hard-delete）操作。

教训 3：与 GitHub 的关系

这是我们的人为错误，GitHub 明确表示他们没有法律义务帮助我们。我们长达十年的互惠互利关系是根据 GitHub 的服务条款确定的，除此之外，再无其他。

毕竟，GitHub 有过有争议的行为，这些行为违背了开源社区的精神。undefined（已收购 GitHub）尽管拥有一定的开源精神，但并不总是有很好的声誉。

我们希望 GitHub / 微软有朝一日能够改变他们的态度，并恢复我们的项目社区，他们拥有实现这一点的所有数据和方法。我们也希望他们改进 UI 和数据库设计，以防止这种情况未来发生在其他团队身上。

最后，尽管我们的 GitHub star 量化为虚无，但 HTTPie 现在发展得非常好，从最初作为一个副项目到现在变成了一家公司，我们的团队正在将 HTTPie 发展成一个 API 开发平台。用于 Web 和桌面的 HTTPie 私有测试版收到了很好的反馈，我们迫不及待地想在接下来的几周内公开发布它。