我们正处在一个激进的后开源时代：开源的过去和未来

我们已经目睹了开源在初创公司的发展过程中所扮演的重要角色，不过事实不仅限于此。

开源改变了初创公司，而初创公司也反过来改变了开源。

两个典型的初创公司，GitHub 和 Stack Overflow，它们一起为软件技术开启了新的篇章。我们现在所做的决定将影响着软件行业未来 5 到 10 年的发展走向。要想知道为什么，我们需要从头讲起。

70 年代到 80 年代：软件行业的开端

在 70 年代，所有人都在开发自己的软件，都在组建自己的电脑。IBM 在 1981 年发布了 IBM PC，也就是所谓的“个人电脑”，从此让硬件市场繁荣了起来。

随着硬件的繁荣，软件也搭上了这趟顺风车。商人从 IBM 身上看到了巨大的市场机会，而风险资本意识到软件比硬件的风险更小，而且更具上升的潜力。

于是，红杉资本注资 Oracle 开发数据库软件，IBM 委托微软为他们的个人电脑开发操作系统 MS-DOS。

突然间，开发自由软件的想法变得不受待见。软件开始变成商品。试想，如果你可以因此赚上百万美元，有什么理由不去做？

开发自由软件开始受到排挤，变成了反主流文化。如果你开发自由软件，你就无法跟上 Oracle 或微软的步伐。如果有人开发自由软件，那么他们也只是想把它们作为平台，而绝非产品。

这些程序员聚集在邮件列表和 IRC 上一起写代码，并且把代码公开放到网站上。任何人都可以根据需要使用和修改这些代码。

不过这些软件项目也并不好过，毕竟它们不带有商业性质。

如果你想为某个项目贡献代码，你必须先加入到维护者的联系通道。它们可能是 IRC，也可能是邮件列表，或者你需要先向他们发送一封自我介绍邮件，更有甚者你可能根本无法找到他们的联系方式。

这些项目不仅没有标准的沟通方式，也没有标准的开发工具。

开源项目使用版本控制系统来跟踪开发者对代码所做的修改。通过这种方式，开发者避免了重复工作和变更冲突。

在今天，如果有人说到版本控制，很多人会想到 Git，但其实除了 Git 之外还有很多其他系统，比如 SVN 和 CVS。每种系统的工作方式都有点不一样，开发者可以选择他们喜欢的系统。

所以，如果你想为某个项目贡献代码，必须先弄清楚要联系谁，以及如何跟他沟通。在你可以贡献代码之前，需要先做足功课。

90 年代后期：开源开始流行

在 90 年代后期，事情开始发生转变。很多组织开始使用 LAMP（Linux、Apache、MySQL、PHP）技术栈，这个技术栈所包含的工具都是开源的。此时，几乎所有人都可以开发几近免费的软件系统。

不过大公司仍然认为开源是一个笑话。Steve Ballmer视 Linux 为“毒瘤”，并认为“人们需要适当地为软件支付费用”。Bill Gates 在 1976 年写了一封公开信谴责盗版 BASIC 软件的“业余爱好者”，并说他们是在“偷窃”：

谁能够毫无目的地做着这些专业的工作？那些业余爱好者可以花上三个人年在编程上，并修复缺陷、写好产品文档，最后免费发布出来，他们可以从中得到什么？

不过不管怎样，初创公司对 LAMP 技术栈很感兴趣，因为他们只要为之付出收费软件十分之一的成本。因为使用这些免费软件，他们不需要太多的钱就可以启动他们的业务。

开源软件开始占领市场。

随着越来越多的人开始使用开源软件，开发者需要更好的工具来管理他们的项目。VA Research 公司看到了机会，他们出售预装了 Linux 操作系统的个人电脑，这里的 Linux 也就是 LAMP 技术栈里的“L”。

VA Research 公司发现越来越多的人使用开源软件对他们的业务来说就越是有好处。于是在 1999 年夏天，该公司的一些员工决定开发一个协作工具，名字叫作 SourceForge，并在同年秋天发布。

开发者在 SourceForge 上开发开源软件，SourceForge 成为一个标准的开源项目网站。开发者可以在 SourceForge 上免费存放代码、管理他们的项目、跟踪缺陷，这些事情都在一个地方完成。

不过版本控制仍然是一个棘手的问题。

Git 是如何改变一切的

开源操作系统 Linux 变得越来越受欢迎。不过 Linux 项目使用的版本控制系统 BitKeeper 不是免费的。虽然 Linux 之父 Linus Torvalds 喜欢 BitKeeper（BitKeeper 为他们发放了“社区许可”），但大部分开发人员对他的决定并不认可。

作为所有权软件，BitKeeper 对它的用户做了很多限制。例如，如果有人在 Linux 上使用 BitKeeper，他们就无法在 SVN 或 CVS 中打开 BitKeeper 管理的代码。

2005 年，BitKeeper 的开发者宣布，因为许可方面的问题，BitKeeper 结束对 Linux 的免费支持。BitKeeper 用户要么被迫接受一项商业协议，要么去寻找其他解决方案。

Linus Torvalds 并不喜欢现有的任何一款免费的版本控制系统，于是他决定自己开发。2005 年，Linus 发布了一款新的版本控制系统 Git。

对于这个名字，Linus 开玩笑地说自己是一个“任性的混蛋”，总是“为所有项目使用跟自己有关的名字”。“git”在英式俚语里是“不高兴的人”的意思。也就是说，除了 Linus，还有很多人都需要一个更好的版本控制系统。除了 Linus，其他开发者也喜欢 Git。Git 速度更快，而且它是分布式的，可以处理多个代码贡献者。

不过 Git 不是很直观，它跟其它的版本控制系统很不一样。SourceForge 并不支持 Git。

几年之后，SourceForge 迎来了新的竞争对手。2008 年，两个新的协作平台 GitHub 和 Bitbucket 出现了。它们都是很好的协作平台，不过它们之间有一个很大不同：Bitbucket 只支持 Mercurial，而 GitHub 只支持 Git。

在 BitKeeper 惨败之后，Matt Mackall 发布了 Mercurial，Linus 几乎在同一时间发布了 Git。Mercurial 和 Git 之间的竞争趋于白热化。

不过最后，GitHub 算是压对了筹码。

Linux 和其它优秀的开源项目转向了 Git。GitHub 让本来不是很直观的 Git 变得易于使用。

2010 年，SVN 在版本控制系统市场占据着主要位置，有60% 的软件项目在使用SVN，而使用Git 的仅11%。但在今天，Git 几乎占据了SVN 原来的市场份额。

Bitbucket 最初使用的 Mercurial 现今只有 2% 的软件项目在用。

GitHub 成为代码协作的首选平台。开源需要具备以下两个条件：

1. 标准的沟通方式

2. 标准的代码管理方式

GitHub 满足了以上两种需求，并且提供了更多的功能，比如新的社交机制，开发者之间可以互相关注，并且可以通过新闻种子查看项目变更。现在开发者还具有：

3. 标准的 Web 社交方式

到这里，整个故事就完整了。

好吧，几乎算是完整了。

Stack Overflow：为代码寻求帮助的地方

GitHub 成为代码协作的集中地。那么当开发者在碰到困难时该怎么办？他们一直在互相请教，并分享知识。

编程书籍因此变得非常受欢迎。有时候，人们会在私人邮件或邮件列表里讨论问题。不过，还没有一个专门的地方可以用来讨论代码内容。

1996 年，Experts-Exchange，作为第一批.com 网站，为 IT 从业者提供了一个可以寻求帮助的地方。

（为什么这个网站名字中间有一个连字符？它原先的网址是 http://expertsexchange.com ，后来有人指出这个网止有可能被误读为“Expert Sex Change”，于是他们把它改成 http://experts-exchange.com 。）

Experts-Exchange 采用的是高级会员制，并在 2001 年随着.com 浪潮的崩塌而破产。有人把这归咎于风险资本，JP Morgan 以550 万美元持有该网站51% 的股份，并让网站以拔苗助长式的速度增长。不过这个网站在拥有了新主人之后还是存活了下来。

不管怎样，这个网站的想法是非常好的。2008 年，Jeff Atwood 和Joel Spolsky 决定创建一个更加开放的网站，它的名字叫作Stack Overflow。

开发者从此有了一个可以寻求帮助的地方，他们可以在上面问关于编程语言的问题，或者为他们无法解决的代码缺陷寻求帮助。Stack Overflow 太过成功了，以至于后来发展成一个全面的问答网站，涉及的领域包括数学、Ubuntu 操作系统和密码学，等等。他们把整个问答网络称为Stack Exchange。

开发者便拥有了他们需要的所有工具。而在80 年代，他们需要同时使用IRC、邮件列表、论坛和版本控制系统。

截止2010 年，开发者可以使用Git 做版本控制，在GitHub 上进行协作，并在Stack Overflow 上进行问答。

2010 年至今：开源的黄金时期

现如今，加入开源项目变得很容易，因为所有人都用同样的工具，而且大多数项目都托管在同一个平台上。

现在要找出开源项目的维护者，以及这些人还在哪些项目上有过贡献，或者找出代码有哪些变更以及哪些缺陷仍然处在未修复状态，都变得比以前容易得多。因为这些准入门槛的降低，让我们迎来了一个开源的黄金时期。

开源项目的爆发

在 2011 年，GitHub 上有 200 万个代码仓库，而现在达到了 2900 万个。GitHub 的 Brian Doll 说，创建第一批百万个仓库用了 4 年时间，而从第 9 个百万到第 10 个百万只用了 48 天。

开源项目的发现

GitHub 的社交机制和平台特性让项目发现变得比之前任何时候都来得容易，这意味着更多的人可以参与到更多的项目当中去。

开源现在看起来很酷

还记得在 80 年代那些公司和风险资本是如何启动开源项目的吗？那样的状况一去不复返了。我们可以说“开源”已经变成了主流的科技名词了，而且它不仅仅只跟软件有关系。

例如，Bloomberg 开源了他们的投资手册 Beta 版，纽约时报开源了他们的代码风格指南，O’Reilly Media 开源了一本书。“开源”变成了“开放信息”，或许有人会说“开源”可以指任何的事物。

开源不再只是一个可选项

说一个有趣的故事，在80 年代自由软件运动的开端，他们推广了一个叫作GPL 的许可协议。随后其它的开放许可协议也纷纷加入进来，包括Apache、MIT 和BSD，这些协议有着不同层级的宽容度。

而GitHub 在开始时并没有推广任何新的许可协议。有些人认为GitHub 之所以这样做，是担心太多的“法律”约束会对开发人员加入开源造成影响。GitHub 对托管在自己平台上的项目并没有采取任何许可约束，你可以允许人们查看你的代码，并拉取它们的分支，除此之外的所有东西都只受版权的约束。

GitHub 的方式奏效了，很少会有人在 GitHub 上使用许可协议。一个来自 SFLC 的调查表明，截止 2013 年，GitHub 上只有 15% 的项目使用了许可协议。

在自由软件时代，人么需要考虑许可，因为他们需要明确自己的立场（比如他们要跟所有权软件区分开来）。而在 GitHub 时代，人们不关心权限问题，因为它们默认就是开放的。

开源在今天这么流行，我们不认为它只是一个意外。我们是如此的“开源”，或者说“后开源”，但在后开源的世界里并非万事亨通。

未来：后开源时代

随着开源成指数级的规模增长，有很多挑战亟待解决。

越来越多的贡献者带来的工作负载

因为越来越多的人可以发现并使用你的项目，他们会针对你的项目表达自己的观点，而你不得不去处理这些问题。

在以前的黄金时期，程序员的数量并不多，而且很多东西都没有标准化，项目的准入门槛比较高。而在今天，任何人都可以加入到 GitHub 项目中，并提出问题或需求，甚至说一些不是很好听的话……然后溜之大吉。

这个问题很难得到解决，因为 GitHub 本身不是开源的！也就是说，只有 GitHub 的员工能够对平台做出改进。

使用所有权软件来管理开源项目，这个听起来有点像 BitKeeper 和 Linux 的故事，人们并没有完全忘记这一点。有些开发者拒绝把代码放在 GitHub 上，他们想保持独立性。Linus Torvalds，作为 Git 的创始人，他也拒绝别人从 GitHub 上拉取他的代码。

当然，使用一个集中式的平台来管理百万个代码仓库也存在着一些问题：GitHub 在近年经历了几次宕机，包括去年的一次 DDoS 攻击，以及最近的一次网络瘫痪。瘫痪的是一个网站，但是受影响的却是所有人。

在这个月早些时候，一波开发人员向 GitHub 写了一封公开信，他们在信中表达了他们的沮丧，因为他们缺乏一个工具能够有效管理持续增长的工作负载，他们希望 GitHub 能够对平台做出重大改进。

开源项目走向产品化

开源项目的激增意味着围绕它们建立巩固的社区变得愈加困难，甚至不现实。

2008 年，GitHub 大约有 18000 个活跃的开源项目，而 SourceForge 大概拥有 15 万开源项目（包括活跃和不活跃的）。

而今天，GitHub 上有 2900 万个项目，比 2008 年的 SourceForge 高出 200 倍。

而在开发者规模方面又是什么样的情况？在美国，软件开发人员从 2002 到 2012 年期间翻了一番，超过了 100 万，不过这个跟开源项目的增长并不在一个数量级上。

以上数据截止 2012 年。美国劳工统计局期望接下来 10 年软件从业人员的工作岗位可以有 17% 的增长，这个看起来已经不少了，不过跟项目的增长比起来仍然不值一提。

在过去的 2 到 3 年里，有很多人开始学习编程，不过指望这些新手具备专业资格来为开源项目做贡献是不大现实的。

事实是，大量的业余开发者使用着开源项目，但他们对这些项目并不感兴趣，他们甚至无法为它们做一些回馈。他们或许可以为开源项目修复一些次要的问题，而重担仍然落在了那些有经验的老程序员的肩上。

有经验的维护者感觉到肩头的重担。在今天看来，开源不太像是一条双行线，而更像是没有人为之掏钱的产品，但仍然要在维护这些项目上花费很多时间。

这个与发生在报纸和音乐行业的情况有点像，只不过软件是开源的而已。

代码并不凌驾于法律之上

许可协议的故事后续是这样的：软件并不凌驾于法律之上。2013 年，GitHub 开始在许可问题上表明自己的立场。他们建议人们在创建新项目时使用许可，并创建了一个小网站 http://choosealicense.com 来帮助项目所有人更好地选择许可协议。

Stack Overflow 也在后开源时代里痛苦地挣扎。自 2008 年以来，Stack Overflow 为它的全站内容使用了 CC-BY-SA 许可协议。CC-BY-SA 要求对发布的内容指明所有权，而且要求对该内容的分享要遵循同样的许可，然而这并不利于人们为他们的代码寻求帮助。

从原则上说，如果你使用了 Stack Overflow 上的代码，必须注明代码的所有权，那么这个人的代码在你的代码里就相当于开启了自己的许可。

大部分业余开发者也许并不关心这些规则，不过基于上述的原因，大部分公司会禁止他们的员工使用来自 Stack Overflow 的代码。

随着我们进入后开源时代，Stack Overflow 决定转向 MIT 许可，但这并非一件易事。那些遗留的代码和代码以外的东西，会让人们产生混淆和强烈的反应。

从公司层面来看，公司也在试图理解他们参与开源项目或发布自己项目的合法性。现在有很多公司都有专门部门来处理开源问题，比如 HP 和 Facebook。

软件开发变得碎片化

Drew Hamlett 在这个月写了一篇叫作“ Web 开发的悲哀现状”，他在文章里抱怨开发者总是在重复发明轮子，而不是帮助一起构建一个稳定的生态系统：

没有人能够开发出一个可以包罗万象的软件库。而项目一个比一个有野心……我只是不明白。我所能想到的是，人们只是在不断地重写 Node.js 应用程序。

在开源流程变得标准化的同时，它的产出却在发生碎片化。开始新项目要比为旧项目贡献来得容易得多。例如，我们可能得到 10000 个功能重复的小型代码仓库，而不是 100 个大型的活跃的开源项目。开源项目最大的一个优势是弹性。从理论上说，一个具有多个贡献者的开放项目要比一个只有少数贡献者的公司私有项目要健壮得多。

而现在，对开源项目的大规模采用，却可能把我们带向另一个方向。

前行之路

LAMP 技术栈、GitHub 和 Stack Overflow 为开源的流行做了很大贡献。就像“移动电话”变成事实上的“电话”，“开源软件”正在成为事实上的“软件”。

这是开源的伟大胜利。不过与此同时，开源也面临着新的挑战，比如，如何有效地管理需求和工作流，如何鼓励代码贡献，以及如何构建健壮的生态系统。

或许我们还未感受到肩上的重担，但是冬天真的来了。在后开源时代，我们必须去面对这些问题。

查看英文原文： We’re in a brave, new post open source world

感谢徐川对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。