我认为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，有效考核企业开源。