Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Slack is inappropriate for open source communications

dave.cheney.net

Post reply on HN
Print view View original

341–350 of 536 posts

Re: Why Slack is inappropriate for open source communications

#341

Post by Sanddancer »

NateDad wrote: post #144
_jal wrote: post #68

Earlier quoted context omitted.

Question for you: I hear this a lot, in terms of older tools being considered obsolete. Other than the natural human tendency towards novelty and the network effects, what, exactly, is obsolete about mailing lists or IRC? What features are missing in IRC that Slack has for synchronous discussion? (I'll start: animated dancing pigs out of the box and the need to write/plug in your own archiver.) What limitations do ma…

To have all the features you get for free out of slack, you have to do a lot of work and maintenance to get out of IRC and mailing lists. Mailing lists by themselves are terrible, because there's no history. You can't scroll up to find context for the conversation. You can get public archives, but then where you actually use the mailing list and where you go to look at history are completely separate, which is a terr…

Slack gets a lot worse once you want to start dealing with two teams using it. With most IRC clients, I can have connections to multiple servers running, and able to see at a glance everywhere that there's activity. With Slack/Discord/etc, that involves a frenzy of clicking as you look through each group of chats individually. I can lay things out how I want, move things around, etc. Slack, fortunately, has bridges built in for IRC and XMPP clients, so I can use my already working clients instead of having to keep another web page open to another javascript-laden nightmare.

Re: Why Slack is inappropriate for open source communications

#342

Post by zAy0LfpBZLC8mAC »

aeorgnoieang wrote: post #289
_jal wrote: post #68

Earlier quoted context omitted.

Question for you: I hear this a lot, in terms of older tools being considered obsolete. Other than the natural human tendency towards novelty and the network effects, what, exactly, is obsolete about mailing lists or IRC? What features are missing in IRC that Slack has for synchronous discussion? (I'll start: animated dancing pigs out of the box and the need to write/plug in your own archiver.) What limitations do ma…

The primary benefit of 'Slack' over "older tools" is that the former are free – not just financially but in terms of how much time, effort, and energy is required to set them up and maintain them. Sure, there's lots of freely available alternatives, but even tiny (but non-zero) costs in time and money are the difference between widespread usage and relative non-use. I setup Gitter on a GitHub repo for a project by cl…

> The primary benefit of 'Slack' over "older tools" is that the former are free – not just financially but in terms of how much time, effort, and energy is required to set them up and maintain them.

You are ignoring the costs that come from lock-in (inflated prices, lack of innovation) and migration in case the proprietary solution shuts down. That's the psychological tendency of humans that these companies exploit.

Re: Why Slack is inappropriate for open source communications

#343

Post by Sanddancer »

branchly2 wrote: post #75

Forums work better. Using IRC/Slack in place of forums is like using a wiki in place of real documentation.

Forums fall apart when you're trying to do things like realtime debugging. With a chat client, I can leave a window open in a corner and keep an eye on it while doing other things. With a forum, that becomes a game of hitting refresh every thirty seconds waiting for new messages.

Re: Why Slack is inappropriate for open source communications

#344

Post by enugu »

erikpukinskis wrote: post #260

We are, temporarily, in a kind of dark ages of end-user open source software. The reason is that we shifted from software-as-a-product to software-as-a-service. With the old upload-and-forget model of software distribution, you could put a tarball on a free FTP site for a few pennies, and then a million people could use it, or one person could, and you wouldn't have to lift a finger. A million people could fork your…

The way this problem will get solved is some service running on top of aws which will allow users to install and run any app, packaged in a standardized format. This will be free in exchange for a column beside the app which serves ads or some small amount of money to get rid of the ads.

Re: Why Slack is inappropriate for open source communications

#345

Post by freehunter »

natefinch wrote: post #202
freehunter wrote: post #118

Earlier quoted context omitted.

I actually argued here recently that email was hard to switch away from because of the history. You can keep your emails forever. I have emails from 2007 sitting in my inbox. And if I want to keep them, I can download them with IMAP or POP. If I send an email to five people and they remember to hit "reply all", well that's a conversation, isn't it? And if I need to show someone an email they weren't party to original…

That puts the onus on every single person to maintain the history of the project. Lots of people delete mail (not me, but lots of people). Also, you can't retain history of what was sent before you joined. Also, emailing individual documents means people can't research by themselves.

I mean, email isn't meant to be a document repository. Slack (or other chat) is great for immediate conversations with many people. Email is great for slower conversations with a more limited number of people. A wiki is great for a very slow conversation. An actual document repository is great to be able to link to when using any of the other conversation methods.

Just because Slack isn't good at slow conversations doesn't mean it's bad. Just because email is bad at including people who joined after the fact doesn't mean it's bad. Those aren't their strengths, and that's fine. They still serve their own purpose just fine.

Re: Why Slack is inappropriate for open source communications

#346

Post by zAy0LfpBZLC8mAC »

frik wrote: post #266

For open source projects: offer Github issues, IRC for chat and a proper forum like phpbb or a more modern forum like discourse (or one of the clones) and/or a mailing list.

> offer Github issues

Why a proprietary issue tracker that requires that people make an account with them in order to communicate with you?

Re: Why Slack is inappropriate for open source communications

#347

Post by Sanddancer »

thehardsphere wrote: post #220
amelius wrote: post #209

I can't believe that in 2017 we're still discussing what's wrong with our chat software. I have to wonder when we will finally see chat as a solved problem.

The OP isn't actually discussing chat as an unsolved problem. OP is arguing that chat is the wrong choice of solution to the problem of open source software project communication, because it's synchronous. Or to abuse a metaphor, OP is arguing we need to use boats instead of cars to ship heavy things overseas, not that cars are an unsolved problem.

OP is arguing we should use boats for everything, including sending something across town. Realtime chat works a lot better for certain things, like troubleshooting, where having to wait around for a forum/email response may not be the best way of doing things.

Re: Why Slack is inappropriate for open source communications

#348

Post by na85 »

duskwuff wrote: post #270
iffycan wrote: post #263

Earlier quoted context omitted.

Call me crazy, but I think your example illustrates one reason why IRC is great: I can read it. And I could probably get it right even typing it from memory.

The IRC protocol is surprisingly difficult to implement correctly. I'm not an expert on the issues involved, but a few of the high points include: * No standard maximum message length. If you input a line which is more than 510 characters after being prefixed with the channel name, server name, and other metadata, it may be truncated for some clients. If you're on a network which includes multiple servers, some clien…

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.

Re: Why Slack is inappropriate for open source communications

#349

Post by Sanddancer »

Arzh wrote: post #160

Can we just go back to aim? I really hate having one damn view for channels, so if I'm talking to two people I have to constantly switch back and forth. I still don't get how these kinds of tools get such a big following.

I think that's the biggest flaw with a lot of web-based chats. There's no flexibility in layout. With a chat app like pidgin, I can choose how things are laid out, set up notifications a lot easier, etc. Webapps tend to be a lot more limited in such areas -- not able to choose notification sounds, set various things to notify in different ways, etc.

Re: Why Slack is inappropriate for open source communications

#350

Post by zAy0LfpBZLC8mAC »

milesrout wrote: post #325
zAy0LfpBZLC8mAC wrote: post #316

Earlier quoted context omitted.

And yet it requires a hilariously complex protocol engine for HTTP for no purpose whatsoever.

I don't agree at all. HTTP/1.1 and HTTP/2 are not especially simple protocols, but they're not that complicated. They aren't unnecessarily complicated, that's for sure. They have a set of features that necessitates a level of complexity, but it's better to do it in HTTP/2 once and only once than to repeat the same failures and reworks and added features and upgrades etc. etc. etc. to get the same level of features in…

> They aren't unnecessarily complicated

They are, for what matrix intends to do.

Post reply on HN