股票代码: 836286    股票简称: 易云股份
官方微信

扫一扫关注易云捷讯官方微信

备案 |       管理控制台

为什么基于成功开源项目的商业产品会失败(一)

导读

首先解释下题目,所谓成功的开源项目,主要是指已经被市场和技术所证明是非常成功的社区下的项目,如Linux,Android,OpenStack,oVirt等等,另外一个特点,就是这些开源项目更加倾向于基础设施软件,如操作系统、IaaS平台,虚拟化管理平台等。至于商业产品,就是基于上述开源项目,进行包装、二次开发,然后出售许可证等之类的商业产品,最后解释下失败,此处的失败不包括其商业模式或公司盈利等的失败,而仅仅指的是上述的商业产品在市场的存活时间,其内部开发的周期上的失败,换句话说,就是这个产品不再有未来,从此消失在历史的舞台。

这个题目,纯粹是从个人的职业经历的角度上的一个总结,不是类似gartner,forbes等技术、市场专家从宏观、调查的基础上去预测和评价的,所以并不具备普遍性。

另外我会从以下几个要点来说明:

●  在失败的路上他们都在做什么

●  失败的症状有哪些

●  为什么会失败

●  如何避免这样的失败

●  安娜卡列尼娜定律

最后的附录部分,给出Linux发行版,OpenStack发行版,BSD发行版之间的一些特征对比。

在失败的路上他们都在做什么

每一家创业公司也好,或者是公司的内部开发新的市场成立事业部也罢,总是先要推出产品的,那么在开源世界大势所趋的时代,快速的开发一款产品,(这里不是指互联网公司开发的应用,而是基础设施软件,换句话说,就是企业或者互联网公司的应用背后所支撑的软件,如操作系统等。)并非是一件很困难的事情,时间也不是什么大的问题。

首先当然是选型了,选型的过程,一般是技术人员对一些功能类似的项目进行对比,然后出报告,最后是老板拍板,因为他要考虑市场和消费群体。靠谱的技术人员会按照下面的角度来考察一个开源项目:

●  解决了什么问题

●  项目的历史有多久

●  发起人是谁或者是哪个公司

●  代码的架构如何

●  使用什么样的编程语言

●  采用何种构建方式

●  社区的活跃度如何

●  背后有哪些商业公司在支撑

●  社区的生态系统是否完善

●  安装、配置的容易度是多少

●  项目是基于什么开源协议

●  文档是否齐全

●  成熟度如何

●  有哪些公司/企业在使用

当你还没有花费3~5个月去做这件事情,有一些遗漏的时候,老板已经表现出非常的不耐烦,这时技术人员会将残缺不全的报告递交给老板,然后,老板会利用他自己的圈子,四处打听,比如找一些在外企工作的,一个星期后,告诉你开始招人吧。(有没有觉得不对劲的地方?)

关于招聘,如果你运气好的话,又恰好在社区中遇到了一些人,否则,只能将目标放在应届毕业生身上,如果你选择了外包公司或者是某个给银行或石油公司写应用的,那么你就留下了后患。

在招聘的同时,技术人员开始搭建开发环境、构建平台、测试,开始向公司申请服务器,这个时候,遇到的冲突可能有代码仓库和知识分享平台。老板会让你严格控制好代码,这个时候如果上游的仓库是使用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太高深,测试人员一脸的无辜。

老板要求研发的经理出去走走,倾听客户的声音,不要埋头做轮子。于是,销售带着研发开始谈项目、谈合作。

培训、合作伙伴等等暂时无从谈起。

最最表现明显的是,同类产品层出不穷,产品进入一个看似蓝海的市场,却毫无竞争力。

 

为什么会出现这些情况,以及如何避免这些情况的发生呢?让我们下期接着聊~

 二维码.gif

关注易云微信号,浏览更多技术文档


© 2011-2017 易云捷讯科技(北京)股份有限公司, 版权所有 | © 2011-2017 Eayun,Inc. All rights reserved.

京公网安备 11010802022475号 | 京ICP备 11028869号

业务咨询:400-606-6396