文章批评GitHub频繁宕机、安全性和性能问题，认为这反映了GitHub及大型科技公司软件服务的整体基础设施衰退。作者指出现有讨论仅触及表面，暗示问题比报道的更严重。

GitHub对软件犯下的罪行

作者：Efron Licht（2026年5月）

引言

文章开篇引用林肯名言指出，当房屋着火时只有两种立场：救火或任其燃烧。作者以GitHub又一次宕机为切入点，指出虽然已有许多关于GitHub可靠性、安全性和性能问题的讨论，但都只是触及表面。GitHub已成为整个科技行业基础设施衰败的标志性案例。

作为分布式系统专家，作者指出GitHub的问题远不止可用性，包括但不限于： - 每月数十起事故（实际可能上百） - 不公开问题追踪系统 - 虚假宣传正常运行时间和优先级 - 明显优先发展AI功能而非基础可靠性 - 前端代码臃肿缓慢 - 频繁无预警更改用户体验

技术分析

通过对比GitHub、GitLab和Codeberg的前端性能，作者发现： 1. 资源消耗： - GitHub加载需下载22MB代码（54万行） - 内存占用达69MB（空白页面） - 而Codeberg仅需1MB代码（3480行），14MB内存

2. 历史对比：

   • 当前GitHub前端代码量超过：
     • 初代DOOM游戏（3.5万行）
     • Windows Quake（12万行）
     • MS-DOS 4.0系统（33.2万行）

3. 性能表现：

   • GitHub在3G网络下需22秒加载空白页面
   • 而作者个人网站在相同条件下仅需200毫秒

根本问题

作者认为这不仅是"平台恶化"(enshittification)现象，更是技术能力的系统性失败： - 微软/GitHub疯狂推动AI功能（每个页面平均3-4个AI按钮） - 前端架构存在根本缺陷（数百个碎片化JS文件） - 工程管理失效（800名工程师年耗153万工时）

解决方案建议

对开发者： - 大幅削减无用代码（测试显示528KB代码完全未使用） - 合并资源文件减少请求 - 改进缓存策略

对用户： - 考虑迁移到Codeberg等替代平台 - 根据SLA条款申请服务中断赔偿

结论

文章以"软件犯罪"作结，指出科技巨头已无法胜任基础设施建设的重任。当业余爱好者的个人项目能轻松超越价值数十亿美元的企业产品时，这不仅是商业失败，更是对整个软件行业的背叛。

（全文保留了核心论点和关键数据，删减了重复性技术细节和代码片段，压缩了实验过程描述，合并了同类问题，使文章更紧凑易读。）

以下是评论内容的总结：

1. 关于GitHub替代方案

   • 支持使用GitLab和Codeberg（评论2、8）
     "Setup is simply 3 steps..."（详细的多平台同步教程）
     "Self hosted gitlab is a dream..."（自建GitLab的优势）
   • 建议去中心化方案（评论5）
     "People should consider decentralized git over Nostr..."

2. 对GitHub的批评

   • 可靠性问题（评论4、10）
     "clearly prioritize flashy AI features over fundamental reliability"
     "Github often breaks on firefox and safari"（但被质疑需要证据）
   • 星标系统的弊端（评论11）
     "Fake stars can propel a good project to great"

3. 文化反思

   • 对黑客文化商业化的失望（评论6）
     "Did everyone just sell out?...money talks"
   • 对VS Code的担忧（评论9）
     "I hope vscode does not end up like this"

4. 其他观点

   • 仍有用户支持GitHub（评论7）
     "I remain happy with GitHub!"
   • 界面体验问题（评论3）
     "This web site is very hard to read..."

5. 延伸讨论

   • 关于Fossil SCM的提问（评论12）
     询问是否有人转向这个自带issue跟踪的系统

注：评分均为None，说明这些评论未获得社区明确赞同或反对。争议焦点集中在GitHub的可靠性、替代方案选择，以及开源文化商业化问题上。