GitHub 联合发起人独家揭秘:规模小又没钱我们凭什么能打败谷歌

时间: 2024-11-19 10:06:54 |   作者: 年报公告

  最近,“GitHub 为何能够在众多代码托管平台中脱颖而出”这一问题引发了广泛讨论。多位科技博主和行业观察者对此进行了深入分析,包括 Ping Labs 创始人 Theo Browne 和 Graphite 创始人 Greg Foster,他们从不同角度解读了这一现象。

  作为 GitHub 的联合发起人,我认为写下我自己对 GitHub 崛起并占据主导地位背后原因的看法可能也同样有意思,或许还能纠正一些他们从外部视角所做出的不太准确的分析。与他们不同,我亲历了这一过程,并撰写了相关书籍。

  GitHub 的四位联合发起人,无论是在 GitHub 之前还是之后,都曾经历过失败。Chris 和 PJ 在创立 GitHub 之前没能成功运营 FamSpam,Tom 和我也没有让 Chatterbug 一飞冲天。在我看来,这两个项目都有不错的品味和出色的产品,但或许是时机、地点、市场或其他因素未能使它们达到 GitHub 的高度。

  在 GitHub 诞生之初,开源的分布式版本控制工具开始变得实用、稳定,并逐渐被广泛采用,但当时还没有人托管这些工具,更不用说商业应用了。大型托管服务商对此不以为意,小型玩家也不够重视。

  2005 年的软件开发处于一个怎样的环境?这是 Git 能够赢得人们青睐、GitHub 能够生逢其时的时代吗?

  如果你在 2005 年是一名软件研发人员,很可能(甚至希望)在使用像 Subversion 这样的集中式版本控制管理系统。在 Git 问世之前,我曾使用过 RCS、CVS、Subversion 和 Perforce。实际上,我在一个企业工作时甚至直接通过 FTP 将 PHP 文件上传到生产服务器。

  现在,如果你在开发商业软件,像 SVN 这样的集中式版本控制管理系统其实并非最糟糕的选择。它简单易用,只需要检出、修改、再检入即可。虽然分支和合并功能很糟糕,但在许多情况下,基本上能够尽可能的防止使用这些功能(我甚至不确定自己是不是曾在 Subversion 或 Perforce 中使用过分支功能)。

  我认为,在这一时期开始显现的问题并不局限于封闭的开发团队,真正的挑战在于不断壮大的开源世界。与今天相比,开源在那个时期几乎微不足道。你们这些年轻人可能不记得那个没有数百万开源项目的年代,直到“开源”这个词在 1998 年被创造出来。

  当时的情况到底有多糟?我们大家可以通过 Subversion 进行开源贡献的经历来看看。

  在 Subversion 时代,想要为一个开源项目贡献代码是非常麻烦的一件事。Subversion 服务器通常设置成未经身份验证的用户只读,这就从另一方面代表着如果你想参与贡献,必须先将整个项目代码检出到本地,然后才能做修改。修改完成后,你还需要手动生成补丁文件,再通过项目的工单系统或邮件列表提交给维护者。

  Ruby on Rails 项目,以及我的朋友(也是 GitHub 后来的联合发起人)使用了一个类似的工单系统,叫作 Lighthouse(令人难以置信的是它至今任旧存在)。我最早的开源项目之一是一个叫作 git-lighthouse 的命令行工具,它可以简化从工单系统中拉取和应用补丁的过程。

  Git 的诞生其实就是源于 Linus Torvalds 十分喜爱的一个(当时)商业版本控制管理系统 BitKeeper。它最初是为帮助简化操作系统内核开发流程而设计的。

  如果 BitKeeper 是开源的,或者拥有更友好的许可条款,可能就不会有 Git 或 GitHub 什么事了。

  在 Git 的早期,我会在演讲中做一些演示,创建分支、提交更改到分支、切换分支,然后将它们合并,所有这些操作都在 60 秒内完成。我看到人们的下巴都要掉了下来。有些人甚至认为我在做假演示。

  我无法形容在 2006 年能够如此快速而轻松地切换和合并上下文是多么令人惊叹。在 Subversion 中,这完全是个噩梦。

  不需要利用互联网与中央服务器协商代码提交也令人难以置信,感觉就像是驾驶一艘火箭船,一切都如此之快。

  去年年底,我与 Tom(也是 GitHub 联合发起人)进行了一次访谈。在我们讨论的内容中,他分享了他最初是如何想到要做 GitHub 的。

  Tom 在 Powerset 工作期间,他的团队开始在内部使用 Git 作为版本控制管理系统。然而,将其他小组成员加到内部服务器的过程相当繁琐,因为 Git 主要是通过 SSH 协议进行通信,这要求在服务器上为每位成员创建具有 SSH 访问权限的账户。这一过程不仅复杂,而且对于大多数小组成员来说也不值得。因此,Tom 萌生了简化这一过程的想法。

  我翻阅了我的旧邮件,试图找到我第一次听说 Tom 要做“GitHub”项目是在何时。结果发现,是 Chris 在 2007 年底回复我关于 Git 屏幕录像制作的邮件中提及的。

  那么问题来了,为什么是 Git 赢了?那个时期出现了很多分布式版本控制管理系统。Mercurial 在很多方面都与 Git 很相似,甚至在很多方面都做得更好。为什么是 Git 在伟大的 DVCS 之争中胜出了?

  我认为答案与两个东西有关,一个是 Linux(以及 Linus),另一个是 GitHub。

  Linux 项目使用了 Git,是 Linus 启动了这一个项目,并给了它“即时的可信度”。

  任何一个人都知道 Linux,任何一个人都知道 Linus。既然他可以开发一个每个人都使用的操作系统,当然也有能力开发下一代版本控制管理系统。即使这个系统可能难以使用,但也许是因为他的智慧超越了我们,所以我们该更努力,不是吗?

  17 年前,Linus 在谷歌园区分享了他对 Git 和分布式版本控制管理系统的见解,当时这还是一个全新的理念,这也是第一场关于 Git 的演讲。这次演讲处于我 2005 年底开始使用 Git 和我 2008 年中加入 GitHub 之间。我反复看了好几次,其他几百万人也是。谁不喜欢听 Linux 的创始人在谷歌的舞台上直言不讳地说“CVS 是有史以来最愚蠢的发明,所有不同意这个说法的人都是既丑陋又愚蠢的”呢?

  除此之外,如果你将 Linux 与 Linus 本人混为一谈——大多数人确实如此——那就能认为 Linux 间接促进了 Git 的普及(主要通过 Android)。这正是我难以衡量自己或 GitHub 所做的努力与那些默默无闻的幕后影响力相比有多大作用的地方——Android 在那时成为一个现象级的存在。即使我个人做了多年的 Git 演讲和企业培训,也很难说究竟有多大影响。

  也许最终决定 Git 超越 Mercurial 的因素是 GitHub。

  GitHub 非常幸运地拥有一个令人难以置信的支持者社区,从一开始就热情地接纳了我们,即 Ruby 社区。在短短几个月内,Ruby 社区的每一个人都将自己的项目迁移到了 GitHub 上。Rails 当时非常火爆,比 PHP 更酷,JavaScript 框架还未兴起,Node.js 也尚未出现。因此,所有人都在关注 Ruby 社区里时髦人士在做什么,他们代表着软件开发世界的潮流。他们正在使用 GitHub。

  我还记得我们——Chris、Tom、PJ 和我——围坐在 Ruby 大会的桌子旁,向早期的 Ruby 社区成员展示 GitHub、推销 Git、做演讲等等。我们都在同一场会议上发表了演讲,并在旧金山的 Ruby 技术聚会后一起畅饮啤酒。这些人是 Rails、Heroku、Twitter、jQuery 等项目的先驱。

  Ruby 社区使用了 GitHub,这在某种程度上预示着每次会议上的演讲都会不可避免地提到一个 GitHub 插件。这就像是无处不在的免费广告。随着慢慢的变多的项目转到 GitHub 或直接在 GitHub 上启动,即便是 Mercurial 的拥趸者也不得不开始使用 Git。久而久之,坚持使用 Mercurial 可能就变得不再有价值了,GitHub 在代码托管领域的主导地位在短短几年内就超越了 Mercurial。

  你可能会好奇我是如何记住这些数字的?那是因为我创建了一个叫作的网站。一位叫 Jesper 的人给我发了一封电子邮件,指出我网站上的一个观点是不准确的。我争论说 Git 有 GitHub 作为支持,而 Mercurial 和 Bazaar 却没有。我相当自信地争辩说,它们不在同一竞争水平上。

  值得称赞的是,Jesper 从来就没因为我的反应而指责我。从我现在的角度来看,我当时确实有点刻薄。但事实上,Jesper 其实是 BitBucket 的创始人。

  当然,尽管 BitBucket 是在我们之后推出的,我们拥有先发优势,但也有一些托管服务是在我们之前就有的。那么,为什么它们没有赢呢?

  2009 年初,Google Code 开始支持 Mercurial,而 Sourceforge 则开始支持 Git 和 Mercurial。既然这一些行业巨头在我们启动几个月后就已拥有庞大的用户基础和 DVCS 的全面支持,那么,为什么他们没把我们这些后来者打得落花流水呢?

  从创业之初,我们就与风险投资公司做了接触。2008 年 7 月,PJ 给我发了一封邮件,表示他们盼望我加入团队,我们该全力以赴,辞去各自的工作,将这一个项目从副业变成全职工作。他明确说:“我们已与一家我们很看好的风险投资公司谈过,我们计划筹集一些资金来做一些事情。”这些事情包括租用办公室、招聘员工等。

  Greg 的文章确实指出,其他公司更关注分销和收入现金流。我们则专注于开发者需求。但这并不是他们何时引入 Git 的问题,这并不是关键。他们缺乏品味,从未真正关心过开发者的工作流程。即使他们随便什么时间都能引入 Git,但我依然认为他们最终会输。

  我认为,我们所做的一切事情的背后,更简单、更根本、更有趣的事情是我们为自己而构建。我们有品味,我们关心用户体验。

  」为你私家整理了一份演讲PPT合集,不容错过。关注「AI前线」,回复关键词「PPT」免费获取。