【CSDN 编者按】本文作者依据从业二十多年的工作经验，阐述他为什么选择放弃GitHub，放弃了GitHub后又有哪些影响及应对之道。

原文链接：

未经允许，禁止转载！

作者 | Dave Gauer 译者 | 弯月
责编 | 夏萌出品 | CSDN（ID：CSDNnews）

起因

我写这篇文章不是为了说服你们，而是解释为什么选择放弃 GitHub。新的 2FA（双重身份验证）要求只是“压垮骆驼的最后一根稻草”。其实，十多年前我就对 GitHub 抱有矛盾的态度，使用 GitHub 也不太情愿。

这些年来困扰我的问题有很多，例如：

2012 年：GitHub 得到普及，是福也是祸

2018 年：被微软收购

2021 年：GitHub Copilot 与 OpenAI 成为合作伙伴

2023 年：“Trending repositories”（自然都是“AI”）出现在我的“feed”中

2023 年：需要 2FA 才能提交代码？

下面，我们从第一点开始说起：GitHub 得到普及，是福也是祸。

福：GitHub 的统一界面对于共享开源项目来说是一个巨大的福音。特别是，你不再需要从各个网站或 SourceForge 下载 .tar.gz 文件。

福：“每个人”都有一个帐户，在开源项目上开展协作非常容易。

祸：“每个人”都有一个帐户，因此人们可以随意提出没什么营养的建议和毫无价值的PR。对于维护人员来说，这是一件十分令人头疼的事情。我怀疑这加重了 FOSS（自由及开放源代码软件） 开发人员的工作负担。

福祸相依：在 GitHub 上查找开源项目十分便利，从而减轻了将其他人的代码添加到自己的项目……以及公司项目的工作量。

至于 2018 年微软的收购，我坚持认为该事件并非福祸相依，而是百分百的诅咒。我并不会因为自己的看法正确而沾沾自喜，也许最终将来证明我错了。五年后我们再来看吧。

Copilot 已经引起了非常激烈的争论。内容收集的合法性、输出的有效性以及该大型语言模型（以及其他模型）的功耗都是争论的热门话题。

在我看来，Copilot 就好像是微软和 OpenAI 攫取你为业余爱好编写的代码，让付费客户快速生成程序。这么说吧，我认为软件开发的世界本已充满复杂性，实在没必要再背负一堆随机垃圾生成器。

之前，Cory Doctorow 曾写过一篇文章控诉平台的“垃圾化”，在我看来，“activity feed”中的“Trending repositories”就是 GitHub 迈向这一步的第一个征兆。我认为情况只会变得越来越糟。

至于新的 2FA 要求，相信他们已经在某个地方用更精确的、律师术语写下了这意味着什么，但我还没有看到。每个 GitHub 网页和电子邮件都在重复“限制访问”的口号：

您的账户需要在2023年9月28日凌晨（UTC）之前启用2FA（双重身份验证）。如果未能在这之前完成注册，则您对 GitHub.com 的访问将受到限制，直到您完成注册过程。

我猜这意味着我将失去向自己的代码库提交代码的权限。但谁又知道呢？

作为一个在这个行业摸爬滚打了二十多年的人，你知道当我看到这个要求时的第一反应是什么吗？“天啊，微软想要收集更多人的电话号码。”（我当时的第一反应确实如此。当然我知道电话不是注册 2FA 的唯一途径。但本文的讨论重点不是电话号码，不是 2FA，也不是提供更多信息的要求。所以，请不要再讨论您最喜欢的 2FA 方法了。谢谢！）

可能对于大多数开发人员来说，这“最后一根稻草”似乎“没什么大不了”，我完全理解。我知道有人会误解我的意思，但我想尽力澄清一下：

我并不反对 2FA 的概念。我愿意在其他地方使用它。这不是本文的重点。

最后，我很清楚，作为行业中的“老牌”程序员，我可以选择放弃GitHub，而且不会对我的职业发展造成任何不良影响（可能？）。但对其他人来说可能并非如此，这是普遍存在的一个问题。

保护“企业”开源“消费者”

我第一次得知这个信息是 8 月 14 日收到的一封电子邮件，标题为“[ACTION REQUIRED] Your GitHub account, ratfactor, will soon require 2FA”：

保护开源生态系统的开发者和消费者（包括大型企业）免受此类攻击是确保供应链安全的第一步，也是最关键的一步。

提高软件安全标准（），一篇标题为“确保软件供应链安全是团队的工作”的博客文章中表示：

开源软件无处不在，90% 的公司表示他们的专有软件中使用了开源软件。GitHub 是开源生态系统的重要组成部分，因此我们必须认真确保帐户安全。多年以来，人们一直认为强身份验证和 2FA 的使用是最佳实践，因此我们认为 GitHub 有责任扩展这一最佳实践，作为保护软件供应链的一部分。

软件安全从开发人员开始做起（）：

在 GitHub，我们相信我们作为所有开发人员之家的独特地位意味着我们有机会也有责任提高整个软件开发生态系统的安全标准。

我既是一名业余项目的程序员，也是一名专业的编程打工人。我既会向自由开源软件做贡献，也会消费这些软件。

独立的自由开源软件开发人员不欠任何公司任何东西，他们没有任何责任保护“企业”开源“消费者”，更没有责任“保护软件供应链”。正如许可所述，这类软件“按原样”提供，不提供任何形式的保证……

放弃 GitHub 后，接下来该怎么办？

首先，我不会愤怒地退出并删除我的帐户。据我所知，即使不再拥有提交权，我仍然可以无限期地将代码库留在 GitHub 上。代码库的 URL 仍然有效。

也许最重要的是，我的最受欢迎的项目 Ziglings（）已拥有一位出色的合作者，他承担了 99% 的维护工作。无论我们是否决定移动这个代码库，它都会被妥善保管，并且每个人都可以轻松访问。

至于新项目和现有项目的新提交，我似乎有以下两种选择：

再找一个托管库；

自托管。

有一些有趣的托管库，最吸引我的是下面这两个：

我很喜欢这两个托管库，因为二者以完全不同的方式解决问题。它们的共同点是：与 GitHub 不同，这些网站是在 FOSS 代码的基础之上创建和运行的。

自托管的方式也很有趣，其实内心深处，我一直是一个“独狼”程序员。

请不要误解，我很乐意在工作中与其他人合作，而且热衷于撰写评论和文档。计算机只需要二进制，人类才需要源代码。

但在为自己编写代码时，我喜欢通过自己的努力创造自己的一片天地。在个人项目中，我可以选择是快速编写一个摇摇欲坠的一次性脚本，还是编写一个经得起时间考验的、精心构建的实用程序。

因此，对我来说，通过一个最小的、自托管的、静态生成的 Web 界面来共享我的项目是目前最为合理的解决方案。尤其是对于小型项目来说，而且我的项目大多数都非常小。

姑且不论是使用现有的程序还是编写自己的程序，我想要的功能按重要性排列如下：

README 文件，以华丽的HTML 呈现。

有克隆存储库的说明。

UI，用于浏览文件树并查看项目源代码。

显示提交日志。

正如文本开头所说，GitHub 代码库的 UI 布局十分正确。我喜欢统一格式的文件列表，以及格式化显示的 README。我想继续采用这类 UI 布局。

下面是两款非常有趣的静态存储库到网页的生成器：

鉴于我的需求非常小，我正在考虑结合使用 Bash 或 Ruby 一起开发。听起来很有趣，对吧？

关于 BitBucket

2012年 2 月，我在极其不情愿地情况下开始使用 GitHub（我是一名快乐的 Mercurial 用户，也是一个不情愿的 Git 用户）。Bitbucket.org 有免费的私人帐户，我需要在工作中与其他协作开发小型项目，而且托管在 Mercurial。所以我一直在使用它们，直到 GitHub（和 Git）逐步壮大，无法忽视。

自 2010 年起，Atlassian 成为了 bitbucket.org 的所有者，但在 2020 年放弃了对 Mercurial 的支持，并删除了我所有的 Mercurial 存储库。虽然我已经很久没有使用它们了，但我的所有链接都失效了，真的是很讨厌。

（在有了此次经历以及许多其他类似的经历之后，我的座右铭之一是：永远不要依靠大公司。）

如果你从未见过此类的明星产品起起落落，可能会觉得 GitHub 将成为永恒。

但如果见惯了世间沉浮，你就会明白终有一日 GitHub 也会在企业手中陨落，这不仅完全有可能，而且是不可避免的。