Why Slack is inappropriate for open source communications • Hacker News Board

Re: Why Slack is inappropriate for open source communications

#361

Post by jrochkind1 » Tue, Apr 11, 2017, 10:31 PM UTC

milesrout wrote: post #314

ktta wrote: post #293

Earlier quoted context omitted.

Well. I'm interested to see what you think is a suitable protocol for business. I said it's an alternative, not a replacement. The days of simplistic IRC protocols have gone. Now people want emojis, search, session persistence, web client, and more things. So for that, there's obviously going to be more complexity compared to IRC. And IRC feels so hacked on when fit it with the modern features one wants today. I'm no…

>I said it's an alternative, not a replacement. The days of simplistic IRC protocols have gone. Now people want emojis, search, session persistence, web client, and more things. Let's take those each at a time, shall we? >Emojis This has nothing to do with the protocol. If you can send arbitrary UTF-8 messages (which you should be able to do, obviously, and can with modern IRC clients) then you can send emojis to you…

>>Session persistence

> No, nobody wants this

Are you serious? I think lots of people do. I think it's one of the draws of Slack.

> The thing is, most IRC servers don't want to buffer messages indefinitely for everyone that makes an account then never logs in again.

Is that what Slack does? Whatever they do, I think it's what people want. Indeed it is not an experience offered by IRC, perhaps because "most IRC servers don't want" to, sure.

Re: Why Slack is inappropriate for open source communications

#362

Post by aiiane » Tue, Apr 11, 2017, 10:33 PM UTC

eridius wrote: post #269

cls59 wrote: post #222

Earlier quoted context omitted.

I don't think it's a generational thing either. I know how to use IRC and how to connect with it. The problem is the difference in the amount of energy demanded by the set-up process. Connecting to Slack is extremely simple and I don't have to fiddle with the settings in order to get a decent experience. Compared to IRC, I have to: - Figure out how to configure my client. - Figure out how to interact with the user ac…

The benefit, though, is once you are set up with IRC, joining new channels is a breeze, especially since most open source software uses a single network (Freenode). All I have to do is type something like /join #rust-lang and I'm in the new channel. Compare this with Slack, where, no matter how many teams you've joined in the past, you have to go through the exact same rigamarole to join a new Slack team.

Discord avoids that issue by having a global identifier, similar to your connection to an IRC network.

However, having that global identifier / IRC network connection is a tradeoff - it forces you to use a single consistent identity for every single interaction on that network. For some people this is a plus; for others it is a negative. Slack's teams option allows people to use different identities for different instances.

Re: Why Slack is inappropriate for open source communications

#363

Post by ocdtrekkie » Tue, Apr 11, 2017, 10:33 PM UTC

educar wrote: post #321

mnutt wrote: post #290

Earlier quoted context omitted.

Along those lines, it sounds like Sandstorm may be a fit for what you're thinking of. It's generally more federated than a totally distributed system, but provides nice mechanics for packaging web apps, distributing them to others, moving from one server to another, sandboxing them, etc. It makes setting up and running web apps as easy and safe as downloading an app from an app store.

Last I checked the development in last few months has greatly died down (after they lost funding). It seems to rely on Kenton for all dev work.

The rate of change for features for the open source sort has not changed drastically, as a lot of effort was being expended on business development and profitability before the funding dried up.

Re: Why Slack is inappropriate for open source communications

#364

Post by eric_h » Tue, Apr 11, 2017, 10:34 PM UTC

djsumdog wrote: post #80

kuschku wrote: post #57

Earlier quoted context omitted.

> The real advantage of slack isn't even client its stuff like massive logging for e-discovery and single sign on integration. Admittedly not terribly appealing for FOSS but once you use it at work... Which can also be done with IRC clients. This is a video of a search system I built for the Quassel IRC client: https://dl.kuschku.de/videos/2016-09-16_04-03-36.mp4 Quassel is a distributed system, so you have a bouncer…

This is the first I've heard of an IRC bouncer. That's a great idea. It still seems like it's and extra step you have to add though, when really it'd be nice to see some work on IRCv3 so you could have multiple clients connect to one IRC server with the same username and sync without the need of a proxy.

When I was a wee lad I was always envious of people on IRC who had these things called "shell accounts" that let them stay connected to IRC 24/7.

They could schedule downloads to their remote boxes and wouldn't have to tie up the home phone line for three days downloading the latest warez from that guy who had an ISDN line and let 10 people(!) simultaneously download from his bot at a screaming 5k/s.

Now I can have all those things (including the equivalent of 1000 ISDNs), and I don't really use IRC anymore, young me would be so jealous.

Re: Why Slack is inappropriate for open source communications

#365

Post by aiiane » Tue, Apr 11, 2017, 10:35 PM UTC

codelitt wrote: post #112

pmarreck wrote: post #27

Earlier quoted context omitted.

Slack chat provides a number of nice features that IRC (at least out of the box... I know there have been attempts) does not. IRCCloud at least lets you see chat history, which IRC doesn't have out of the box but Slack does.

Slack only provides a bit of history unless it's a paid account. What open source community could support that many paid users on Slack?

That "bit of history" goes a long way, though. In particular, it means you don't lose context when you disconnect temporarily, which makes a huge difference for both mobile and laptop use cases. (Obviously, this is also one of the reasons why bouncers were invented for IRC - and why they're popular. But Slack having it out-of-the-box is a huge yak saver.)

Re: Why Slack is inappropriate for open source communications

#366

Post by aiiane » Tue, Apr 11, 2017, 10:36 PM UTC

to3m wrote: post #334

VLM wrote: post #50

Earlier quoted context omitted.

Just run your IRC client in screen/tmux like we've done for a quarter century. The real advantage of slack isn't even client its stuff like massive logging for e-discovery and single sign on integration. Admittedly not terribly appealing for FOSS but once you use it at work... Also integrations in general are smoother in slack than in IRC. Someone has already written the bot and its a click away to install and it gen…

> Just run your IRC client in screen/tmux like we've done for a quarter century. Wait... did you just tell me to go fuck myself?

I believe they did, Bob.

Re: Why Slack is inappropriate for open source communications

#367

Post by smhx » Tue, Apr 11, 2017, 10:37 PM UTC

cristaloleg wrote: post #29

caseysoftware wrote: post #5

Good points but the bigger problem for me is the lack of an archive. You only have the last 10k (?) messages and that includes public and private messages. If you have a mildly active project, messages may only be available for a month and you lose the history of the project. That makes it an awful support option too.

Well, some of the open communities are using http://slackarchive.io/

thanks for the pointer. I started using this today for pytorch

Re: Why Slack is inappropriate for open source communications

#368

Post by voltagex_ » Tue, Apr 11, 2017, 10:41 PM UTC

duskwuff wrote: post #357

na85 wrote: post #348

Earlier quoted context omitted.

Agree about DCC but lot of the other issues you list are due to curmudgeonly (IMHO) users insisting on using non-modern clients and networks. If they would tolerate a little breakage of backwards compatibility, the big networks could easily move to utf8 with standardized identity and colours, etc. Unfortunately there is a small but very vocal faction of IRC users that are highly entrenched and resistant to change.

At the same time, that existing base of legacy IRC clients and servers is the only reason it could be worth hanging on to the old protocol. If we're going to break backward compatibility, we might as well take the opportunity to fix all of the other long-standing issues with the protocol.

I still have hope for the IRCv3 project, it appears to be fixing a lot of the issues mentioned. I'm on Matrix, but until #debian moves, I'll be found on Freenode and OFTC.

Re: Why Slack is inappropriate for open source communications

#369

Post by xfalcox » Tue, Apr 11, 2017, 10:41 PM UTC

throw2016 wrote: post #167

xfalcox wrote: post #44

Discourse offers free hosting for big Open Source projects, and you can self-host it on a $5 VPS too. Full Disclosure: I work at Discourse.

I doubt Discourse will run on a $5 VPS. The last time I checked its crashes on 512MB RAM, needs at least 1GB just to start. Have the minimum requirements changed? 1GB minimum and 2GB is recommended by Discourse itself. Discourse is also not easy to setup, its quite involved and complex and you need some Ruby and systems expertise. Infact I think Discourse only supports Docker installs. So you need to know Docker too.…

I believe Linode and Vultr already have $5 1GB VPS offers.

Also the Official Install Guide[1] doesn't require any Docker-fu.

Also, we give hosted Discourse for free for open source projects with a big enough community to have a forum[2].

1: https://github.com/discourse/discourse/blob/master/docs/INST...

2: https://blog.discourse.org/2016/03/free-discourse-forum-host...

Re: Why Slack is inappropriate for open source communications

#370

Post by tabbott » Tue, Apr 11, 2017, 10:43 PM UTC

I am the lead developer of Zulip (zulip.org), an open source Slack alternative built around a better threading model.

I strongly agree with both criticisms of using Slack for open source, and I am impressed that Dave wrote this post, given that some of those criticisms apply to his own product.

However, I think the proposed solution of relying on mailing lists, issue trackers, and forums is the wrong solution.

Support for synchronous communication is not the problem with using Slack/IRC/etc. for having discussions in open source organizations. After all, even with "asynchronous" media like email, bug trackers, or forums, often people reply basically immediately (within minutes or maybe hours), just like you can in chat, and it might be hours or days before everyone has a chance to see the conversation and respond.

The problem is that the messages have no organizational structure beyond the channel. In Slack and friends, there's no easy way to see what _actual conversations_ happened while you were away, and it's really hard for a channel to discuss multiple things, so conversations either die or become hard to read when someone starts talking about something else. Combined, this means you have to (1) read _everything_ in order to know what happened and (2) be continuously online in order to participate effectively. This may not matter if your community is super low-traffic, but if you have hundreds or thousands of messages being sent daily, this effectively excludes everyone who doesn't have a LOT of time to spend on the chat community.

It doesn't have to be this way. Nothing prevents creating group chat software that handles both synchronous and asynchronous communication well. In particular, Zulip is built around a simple threading model that solves both of these problems. In our own chat.zulip.org community, people constantly contribute valuable commentary or feedback to a thread that started a few days and hundreds of messages ago. And I can come back from a week's vacation, and skim the 5000 messages that might have happened while I was gone, and easily reply to all the threads where I have something to add.

(As a sidenote, it's easy to post permanent links to conversations in Zulip, which we use regularly in the Zulip issue tracker to point to the original discussion that led to a given proposal. But the important problem isn’t the link part, it’s separating the conversations from each other: without something like Zulip's threading, reading chat logs can be a slog).