|
我们已经目睹了开源在初创公司的发展过程中所扮演的重要角色，不过事实不仅限于此。
两个典型的初创公司，GitHub和Stack Overflow，它们一起为软件技术开启了新的篇章。我们现在所做的决定将影响着软件行业未来5到10年的发展走向。要想知道为什么，我们需要从头讲起。 在70年代，所有人都在开发自己的软件，都在组建自己的电脑。IBM在1981年发布了IBM PC，也就是所谓的“个人电脑”，从此让硬件市场繁荣了起来。 随着硬件的繁荣，软件也搭上了这趟顺风车。商人从IBM身上看到了巨大的市场机会，而风险资本意识到软件比硬件的风险更小，而且更具上升的潜力。 于是，红杉资本注资Oracle开发数据库软件，IBM委托微软为他们的个人电脑开发操作系统MS-DOS。 突然间，开发自由软件的想法变得不受待见。软件开始变成商品。试想，如果你可以因此赚上百万美元，有什么理由不去做？ 开发自由软件开始受到排挤，变成了反主流文化。如果你开发自由软件，你就无法跟上Oracle或微软的步伐。如果有人开发自由软件，那么他们也只是想把它们作为平台，而绝非产品。 这些程序员聚集在邮件列表和IRC上一起写代码，并且把代码公开放到网站上。任何人都可以根据需要使用和修改这些代码。 不过这些软件项目也并不好过，毕竟它们不带有商业性质。 如果你想为某个项目贡献代码，你必须先加入到维护者的联系通道。它们可能是IRC，也可能是邮件列表，或者你需要先向他们发送一封自我介绍邮件，更有甚者你可能根本无法找到他们的联系方式。 这些项目不仅没有标准的沟通方式，也没有标准的开发工具。 开源项目使用版本控制系统来跟踪开发者对代码所做的修改。通过这种方式，开发者避免了重复工作和变更冲突。 在今天，如果有人说到版本控制，很多人会想到Git，但其实除了Git之外还有很多其他系统，比如SVN和CVS。每种系统的工作方式都有点不一样，开发者可以选择他们喜欢的系统。 所以，如果你想为某个项目贡献代码，必须先弄清楚要联系谁，以及如何跟他沟通。在你可以贡献代码之前，需要先做足功课。 在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上免费存放代码、管理他们的项目、跟踪缺陷，这些事情都在一个地方完成。 不过版本控制仍然是一个棘手的问题。 开源操作系统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社交方式 到这里，整个故事就完整了。 好吧，几乎算是完整了。 GitHub成为代码协作的集中地。那么当开发者在碰到困难时该怎么办？他们一直在互相请教，并分享知识。 编程书籍因此变得非常受欢迎。有时候，人们会在私人邮件或邮件列表里讨论问题。不过，还没有一个专门的地方可以用来讨论代码内容。 1996年，Experts-Exchange，作为第一批.com网站，为IT从业者提供了一个可以寻求帮助的地方。 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上进行问答。 现如今，加入开源项目变得很容易，因为所有人都用同样的工具，而且大多数项目都托管在同一个平台上。 现在要找出开源项目的维护者，以及这些人还在哪些项目上有过贡献，或者找出代码有哪些变更以及哪些缺陷仍然处在未修复状态，都变得比以前容易得多。因为这些准入门槛的降低，让我们迎来了一个开源的黄金时期。 在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:// Stack Overflow也在后开源时代里痛苦地挣扎。自2008年以来，Stack Overflow为它的全站内容使用了CC-BY-SA许可协议。CC-BY-SA要求对发布的内容指明所有权，而且要求对该内容的分享要遵循同样的许可，然而这并不利于人们为他们的代码寻求帮助。 从原则上说，如果你使用了Stack Overflow上的代码，必须注明代码的所有权，那么这个人的代码在你的代码里就相当于开启了自己的许可。 大部分业余开发者也许并不关心这些规则，不过基于上述的原因，大部分公司会禁止他们的员工使用来自Stack Overflow的代码。 随着我们进入后开源时代，Stack Overflow决定转向MIT许可，但这并非一件易事。那些遗留的代码和代码以外的东西，会让人们产生混淆和强烈的反应。 从公司层面来看，公司也在试图理解他们参与开源项目或发布自己项目的合法性。现在有很多公司都有专门部门来处理开源问题，比如HP和Facebook。 Drew Hamlett在这个月写了一篇叫作“Web开发的悲哀现状”，他在文章里抱怨开发者总是在重复发明轮子，而不是帮助一起构建一个稳定的生态系统：
在开源流程变得标准化的同时，它的产出却在发生碎片化。开始新项目要比为旧项目贡献来得容易得多。例如，我们可能得到10000个功能重复的小型代码仓库，而不是100个大型的活跃的开源项目。开源项目最大的一个优势是弹性。从理论上说，一个具有多个贡献者的开放项目要比一个只有少数贡献者的公司私有项目要健壮得多。 而现在，对开源项目的大规模采用，却可能把我们带向另一个方向。 LAMP技术栈、GitHub和Stack Overflow为开源的流行做了很大贡献。就像“移动电话”变成事实上的“电话”，“开源软件”正在成为事实上的“软件”。 这是开源的伟大胜利。不过与此同时，开源也面临着新的挑战，比如，如何有效地管理需求和工作流，如何鼓励代码贡献，以及如何构建健壮的生态系统。 或许我们还未感受到肩上的重担，但是冬天真的来了。在后开源时代，我们必须去面对这些问题。 本文翻译已获授权，原文链接见： https:///@nayafia/we-re-in-a-brave-new-post-open-source-world-56ef46d152a3#.hudqzkz27  |
|
|
来自： openlabzeng > 《待分类》
