GitHub 上 5.4 万颗星是如何流失的

获得 54,000 个 GitHub 星标

如果您不熟悉这个项目，它是一款开源的 CLI HTTP 客户端。HTTPie 的与众不同之处在于，我们从零开始构建它，力求使终端的 API 交互尽可能人性化。

从 2012 年 2 月 25 日在阴雨绵绵的哥本哈根发布的第一个公开版本开始，我们就在 GitHub 上托管了该项目。

自从几年前成为 GitHub 的会员（就是那种穿着章鱼猫图案 T 恤的那种）以来，我就一直是它的粉丝。那时候，GitHub 的“关于”页面上还自豪地宣称他们没有接受任何风险投资，还告诉你他们旧金山办公室里有多少种美味的啤酒可供选择。

因此，当我意识到自己解决 API 测试难题的结果可能会引起更广泛的开发者社区的兴趣时，GitHub 成了我自然而然的选择。事实也确实如此。

我还记得 HTTPie 首次登上 Hacker News 热门链接时，GitHub 社区蓬勃发展的景象。多年来，随着我们不断改进项目，它逐渐被广泛采用。它成为了平台上最受欢迎的 API 工具，GitHub 社区也发展壮大，拥有 5.4 万名 Stargazer 和 1000 多位关注者。

HTTPie拥有2.89 亿个公共代码库，因此它跻身 GitHub 上最受欢迎的 80 个公共代码库之列，占比高达 99.99997203%。简而言之，看到这个不起眼的工具吸引如此规模的社区，真是令人难以置信。而 GitHub 在其中发挥了重要作用。

正如我们从 GitHub 的“社交编码”功能中受益一样，GitHub 也因我们在其平台上托管这个热门项目而受益。在过去十年中，可能有数百万开发者访问了我们的 GitHub 页面。这有助于强化 GitHub（微软）作为一家关心开源和社区的公司的地位。这是一种共生关系。

GitHub 星标丢失 5.4 万

然而，如果你是我们 55,000 名观星者和观察者之一，那么从几周前开始你就不再是了 💔

发生了什么？

由于一系列不幸的事件，我无意中将项目的仓库暂时设为私有。GitHub 也因此连环删除了我们耗时十年建立起来的社区。

这是什么意思？

例如，如果您是下游维护人员，或之前关注过httpie/httpie通知的用户，则需要重新关注该代码库。顺便提一下，我们最近发布了一个安全更新。

加星标也一样。如果你是过去十年中为某个代码库加星标的 5.4 万人之一，那么该代码库将不再属于你的加星项目。

你为什么要把这个 repo 设为私有？

委婉地说，GitHub 的一个特点是，将仓库设为私有会永久删除所有关注者和点赞者。我当时甚至意识到了这一点，而且我显然无意将其设为httpie/httpie私有。那么，为什么呢？

最直接的原因是，我误以为我进入了另一个仓库；一个没有内容、星数为零的仓库。我实际上想做的是隐藏HTTPie 组织的简介 README 文件，该文件是我在前一周创建的，但一直没机会更新。

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

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

我目前没有意识到这个包含配置文件自述文件的特殊 repo 的命名存在不一致，并且对于用户和组织而言是不同的：name/namevs. name/.github。

这就是为什么我继续将其设为httpie/httpie私密，而不是httpie/.github没有意识到自己的错误。

但有确认，对吧？

有一个确认框。它是为了防止像我这样的用户做出愚蠢的行为而设计的。它会告诉你“你将永久失去此仓库的所有星星和关注者”。这听起来挺吓人的。

问题在于，对于没有提交和星标的仓库，以及对于拥有十年历史、拥有 5.5 万星标者和观察者的仓库，该提示框看起来完全一样。并且会显示“警告：此操作可能具有破坏性”。

换句话说，盒子告诉你“你即将拆毁一所房子。如果里面有人，他们都会死”。

但是，如果您混淆了地址并认为您正在看一栋空房子，它不会包含任何具体内容来帮助您摆脱自动驾驶模式。

一个 54k 星的问题：这两个对话框中哪一个可以安全确认，哪一个会删除一个已有 10 年历史的社区？

对话应该更具语境，再次解释一下，应该是“你即将杀死 55,000 人。”这肯定会让我停下来。

所以你把它设为私密，只需拨动开关！

你可以想象当我回到组织页面时，我不仅仍然能看到空的 README 文件，而且我们最受欢迎的仓库也找不到了，我当时有多困惑。过了一会儿，我意识到发生了什么。于是我回到仓库的设置页面，想切换开关。但 GitHub 不允许我这么做——整整半个小时。

如果你想知道为什么这么久，那是因为 🥁 GitHub 花了这么长时间才级联删除了我们十年来的 stargazers 和 watchers。而且没有办法阻止这个过程。我所能做的就是开始写信给 GitHub 支持，刷新页面，等 star 数降到零，我才能再次公开。

GitHub 为什么不恢复它？

GitHub 显然有备份。而且确实可以撤销意外将仓库设为私有造成的损害。GitHub 团队自己也曾意外将GitHub Desktop 应用的仓库设为私有。但他们在几个小时内就恢复了一切。以下是 GitHub 前 CEO对当时情况的解释：

然而，就我们而言，他们拒绝了，理由是副作用和资源成本过高。我们甚至承诺向 GitHub 提供所需资源的经济补偿。但遗憾的是，他们拒绝了。他们还有其他优先事项，而不是重建平台上最古老、最受欢迎的社区项目之一。

所以，很遗憾，这个问题的答案是：GitHub 会修复因私有化而受损的仓库。但前提是它是 GitHub 自己的项目，而不是社区项目。社区项目最多只会收到一条推文。

经验教训

绝不能浪费一次良性危机。我们的选择有限，但至少有一些经验教训值得分享。

课程 #1：UI/UX 设计

展现而非诉说。设计确认对话框时，要避免“让我思考”。当用户即将销毁某些内容时，不要用抽象的语言将其描述为潜在场景，而需要用户将其转化为心理图像并赋予其价值。尤其是在级联删除作为主要操作的副作用时。例如，我们在HTTPie 桌面版中就是这样做的：

当然，对话框应该反映副作用的严重程度。当没有任何副作用时，对话框应该保持安静。否则，我们可能会浪费用户有限的注意力，导致用户变得麻木：

课程 #2：数据库设计

使用软删除。人都是人，都会犯错。对于硬删除，请延迟删除过程。

课程 #3：与 GitHub 的关系

这是我们的人为失误，GitHub 也明确表示他们没有法律义务帮助我们。我们长达十年的互惠互利关系的基调是由 GitHub 的服务条款决定的。认为事情还有更多问题的想法太天真了。

毕竟，GitHub 曾有过一些有争议的举动，违背了开源和社区的精神，然后仅仅因为公众的愤怒才撤销这些举动。而微软（现在拥有 GitHub）尽管最近对开源产生了浓厚的兴趣，但其声誉并非一直很好。

下一步是什么？

我们仍然希望 GitHub/Microsoft 能够改变他们机械式的态度，有朝一日重建该项目的社区。他们仍然拥有所有数据和实现这一目标的手段。我们也希望他们改进 UI 和数据库设计，以防止将来其他团队再次遭遇类似的问题。

与此同时，您可以通过分享这个故事和重新观看/主演该 repo来帮助我们。

至于我，我可能会暂时不再穿带有 Octocat 装饰的 T 恤。

结语

尽管我们的 GitHub 星星已然化为灰烬，HTTPie 却从未如此出色。最初只是一个业余项目，最近已发展成为一家公司，我们的团队正在将 HTTPie 打造成一个 API 开发平台（正如您对 HTTPie 的期望一样，它令人欣喜）。HTTPie 的Web 和桌面版内测版已收到大量反馈，我们迫不及待地想在接下来的几周内将其正式发布。

如果您想了解最新动态，可以加入我们的Discord 社区或关注@httpie。