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

351–360 of 536 posts

Re: Why Slack is inappropriate for open source communications

#351

Post by always_good »

exelius wrote: post #33
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.

So get a better IRC client? Really not hard to do things like syntax formatting and auto link follow (GUI versions of IRCII had plugins for this in the late 90s, so it's not like it's even a novel idea).

The problem is that you might be running a nicer IRC setup, but almost nobody else is. Doesn't do you much good if everyone else logs off the second they close their laptop lid, or can't scroll back up to see what you just said because they had to relaunch their client.

Chatting is interesting because of other people. That's why I'm chatting.

In Slack, I can ping people that are offline. And all they have to do is open Slack again or reconnect to the internet and they get notified. I don't need to count on them being an IRC veteran.

All these people pointing out ways to enhance your personal IRC experience are missing the point.

Oh yeah, and I can post code in Slack.

Re: Why Slack is inappropriate for open source communications

#352

Post by Sanddancer »

scrollaway wrote: post #95

I massively disagree with #2. Unless your project has very little activity, synchronous or pseudosynchronous communication is a lot more efficient than async through email/discourse. It's also a lot more friendly to your contributors, it makes things less formal and more human. Async shines when you have a lot of users, but only if it's very accessible (searchable). Otherwise it's just people repeating themselves con…

The biggest problem I have with discord is that the client is complete and absolute balls if you want to be in more than one group at once and keep up with notifications and the like. With IRC, my one client shows the activity of all of the networks I'm in, with discord, the only notification I get is that there's "something" going on in another group, without telling the channel, etc. It's much more interrupting and frustrating.

Re: Why Slack is inappropriate for open source communications

#353

Post by okdana »

maehwasu wrote: post #296

> Slack, et al, are based on synchronous communication, which discriminate against those who do not or can not take part of the conversation in real time. For example, real time chat discriminates against those who aren’t in the same time zone–you can’t participate fully in an open source project if all the discussion happens while you’re asleep. Even if you are in the same time zone, real time chat assumes a privile…

There's no talk of 'oppression' anywhere in the article.

You understand that 'discriminate' and 'privilege' are regular words with regular definitions that were used by regular people for hundreds of years before you came along with your chip on your shoulder, right?

Re: Why Slack is inappropriate for open source communications

#354

Post by ktta »

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…

>>Emojis

Unless you have a mobile keyboard you'll have to search for emojis yourself and paste them. Emoji's will always be an after thought unlike in Matrix[1] and riot[2].

>>Search

You're right, it has nothing to do with the protocol. It was never about if it was possible or not. I'm talking about if it is available right now. Try riot.im and then please show a mainstream IRC client with has the same search features.

>>Session persistence

>No, nobody wants this.

Really? Are you sure?

> The former is solved by the same server-side logging mentioned above and the latter is really the same idea. The thing is, most IRC servers don't want to buffer messages indefinitely for everyone that makes an account then never logs in again.

Again, this isn't about if it is possible. It is about if it is available right now. You seem to be a big fan of writing code by yourself for features. Please link me to the cool IRC client you use which has all these features.

>>> Web Client

IRC was never intended to be run in the web browser. But matrix was built with that in mind. This is what my ' And IRC feels so hacked on when fit it with the modern features one wants today' comment was all about.

>IRC has lots of features that are much, much more complicated than what you mention above, like DCC file transfer.

Honestly, I might sound ignorant, but I've never ever heard of DCC file transfer. And matrix has implemented E2E encryption in some of their clients(all the major ones), and implementing them in the rest is a priority. I don't ever thing IRC will have this. I'd be glad if I was wrong.

Also, why the boast about 'much, much more complicated'? What features require so much complexity, and if they did require high level of complexity, how useful are they? Also IRC doesn't think a lot about the UX/UI part which is what I often am frustrated about.

One thing I find interesting about your reply is that you seem to assume the user is an experienced programmer. You make suggestions about extending an IRC server feature like it's changing a setting. But most people who are in OSS wouldn't bother with that. And what about non-technical users? Shouldn't this be easy to use for them to?

Or do you want to ignore them so that they continue using a closed messenger and wonder why they're dominating the mindshare today?

Have you wondered why a lot of OSS projects moved to slack? I'm surprised no one in this thread is trying to find out why IRC doesn't seem to be the choice of OSS projects. Rather it seems to be about bashing matrix and one-upping IRC over matrix. Which solves nothing.

[1]:https://github.com/matrix-org/matrix-react-sdk/pull/296 [2]:https://github.com/vector-im/riot-web/issues?utf8=%E2%9C%93&...

Re: Why Slack is inappropriate for open source communications

#355

Post by ravenstine »

milesrout wrote: post #317
ravenstine wrote: post #313

Earlier quoted context omitted.

Stallman only really cares about free software and not really OSS. But I get what you're saying.

Free software and open source software are synonyms. Even Stallman agrees on this. He cares about the use of the terms because of their other implications.

Ok, that's interesting. My impression from watching his talks is that he does not consider the two ideas as synonymous, in that a software can technically be closed-source but have licensing that is libre-free so that it can be used by whomever however. But perhaps I got it wrong.

Re: Why Slack is inappropriate for open source communications

#356

Post by panic »

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…

What if we had an easy-to-use home server you could just plug in and start running "apps" on? Being able to download and run services on hardware you control would avoid some of these problems.

Re: Why Slack is inappropriate for open source communications

#357

Post by duskwuff »

na85 wrote: post #348
duskwuff wrote: post #270

Earlier quoted context omitted.

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.

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.

Re: Why Slack is inappropriate for open source communications

#358

Post by eric_h »

s73ver wrote: post #326
kuschku wrote: post #124

Earlier quoted context omitted.

> There's a reason people like slack so much. It does a ton of stuff out of the box with no headaches. Nobody wants to maintain all that stuff. So instead of paying someone to maintain it, you pay someone to maintain it who keeps all your data from you and prevents you from accessing it, and who admits he’ll read all your stuff. How is that better again? That said, IRCCloud already does it for free, in the cloud, jus…

You can get upset over this and argue with people, but that's not going to make anyone choose IRC over Slack.

Slack, Hipchat, Campfire, etc. are all just IRC for normal people. There is without a doubt a barrier to entry to IRC that actually requires a bit of understanding of how the protocol works. "I'm in #this-channel-you-told-me-about, but no one else is in here, wtf?". "Oh, you're on the wrong network - it's EFNet, not Freenode".

There is no such barrier for the current set of chat apps. Download > Login with google, start chatting with the person who invited you. Search history? File sharing? No need to remember anything about dcc/xdcc, no need to manage servers running bots, no need to manage anything, really; it's all taken care of by the nerds that run the service.

I think one might actually be able to build a business by building a Slack that runs on top of IRC, and releasing client apps that actually significantly reduce the flexibility that a standard IRC client gives you. If you can get the on boarding flow to invite -> download -> log in -> start chatting with the people you want to chat with, you could crush slack (assuming you had the marketing budget to compete with theirs).

I think, however, that IRC will remain in some ways as a small haven from eternal September (haha, yeah, I know). The barrier to entry is a feature, not a bug.

Re: Why Slack is inappropriate for open source communications

#359

Post by zAy0LfpBZLC8mAC »

Arathorn wrote: post #339
zAy0LfpBZLC8mAC wrote: post #322

Earlier quoted context omitted.

> we're still waiting for anyone to contribute a more efficient transport, but turns out HTTP+JSON works well enough that nobody has bothered. Well, except you managed to needlessly intertwine matrix and HTTP such that it's essentially impossible to reasonably port it to a sensible transport protocol.

What do you have in mind? There is nothing particularly specific to HTTP about Matrix at all - it just needs some kind of request/response mechanism, and a way to stream events back and forth. For instance https://github.com/matrix-org/matrix-doc/blob/master/drafts/... is the proposal for Matrix over websockets (which streams server->client events over a websocket in a manner which has nothing to do with HTTP). But n…

> What do you have in mind?

You are using URIs and HTTP status codes (if you want to call it that, as you are not actually speaking HTTP), which is completely unnecessary (you could transport that same information in JSON, reducing the number of languages that an implementation needs to be able to generate and parse to one instead of three, thus reducing the attack surface by at least 66 % (probably more, given the complexity of HTTP)).

I mean, just look at the "lightweight C client" that you linked to above: Not only is it not in C, but it's already full of bugs that are essentially caused by the complexity of all those languages on has to interface with.

> But nobody's bothered to implement it, because nobody seems to feel HTTP+JSON is particularly broken in practice.

Or, more likely, those who do feel that way have read the spec, facepalmed, and forgot about it?

Re: Why Slack is inappropriate for open source communications

#360

Post by aiiane »

Arzh wrote: post #333
frikk wrote: post #247

Earlier quoted context omitted.

We migrated from IRC to Mattermost and haven't looked back. It integrates so well with our Gitlab/Jenkins flow, too. It's been great. The biggest benefits for us: - Easy to use web push endpoints w/ API keys (great for scripting with curl) - Integration with Gitlab / Jenkins - Chat Logs (see what happened while you were away) - Public listing of channels (no more "oh you have to join #whatever to see that") - Mobile…

Why do you want a chat client to integrate with gitlab or jenkins?

Oftentimes the 'sync' conversations are either triggered or resolved by commit/build events.
Post reply on HN