主要观点总结
文章描述了Elastic公司在GitHub上的公开代码仓库因内部人员操作失误被错误地标记为私有，导致部分仓库无法访问的事件。经过紧急响应，所有受影响的仓库最终恢复为公开状态。
关键观点总结
关键观点1: 事件概述
Elastic 公司在 GitHub 上的公开代码仓库因内部人员操作失误被标记为私有，导致仓库无法访问。经过调查后，Elastic 团队开始紧急响应，恢复受影响的仓库为公开状态。
关键观点2: 事件影响
除了 Kibana 仓库外，所有其他仓库都被改回为公开状态，并且它们的分支正在恢复中。最终，所有受影响的仓库都已完全恢复为公开状态。
关键观点3: 观点讨论
文章下方评论对于事件表达了不同的观点，包括误操作、项目版本调整、star 数据的重要性、商业路线调整等。
正文
Elasticsearch 团队公布了此次 “GitHub 仓库归零” 事故的具体过程，万万没想到居然是内部人员操作失误 —— 将原本的公开仓库设置成了 “私有”。- 问题发现：2024 年 10 月 29 日 12:28 UTC，Elastic 公司发现其在 GitHub 上的一些公开代码仓库暂时无法访问。
- 问题识别：经过调查，确认问题是由于内部变更操作导致，Elastic 公司在 GitHub 组织下的某些公开 git 仓库被错误地标记为私有。
- 紧急响应：Elastic 的团队开始紧急工作，以恢复这些受影响的仓库为公开状态。
- 部分恢复：在 12:51 UTC 至 15:09 UTC 期间，除了 Kibana 仓库外，所有其他仓库都被改回为公开状态，并且它们的分支（forks）正在恢复中。
- 持续沟通：Elastic 公司持续更新状态，表示正在等待 GitHub 支持团队对 Kibana 仓库的进一步操作，预计可能需要几个小时或更长时间。
- 完全解决：18:39 UTC，Elastic 宣布所有受影响的仓库都已恢复为公开状态，它们的分支 (forks) 也已恢复。（来自：OSC开源社区）
- 观点 2：没有误操作的可能。还是想在一个版本上取消开源的版本。
- 观点 5：stars 就是无法恢复了，之前也有著名项目也是相同的操作，最终 starts 只能慢慢回
- 观点 6：不可能误操作，设置 private 的时候需要重复输入一次仓库名称的
- 观点 7：es 这种级别的项目，star 数据已经用处不大了吧
- 观点 8：他们已经完全走商业的 saas 路。所以想用的人都要付费了。
- 观点 11：github 公有库改成私有库，就会清空 star。不过在操作的时候，会上手动输入当前 star 数进行确认。gitee 倒是不会清。
- 观点 12：httpie 当时就这么干了，这会星星已经涨回来了
