Before GitHub — Ronacher 回望 GitHub 之前的开源世界
Layer 1 — 核心论点链
这篇在讲什么:Flask 作者 Armin Ronacher(开源老炮,Pocoo collective 的创始人之一)回望 GitHub 之前的开源世界长什么样,分析 GitHub 怎么从”工具”变成了”开源世界的图书馆”,又为什么今天在掉血,以及之后该怎么办。
(段 1) 他从自己的轨迹起头。 GitHub 之前他第一站是 SourceForge(2000 年代主流的开源代码托管平台,VA Linux 出品,到 2010 年代末几乎被废弃)。再之前他和 Georg Brandl(Sphinx、Pygments 的作者)一起跑过自己的 Pocoo collective(一个共担服务器开销的开源小团体,Flask、Jinja、Werkzeug 都来自这里)——自建 Trac(开源项目管理工具,把 wiki、bug tracker、源码浏览器拼在一起)配 Subversion / SVN(集中式版本控制系统,那年代的主流),再加邮件列表和自己掏钱买的服务器。后来他短暂去过 Bitbucket(Atlassian 旗下的代码托管,曾被认为是 GitHub 的认真对手),最后才搬到 GitHub。
“GitHub was not the first home of my Open Source software. SourceForge was.”
(段 2) GitHub 在他生活里的分量。 他说”很难夸大 GitHub 对我生命的重要性”——开源身份在那里成型,用户、合作者、朋友都通过 issue / PR / comment thread 互相发现。所以他现在看 GitHub 变差不只是觉得”微软的产品决策我不喜欢”,是真的难过——因为 GitHub 是开源社区的基础设施,是社区生活的地方,不只是代码住的地方。
“It was not merely where the code lived; it was where a large part of the community lived.”
(段 3) GitHub 之前是个小世界。 那时候项目数量不大,每个人现实中能依赖的项目数也少。但你认得名字、认得邮件列表、认得维护者多少年没换过。声誉非常直接——Debian 打包者来挑你 license(许可证)和 copyright header(版权声明)的毛病,你会有点烦但也会引以为荣,因为他们真的会把你的代码推到千家万户。关键这一刀:那时一个 dependency(依赖项)不是一个包名,是一个有历史、有网站、有维护者、有发布流程的项目,加 dependency 这个动作要付摩擦——你得理解它从哪儿来。
“A dependency was not just a package name. It was a project with a history, a website, a maintainer, a release process, a lot of friction.”
(段 4) 中央化的讽刺。 SVN 是集中式的,必须有人跑服务器,所以”项目有家”在那个时代天然——一个 hostname + 一个 Trac instance + 一个 mailing list archive 就构成”项目家”。后来 Mercurial 和 Git 来了,哲学上正相反:DVCS(distributed version control system,分布式版本控制系统,每个人都可以有完整 repo 副本和分支历史),原则上不需要单一中心。结果世界反而集中到一个 GitHub——分布式 VCS 赢了,开源世界却 standardize(统一)到一个巨大的中央服务上,是现代开源最大的讽刺之一。
“The distributed version control system won, and then the world standardized on one enormous centralized service for hosting it.”
(段 5) GitHub 给了开源什么(公允的部分)。 他不想只骂。GitHub 让”创建项目”和”发现项目”都简单了,把 PR(pull request,提交合并请求)这套流程让从来没订过 mailing list 的人也能贡献代码。它给了 issue tracker、PR、release page(发布页)、wiki、organization 页面、API、webhook、后来还有 CI(continuous integration,持续集成)。最被低估的一件事是:GitHub 顺手成了开源世界的图书馆——废弃项目还能查到、fork 关系还在、老 issue 和讨论都不会消失。这种 discoverable memory(可检索的记忆)是中央化白送的副产品。
他举自己的反面例子:早期一些包元数据还在 PyPI(Python 官方包索引)上,但实际 tarball(.tar 格式打包的发布物)随他旧服务器一起没了——指针还在,文件死了。这就是”项目家在个人服务器”时代的常态:域名过期 / VPS 关停 / 维护者去世,服务跟着消失。
“Some of my earliest Open Source projects are technically still on PyPI, but the actual packages are gone.”
(段 6) npm + GitHub 让 micro-dep 爆炸。 GitHub 加 npm(Node.js 的包管理器)和类似生态,把”创建、发布、发现、安装、依赖”全部摩擦降到几乎为零。结果是 micro-dependency(微小依赖,往往几行代码一个包)现象——package graph(包依赖图)增长速度超过任何人能理解的能力。GitHub 之前,vendoring(直接把依赖代码拷进自己仓库一起 commit,避免被别人服务挂掉影响)是常态,因为外部服务靠不住、写抓取脚本又痛苦。这种摩擦反而逼出反思和长期性偏好。GitHub + npm 把摩擦干掉,supply chain(供应链)跟着爆炸。
“…with npm-style ecosystems, the package graph can grow faster than anybody’s ability to reason about it.”
GitHub 反过来又承担了部分信任修复:你装一个小包前至少能去 repo 看看维护者还在不在、最近有没有提交、license 是什么。最近还有 trusted publishing(npm 和 PyPI 用 GitHub 的 OIDC token 认证发布者身份,比静态 API token 安全),让 GitHub 直接成为供应链的发布闸口。所以一旦人对 GitHub 的信任下滑,问题就不只是源码托管这一件事,整个建立在它之上的供应链文化都受影响。
(段 7) 但它在掉血。 现在 GitHub 失去了”必然性”——产品改动太多、Copilot AI 噪音盖过来、领导不清、不再像是”为造就它的社区而设计”。再加 agentic coding(智能体写代码)革命的压力。Ronacher 直接自爆:“这个网站没有 leadership!现在还能维持已经是奇迹。”
“But the site has no leadership! It’s a miracle that things are going as well as they are.”
迁出 GitHub 的强信号也变了——以前主要是小项目或 free software(自由软件)信徒(他承认 Zig 语言搬到 Codeberg 那次他自己都 cringe 了一下),现在是有分量的人在动。最显眼的是 Mitchell Hashimoto(HashiCorp 联合创始人,Vagrant、Terraform 作者,开源圈顶级人物)宣布把 Ghostty(他自己写的现代终端 emulator)搬出 GitHub。Strudel(一个 live-coding 音乐工具)和 Tenacity(Audacity 的 fork,开源音频编辑器)已经去了 Codeberg(基于 Gitea 的非营利、非商业代码托管平台,欧洲)。
(段 8) 分散有代价,他真正想要的不是另一个 forge。 回到”很多 forge(代码托管平台的统称,GitHub、Codeberg、Gitea、SourceHut 都是 forge)、很多服务器、很多小家”会增加去中心化、降低单一公司心情对所有人的影响力——是好处。但代码可以分布式,社交语境不会自动分布式:issue、review、设计讨论、release notes、安全公告、老 tarball 都很脆弱,比大家承认的更容易消失。邮件列表这代人扛过这些事,但已经跟不上今天的需求,UX(用户体验)灾难。
所以他不是要”下一个 GitHub”。他真正想要的是:一个无聊的、由 endowment(类似大学基金会那种长期捐赠基金)或公共资金撑住的开源公共档案馆——任务不是赢开发者生产力市场,只是保证人类创造的最重要的代码不消失。花哨功能让别人做,archive 这一档要交给一个不会被单一公司心情绑架的机构。
“Something whose job is not to win the developer productivity market but just to make sure that the most important things we create do not disappear.”
他不希望回到旧 web 那种 broken tarball link 和废弃 Trac 实例的世界,但也不愿让大家假装”过去 20 年是常态”。GitHub 写了开源精彩的一章,这一章如果在结束,下一章应该既学 GitHub 又学 GitHub 之前。
📌 金句摘抄
- (开篇) “GitHub was not the first home of my Open Source software. SourceForge was.” — 老兵视角的开场声明
- (段 2) “It was not merely where the code lived; it was where a large part of the community lived.” — GitHub 不是托管,是社区基础设施
- (段 3) “A dependency was not just a package name. It was a project with a history, a website, a maintainer, a release process, a lot of friction.” — 一句话定义”GitHub 之前加依赖”到底是什么
- (段 4) “The distributed version control system won, and then the world standardized on one enormous centralized service for hosting it.” — Git 时代最深的讽刺,一句话讲完
- (段 6) “…the package graph can grow faster than anybody’s ability to reason about it.” — 供应链爆炸的根本机制:人类推理速度跟不上 graph 增长速度
- (段 7) “But the site has no leadership! It’s a miracle that things are going as well as they are.” — 自爆式坦白,比任何外部批评都狠
- (段 8) “Something whose job is not to win the developer productivity market but just to make sure that the most important things we create do not disappear.” — 他想要的东西的精确定义
Layer 2 — 我的标注
1. 真正的论点不是”GitHub 不行了”,而是”分布式 VCS + 中央化生态”是个不稳定均衡。
这是文章最值钱的判断。Git 在代码层是分布式的,但社交层(issue、review、release notes、关系链)从来不是分布式的,不会自动跟着代码走。GitHub 健康的十几年盖住了这个矛盾——只要中央服务还在,看起来就像两层都解决了。一旦 GitHub 走弱,矛盾立刻暴露:搬 git history 是分钟级的事,搬 issue / PR / advisory 历史几乎不可能,没人会去 mirror 别人项目的 release artifact。Ronacher 把”开源的记忆”和”开源的代码”分开来看这一刀,比”该不该离开 GitHub”重要得多。
2. 他对”档案馆”的设想是反常的——明确去掉产品野心,值得记下来。
绝大多数想”做下一代 GitHub”的人想的都是”做一个更好的产品”——更强的 CI、更好的 PR 体验、更聪明的 AI。Ronacher 反过来说 archive 要 boring——不是赢市场,是不死。这个思路在你投资视角下有同构存在:Internet Archive、Wikipedia、CCC(Chaos Computer Club)的服务——都是”靠 mission 撑住而不是靠产品赢”的存在。它和 VC 模式根本冲突:endowment-funded 的东西不可能给 10x return,必须靠 grant 或公共部门,这是 deal flow 上几乎看不到、但生态层重要的结构性空缺。
3. 对你 dogfood 视角直接相关:你 memory 系统的归档逻辑和这篇结构同构,并且 agent 时代的供应链信任会变。
你做 memory 系统的关键判断之一是”信号驱动的 conditional writeback + 时间归档 + vec-search 索引”——本质是”把事实和社交语境分开存,并让旧的可检索”。Ronacher 描述的”开源档案馆”和你 memory 系统的 archive 逻辑是同一个判断的两个 instantiation:分布式带来去中心化,但需要专门的归档机制保证记忆不丢。再往前一步——agent 写代码时代,“我至少能去看那个 repo”这条供应链信任心智模型在变薄(人没时间真去看,agent 只读 metadata 和 README),下一代供应链信任的支点是什么?这是这篇没回答但应该想的问题。