class="topic_img" alt=""/>
作为 LedisDB 的作者，时不时收到一些私信，问我“有没有 QQ 群，有个问题想咨询一下”，而每次我都会答道：“没有，不过你可以在 github 的 issues 上面提交你的问题”，然后就没有然后了。
Github 已经是一个很成熟的代码管理平台，并且提供了非常丰富，便捷，人性化的协作方式。但我发现，相比于国外程序员使用 issues，使用 pull request，使用 mailing list 等，国内的同学大多仍然喜欢使用 QQ 技术群的方式来讨论问题。这么说可能比较绝对，但至少我接触的几乎都是这样。
QQ 群的好处就在于交互非常及时方便，我有一个问题，找到相关的群，在群里面吼一声，立马就能得到回复，多容易呀。但没准就是因为这种便捷反而让我们少了很多思考的空间。
当然有很多优秀的 QQ 技术群，但相当大一部分，开始的对话可能都是这样：
群主在吗，我在 linux 下面编译不过。
群组在吗，我这个东西跑不起来，不知道出了什么问题。
群组在吗，你看看我这个配置是不是不对？
我想很多人应该见到过这种对话，作为群主来说可能是非常反感这样的问题的，但有时候仍然得客气的回复一下，不然别人会以为你这人太高傲，就做了点东西有啥了不起的。但是拜托，源码这些的都已经开源了，你不知道自己先看看问题出在哪里呀，或者你写明到底怎么使用以至于出了问题的。再不济，这世界还有一个叫 Google 的东西呀。
我个人其实是比较反感给一个项目建立一个 QQ 讨论群的，虽然里面会吸引很多牛的人入驻，共同进步，但多数时候很多人只会将这里当成一个随意提问的地方。
也有人会说，使用 issues 也可能随意提问呀，当然是的，但是比起 QQ 群里面只有群成员见到你的问题（没准最后就变成一堆人在瞎扯），你在 issues 上面提出来的东西将会被更多地人看见，没准这会无形的让你首先考虑如何写出自己的问题。另外通过 issues 的方式，你不会期望项目作者能快速的像 QQ 群那样给你及时响应，所以你必须得考虑把问题写清楚。
就拿上面 QQ 群的例子，我们如果使用 issues 来交互。
你好，我在 linux 下面编译不过。
假设开发人员是一个极有耐心的家伙，他可能一个小时后（没准更晚）check 了这条 issue，然后回复：
你好，你能详细的说明下你的编译错误吗？
然后，假设你也是一个极度无聊的家伙，你列出来一堆编译错误回复了过去。
然后又过了一个小时，开发人员再次 check 了，发现无法解决你的问题，又回了一句：
你好，你能详细的提供下你的开发环境吗？
然后你写到
我的是啥 xxx cpu，xxx mem，是 windows 系统。
又过了一个小时，开发人员 check 了，回复到：
你好，我们的项目不支持 windows。
好的，如果你能忍受这样的交互，我觉得你可以试试在 issues 上面这么干。但如果在 QQ 群里面，这别提有多方便了。
我加入了很多技术讨论群，觉得有两个群很具有可比性，后面就用群A和群B表示吧，我明显感觉群A的作者要比群B的轻松很多，因为里面问的问题显得比较高端，可能是因为大家都被 MySQL 这家伙给折磨的成大神呢？而群B的群里面，经常见到我上面那些对话，以至于作者都要写通告告诉大家来怎么提问题了，这里完全没有黑群B的意思，只是真心希望大家在群里面提问题的时候也需要考虑一下回答问题人的感受。
也许，我就是因为怕在 QQ 群里面回答问题而不愿意建群吧（人太懒），还有可能是因为项目影响太小，建了也没有人加入，最终成了一个死群（mixer 就是典型的教训）。不过还有最重要的一个原因，国外的程序员真没几个有 QQ 的。
所以，我觉得，没必要为自己的开源项目建立 QQ 群，没准建立一个 Google Group 都可能更好。
相关文章
