一点号编程派3小时前
作者：董伟明我是一个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及其贡献的项目名字：
这个结果有三点超出我的预期：
1. 很欣慰，国人的参与度还可以。
2. 列表中的用户ID有一半我之前并没有见过。
3. CPython中有一个中国的贡献者，ID为gumblex， 他也是结巴分词的主要贡献者。国人使用Python如此之多，却没有一个Python核心开发者。好桑心！
顺便想做个调查，为什么Github上Python语言Star数量第一的Httpie竟然只有我一个贡献者呢？是大家都不用么？
接着我们看看国人写的优秀项目的列表（只能抓到前一千个项目）：
PS：其中有些项目并不是Python的，比如iOSBlogCN、zhao和nginx-book，有些是组织下的，比如dpark和interpy-zh。国人做的好的项目还是蛮少的。
BTW，你心目中的大神，有几个上榜了呢？
在我拟本文的时候，我找到了一篇玉伯写的《什么是开源精神》。这篇文章的2个主标题很好：
1. 在开源世界里，参与比主导更重要。
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
在使用http://Gitbooks.io的和评审老师讨论的时候，一位评审老师建议如果是按行讲解，最好代码中显示出行号。但是Gitbook对于代码只支持语法高亮，还没有支持行号。编辑说他们转化格式的时候支持这样表达行号：
Gitbook是使用javascript写的。我Javascript用得不好，但是觉得可以试试，就这样，一个周末下午的时间完成了这个插件，效果如下：
再下面的逐行讲解中就清楚多了：
有想法就付诸行动，哪怕最后没有完成，至少努力了。
由于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，7月8日Matthias发布了IPython 5.0 LTS，我的内容随之调整，比如之前只是介绍prompt_toolkit，现在已经真的可以用了。在看5.0的whatsnew的时候，我发现它支持定制终端的颜色方案了。但是按照文档的提示，我终端颜色并不符合预期，一言不合，我就直接去翻源码了。然后就发现这个typo fix highlighting_style typo by dongweiming Pull Request #9766
严格的是，这不是typo，而是错误。
另一位评审老师建议我supervisor内容中加上和虚拟环境工具virtualenv一起用的例子。
之前的例子是在虚拟环境中实现的，如果Supervisor安装在全局而要使用虚拟环境，可以通过如下两种方法。
但事实上它是错误的（「这不科学啊」）。
我之前也给它贡献过代码，但是这次比较懒，因为调试很麻烦，当时又没有时间，所以先提了一个Issue Supervisor Issues 787，现在的维护者认可了这个问题却并没有想添加这样的支持。
好吧，自己动手丰衣足食：Search for command using PATH from environment=. Fixes #787 by dongweiming Pull Request #799，维护者会在下次发版的时候合并它。期待中...
注意哦，书中已经明确了这样的用法，然而PR还没合并呢，但是我有信心！
Fix Mongo ValueError by dongweiming Pull Request #534 mattupstate/flask-security GitHub 这个也是在写书中发现的问题，但是这个项目看起来属于没人维护状态，这个PR安静的躺在那里。但是不要感觉失望，因为这个PR是open状态，别人遇到这个问题就可以搜到。这也是一种对开源项目的贡献。
pallets/werkzeug我书里面没有介绍到Flask-Cache，因为它基本依赖于werkzeug且一般项目不会使用多种缓存方式，我觉得实际工作中用这个插件意义不大