昨天看到金山卫士开源了,着实兴奋了一把,但上code.ijinshan.com转了一圈,这心里又变成哇凉哇凉的了。 为什么呢?首先,上网站转了一圈,看到了声明、代码和README文件,唯独没有看到开源协议。
官方声明中说“任何第三方的厂商或者个人均可自由下载和使用金山卫士源代码,不限制开源后的代码进行商业性的使用”,这看起来和MPL/BSD/APL协议都很类似。最后是在代码目录下找到了一个Notice.txt文件,其中声明了源代码开放的协议。后来发现在trac的wiki中也写到了,但这实在不符合一般开源代码的规则,也就是以一个LICENSE文件声明协议,并在所有代码文件的开头附上协议的部分内容。协议虽然不是代码,但却是源代码开放运动中极其重要的一环,所以没能在最显著的地方让人第一眼就找到卫士开源采用的协议,实在是很失败。
其次,开放源代码是一种技术行为,但这次金山高调开源卫士,怎么看起来都像是商业行为。查看trac的wiki,只有可怜的两篇
文档,只有一篇粗略的讲了一下构架。如果你想参与,应该从什么地方开始?如何检出代码?如何构建?有什么依赖?从什么地方开始阅读代码最好?如何登记bug(传票)?在传票中沟通应该注意些什么?传票是如何流转的?如何提交patch?review制度是怎样的?什么人能够获得commit权限?卫士会不会有开源和闭源两套并行的版本?……
经营一个开源社区,并不是仅仅把源代码往外一扔然后大喊一声“开源”就成功了的。
有人说金山没有把核心的代码开放出来,所以是伪开源,我并不同意这一点。程序员的水平和能力不同,开源的这些代码,也足够使很多学生获益,这难道不是一件好事么?只是开源并不只是等于开放代码,开源的本质是经营社区,用集体的力量做出更好的产品。金山能够把卫士开源是很有勇气的,但是还应该有更广阔的胸怀,把社区的各个部分都建立起来,包括
文档、构建、测试、发布等等。只是毒霸内部的开发流程都没能理顺,代码管理也并不清晰,要
经营外部社区,不知道有多少经验可以复用。
有同学应该注意到了,卫士开源项目的负责人是zoom.quiet。此人在国内的开源社区还是小有名气的,跟各路技术大牛都能打上招呼,但是你要是因此就觉得他的技术也很牛,那就大错特错了。他是开源运动的忠实参与者,但却只能学到些表面功夫。国内的社区把这种“大妈”奉为牛人,是一种悲哀。trac是个不错的产品,trac的中文化也是zoom.quiet的得意之作,但是他对trac的积累有多少那就很难说了。昨天下午对卫士的代码库的访问很慢,还出现了“连接用户数过多”的错误,昨晚金山维护trac的同学加班到了十一点多呢。这次卫士项目的开源的问题我刚才也说了,让他这么弄下去,估计是要打水漂的。
也许有人觉得我是在吹毛求疵,这毕竟是金山第一次尝试开源一个重量级的产品,难免有做的不尽如人意的地方。但我想说的是,开源是一把双刃剑,用的好了,不但能够做好产品,还能提升自身的品牌形象;但如果做不好,那就是自己砸自己的招牌,把技术优势拱手让给竞争对手。总是有人说金山是低调做事的好公司,但其实金山的水平从公司在行业内的地位就知道了,做事高开低走也不是一次两次了,希望这次不要重蹈覆辙。