5.4万颗星清零!GitHub上10年心血,开发者误操作项目消失

2022 年 4 月 20 日 新智元



  新智元报道  

编辑:袁榭 拉燕

【新智元导读】手滑点错按钮,会有什么后果呢?GitHub大佬亲自用自身经历现身说法。


手一滑,误关闭了文档、PPT、会议窗口、网页,这是当代人生活的必有场景了。
 
至于影响,小到订不到机票车票、大到丢饭辙丢老婆,都是有可能的。
 
这种失误在开源程序界的明星那里,会有什么影响呢?

下文就会告诉你一个典型的例子。
 

Github网红项目


HTTPie for Terminal距离第一次上传,已经过去10年了,这可是一件值得庆祝的事。
 
如果大家还对这个项目不是很熟悉,首先要知道这是一个开源的CLI HTTP用户端软件。HTTPie与众不同之处在于,它是从零开始搭建的,目的是为了让终端的API交互尽可能的方便用户操作。
 
2012年2月25号,在哥本哈根的一个雨夜,HTTPie第一个公开版本在GitHub上发布。
 
发布者Jakub Roztočil说,他一直是GitHub的粉丝,多年前他就是GitHub的会员了。按Jakub Roztočil自述,他就是个身着格子衫的标准程序员,lol。
 
在那个时代,GitHub曾经在他们的首页上,非常骄傲地宣布,他们在风险投资中筹得了0美元的巨款,并且在他们旧金山的办公室里有很多美味的啤酒。
 
当Jakub Roztočil意识到,他做的API测试可能会让大开发者社群里的成员感兴趣的时候,他就知道GitHub就是他的首选发布站了。
 
事实也确实如此。
 
Jakub Roztočil还记得,当HttPie第一次成为Hacker News上最热门的链接,还有GitHub社群不断壮大的场景。
 
很多年来,开发人员仍然在不断完善这个项目,这个项目也吸引了越来越多人的注意。慢慢这个项目成为了GitHub平台上最时髦的API工具。而彼时的HTTPie项目也成为了有5.4万关注并评分者的大社群,
 
 
GitHub上有多达2.89亿的公开程序托管项目,HTTPie也成为了社群中排名前八十的公开项目,排名前99.99997203%.
 
简而言之,看到这个项目能收获这么多的关注,实在是一件美妙的事。GitHub作为平台功不可没。
 
开发HTTPie的人员和GitHub是互利互惠的关系。前者收获了后者提供的开源平台的服务,而平台也因为这个项目的热门而收获不少。
 
在过去十年,差不多有上百万人浏览过这个项目的主页。这也反哺了GitHub和Microsoft,使其作为一家公司更加关注开源和社群的搭建。
 
可以说,项目和平台互相成就。

缘,妙不可言。


因误操作,5.4万评星蒸发


然而,如果你是5.4万对此项目关注并评分者的其中之一的话,这几周你会发现,你不再是了。
 
到底发生了什么呢?
 
因为一系列倒霉的误操作,Jakub Roztočil不小心把项目权限设置成「私密」了。然后GitHub就这么把他们搭建了10年的项目删掉了。
 
 
这意味着什么呢?
 
如果你是一名下游的维护人员,或者是此前关注过HTTPie通知的人,现在你得把托管项目重新看一遍。
 
另外,Jakub Roztočil还发布了一份安全声明。
 
而对评分者是一样的道理。如果你是其中之一的话。如果你在过去十年里给HTTPie点过赞,那么现在HTTPie这个项目不会在你的喜欢列表里再次出现了。


那么开发者为什么要设置私密呢?


这其实得怪GitHub。简单来说,如果把项目设置成私密,那么就会自动永久删掉所有的关注者和评星。Jakub Roztočil其实知道这一点,那么他为什么还要这么做呢?
 
 
Jakub Roztočil表示,最直接的原因就是,他误以为自己打开了一个完全不同的项目。这个项目页面里没有任何内容,也没有评星。
 
其实Jakub Roztočil只是想隐藏HTTPie的组织文档README。这是一份他前一周创建的文档,但是还没有机会往里面添加任何内容。
 
而让开发者走上错路的原因则是另一件毫不相关的事:就像他把README文档隐藏了一样,他把他个人的jakubroztocil/jakubroztocil用户页面也给隐藏了。
 
在涉及到档案文件和托管项目的时候,GitHub的概念模型会把所有的用户和组织都视为相似的实体。所以说,当开发者只是想简简单单的隐藏文档的时候,他不多注意时就很容易点击错到「私密」按钮。
 
这才导致了一切。
 
Jakub Roztočil一时糊涂,没意识到,命名这个特殊的项目包含README的配置文档有不一致的情况,并且对用户和组织的名称是不同的,一个是name/name,一个是name/.github。
 
这就是为什么他是把httpie/httpie搞成了隐藏,而不是httpie/.github。


但点击时该有确认窗口啊?难道不是吗?!


的确,GitHub在这时候会弹出确认窗口。这个功能的设计本意确实是让Jakub Roztočil这种状况中的用户别做傻事、点击错误选项。它的文本内容会告诉你「将永久失去所有的项目评星和所有本托管项目的关注者」。
 
蛮吓人的哦。
 
问题在于,一个完全没有关注者和评星的项目,与一个更新了十余年、关注者与粉丝过5.5万的项目,Github的确认提示窗口都是一样的:「警告:这可能是一个有毁灭性潜质的决定。」
 
说成白话,提示窗口的警告语等同于「你将爆破一栋建筑,如果内有人居,住户都会死。」
 
不过这个提示窗口没有任何随用户变化的特定内容,让不专注的用户摆脱无心的下意识自动模式。这种用户很容易读混这些警示语,以为建筑里没有人。
 
一个价值5.4万个评星的问题:下图里两个警告窗口的对话,哪个在针对初学菜鸟自己决定删掉也没大损失的项目,哪个又是在针对一个逾时十年、关注者形成可观社群的项目?
 
 
提示窗的对话文本里应该有更多的随不同项目背景变动的内容,比如在Jakub Roztočil这个项目上弹出时就该有「你将干掉5.5万关注者!」的文本。那肯定会让Jakub Roztočil停下来细看的。
 

你只是把项目改成私密了,可以再改回来嘛

 
Jakub Roztočil一开始也是这么想的。
 
大家可以想见Jakub Roztočil点击回到「组织」页面时的困惑:不仅README文档是空白的,整个非常受欢迎的托管项目也无处可寻。
 
片刻之后,Jakub Roztočil意识到发生了什么事。所以Jakub Roztočil点击按钮回到托管项目的设置页,来重新将其重新设置为公开。但在整整半个小时的努力后,GitHub仍然不允许Jakub Roztočil做到这点。
 
如果你在疑惑为什么耗时是这么长,那是因为GitHub花了这么长的时间,来级联式全部删除了Jakub Roztočil项目十年来累计的关注者。而且项目开发者没有办法阻止这个过程。
 
 
Jakub Roztočil所能做的就是开始给GitHub技术支持部门写电邮、刷新页面、并等待关注数达到零,然后Jakub Roztočil才能再次将项目页面设为公开。
 

为何GitHub不自行恢复这个项目?!


GitHub显然有托管在其上的开源软件项目的备份,并且确实能消除意外将托管项目误改为私密权限所造成的损害。

GitHub团队自己就曾不小心将GitHub桌面应用程序的托管页面设为私有一次。 们在几个小时内为自己恢复了一切。
 
以下是 GitHub前CEO对情况的解释:早上有开发人员误操作了。权限改回来是无法直接回复项目评星的,所以开发者们用数据备份整个完全还原了项目,就这样。
 
 
然而,在Jakub Roztočil这次的事件中,GitHub拒绝这样做,理由是会产生不良副作用和额外的资源耗费。
 
Jakub Roztočil甚至表示愿为所耗费的任何资源对GitHub提供经济补偿。但遗憾的是,他们拒绝了。除了在平台上恢复最悠久和最受欢迎的软件项目及关注者社区之外,GitHub似乎还有其他优先偏好。
 
所以问题的答案很不幸地非常明显:GitHub会恢复权限误设为私密的开源软件项目,只要哪个项目是自己的就好。至于社区里其他人的项目嘛,自求多福吧,顶多给你个安慰性的推特回复。


吸取的教训

 
聪明人从不浪费任何一次挫折。开发者们现在的选择余地很小,但的确能学到好几条很值得分享的教训:
 
教训1:UI/UX设计原则
 
展示,而非告知。将确认选项的对话窗口设计为不需要用户多想的风格。
 
当用户要破坏/放弃某项目时,警示窗口不应将选项用抽象文本描述为潜在场景,这样需要让用户将文本叙述场景转化为直观的精神印象,然后才会权衡。
 
当主要选项的副作用是级联式删除时,更该如此。
 
开发者们现在把HTTPie桌面版的「删除」按钮设计成这样了
 
 
而且,不消说的是提示窗文本得反映潜在选项后果和副作用的严重性。当没有副作用时,对话框就不该有大块文本。否则的话,用户的注意力会很快被磨钝、不会放在应有的选项上。
 
教训2:数据库设计原则
 
尽量导入软删除选项。人都会犯错的,所以应该尽可能迟滞硬删除过程,给用户挽回空间。
 
教训3:与GitHub的关系
 
这次事故的确是开发者一方的人为无意失误,而且GitHub也明确表态他们无法定义务要帮助开发者们恢复项目。
 
所以,逾时十年的互惠互利关系最终被GitHub的服务条款与律师给定性了。开源软件人以为自己跟GitHub有更深厚情谊的话,纯属天真。
 
毕竟,GitHub有违开源精神的行迹已经不新鲜了,除非有公众意见的怒潮,他们一般不会改变决策。

而且他们的母公司微软,即使现在表面欢迎开源了,也并不是个真正名声上好的企业。


终局

 
尽管Jakub Roztočil的GitHub页面与评星化灰了,HTTPie项目仍然在蓬勃发展。
 
一开始只是个业余小项目的HTTPie,现在成为了专业公司,而且开发者们的团队在不断将HTTPie拓展成一个令用户满意预约的API开发平台。
 
HTTPie的网页版与桌面版的beta版,用户反馈良好,在接下来的数周内将会面向大众发售。


参考资料:

https://httpie.io/blog/stardust



登录查看更多
0

相关内容

GitHub.com 使用 Git 作为版本控制系统(version control system)提供在线源码托管的服务,同时是个有社交功能的开发者社区。 国外类似服务: Bitbucket.com
Gitlab.com
国内类似服务:
Coding.net
霍普金斯《操作系统原理》2020课程,不可错过!
专知会员服务
36+阅读 · 2020年10月27日
【2020新书】C语言编程傻瓜式入门,第二版,464页pdf
专知会员服务
62+阅读 · 2020年10月15日
【经典书】C语言傻瓜式入门(第二版),411页pdf
专知会员服务
51+阅读 · 2020年8月16日
一图搞定ML!2020版机器学习技术路线图,35页ppt
专知会员服务
93+阅读 · 2020年7月28日
Keras作者François Chollet推荐的开源图像搜索引擎项目Sis
专知会员服务
29+阅读 · 2019年10月17日
战火之下,乌克兰开发者还在提交代码
InfoQ
1+阅读 · 2022年3月7日
Python:Bug 官网不要了,全迁去 GitHub!
CSDN
1+阅读 · 2022年2月25日
国家自然科学基金
0+阅读 · 2015年12月31日
国家自然科学基金
0+阅读 · 2014年12月31日
国家自然科学基金
0+阅读 · 2014年12月31日
国家自然科学基金
0+阅读 · 2013年12月31日
国家自然科学基金
0+阅读 · 2013年12月31日
国家自然科学基金
0+阅读 · 2012年12月31日
国家自然科学基金
0+阅读 · 2012年12月31日
国家自然科学基金
0+阅读 · 2011年12月31日
国家自然科学基金
0+阅读 · 2011年12月31日
Arxiv
0+阅读 · 2022年6月7日
Arxiv
17+阅读 · 2021年1月21日
Arxiv
21+阅读 · 2018年5月23日
VIP会员
相关基金
国家自然科学基金
0+阅读 · 2015年12月31日
国家自然科学基金
0+阅读 · 2014年12月31日
国家自然科学基金
0+阅读 · 2014年12月31日
国家自然科学基金
0+阅读 · 2013年12月31日
国家自然科学基金
0+阅读 · 2013年12月31日
国家自然科学基金
0+阅读 · 2012年12月31日
国家自然科学基金
0+阅读 · 2012年12月31日
国家自然科学基金
0+阅读 · 2011年12月31日
国家自然科学基金
0+阅读 · 2011年12月31日
Top
微信扫码咨询专知VIP会员