评论：为什么我为金山卫士开源捏把汗

昨天看到金山卫士开源了，着实兴奋了一把，但上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的同学加班到了十一点多呢。这次卫士项目的开源的问题我刚才也说了，让他这么弄下去，估计是要打水漂的。

也许有人觉得我是在吹毛求疵，这毕竟是金山第一次尝试开源一个重量级的产品，难免有做的不尽如人意的地方。但我想说的是，开源是一把双刃剑，用的好了，不但能够做好产品，还能提升自身的品牌形象；但如果做不好，那就是自己砸自己的招牌，把技术优势拱手让给竞争对手。总是有人说金山是低调做事的好公司，但其实金山的水平从公司在行业内的地位就知道了，做事高开低走也不是一次两次了，希望这次不要重蹈覆辙。

作者:杨仙咏