NodeJS即将超越Ruby， 正在悄悄改变开源面貌

截至2013-09-11日：　现在你打开 https://npmjs.org/ 你会看到基于nodejs的包已经超过4W了 , 基于NodeJS的模块数据增长惊人,
在过去的５个时间里，包的数量增加了了1.4Ｗ个，增长接近50%, 已经接近Ruby。

关注下pypi，npm, rubygems社区上的开源包的发布，从python（1991），ruby(1995)，和node.js(2009)发布日期开始，
这些社区上每年发布的开源包以下面的比例增长：
python: 29,720包/22年 = 1351包每年
ruby: 54,385包/18年 = 3022包每年
node.js: 26,966包/4年 = 6742包每年

这种node.js开源包惊人的增长现象，怎么会成为可能？

不内置电池

如果，你曾经需要一个Python的客户端库，你可能问你自己"我是要用urllib, urllib2, 还是 httplib呢?”，就像其他所有人 . 好吧，答案可能是你应该使用requests. 它是一个很简单，直观的HTTP客户端库，很好的封装了很多标准库的陷阱和bug，但很可惜的是它不像上面其他库一样是标准库。
Python的“电池内置”策略在90年代中期绝对是正确的，这也是我很喜欢它的一个原因。在那个年代，没有现代化的包管理，查找和安装社区创建的库并不是很容易。现在，虽然，我认为这样效率并不高，但当时社区的开发者很少想去和标准库竞争，所以人们很少尝试着去写出提升标准库的改良库。

开发者也很不喜欢在他们的项目中使用非标准库。我听到过很多人隐忍着使用次等的标准库只是为了“不依赖外部库”。但在现在，大容量存储器如此便宜，又拥有现代化的包管理工具，人们不应该再采用“不依赖外部库”的策略.
相反, node.js 核心开发者实际上想尽可能的最小化标准库。他们已经多次从标准库里移除的特性，而鼓励大家使用社区实现的版本。这样的方法允许最大的多样性，让最好的实现版本胜出（当然，当有人实现出来一个更好的版本就会再次替换!）。
想像一下，这样对标准库维护者也是多么自由啊。node.js 标准库是 相当小, 这样可以释放核心开发者更专注在核心的部件上。

小就是美(The Tiny Module Aesthetic)

这种方法也并不是多特别，起码在node.js社区。这个社区被一群开发者领导，其中每个开发者都发布了几百个包。我从前都不相信有这种可能性.
当然，我们不可能限制其他语言也这么做，所以，我更相信是社区文化起了决定性的影响。
像Ruby on Rails这种大单体框架并没有侵占node.js社区的份额，我想部分原因在于"小模块更美"(“tiny module aesthetic”)这种思想, 而且这个思想也更适合node.js。对我来说，像Rails这种大框架没有一个清晰的边界，所以他们倾向于无限的扩张从而包含一个应用可能需要的所有东西。这导致人们坚信Rails是所有问题的最好解决方案，从而阻碍了Ruby社区在web应用领域的变革。

这种小模块更美的思想也导致了一个高度重用的生态系统。当一个包只做必要的事情时，它非常容易理解和更容易集成到其他应用。相反的，大单体框架趋向于出现在大量的终端用户应用中，而很少被其他包依赖。这对我来说感到很遗憾，因为那些软件那么优秀，却那么难重用。

git 和 github.com 单种栽培(monoculture)

老实说，对我来说软件开发过程中，很少有东西比版本控制让我更厌烦的。而且我发现git对我来说有点太复杂了。但是我还没听说过那个node.js开发者不用git的，这种单种栽培有非常大的价值。这意味着他们使用同一种通用语言，当他们想为其他人的项目贡献时，没有任何障碍。
Github.com 在降低开发者相互贡献的障碍时有同样的效果。我很少看见node.js项目不在github上.这意味着如果我想做出贡献，我可以马上知道去哪里找到源代码。
github单种栽培的优缺点远远超过这些，但要完全说明它们，恐怕要开单独的一个文章来说明。


自由的许可(Permissive Licensing)

Node.js 包倾向于使用非常自由的许可，例如MIT和BSD许可。实际上，使用`npm init`创建一个包时，缺省的许可是BSD. 我想这是新时代的另一个标志。
很少的人会在意别人创建新分支(forks)却不回馈(contribute back)。而且人们如果不回馈也收获甚少，因为要花精力维护自己的分支。
这很重要，因为没有人想去处理牵涉到法律后果和更多法律责任的事务。像GPL这样的许可，因为这个原因，最终减缓了软件重用。