vlambda博客
学习文章列表

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

机器之心报道

编辑:蛋酱、小舟

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


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


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

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

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

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

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


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


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


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

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

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


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

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


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 隐藏。

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


最直接的原因是我认为我在另一个 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 是完全一样的。它说的是:「警告:这是一个潜在的破坏性行动。」

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


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

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

一番操作之后

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

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


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

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

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

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


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

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

经验教训

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

教训 1:UI/UX 设计

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

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


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

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


教训 2:数据库设计

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


教训 3:与 GitHub 的关系

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

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

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

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

参考链接:
https://httpie.io/blog/stardust

IJCAI 2022 - Neural MMO 海量 AI 团队生存挑战赛


4月14日,由超参数科技发起,联合学界MIT、清华大学深圳国际研究生院以及知名数据科学挑战平台 AIcrowd 共同主办的「IJCAI 2022-Neural MMO 海量 AI 团队生存挑战赛」正式启动。

本届赛事以「寻找未来开放大世界的最强 AI 团队」为主题,通过在 Neural MMO 的大规模多智能体环境中探索、搜寻和战斗,获得比其他参赛者更高的成就。比赛还设置新的规则,评估智能体面对新地图和不同对手的策略鲁棒性,在 AI 团队中引入合作和角色分工,丰富了比赛内容,增强了趣味性。

比赛设立了 20000美元的奖金池 以及丰富的 学术荣誉奖 & 趣味奖 ,比如“酸脚(Jio)奖”。对比赛感兴趣的小伙伴点击阅读原文赶紧报名吧!

© THE END 

投稿或寻求报道:[email protected]