2008年，Tom Preston－Werner、Chris Wanstrath 和 PJ Hyett 三位挚友聚在一起，准备合作开发一个周末小项目。但是没过多久，他们便意识到这个想法可能比他们预想的要大得多。他们的想法远不止一个周末小项目那么简单，它将彻底改变人们编写代码和分享代码的方式。
这个想法就是 GitHub。
在短短10年间，GitHub 便彻底改变了人们的编码方式。GitHub 不仅让编码变得容易，它还改变了软件开发人员对编程的看法和理解。
世界范围内，无数的人都在为代码协作方式感到头疼，GitHub 横空出世，解决了这个疑难问题，并设计出了市场迫切需要的优雅解决方案。以此，它得以惊人的速度发展壮大，取得了巨大的成功。通过围绕开源项目 Git 构建 SaaS 服务，GitHub 能够为开源生态系统提供价值并从中获利。GitHub 对微软来说充满吸引力，尽管微软曾经在开源社区并不显眼，但它在2018年6月初对 GitHub 进行了收购。
我们一起来看看下列问题：
GitHub 如何从一个版本控制系统发展为程序员的社交工具，并最终成为在线存放和管理代码的重要场所？
为什么 GitHub 的免费增值模式运行良好，并且能够如此有效地引领时代？
GitHub 如何抓住了广阔的潜在市场需求，并围绕这种需求创造了一种刚需产品？
为了更好地理解 GitHub 的重要性，我们需要回到2008，了解当时的软件开发现状，以及是什么造就了伟大的 GitHub。
一、2007～2011年：代码协作与软件社交
比尔盖茨和史蒂夫乔布斯从根本上重塑了个人计算机，他们成为家喻户晓的名人，但我们也完全无法忽视芬兰软件工程师 Linus Torvalds 对科技领域的巨大贡献，他创造了 Linux 操作系统。
当时的 Windows 和 Mac 几乎统治了整个操作系统领域，Linux 操作系统于1991年发布，它是一个非常灵活、轻量级和安全的开源操作系统，面世之后，很快就受到了想要对系统进行深入控制的极客以及技术人员的青睐。
发明一个全新的操作系统这样的成就可能对大多数程序员来说都应该感到知足了，但 Torvalds 却并不满足，他没有停下创新的脚步。2005年，Torvalds 推出了他的最新项目：一个名为 Git 的新的版本控制系统。版本控制对编程协作来说至关重要，它需要跟踪计算机中随时间变化的文件。它与计算机备份系统用作还原点的“快照”类似，版本控制系统让程序员能够通过“fork”或者“分支”来管理项目代码，程序员在同一个项目工作，但不会影响其他人编写的代码。程序员可以在自己的分支上进行开发，之后将新的代码合并到主项目（也就是代码仓库）中。
在 Git 诞生之前，程序员之间进行编程协作的方式很少。其中 Subversion 比较受欢迎，它是一个开源的版本控制系统。它存在着与其他版本控制系统类似的缺点，当然这些缺点是当时的协作编程概念所无法避免的。即使使用了Subversion，与开源团队合作通常也需要获得项目管理员的许可才能 fork 项目的一个分支，否则便无法编辑代码。在许多情况下，批准过程比编写代码花费的时间更长。许多开源项目都受到权限问题以及其它一些低效率事情的困扰。
当 Git 于2005年发布时，开源领域正在经历一场文艺复兴。那时的开发者对 Linux 充满浓烈的兴趣。第一个 Web 2．0 应用程序已经开始出现。许多公司正在将他们的项目迁移到开源服务器。尽管 Git 通过引入 fork 概念使得开源项目的合作变得容易，但 Git 依然有其局限：它无法帮助开发人员寻找开源项目。许多程序员开发了大量的优秀开源项目，但却很难让他人知道这些项目。
GitHub 改变了这一切。
PJ Hyett 和 Chris Wanstrath 在2007年开始讨论 GitHub 项目，当时这两人都是科技网站 CNET 的程序员。他们都支持 Ruby on Rails 开发框架。当他们在 CNET 工作时，Hyett 和 Wanstrath 还为 Rails 的代码库提出了一些改进和建议。但是，让其他人真正查看他们的代码是另一回事。
正如当时大多数开源项目的典型情况一样，Rails 的代码库由一个小型的、紧密结合的程序员管理，他们手动管理对代码库的贡献。这些程序员扮演者管理员的角色。Hyett 和 Wanstrath 不仅要请求这些管理员查看他们的代码，还要让他们相信自己提交的代码对 Rails 项目是有价值的。即使其中一个项目管理员认为提交的代码有用，但是补丁的合并也不会很容易。
从本质上讲，想要为 Rails 项目贡献代码，熟人的烂代码比陌生人的好代码更容易通过。
Git 试图解决其中的一些问题。Linus Torvalds 的版本控制系统与他几年前单枪匹马打造的操作系统一样出色。Git 使得程序员无需管理员开通访问权限，即可进行编码协作。Git 是编码最终民主化的关键第一步，特别是在开源社区。但是，尽管 Git 解决了很多问题，但它缺乏协作工具，并且两个程序员之间共享代码仍然很笨拙和困难。现在可能很难想象，当时软件开发人员需要通过电子邮件不断来回发送补丁，这就很容易理解为什么迫切需要 GitHub。
遗憾的是，这不是 Git 唯一需要的东西。起初 Git 主要依赖于命令行界面，好在 Git 发布后很快就推出了图形界面。对于那些多年来一直在编写 bash 脚本和正则表达式的系统管理员和其他高级用户来说，这是个好消息。对于其他人来说感觉倒并不明显。
“人们开始在 Ruby 会议上谈论 Git。主要讨论它的好处，但有时也谈到缺点。Git 会以分布式方式处理代码，但是如何保证共享私有代码的安全性呢？唯一的选择是在 Unix 计算机上设置用户帐户并将其用作临时解决方案。这个解决方案并不理想。”? —?Tom
Preston－Werner
尽管存在这些缺点，但 Git 依然充满潜力，它给了来自湾区的 Ruby 程序员 Tom Preston－Werner 一些想法。当时 Preston－Werner 正在开发一个名为 Grit 的项目，这个工具让程序员能够使用 Ruby on Rails 以面向对象的方式访问 Git 存储库。Preston－Werner 在旧金山一家名为 zeke＇s 的体育酒吧内举办的 Ruby 会议上认识了 Chris Wanstrath，Preston－Werner 把 Grit 告诉了 Wanstrath。
Preston－Werner 的愿景是创建一个可以托管整个代码库的地方，程序员可以协同工作代码项目，并了解如何充分利用 Git。用 Preston－Werner 的话说，它将是一个“ Git hub（中心）”。
Preston－Werner 和 Wanstrath 于2007年10月1日正式开始制作 GitHub 的第一个版本。在旧金山体育酒吧相识的几周之后，Chris Wanstrath 提交了第一个 GitHub 版本，从此便彻底改变了编程方式。
当 Preston－Werner 和 Wanstrath 在2007年开始合作时，他们的想法不是将 GitHub 作为商业工具开发并围绕它开展业务。Wanstrath 和 Preston－Werner 需要 GitHub 来完成他们自己的工作，所以他们开发这个工具是为了满足自己的刚需。他们很快就发现了他们工作中的一个主要问题：他们需要 fork 代码分支和协作编程，并设计出满足他们需求的解决方案。对于这个 Wanstrath 和 Preston－Werner遇到的问题，无论使用哪种编程语言或者操作系统，几乎所有软件开发人员都会遇到。这代表了他们的产品在未来拥有巨大的市场潜力。
在接下来的几周里，Wanstrath 在周末与 Preston－Werner 会面，共同完成了 GitHub 的第一次迭代。Preston－Werner 主要负责设计，Wanstrath 专注于实现 Preston－Werner 提出的功能。
“在接下来的三个月里，Chris 和我花了很多时间来规划和编写 GitHub。平时我继续为 Grit 设计 UI。Chris 构建 Rails 应用程序。我们每个星期六都会见面讨论设计，并规划这个产品的蓝图。” —?Tom Preston－Werner
2008年1月，经过三个月利用周末时间编写代码，GitHub 有点像模像样了，Wanstrath 和 Preston－Werner 准备向全世界推出 GitHub。正如 Spotify 在其关键的早期开发阶段所做的那样，GitHub 首次以私有测试版的形式推出。Wanstrath 和 Preston－Werner 通过向他们在湾区及其他地区的初创公司的朋友发送电子邮件，邀请他们使用他们构建的工具，之后便立即得到了积极的回应。接下来的一个月，他们将 Logical Awesome 改名为 GitHub，Inc，并作为公司正式成立。
虽然这两个人还没有开始创业，但他们的想法蕴含巨大的商业潜力。2008年4月，就在 GitHub 推出私有测试版并在同月推出其官方网站的三个月后，Chris Wanstrath 收到了来自在线学习网站 PeepCode 的创始人 Geoffrey Grosenbach 的消息，该网站刚刚将其代码迁移到了 GitHub。Grosenbach 告诉 Wanstrath 他不习惯使用 GitHub 免费托管他公司的代码库，他愿意付费。来自活跃的 GitHub 用户的这类消息展现了 GitHub 的价值。即使 GitHub 没有向用户收费，有些人也愿意为此付费。
“我使用 GitHub 免费托管我公司的代码，我对此感到有些不好意思。我可以发一张支票给你们吗？” ?——PeepCode 的创始人 Geoffrey Grosenbach
GitHub 发展中最重要的一个因素是其商业模式的简洁和优雅。如果你想公开托管你的代码，GitHub 可以永久免费使用。如果你想使用私有存储库或专有代码，你需要付费。这两个用例完全不同，这消除了 GitHub 使用免费增值产品蚕食其受众的风险。
GitHub 公司完全可以将 GitHub 置于付费模式，并且可以通过收费来赚很多钱，但事实上 GitHub 并没有这么做。GitHub 商业模式的另一个特点就是无缝从免费增值产品过渡到私人付费存储库。如果程序员在 GitHub 上托管他们的开源个人项目并定期使用该产品，他们很有可能会建议他们在日常工作中使用 GitHub。
与 GitHub 的商业模式一样简单和合乎逻辑，它是 GitHub 以其实现方式有效商业化开源软件开发的唯一可能方式。如果 GitHub 从一开始就试图从所有存储库中获利，那么 GitHub 可能永远不会被开源社区所喜爱。如果没有这种基层支持，该公司将无法生存。
另一个需要采用智能方法定价结构的因素是将 GitHub 作为 Web 服务运营。作为开源代码在网络上存放的地方这听起来很棒，但有人必须为带宽付费。对于 GitHub 来说幸运的是，Geoffrey Grosenbach 并不是唯一一个想要给 GitHub 捐款的热心用户。一些公司还提出愿意花钱使用 GitHub 来托管他们的代码，这让公司的创始人意识到该公司作为营利性企业的潜力非常巨大。
“我们意识到 GitHub 可能不仅仅是能够收回成本，它可能成为一项真正的商业。我们决定继续免费提供无限制的公共存储库，但我们会向私有存储库收取费用。换句话说，我们会向该付钱的人收钱。”?——Chris Wanstrath
