開源與創業

本文是根據我在高可用架構群聚會上的演講整理而成。從小一直是個訥於言的人，每次公開演講都感覺會有緊張，不能完整的表達自己的想法，很羨慕演講時能侃侃而談的人。所以還是把自己的想法整理成文章表達出來。

個人在開源方面算是新手，16年初發布了一個開源專案，叫go-commons-pool，是一個golang的通用物件池，到現在快200個星。創業方面也算是新手，15年初開始作為技術合夥人創業做團隊通訊協作工具。一年裡做開發的同時兼職做點產品的工作，也做點運營的工作。感覺創業和開源二者的共通之處挺多，所以和大家分享一些感悟。前面各位講的乾貨比較多，我這個專案技術上比較簡單，所以我聽從Tim的建議，多攙些雞湯吧。 ：）

無論是創業還是開源，首先面臨的第一個問題是做什麼？要做什麼的想法從哪兒來呢？無外乎以下兩個途徑：

1. 觀察 觀察周圍的人，觀察自己的生活和工作，觀察大家的習慣，看哪兒還有改進的地方，看哪裡有痛點。比如我這個pool的想法就是有人在群裡提問，我搜尋了下，發現golang確實沒有通用好用的物件池。再比如有人發現叫車這麼難，站路邊半天等不到，於是有了Uber。有人想在多個裝置同步檔案，於是有了Dropbox。有人發現工作中老在做重複工作，於是有了各種框架。
2. 借鑑 看看其他先進的地區，先進的領域，是否有可借鑑的，將先進地區或者領域的成果移植到落後地區或者新的領域。一直比較熱門的Copy To China創業就是這種模式，透過先進地區的發展軌跡來預測落後地區的未來趨勢。那天高可用群裡indigo的分享，透過日本的經濟社會的發展來預測中國的趨勢也是這個道理。我做這個pool，其實也是分析了java社群的情況，覺得golang在以後伺服器端大有作為，肯定需要一個健壯的物件池，用來做連線池等用途。

想好了做什麼，下一步就是怎麼做。這一步，貌似創業和開源差距比較大，但二者共通之處還是有的，其實做的關鍵點是評估以及安排『事』的資源投入。資源包括金錢和時間。如果前面想的事情太大，和實際的資源不匹配，結果可能就是創業黃了，或者開源專案建立了個倉庫，寫了個readme然後就沒有然後了。這裡面考驗的是對事情的複雜度的評估能力和對資源的把控能力。

專案做出來之後呢？再下一步就是怎麼讓你的使用者群知道了，也就是現在流行的說法叫『安利』。PingCAP的黃東旭剛才也提到了他們的營銷方式和渠道。這步的核心是你要知道你的使用者群的注意力一般在哪兒，如何以最小的成本觸達你的使用者。開源專案可能是透過各種開源社群或者技術人社群，自己的社交網路，技術會議等各種方式。

初步的使用者觸達完成，使用者知道了你的專案，有部分人可能點了星，這部分人是潛在使用者。另外一部分人fork了，估計是準備要使用或者做二次開發了。那如何維繫當前的使用者，並且吸引更多的使用者呢？這就是這個階段要考慮的。包括但不限於以下方面：

1. 完善文件，教使用者如何使用。不要嫌棄使用者『弱智』。
2. 響應使用者的反饋，處理issue。創業產品的話就是要有客服體系了。

逐漸使用者多了，然後形成社群，有了自己的品牌。這一步，像我做的這樣的小工具達不到，但比如PingCAP的TiDB,像謝孟軍的beego這種框架，都已經形成自己的社群和品牌了。

總結下這個過程中的關鍵點：

1. 點子沒抽象好。其實所有工具和產品都是在做一種抽象，對使用者需求的抽象。比如那個經典的例子，問使用者需要什麼，使用者肯定說是要更快的馬，而不是一輛汽車。汽車就是對使用者出行需求的抽象。但如何做這種抽象呢？我總結了下有三個境界。

   • DRY原則（Don’t repeat yourself），不要重複自己，最常見的是用在程式碼規範裡，建議大家不要隨意複製貼上，而是要做一定抽象。但實際上，所有的語言的高階功能，面對物件，模組化，程式碼生成工具，各種框架，都是在解決這個問題。也就是說，如果你發現你在做許多重複勞動，說明這裡就有可能抽象出個工具出來。
   • 不要重新發明輪子 這個原則貌似有爭議，但我覺得爭議是沒搞清楚『發明』和『造』的區別。不要重複發明輪子，但你可以造新的輪子，或者改進已有的輪子。這個原則說的是不要重複別人已經完成的工作，不要閉門造車，要在前人的基礎上做改進。一直覺得發明輪子的人是很偉大的，也很難的，歷史地位可以和發明取火術有的一拼。有了輪子後，人類所使用的工具和動物所使用的工具才有了本質的區別。
   • 前面我們做到了不要重複自己，也做到了不要重複別人，第三個境界就是『不要讓別人重複你』。將你的工具，框架，抽象分享出去，作為開源產品或者SaaS服務，讓別人不再重複你已經完成的工作。
2. 開發速度慢了，競品出現，或者功能比競品弱。
3. 推廣沒做好，大家不知道，結果被後來者超越了。
4. 做出來的東西沒有實際需求 比如pool，有人覺得go裡用channel模擬就很簡單，沒必要用個複雜的pool。比如許多Copy To China的專案，發現在中國的環境水土不服。
5. 開源後不維護，沒了熱情，使用者反饋無響應，最後都流失了。好多殭屍開源專案都是這樣了。

所以，我覺得想創業的工程師，可以先從開源做起，將開源做為創業的一次演習。體驗一次從構想，開發，推廣的整個流程，這樣可以對創業過程中的關鍵點有些體驗，可以評估自己的長處和短板。畢竟自己是工程師，開發的時間可以自己掌控，面向的使用者也是工程師，所要解決的問題是自己熟悉的領域，需要傳播的社群也是自己熟悉的社群，這種天時地利人和的情況下做專案還是遇到困難，可以想象下，如果換到一個自己不熟悉的領域，不熟悉的使用者，不熟悉的社群，困難會有多大？

另外說一句關於技術人創業的觀點。我覺得王安石一句詩非常好『春江水暖鴨先知』，我們一線的寫程式碼的工程師是在水裡的鴨子，江水變化我們肯定首先會感覺到，這方面是有優勢的。如果你高升了，不寫程式碼了，跑岸上去了，那可能就感覺不到江水變化了。