我認爲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，有效考覈企業開源。