GitHub 之前,我们是怎么写代码、托管代码的

查看原文 HN 讨论

文章摘要

Armin Ronacher(Flask、Jinja2、Sentry 早期开发者)在这篇带回忆色彩的博文里,向更年轻的开发者描述了一个被很多人遗忘的世界:GitHub 出现之前的开源生态长什么样。他自己的早期开源项目跑在他亲手维护的服务器上——一个 Trac 实例、一组 Subversion 仓库、tarball 发布、自己写的文档站。多个项目通常会抱团组成”集体”以分摊运维成本,他和一群朋友就一起搞了 Pocoo 这个共享基础设施,承载 Flask、Jinja2、Werkzeug、Pygments 等一系列项目。

那个时代的版本控制以 Subversion 为主,集中式架构让”自托管”成了天然选项——一个项目就是一个有具体 hostname 和目录的”家”。后来 Git 和 Mercurial 这类分布式系统出现,但多数项目仍保留独立的 home page、独立的 bug tracker(Trac、Bugzilla、Mantis、Bitbucket、SourceForge…),还没有统一的”个人主页”概念。开发者之间的信任更多来自直接参与项目本身——读源码、看历史、跟维护者打交道——而不是看 GitHub follower 数、绿色草地图或者 star 数。Debian 这样的发行版会真的去逐项审 license 和代码质量,”声誉”是一种实打实的资本。

文章的另一条主线是依赖摩擦。当时引入一个新依赖是要慎重权衡的事:外部源未必可靠访问,所以”vendor 进自己仓库”是常见做法。这种摩擦反过来逼着开发者认真评估”我真的需要这个依赖吗”。与今天 npm install / pip install 一行命令拉来上千依赖、大家对依赖图基本无感的世界形成强烈对比。Ronacher 没有做出”那时更好”的廉价怀旧判断,而是提醒读者:GitHub 把许多东西做得更省事,但同时也抹掉了一些有价值的摩擦和分布式韧性——当 GitHub 抽风时,整个生态才意识到自己有多依赖一个中心。

HN 评论精华