众所周知，我一直在各处主张“团队无用”这一理论，但是并不被人所看好。我认为，现在是写一篇文章讲清楚讲明白这一看法的时候了。

什么样的团队是无用的？团队无用，真的是所有团队都没有用处吗？显然非也。在一个巨型公司中，划分项目组和事业部，显然是必要而且可以提高工作效率的。这里我指的“团队无用”，展开来讲，就是基于具体产品和项目之上构建的但凌驾在项目之上且组织架构与项目无关的团队。举个例子吧，Litmus OS就是一个产品，而它的开发者原来是“Litmus OS开发团队”，这很好；但是，后来变成了“十叠Cladonia”，虽然它的产品还是只有Litmus OS，但这个团队的名称和理念与Litmus OS已经毫无关系，于是我们说，这种团队是无用的。

为什么说团队是无用的？难道团队不是协作以提高效率的吗？确实不错，但是正如我上面所讲，一些纪律严格到变态，将组织放在项目之上的团队，事实上一定会降低协作效率。有一些团队，只有一个项目（产品），就开始招人；你确实能招来人，但是这些人是因为热爱你的项目还是热爱你的团队才加入你的团队的？举个例子，比如有个YOUR Stuido，有个产品叫Conncet IU，他们开始招人，有不少人想要参加这个项目开发。但是，并不是所有人都热爱这个团队，大部分人是奔着项目来的。

此时，这个团队里的人，他们有的只是想来做一点点东西，有的只是想来提供一小部分支持，你却让他们加入一个团队，他们怀着对你们项目的热爱不情愿的进来之后却发现你给他们分配了一堆他根本不愿意完成的任务。无论何时，项目和产品开发一定是一群人工作的核心，此时如果在上面胡乱的就搞一个高高在上的团队，把产品作为这个团队的所谓“战略步骤”，而且还将团队成员作为团队财产随意支配，这种团队注定失败。这种团队只不过是虚假还束缚个人个性的东西，正如此前的“十叠Cladonia”和“野望Earthink”，它们都有自己的一套规程，把项目视为自己的财产。但是“ZeroX Studio”则可以说部分脱离了“无用团队”的范畴。如果要说凝聚力的话，这种团队不可能有凝聚力，劲不可能往一处使，因为它的成员并不是全身心的投入在项目中，他们要应付团队的各种官僚主义的制度和形式，要完成自己本不愿完成的任务，团队绝无可能拥有凝聚力。

我现在可以斩钉截铁的说，一切团队都是刚起步的好项目的绊脚石，团队做的只是降低效率。

所以说，为什么你的团队招不来人？你打出的旗号是“XXX工作室招人了！”还是“XX项目需要你！”？可能因为，你的项目虽然很想让人给你做点东西，但是你却让他加入一个有名无实团队，虽然实际上他只想给你做点微不足道的贡献。这个项目是所有人的项目，管理者本人确实需要对项目做出长远的规划，但是决不能让管理者的错误行动成为项目的方向，管理者不能负这样的责任。

既然团队无用，那么是不是说一个产品就只能个人开发？当然不是。即使再狂热的个人主义者，也不得不承认要做好一件事，必须有很多人共同参与才行。我们的确需要一群人共同开发，但是，团队并不是协作开发的唯一手段和形式。既然已经说明了团队毫无用处，那么为什么还要在它上面做一点点无关痛痒的改良？就应该全盘抛弃团队，这不是逃避，这是直面现实，而不顾团队这一模式的重大缺陷还想着稍稍改一下继续用团队，那才是真正的逃避问题。有一种协作开发模式，名叫“社会化编程”（或社会化开发，Social Coding），这也是GitHub诞生时候写在LOGO下面的Slogan。

所谓“社会化编程”，是由GitHub打造的概念。这是一个真正的以项目和产品为核心的，为人服务的协作模式。它以Repository（仓库）为核心，这里的仓库可以理解为一个项目/产品。你可以在GitHub上创建一个仓库，然后在上面添加一个README（自我描述）文件，写下你的项目的目标和里程碑等。你可以在你的仓库中上传你的项目文件（代码、程序等）。在GitHub上，绝大多数仓库都是公开的，任何人都可以看到仓库里的文件并下载到本地。这是讲如何创建一个项目。

那么，如果要多人协作该怎么办呢？任何人都可以Fork（分叉）一个他人的仓库到自己的账号上，简单理解就是复制一份别人的仓库给自己，但是这不是普通的复制，如果这个仓库的原作者更新了自己的仓库，你可以选择将他的更新拉取到自己这里；如果你更新了这个分叉的仓库，原仓库不会同步更新，但是你可以将你的更改提交给原作者，他可以将你的更改合并到原仓库之中；如果原作者不理会你的更改，你照样可以将你分叉的仓库作为自己的作品继续开发。在GitHub的仓库中，以上操作有一个专门的叫做Pull requests的功能处理。除此之外，GitHub上还有一些功能，比如Issues，用来管理需求和缺陷；Wiki，用于编写文档等。

而社会化编程，简单而言，就是你可以以个人的身份随便浏览GitHub上的仓库，然后为它修改代码、进行开发，而不需要加入这个项目组/团队。你是一个贡献者（Sponsor），你可以为这个项目做出一些自己的微小的贡献然后就离开再也不管不顾，而不需要像加入团队一样持续关注。这是个人与个人的自由联接，项目之间的分支和合并，这里不需要存在团队，不需要存在组织架构。这是一个松散和自由的组织，是社会化的协作。我们不需要一个团队，我们需要的是人和人之间的交流与共鸣。

团队终究是一个相对封闭的组织，内部的信息不能对外开放。而开放源代码、社会化编程的世界中，任何人的项目和产品都是开放的，只要有人对你的项目感兴趣，他就可以对你的项目做出一些贡献，无论是调整一点点小细节还是大刀阔斧的推倒重来，都只需要Fork+Pull requests，而不必加入一个团队，被迫接受一个团队的官僚化的规章。如果一个人对项目的贡献特别的大，项目的运营者自然会找到他，请他成为这个项目的管理者（Comitter），也就是“核心开发人员”。在社会化编程之中，没有什么中心，一切都是共享的、共有的，你找不到核心版本库，只有比较重要的版本库，这里也没有什么私有的东西，一切都是公开的。这对于发展开发人员的生产力的益处，是很难用文字表达的。

如果想让项目更好地发挥自己的生命，开放源代码和社会化编程就是最好的方式。我们可以举个例子——Linux。Linux是当初由Linus Torvalds开发的一个操作系统，在开发出来的第一时刻，Linus就把它放到了互联网上，以GPL许可证开放了源代码，欢迎所有人修改提交。现在，围绕Linux内核有了几千人的核心开发团队，还有数不胜数的或许超过几十万人在为Linux提交自己的贡献和创意，Linux凭借它的安全和稳定，已经成为现在绝大部分服务端的操作系统。这不是Microsoft封闭的Windows能比的，即使Windows有几千人的开发团队，每一个人都是最棒的工程师，但是相比Linux动辄数万人的贡献，还有无数用户的反馈，Windows绝对算不上是伟大的产品，更不会有Linux那样的成就。

至于Ruby on Rails、npm等，就更不必说了，它们以开放源代码和社会化编程的方式，打造出了以团队方式八辈子都做不出来的优秀产品。

现在，对于“团队是优秀项目的绊脚石”和“团队无用”这一看法，想必你已经有了更多的感触。团队，尤其是自以为是的团队，会把项目搞得一团糟。

我想，我已经把我为什么主张团队无用论的理由，讲的很清楚了。对于社会化编程和意识形态之间的关联，我们会在以后加以详细讨论。