我是一個python程式員，在web開發中我會用到一大堆的開源項目，如linux、python、emacs、spacemacs、httpie、flask、requests、sentry、ipython、pyramid、mako、oh my zsh等等。無法想象沒有它們，我該如何工作。
相信你看到上述清單中出現的項目名字，有些也很熟悉，甚至是經常和它們在打交道。
我們先看一個有趣的事情（2016-09-07）：
其中，django的貢獻代碼的人數1250，而fork的數量是8509！！flask的貢獻者為346人，fork數量為7108！！star可以了解：欣賞這個項目，未來可能用到，友善檢索，但是fork了不貢獻代碼這是什麼心态呢 (ÒωÓױ)？
很多人也會開源自己的項目，但是除了熟人和公司這樣的紐帶，一般很少可以看到其他人來提pull request或者issue的。當然國人也不乏一些好的項目，比如結巴分詞。但是大量的項目star數量止步于1（因為自己可以給自己點呢！）。
我們看一下github上目前python社群中很火的一些項目國人的參與度。我寫個一個小腳本cn_participation.py，通過 list contributors、get a single user 和 search repositories這3個github api擷取需要的資料。
國人的參與度的項目，選擇的标準是star數量超過3k，工作中常用。結果如下：
這個資料不一定是正确的結果。因為django和ansible等項目的貢獻者實際的數量都已經超過1k，但是github api由于性能等原因做了緩存，且隻能展示前500個貢獻者（實際還上不夠500）。其次我隻是通過location字段中是否包含北京、上海、廣州、深圳和china這幾個詞判斷是否是國人，如果有些人沒有添加位置資訊，就會被忽略了。
限于篇幅，這裡隻列出了貢獻2個或者更多項目的貢獻者id及其貢獻的項目名字：
這個結果有三點超出我的預期：
很欣慰，國人的參與度還可以。
清單中的使用者id有一半我之前并沒有見過。
cpython中有一個中國的貢獻者，id為gumblex， 他也是結巴分詞的主要貢獻者。國人使用python如此之多，卻沒有一個python核心開發者。好桑心！
順便想做個調查，為什麼github上python語言star數量第一的httpie竟然隻有我一個貢獻者呢？是大家都不用麼？
接着我們看看國人寫的優秀項目的清單（隻能抓到前一千個項目）：
ps：其中有些項目并不是python的，比如iosblogcn、zhao和nginx-book，有些是組織下的，比如dpark和interpy-zh。國人做的好的項目還是蠻少的。
btw，你心目中的大神，有幾個上榜了呢？
在我拟本文的時候，我找到了一篇玉伯寫的《什麼是開源精神》。這篇文章的2個主标題很好：
在開源世界裡，參與比主導更重要。
開源的是社群，代碼僅是很小的一部分。
無論是我現在的公司，還是之前的公司都不乏非常優秀的工程師，他們有想法并且會付諸行動。在和他們合作過程中會有驚喜，能碰撞出靈感，也會學到新的解決問題的方法和思路。他們有兩個特點：「喜歡造輪子」和「對開源不熱衷」。好像大家都愛寫個web架構啦，orm啦，開發工具的插件啦...，對，有段時間還流行造wysiwyg的富文本編輯器。說到這裡好尴尬，因為在豆瓣2年多，我好像沒有給項目引入什麼額外的第三方庫，也确實沒有造過幾個「輪子」，總體大概就是一件：做别人「輪子」的第二個使用者（第一個是作者本人），回報甚至去提代碼幫助改進。說到這裡，解釋下為啥我工作中「不熱衷造輪子」。我明知道「造輪子」會讓我更有地位和價值（因為除了我别人不懂啊，這是潛規則好吧-。-），但在團隊内還是考慮大家的感受，不給其他同僚添加用我的「輪子」的痛苦，除非我知道這個「輪子」足夠好。
在2年前，我曾經寫過一個web架構，也是想要一個人搞定模闆、wsgi、orm等等。做着做着，我發現無法說服自己做的這個東西比現存的競品的優勢在哪裡，也就沒有堅持下來。對于當時的能力而言，我還做不出來一個有意義的「輪子」。
後來我開始閱讀各種開源項目，看到好的項目star一下甚至寫部落格宣傳一下；嘗試了解它們的設計思想；使用中遇到了問題又沒有能力解決就去提issue；有能力的時候，遇到bug或者想添加功能我就自己去提pr。并不需要刻意，順手而為罷了。
今天和大家聊聊我在完成《python web開發實戰》這本書時和開源世界發生的故事，以及我對參與開源的一些看法。
aiglos
說出來你可能不信，一開始和編輯讨論書稿還是使用郵件。走的是「我寫完了一章就把書稿用郵件發給編輯，編輯添加意見和修改再發給我，我再修改...」這樣的循環。我當時有種「都什麼年代了還用這麼古老的方式」的感覺，不能忍。首先從網上找了下，确實沒有合适的解決方案（要考慮編輯的技術能力），那寫一個吧！大家先看看效果：
假如你學過django，應該覺得好熟悉。對， 這是django book 中文的翻版，樣式是抄的，我隻是把後端改成了flask + sqlalchemy + mako，并且支援markdown。這頁面顯然沒有material-ui之類的庫做出來的東西酷炫好看，但是别忘了，這隻是一個試水項目，需要糙、快、猛的驗證需求就可以了，如果大家真的接受，我再優化也不晚。顯然考慮對了，最後它還是被抛棄了，我和編輯改成用google drive完成日常讨論及修改。
gitbook-plugin-highlightt
some stuff...
gitbook是使用javascript寫的。我javascript用得不好，但是覺得可以試試，就這樣，一個周末下午的時間完成了這個插件，效果如下：
在下面的逐行講解中就清楚多了：
有想法就付諸行動，哪怕最後沒有完成，至少努力了。
saltstack/salt
由于salt貢獻者已經超過了1.5k, 雖然我之前也改過一個小問題，但上面的清單中，我被無情的忽略了。我寫書的時候全部庫和軟體基本都使用最新版，在用salt的過程中，發現一個錯誤。詳情可見 fix psutil.cpu_times unpack error by dongweiming · pull request #32182 。簡單地說就是psutil在更新的時候修改了傳回值的數量，造成使用它這個接口的項目都會出現這樣的錯誤。
出現問題，是給你天天使用的項目貢獻代碼的最好機會，雖然大部分是其實是使用者用錯了。
celery/celery
在我編寫celery對應章節的時候，遇到一個很偶遇的錯誤： fix event result is none by dongweiming · pull request #3170 · celery/celery · github 。
報錯資訊的格式好亂。
ipython/ipython
書中有專門的一節講ipython，7月8日matthias釋出了ipython 5.0 lts，我的内容随之調整，比如之前隻是介紹prompt_toolkit，現在已經真的可以用了。在看5.0的whatsnew的時候，我發現它支援定制終端的顔色方案了。但是按照文檔的提示，我終端顔色并不符合預期，一言不合，我就直接去翻源碼了。然後就發現這個typo fix highlighting_style typo by dongweiming · pull request #9766
嚴格的是，這不是typo，而是錯誤。
supervisor/supervisor
另一位評審老師建議我supervisor内容中加上和虛拟環境工具virtualenv一起用的例子。
我是這麼寫的：
supervisor支援environment參數，可以指定環境變量，那麼第二種是不是看起來「沒毛病」？
但事實上它是錯誤的（「這不科學啊」）。
我之前也給它貢獻過代碼，但是這次比較懶，因為調試很麻煩，當時又沒有時間，是以先提了一個issue supervisor issues 787，現在的維護者認可了這個問題卻并沒有想添加這樣的支援。好吧，自己動手豐衣足食：search for command using path from environment=. fixes #787 by dongweiming · pull request #799，維護者會在下次發版的時候合并它。期待中...
注意哦，書中已經明确了這樣的用法，然而pr還沒合并呢，但是我有信心！
mattupstate/flask-security
fix mongo valueerror by dongweiming · pull request #534 · mattupstate/flask-security · github 這個也是在寫書中發現的問題，但是這個項目看起來屬于沒人維護狀态，這個pr安靜的躺在那裡。但是不要感覺失望，因為這個pr是open狀态，别人遇到這個問題就可以搜到。這也是一種對開源項目的貢獻。
pallets/werkzeug
我書裡面沒有介紹到flask-cache，因為它基本依賴于werkzeug且一般項目不會使用多種緩存方式，我覺得實際工作中用這個插件意義不大。書中介紹了豆瓣使用的memcached用戶端libmc，我認為它應該是現存的用戶端中被大型網站應用的最頻繁和最快的選擇了。werkzeug中并沒有對應的支援，是以我去提了一個issue add libmc support · issue #982。 untitaker并不反對，但是想把這部分重構一下，我最近終于閑下來，也在思考他提到的問題，如果你有好的想法，歡迎去回應。
和本書有關的部分就到這裡了。但還沒有結束。
開源對我的意義
有些人會問，開源對我們有什麼意義呢？
有一波大神給你做代碼評審。如果你在公司寫代碼，就算是代碼評審，由于情面性格等原因，大家一般不會說的太狠，你有錯，别人也不會認真的說。但是在外面不是，大家都很直接的，整個過程你可看到的都是真相。
學習一些工作中不能學到的東西。舉個例子，pip commit e430b58cebff96#comments，那時候我真的不知道原來sorted可以對set類型的資料排序，漲了姿勢。
個人的意願。我曾經給celery修改過例子： modify some examples by dongweiming · pull request #1851， celery有很多有意思和有用的功能特性并不及時或者根本沒有出現在官方文檔中，如果你沒有watch這個項目經常關注或者去閱讀它的代碼，你是不會知道的。它疊代很快，但是有時候代碼并不向前相容。對于初學者，這些例子很可能是它接觸celery的第一步，ta有可能因為例子跑不起來就放棄了。而對我來說，就是順手的事。
我聽過有人說：他看不起用typo混進貢獻者的人。我覺得我可以去知乎回答一個問題「人為什麼可以如此狹隘？」。有一天，我看到我的timeline上，gvanrossum（不知道他是誰我可真沒有辦法了）fork了pyjion，我當時想「(⊙v⊙)嗯，這是什麼節奏」。 等了一會發現gvanrossum來提pr it's holistic (one ell) by gvanrossum · pull request #193。 python作者出來改typo，這個事情太有必要拿出來看了，我要截圖：
最後。用我非常喜歡bootstrap作者之一在另外一個項目zoom.js上面留下的一句話：
希望越來越多的人能來支援開源項目。