我认为 KPI 是一个让开源更好发展的方式。个人开源给自己定 KPI，并予以自我奖励有助于个人开源长期发展，国内企业的开源搞 KPI，也是符合软件产品研发规律。 开源产品的特殊性，企业开源产品应避免不让 KPI 成为唯一开源考核指标

接触开源

2000 年刚毕业，在公司默默无闻。记得头一次能在团队里得瑟，还是因为从 JBuilder（早期 Java IDE）的插件市场找到一个开源的数据库访问代码的生成器。我把源码下载下来，魔改成适合公司规范和业务要求的 Java 代码生成器。我的同事们用了这个工具，直呼过瘾，大量的 Java 代码不需要手工写，能节省出一半时间。公司后面的项目几乎都在用这个插件生成代码，个人和公司得益于别人开放的源码。

2005 年后，记得 Java 开源产品越来越多的应用在项目里，Tomcat 代替了 Weblogic，WebSphere，MySQL 代替了 Oracle，SQLServer。 开发框架也使用 Struts，Spring 代替 Servlet+JSP。。个人能从开源中学习如何更开的编写软件，编写好的软件不再是商业公司的内部机密。个人能更好的找到工作，不像之前商用技术的门槛让人才无法自由流动。 企业使用开源能节约成本，能招到更多通用的（开源技术）人才。

个人开源和激励

我在 2010 年决定做自己的开源模板引擎 Beetl，这处于个人兴趣，跟在企业做的事情没啥关系，当时公司在给移动集团做项目，我负责自研的消息服务，研发完毕很空闲，我另外一个同事负责大数据存储研发，用了一个叫 Hadoop 和 HDFS 的开源系统，后来他顺着 Hadoop 研究了容器技术 **。**同事顺应公司和客户的需求对开源的研发和应用，让他收益颇多，出了一本书叫《Kubernetes 权威指南》，现在也在 HP 学院任职 。 我的工作内容主要是消息服务的性能和企业应用性能调优，Beetl 模板引擎也面临其他模板引擎竞争，专研了 Java 性能非常有必要，后来也出书《Java 系统性能权威指南》。

Beetl 从 2010 年开始到现在持续维护了 12 年多，固然有年轻时候 “为中华开源崛起” 的崇高理想作为动力，但也有个人激励办法保持开源动力。比如，修复一个 BUG，奖励自己一杯咖啡。完善一个功能，奖励看一场电影，发布一个大版本，可以做保健放松庆祝一下。 这是学习了 Antlr 作者 Terence Parr ，Beetl 用到 Antlr 作为语法解析引擎，我曾捐助过这位美国教授 5 美元，他回信表示感谢，并说，他可以给自己买一杯啤酒作为奖励。这个自我激励办法非常好，可以说，没有自己拿钱对自己的开源作激励，Beetl 很难坚持一直维护。

企业开源和 KPI

领着公司的薪水，空闲时间研发个人的开源模板引擎，然后与同行的 HTTL，Rythm， jetbrick-template , BSL， Febit Wit。等国内模板引擎作者一起讨论模板编译和运行技术， 这好比古代竹林七贤 煮酒论诗，日志好不快哉，如果当时国内这几个作者能作为一个团队共同研发模板引擎，绝对能领先国外同类技术一代。

开源美好日子持续直到 2015 年，国内开源模板引擎出现了 XXXtemplate (隐去真实的名字）, 引起了我个人一丝恐慌。因为这个模板引擎是公司团队研发，它从无到有不到一年时间，各方面都有赶超个人开源模板引擎趋势。我当时戏称这种公司开源为开源大鳄，面目狰狞，会吃掉其个人开源。开源模板群里讨论的好想法，XXXtemplate 能非常快的落实，它毕竟是企业来运营的。

再后来，新一代的 IT 同行们也清楚开源发展的脉络，越来越多的企业支持的开源，比如阿里，美团，京东开源，相对于个人开源，一些名不见经传的企业也因为 开源获得广大程序员支持。 企业开源有着非常强的优势

• 开源有专业团队维护，每年公司为这些专业团队的人力成本都有数百万资金。个人开源则需要倒贴时间和金钱。
• 开源产品在大流量和高并发下有充分的实践，值得信赖。比如阿里的 FastJson，Dubbo 等
• 企业开源有更好的媒体资源，媒体平台倾向于和公司开源合作。在 2015 年以前，个人开源还能出席网络媒体上，那时候个人开源作者相当风光。 现在则绝大多数是大厂的开源作品与网络媒体合作，个人开源基本上陪跑，比如 2023 年初的 CSDN 举办开源大会，邀请了很多个人开源作者陪跑企业开源，引发了人开源作者的退群。

企业投入人力物力，主导开源，提高了开源产品的质量，也提高了中国开源产品同世界其他产品的竞争力，这同非软件的其他行业一样没有什么区别，发展规律是一样的， 现在 Apache 上就有很多中国公司提供的世界级开源产品，证明了企业投入开源的成功。

作为个人开源作者，非常羡慕参与企业开源的程序员，领着高薪和高绩效做有趣的开源。但也发现这几年来，企业开源会有弊端，总结下来如下：

• 重复造轮子：公司开源有资金投入，重复造轮子的开源最简单，最容易提升个人 KPI，然后，做出的产品不能用，可能公司内部都不会得到认可。
• 以项目进度要求开源产品进度，KPI 忽略了开源产品本质是创新，不是劳动密集型工作。如果真的能规划好进度，那说明这个开源没什么创造性，有可能是重复造轮子。 现在很多公司开源都集中在年底发布版本，被程序员戏称为”KPI 开源 “。开源产品的进展是难以 KPI 度量的。
• 企业开源也容易失败，看到过一些开源因为公司大力投入，有那么俩年似乎很火爆，然后，由于公司调整，开源被砍。导致再无人维护。比如 Dubbo 曾落此下场，之前提到让我恐慌的 XXXTemplate 也是这样。
• 企业开源以每年参加技术大会多少次，每年开源有新增多少 Star，Fork 作为 KPI 之一，为难开源作者，我见到的大部分开源作者都是低调内敛的，无法在讲台上做到激情四射，侃侃而谈。也不会追着问别人要星星：)
• 公司开源的主要目标还是以服务本企业为主。所以不像个人开源那么适用范围广泛。比如同为 RPC 框架，公司开源可因为铁定用不上 thrift 协议，而不会投入研发，个人开源则能接纳更多的不同想法和建议

总的来说。企业投入资金做开源，是一件非常值得赞同的事情，通过一定手段考核开源项目无可厚非。 不是所有企业的开源都加入 Apache 那样的组织进行管理，更多的中小型企业的他们的开源，如何在企业自身发展情况下更好的发展开源，需要开源中国这样的组织，以及一些国家队基金站出来，帮助中小企业，推广开源，发展开源，促进开源之间的合作，也包括定义适当的 KPI，有效考核企业开源。