小型研发团队应该怎样对待开源项目

首先得定义一下什么是小型研发团队？第一，开发人员在30人以下；第二，开发“自有”产品。第一点是现在的软件越来越复杂，同时终端平台众多，三十来个人其实做不了太多的事，所以只能说是小团队。至于五十或一百人算不算小团队， 由于我本人只在小公司呆过，见过的也就是三十来个人的团队，所以 这个我说不好；第二点，这里强调的是做产品，做项目的时候遇到的情况会不同，这里就不讨论。

小型研发团队对待开源项目，我建议采用下面的态度：

• 不要抗拒

作为程序员不要抗拒使用开源项目，毕竟你在短时间内很难写出同样功能、性能和稳定性的东西；作为团队的领导，不要因为你的手下使用了开源的项目而怀疑他的能力和职业精神。 市场的竞争是很残酷的，公司如果想立足，就要求研发团队快速地形成新产品实现新功能，如果有开源项目作基础，一定会事半功倍的。

举个例子：如果你们的产品中需要远程控制电脑的功能，那么你最好参考vnc的开源实现(或者spice,或者rdesktop)，因为它已经相当成熟，包括服务端，各个终端平台上的客户端都有非常好的实现。你可以在现有开源代码的基础上进行修改，实现你所要的功能。这时如果你选择重新开发，30个人干个一两年也未必可做出来。这种工作意义何在？

有的研发团队可能也有版权的顾虑，这种事情就自己衡量了。实在不放心可以看看开源项目有没有商业授权，花点小钱买个安心。

• 不要在自己人面前吹牛

不管销售人员对客户怎样吹牛皮，说什么“自主研发”，“拥有xx专利”，“得过xx奖”，这些都是销售的需要，我们自己人可不能全部当真。

矛盾是由于看问题的角度不同而产生的。一般来说，团队的领导关注的是功能，而普通程序员关注的是技术。功能实现了不一定技术就掌握了，这一点普通程序员跟领导往往有冲突，特别是领导吹嘘新功能有多强大的时候，手下的程序员往往心里很没底。 长此以往，程序员对开源项目的态度就会越来越谨慎，态度也会越来越消极。

• 认真维护代码

这一点最容易被忽视，一方面，领导们以为技术已经掌握了，可以安排其它事情了；另一方面，程序员因为还没吃透原理（没时间？不在意？），觉得维护开源代码是很难的事情。最终的情况可能是这样子的：一堆代码放在那里没人看得懂，出了问题或者有新功能要实现时就急急忙忙上网找补丁，然后发现该项目的代码已经更新了好几个版本了，这时就想着拿新版本的开源代码来改......于是整个团队就开始忙碌，但谁都不知道这种事情还要经历多少次！这样的做法，最直接就是影响到产品的质量；其次，严重影响团队士气；还有就是对于研发团队来说，没有技术积累。这就是不认真维护代码的后果，你已经通过开源项目省了好多时间，现在又想把维护的时间也省了，结果报应来了！

不管是团队的领导还是普通的程序员，都要树立这么一个观点：开源代码是可维护的，而且应该认真地去维护。

首先是团队的领导人要预留一定的时间给程序员，让他们能深入的去研究开源项目，把这件事当成一种研发任务；其次，开源项目的文档往往比较少，在研究开源项目的同时要不断补充文档；第三，程序员要定时跟踪开源社区的动态，对重要的bug要及时在当前版本中修复，对新功能要做记录；第四，如果维护得好，就一直用这套代码，不要随意推倒重来。

• 积极改进

开源的东西不一定就是先进的。它也是由一个个普通的程序员实现的，所以我们应当采取进取的态度，对开源项目积极改进。有时候，你所使用的开源项目的社区不太活跃了，或者很长时间没有更新了，那就要考虑是不是已经有替代的技术？如果你的团队中使用了一个陈旧的开源项目，那是不是技术上已经没有竞争力了？那是不是有改进的空间？ 最理想的情况是研发团队能够消化吸收开源项目的长处，然后形成真正意义上的“自有知识产权”。