作者声明：本人所在公司也做了一个 Slack 的替代产品。但我对使用 Slack 聊天服务的担忧和顾虑适用于所有类似产品，包括敝司的产品。
许多开源项目选择从开源的、异步式的通信交流工具如论坛、邮件列表以及 bug 跟踪跟踪系统，迁移到封闭的、同步式通信服务如 Slack，对于此我深表担忧。现在用这篇长文章来展开说明原因。
Slack 适合什么？
在正式开始之前，让我们来聊聊同步式聊天工具（如 Slack、HipChat 等）的优点。
在工作环境中，这类聊天应用程序取代了“系统演练”、“故障通知”等事件时群发给全体成员的邮件（@all_staff）。这是非常好的，因为这种来自公司的无用邮件根本是无法取消订阅的。
在开源的聊天工具，如 Slack，HipChat，Gitter 等的使用场景中，为上述的通知、非正式讨论甚至是八卦，提供了类似论坛的通道。渐渐地，当所有朋友都推荐 Slack 作为项目沟通的工具时，我的顾虑就开始加深了。
为什么 Slack 不适合开发团队？
在越来越多地使用聊天服务（如 Slack，HipChat 等）进行开源项目交流时，我的顾虑是这些服务并不是真的开放。我列举两个问题：
Slack 等付费工具的用户体系是封闭的。当然，在 Heroku 上有许多小应用程序可以用来自动化“发送用户邀请”这一过程，但从根本上说这些系统都是封闭的。这也意味着这些系统内的内容是封闭的：对于一个 Slack 频道中的讨论，我无法在一条推文或微博中链接它；我也无法在 bug 描述中关联它；同样也无法在演示幻灯片中引用它。这些内容只对那些有时间有能力实时参与聊天讨论的人们有帮助。
Slack 等系统是同步式的聊天通信工具，这对那些无法实时参与聊天的人是一种歧视。比如，对于一个开源项目中不在同一时区的成员，如果讨论交流是在你睡觉时进行，那你无法完全参与该项目。即使你在同一个时区，实时聊天也需要你有充裕的闲暇时间，或者你的老板不介意你分心。“始终保持在线”进一步提高了参与的代价和门槛。
在我看来，这两个问题是无法割裂的。使用 IRC 时候忽略 IRC 是实时的，就像创建一个 Slack 频道进行讨论时也忽略了一个事实，那就是并不是所有人都可以平等的参与对话。
对于开源项目开发，强烈建议使用异步式沟通工具
相比于封闭的同步式聊天系统，我建议开源项目坚持使用异步式通讯工具，并且有公开的、可引用分享的、可搜索的地址。最符合这一要求的工具就是你们熟悉的：邮件列表，bug 跟踪系统和论坛。
参考
Suggestions for contributing to an Open Source project https://dave.cheney.net/2016/03/12/suggestions-for-contributing-to-an-open-source-project
ack! and Go source files https://dave.cheney.net/2011/02/11/ack-and-go-source-files
Channel Axioms https://dave.cheney.net/2014/03/19/channel-axioms
Five suggestions for setting up a Go project https://dave.cheney.net/2014/12/01/five-suggestions-for-setting-up-a-go-project
原文链接：
https://dave.cheney.net/2017/04/11/why-slack-is-inappropriate-for-open-source-communications
Image credit：
https://www.arcanys.com/blog/skype-vs-hipchat-vs-slack-tools-for-offshore-development-collaboration/
推荐阅读
本文原文作者 Dave Cheney, 由魏佳翻译，转载请注明出处，技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿。
高可用架构
改变互联网的构建方式
长按二维码 关注「高可用架构」公众号
