为什么基于成功的开源项目的商业产品会失败？
点击上方“开源之道”关注我们
导读
首先解释下题目，所谓的成功的开源项目，主要是已经被市场和技术所证明已经非常成功的社区主持下的项目，如Linux、OpenStack、oVirt、Kubernetes等等，另外一个特点，就是这些开源项目更加的倾向于基础设施软件，如操作系统、IaaS平台，虚拟化管理平台等。至于商业产品，就是基于上述开源项目，进行包装、二次开发，然后出售许可证等之类的商业产品。最后，解释下失败，此处的失败不包括其商业模式或公司盈利等的失败，而仅仅指的是上述的商业产品在市场的存活时间，其内部开发的周期上的失败，换句话说，就是这个产品不再有未来，从此消失在历史的舞台。
这个题目，纯粹的是从个人的职业经历的角度上的一个总结，不是类似 Gartner，Forbes等技术、市场专家从宏观、调查的基础上去预测和评价的，所以并不具备普遍性。虽然我想着这篇文章是尽可能的惠及众人，但我仍然会阐述一些如何避免类似的悲剧发生的几点大的方向。
另外我会从以下几个要点来说明：
我个人所经历的失败。
在失败的路上他们都在做什么？
失败的几个症状有哪些？
为什么会失败？
如何避免这样的失败？
安娜卡列尼娜定律
附录： Linux发行版，OpenStack发行版，BSD发行版之间的一些特征对比。
个人职业生涯经历
我从事软件开发从07年算起，到今天已经7年多了（注，本文写于2015年初），但是经历的产品却一点也不少，下面是一一的列举：
07-10 中科红旗Linux服务器企业版 CentOS 4
08-10 中科红旗高可用集群 Heatbeat + Pacemaker
10-11 普华IaaS云平台 CloudStack
11-12 云端时代x86终端Linux构建平台 OBS
11-13 云端时代云桌面 oVirt
13-15 易云捷迅 oVirt&&OpenStack
在上述的这些项目中，有的我只是一个普通成员参与的，有的则是以完全主导的身份参与的，无论什么的角色，最后都难以避免最终消失于市场的命运，我个人的遭遇也不太好，因为意见的不一致，导致闹的不愉快的公司有两家。虽然最终时间证明了我的观点，但是又能怎样了呢？最后我也不得不逃离这些公司，尝试着去保持独立。
在失败的路上他们都在做什么
每一家创业公司也好，或者是公司的内部开发新的市场成立事业部也罢，总是先要推出产品的，那么在开源世界大势所趋的时代，快速的开发一款产品，（这里不是指互联网公司开发的应用，而是基础设施软件，换句话说，就是企业或者互联网公司的应用背后所支撑的软件，如操作系统等。）并非是一件很困难的事情，时间也不是什么大的问题。
首先，当然是选型了，选型的过程，一般是技术人员对一些功能类似的项目进行对比，然后出报告，最后是老板拍板，因为他要考虑市场和消
费群体。靠谱的技术人员会按照下面的角度来考察一个开源项目：
解决了什么问题。
项目的历史有多久。
发起人是谁？或者是哪个公司？
代码的架构如何？
使用什么样的编程语言？
采用何种构建方式？
社区的活跃度如何？
背后有哪些商业公司在支撑？
社区的生态系统是否完善？
安装、配置的容易度是多少？
项目是基于什么开源协议？
文档是否齐全？
成熟度如何？有哪些公司/企业在使用？
当你没有花费了3～5个月去做这件事情，有一些遗漏的时候，老板已经表现出非常的不耐心，这时技术人员会将残缺不全的报告递交给老板，然后，老板会利用他自己的圈子，四处打听，比如找一些在外企工作的，一个星期后，告诉你开始招人吧。（有没有觉得不对劲的地方？）
关于招聘，你只能按照上述第5项中的内容来进行JD描述，这是国内最为普遍的现象，如果你运气好的话，又恰好在社区中遇到了一些对的人，否则，你只能将目标放在应届毕业生身上。如果你选择了外包公司或者是某个给银行或石油公司写应用的，那么你就留下了后患。
在招聘的同时，技术人员开始搭建开发环境、构建平台、测试，开始向公司申请服务器，这个时候，遇到的冲突可能有代码仓库和知识分享平台。老板会让你严格控制好代码，这个时候如果上游的仓库时使用git的话，那么你就要考虑gerrit了，并且需要招聘一个版本控制的管理者，如果上游的是SVN的话，那么你就得想好控制权限了。一般的项目都会有一个自己的wiki、etherpad等平台，但是老板会要求加入全公司的微软sharepoint之类的系统，或者是办公自动化之类的系统，并会告诉你所有的东西都不可外流，知识产权归公司所有。
这样过了几个月，也招聘到了一些人，早期的这些人也开始对系统有所了解了，这个时候差不多，公司会招到一个产品经理，开始参与项目，开始向系统提一些需求了，然后，公司会要求开发经理第一版什么时候出，销售已经等不及了，让销售们干坐着可不行。好！ 那么就开干吧。
从社区的某个分支正式的克隆下来，开始了产品化之路，要求有：
界面要更改，不能和上游有任何的相似之处。
全部汉化。
增加xxx功能，这是我们客户明确要求的。
要测试，连续跑30个昼夜，要稳定。
2/3个月的时间够不够？晚餐和路费公司报销。
好吧，开发人员的选择不多，产品经理也一样，产品经理这个时候已经开始物色文档人员了，要求是会office,英文可以，最好是有计算机背景。
虽然人员还在招聘中，项目已经不得不进行，公司还有可能让你们出去封闭开发。这个时候，开发人员，不管是从新的技术的角度，还是老板的加油点火，总而言之是内心充满了干劲，激情四射，满脑子都是开发出一个划时代的产品。大约过去了几个月（一般不会超过3个月），基于某个版本的产品出来了，也经过了功能测试和一些老板要求的非功能测试。
产品正式发布，一般情况，老板会开个庆功会，因为这个时候，大多数的公司其它部门都在等，没有什么业绩可说的，研发简直是公司明星，老板希望这样的精神传递给每个兄弟部门。
热闹过去之后，工作还得继续，于是，产品经理在写文档的同时，培训、定价、竞争对手分析等，开始提出另外的一些需求，比如和某个商业产品的对比，因为这个时候，还没有来自一线的反馈。（如果你和我一样，是个负责任的开发者，你会和他们争执、讨论，因为你想着不要和社区离的太远，因为现在从上游merge代码已经花费很多时间了。）那么你就照着产品经理的话，开始寻思如何完成这一该死的任务了，哦，对了，这个时候，测试也开始参与进来了，会每天问你这个功能是这样的吗？你们的设计文档哪里去了？输出正确吗？
这个时候，社区差不多发出了你们基于的版本的下一代了，增加了很多优秀的特性，甚至重构了某些模块，那么你在开发新功能的时候，并保留第一版的功能，就开始合并代码，修复bug。所有人的精力已经都扑在了产品上，上游的邮件列表、在线会议、IRC讨论都无法参加。
这样又紧张的度过了几个月，第二代产品终于在老板要求的日子提前半天发布了，产品经理这个时候会郑重的向公司宣布我们的产品具备了市场竞争力。深度定制xx项目，自主研发了xx，可以申请自主知识产权，以及国家扶持基金。但是，为了公司能够顺利通过ISO9001认证，需要研发人员协助编写xxx文档。
某个销售开始谈了一个单子，号称是自己多年的老客户，为了我敢于尝鲜，但是，他们要求必须满足以下功能，要求研发人员支持，尽快赶出一个版本：
将Logo替换为我们的
实现和现有OA系统的整合
要傻瓜化的操作界面
要有ios的app.
. ..........
失败的症状有哪些？
先从项目本身说起，这个时候，上游已经发布了2到3个版本，你当年基于的那个版本，和他们比起来已经显得过时，你做的功能上游做的更好，汉化也更加的全面，界面甚至都有了branding功能，和各种时髦的技术整合的也完美，更加的稳定。而你那个版本，bug不断，也无法合并上游的代码。
开发人员的士气开始低落，上游的实现已经严重打击到了他们的信心，最有甚者，如果这个项目比较火，竞争对手开始恶意挖人。
由于上游的项目功能更加的完善，而合并的代价又太大，或者说是不能满足市场的压力，公司开始抛弃原来的项目，重新进入下一个循环和轮回。
开发人员不再受到公司的追捧，渐渐失去了所有的话语权，公司的方针是”以市场为导向“，以满足客户需求为最终目的，开始做定制的项目。
老板眼中的开发人员开始变得懒散、无能，开始出一些制度，比如按时间打卡，撰写年度、月度计划，并撰写周报，按照IBM，微软的绩效考核制度来衡量开发人员。
技术人员反馈的低级问题，占去了开发人员的很大一部分时间，产品部写的文档没人看，技术人员写的wiki太高深，测试人员一脸的无辜。
老板要求研发的经理出去走走，倾听客户的声音，不要埋头做轮子。于是，销售带着研发开始谈项目、谈合作。
培训、合作伙伴等等暂时无从谈起。
为什么会失败？或者说失败的原因是什么？
正如我们将在第六节中要谈到的，我们先来看看成功的运作开源的商业的公司，如RedHat,WordPress,Cloudera,Mirantis,他们看起来都找到了属于自己的路。
对于开发人员的重视，不是体现在集中的那几个月，而是一个漫长的过程。施展各种办法让人留下来，允许价值观的发挥。
一般情况，开源项目大范围的宣传或者是已经有了很多的工程师去关注，那么这个时候的参与和学习，已经有点晚了，太过于快速的想急于求成，没有很好的消化设计理念、工作原理、愿景目标，直接上来堆代码其实就预示着悲剧的发生。
招聘靠谱的人员，在我们所生存的这片土地上，能够理解开源的生态系统者寥寥。虽然都是被社会主义洗过脑的，但多数人还是人格分裂，没有人相信这件事情。所以，太过于着急的仅仅以语言和项目来招聘人员，未必能够理解和认同。
缺乏开放的心态，总想着哪些垄断的霸主，比如apple,microsoft,vmware.殊不知自己的实力？
重视知识产权是件好事，但是用错了地方，在一个开放的世界，以分享为常识的世界里，想自己藏着掖着，这是种什么样的心态？时间久了，必然会被抛弃，除非你自己愿意改变。
在开源社区混的久了的工程师，形成了自己独特的文化，若要逼着他们适应新的文化，没有多少人能够做到在两种文化之间切换来切换去。
面子，我们国人糟粕的文化之一，这在商业中，尤其是重视这点的人做了甲方后，他/她一定会以什么都懂的身份出现，哪怕是最初装着谦虚的样子，会告诉你应该这样做，如果这个时候，你或者代表你的销售没有把持住，听了他/她的，那么很不幸，这个产品基本就废了，而他是不会负任何责任的。
所谓的“深度定制“”自主开发“，这是失败的最大原因之一。只要这么一说，其实是不为社区反馈的，也就意味着某些功能和模块和社区相脱离。如果你的开发人员不是很多，或者不是项目的发起者和维护者，那么你就有可能做的不如上游的优秀。
如何避免这样的失败？
我这里给出的良方，人们未必听的进去，因为这是一个崇拜成功者的文化，对失败者没有任何的宽容。
必须雇佣大量的开发、测试、文档人员，直接纯粹的参与到社区。
在选型之前，要明确自己的业务方向。
营造宽松的文化氛围，努力的施展各种手段让工程师脑子里想着开发更好的产品。
重视生态系统，不要孤立的想独霸天下。
分清core和外围部分，这点可以参考各个Linux的发行版，或BSD的发行版。不要轻易的去动core的东西而不和社区相互动。
注意知识的传播，优秀文档的撰写。你做的东西一定得有熟练得专业用户使用。
重视服务，换句话说，需要提升技术支持团队的能力。
安娜卡列尼娜法则
托尔斯泰留给世人不朽的著作《安娜卡列尼娜》中有这么一句话，“幸福的家庭看起来都差不多，而不幸的家庭却各有各的不幸。“
我对这句话的理解，一直以来比较肤浅，直到看到《枪炮、病菌与钢铁：人类社会的命运》 ，才有了新的认识，这本书对于其的引用，作者是以动物的驯化来阐述的，“能够被驯服的动物看起来都差不多，而不能被驯服的动物却有各自的不能被驯服的理由。” 不能被驯服的动物，诸如斑马、熊、豹子等，或太过于凶残、或食量太大、或由于繁殖等各种各样的问题。
回到我们基于开源项目做产品的话题上来，每个项目或者每个公司虽然面对的是同一个问题，但是失败的理由却千差万别。其实，让那些失败的经理们回忆，也不可能得出相同的结论，甚至相似的结论，比如因为找了有道德缺陷的人，比如后期资金不足，比如调研失败，比如市场预测，比如对开源选型错误，比如应该自己重新去写，比如忽略了测试的重要性，比如没有重视文档。
本文的题目同样可以以安娜卡列尼娜法则来表述。
那些
发行版的特征
附
录
我们知道Linux的发行版有300多种，曾经有人专门做了张路线图，可以到维基百科中查到。即使是成功的商业发行版，如redhat，SUSe，Ubuntu等也有好多种。OpenStack的发行版眼下也有好多了，BSD就更加的悠久了FreeBSD，NetBSD，MacOSX等。
要比较他们，需要做大量的规划、试验等工作，wikipedia上也有类似的对比，我们这里就不细谈了。这里要谈的是总结性质的，以笔者对个人主观经验和实际操作中得来的，哪位有兴趣的话，可以补充。
Linux发行版之间的差异
0、包管理器，如RPM，Deb
1、UI，无论是gnome还是KDE，还是utiy2，都在追求着不同。
2、安装程序，anaconda，Yast2，debian-installer.各有千秋。
3、上下游的生态系统，如硬件兼容性，应用程序兼容性，比如SuSe和SAP的合作。
4、对kernel,gnu工具链的贡献。
5、对Linux操作系统的知识传播，文档、培训、社区、桌面版。
6、独立的社区，如Fedoa，OpenSUSe。
OpenStack发行版之间的差异
0、带外管理，如Fuel，RDOmanager，甚至是裸的puppet／chef
1、上下游生态系统，各类设备，如存储、网络的驱动认证，上游的应用，如Oracle12C。
2、主导OpenStack社区核心项目之外的项目，如Murano，Sahara。
3、对于OpenStack知识的传播，培训、完善的文档、技术活动等。
4、对核心项目的参与人数，及代码贡献。
最后是BSD，这个我不太熟悉，只是特别喜欢NetBSD当年独立出来的故事。这个微内核的架构，和上述两种非常的不同。甚至还包括开源协议的不同。
BSD发行版之间的差异
0、注重点不同，如NetBSD就是为安全而生的。
1、借鉴其它如Linux，GNU的项目不同。
2、跑在专有的硬件中，彼此孤立。
3、尤其有Apple在背后，商业的氛围较浓，反而社区相对比较稳定。
后记
写这篇文章的那个下午，记忆依然清晰，这是我抽着烟，花了5个小时坐在电脑前一气呵成的文章，仿佛把我多年的积怨一下子吐出来一样。这么多年过去了，我执意的一字未改，没有任何的润色和修复，就是这样一个时刻，改变了我很多东西！
END
点击下方“阅读原文”查看更多