互联网与文化drewdevault.com
请不要在自由/开源项目中使用 Slack
Please don't use Slack for FOSS projects
2015 — 2019，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 Drew DeVault 2015 年的一篇博客文章，标题即主张：自由/开源软件项目不应把社区沟通放在 Slack 上。文章从自由软件项目的价值观出发，反对 FOSS 项目依赖 Slack 这类闭源、由第三方托管的商业聊天服务，并讨论 IRC 等开放替代方案。
为什么经久不衰：它把“好用”与“开放、自主可控”的张力摆上台面；Slack 已改变、替代方案也更多，但 FOSS 社区该把沟通放在哪里仍是常谈常新的话题。
HN 评论精选
批评 IRC 方案：它并不好用/安全，Slack 对小队更省维护成本。
如果 IRC 真能满足小型软件公司的沟通需求，人们就会用它；假装大家只是不知道一个 20 多年的技术很可笑。IRC 的分布式设计脆弱、易被拒绝服务，而 Slack 的日志服务默认配置正确且安全；对只有 1–3 名技术人员的组织，维护近似 Slack 的功能不如把时间花在产品上。IRC 适合低流量公共沟通，但多数周边工具对小软件团队很不够用。
KirinDave查看英文原文
If IRC were good enough to handle the needs of small software company communication, people would use IRC. Sitting here pretending everyone just doesn't know about a 20+ year old technology is comical. The "IRC Features" section bugs me, too. Unless you run a private IRC server IRC has a long, tortured history of design-based security difficulties. Gone are the days of netsplits permanently owning channels, but the so called "distributed" design of IRC makes it very brittle and easy to deny service. Oh, and did you know that with modest, low volume channels (>200 <1000, some networks tolerate more) you can make IRC networks struggle? Turns out that their lousy distributed design hurts more than helps when single channels get heavy. Slack also offers a logging service that, for what it's worth, is configured correctly and secured by default. For organizations with 1-3 technical staff, maintaining and securing a reasonable approximation of Slack's feature is probably time better spent working on your product. IRC is a classic example of the "it's broke but we don't fix it because it's familiar" mentality of old school services. While it may be a good choice for running low-volume (<500 users) public communication. Most tooling around it is woefully inadequate and often tedious to use for small software-oriented teams where Slack thrives. But if you're genuinely concerned about security, HipChat will sell you a whitelabel product you can host and monitor and its setup is quite good for what it is.
IRC 作为唯一替代不够；Slack 的易用性和功能是项目迁移的现实原因。
如果唯一提出的替代方案是 IRC，我很难认真对待这个观点。IRC 对 FOSS 有好处，我也用过很多次，但项目转向 Slack 是有原因的：更易用，离线状态处理更好，加入/邀请房间更容易，设计干净，网页界面与客户端一致且无需安装；还有文件共享、工单/构建集成、链接预览、消息编辑等功能。Slack 在 FOSS 领域当然可以有竞争者，但假装 IRC 是终极方案会完全忽略问题。
publicfig查看英文原文
It's really difficult for me to take this point seriously if the only proposed alternative is IRC. I understand the benefits of IRC for FOSS and have used it many times in the past, but there's a reason why projects are adopting Slack over IRC. It's easier to use, it deals with on/offline states a lot more gracefully, it allows joining and inviting to rooms much easier, it has a clean and easy to use design and it's available pretty much anywhere using the same interface without having to install a client through their web interface (which is the exact same as their app interface). Along side that, there are hundreds of other minor to major features (File Sharing! Ticketing/build integration! Link Previews! Editing a message after it's sent!!!) that make it much more useful for many use cases than IRC. I think there is definitely room for competition with Slack for FOSS projects, but trying to pretend like IRC is that ultimate solution will ignore the problem completely.
给出可自托管开源替代，并指向联邦协议方向。
一些可自托管的开源 Slack 替代品：Rocket.Chat、Zulip、Mattermost、Let's Chat。另外，在 Sandstorm 上大约 30 秒就能跑起自己的 Rocket.Chat。我也希望看到现代联邦聊天协议兴起，比如 Matrix。
ash查看英文原文
Some open source self-hosted alternatives to Slack: * Rocket.Chat (https://rocket.chat/) * Zulip (https://zulip.org/) * Mattermost (http://www.mattermost.org/) * Let's Chat (http://sdelements.github.io/lets-chat/) Oh, and by the way, you could have your own Rocket.Chat instance running in Sandstorm in about 30 seconds: https://sandstorm.io/apps Update. And I would love to see a modern federated chat protocol to take off. Something like http://matrix.org/.
作者澄清文章范围，并承认应更多介绍 Matrix/Gitter 等替代。
作者本人：上次讨论说过很多了，补充几点回顾：如果我只说 IRC 对 FOSS 项目更合适，而不是把它说成整体上优于 Slack，文章效果可能更好；这篇不是要一般性地羞辱 Slack，虽然结尾有点那意思。重要的是，Slack 已表示不希望大型公共项目托管在 Slack 上，把 FOSS 项目放上去并不是好用例。事后看，Matrix、Gitter 等对 FOSS 友好的替代相当不错，我应该多研究并在文中讨论。现在引导讨论太晚了，但请记住文章针对的是 FOSS 项目使用 Slack，不是一般场景。
Sir_Cmpwn查看英文原文
Author here. There's not much to say here that wasn't said last time, but here are some retrospective thoughts on this post: - Probably would have come across better if I didn't pitch IRC as better than Slack in general, but only that it's better for FOSS projects. This blog post wasn't meant to shame Slack in general, even if it kind of did in the end. - Importantly, Slack has come out as saying that they don't want big public projects to host themselves on Slack. It's really just not a good use-case for Slack to put a FOSS project on it. - In hindsight, a lot of the FOSS-friendly alternatives (Matrix, Gitter, etc) are quite good and I should have put more effort into researching them and discussing them in my article. It's probably too late to steer the discussion, but please remember that my post addresses the use of Slack for FOSS projects, not in general.
历次讨论
同类还值得读
如今电脑上几乎所有操作在感知上都比 1983 年更慢（2017）
Almost everything on computers is perceptually slower than it was in 1983 (2017)
2017 年的推文串认为，尽管计算机硬件比 1983 年快得多，日常操作的感知速度却常常更慢：启动、界面响应和网络应用被层层抽象、动画、后台检查与网络依赖拖累。
互联网与文化上首页 5 次 · 2017–2020twitter.com网站肥胖危机
The Website Obesity Crisis
Maciej Cegłowski（idlewords）的经典演讲文稿《网站肥胖症危机》，批评现代网页越来越臃肿：动辄数 MB 的 JavaScript、追踪脚本和广告，把本可以轻…
互联网与文化上首页 5 次 · 2016–2021idlewords.com编辑精选亚马逊那本标价 23,698,655.93 美元的苍蝇书
Amazon’s $23,698,655.93 book about flies
博文讲的是亚马逊上一本关于果蝇的二手书被标到 23,698,655.93 美元。
互联网与文化上首页 5 次 · 2011–2022michaeleisen.org浏览器 User-Agent 字符串的历史
History of the browser user-agent string (2008)
2008 年的经典文章用戏谑的“创世纪”口吻，讲述浏览器 User-Agent 字符串如何从简单的标识演变成层层叠加的伪装：浏览器为了绕过按 UA 分发的网站检测，纷纷把自己伪装…
互联网与文化上首页 5 次 · 2012–2022webaim.org编辑精选最后的问题——艾萨克·阿西莫夫
The Last Question - Isaac Asimov
阿西莫夫最著名的短篇科幻小说《最后的问题》的在线全文。
互联网与文化上首页 5 次 · 2009–2019multivax.com编辑精选