Live data from Hacker News

Why Slack is inappropriate for open source communications

dave.cheney.net

231–240 of 536 posts

Re: Why Slack is inappropriate for open source communications

#231
post #196

Earlier quoted context omitted.

I've tried to give IRC a chance a few times, but it always felt like there were a few too many odd little things to learn before I could be productive and comfortable. I didn't get used to it and dropped it. It never felt inviting. I use slack at work and love it. I fully agree that it isn't that different from IRC and I hate that it's another walled garden (of sorts), but it fixes a lot of the little annoyance in de…

I've been IRCing for 24 years. I know about bouncers, different clients, etc., and I still prefer Slack to IRC. I like knowing that it's going to handle unicode properly, in all cases, for everyone on the Slack channel. I like that it handles right-to-left text for everyone reading. I like not having to ever think about, is my bouncer down? I also like not having to think about, where am I going to run my bouncer? It…

I used IRC a lot as a teen back in the late 80s early-to-mid 90s. This was back when to make a private channel you would have to join a channel that was a negative number and hope nobody else wandered in on a guess (which was unlikely to happen since the number of users was literally under 200 at peak times). Pre-Eris, Pre-EFNet, etc.

Despite the nostalgic kick of it, I never used it as a serious work tool at any of my jobs, haven't used IRC at all in probably a decade, and totally agree that options like Slack are just plain better work communication tools.

Re: Why Slack is inappropriate for open source communications

#232

What drives me nuts is that there are so many of these things. I know groups that (for business or pleasure) use Slack, Discord, Skype, Google Hangouts, IRC, etc. All of these clients are a bit more obstrusive than they need to be in terms of pop-up notifications, software updates, cpu, memory, transfer, etc. They all screw up enough that there's always a little apprehension that something will go wrong when you get…

What if software engineering as a skillset hit its peak within the last 5 years and now it is just going downhill in general? The quality of "companies" isn't going down - companies are made of people, and some of those people are in charge of creating and testing its technology...

Re: Why Slack is inappropriate for open source communications

#233
post #213

A great alternative to Slack, in the spirit of IRC, is matrix[1]. It has lots of clients, and a great vision. You use an online client called riot[2] which uses the matrix protocol. There are other clients available[3] including desktop clients. There's E2E encryption coming to more of the clients which is inspired from signal protocol (double ratchet part of it specifically), without Forward secrecy so as to maintai…

"in the spirit of IRC" is a bit of a stretch. This is all a massive blob of web technologies which contrasts IRC's minimalism and it's lightweight clients written in C. It doesn't appear to require any specific service though so at least it has that.

Re: Why Slack is inappropriate for open source communications

#234

Tangentially, I don't get how developers on the one hand strive for private offices and no (physical) interruptions, but on the other want to communicate through chat channels. Maybe these are different people altogether, and I'm just getting the wrong impression. But personally I prefer a little personal interaction over a long chat.

I don't have to drop (as much of) my mental state in order to communicate via chat. It's asynchronous, so I can finish typing out whatever I'm thinking about, or looking for whatever I'm trying to find, kick off a build, etc., and then turn my attention to the chat window and bang out whatever comes next in the conversation. Once written, I can switch right back to whatever I was doing - I type quickly, so it's usually only a few seconds of interruption. I can easily carry on a couple of extended chat conversations while simultaneously continuing to get my actual work done.

If someone wants to talk in person or via voice instead, my heart always sinks a little, because it means I have to drop whatever I was doing and give the conversation my full attention instead. Once we're done, I have to try to remember what I was thinking about before the distraction happened, get myself back up to speed...

This doesn't come up so frequently anymore, but it was very noticeable when I used to work remote. Some coworkers were happy with chat, and it was easy to communicate with them; with others, it'd be like twenty seconds of productive conversation, then "can we please just have a call about this" and, oh god, that's it for getting anything done for the next 40 minutes.

Re: Why Slack is inappropriate for open source communications

#235

Earlier quoted context omitted.

Lounge has a responsive view you can save to home screen on iOS and android. Looks like this: http://i.imgur.com/MmajSU1.jpg

I've seen it, but it's nothing like even Quasseldroid. And quasseldroid is already a horrible codebase (mostly because I took over maintenance when I knew nothing about code quality). Yet even Quasseldroid manages to be better. That said, there is truly a need for a really good, FLOSS irc client ob mobile.

You're saying they're nothing like each other but are providing no examples. Besides one being an app and one being a website, what are the differences? Neither quasseldroid or Lounge have push notifications or searchable messages yet, so they seem to be pretty identical feature-wise.

EDIT: and we aren't talking about code-base, are we? If so, Lounge's is pretty solid (although it is in a pretty constant state of transition from ES5 -> ES6)

Re: Why Slack is inappropriate for open source communications

#236
post #233
post #213

A great alternative to Slack, in the spirit of IRC, is matrix[1]. It has lots of clients, and a great vision. You use an online client called riot[2] which uses the matrix protocol. There are other clients available[3] including desktop clients. There's E2E encryption coming to more of the clients which is inspired from signal protocol (double ratchet part of it specifically), without Forward secrecy so as to maintai…

"in the spirit of IRC" is a bit of a stretch. This is all a massive blob of web technologies which contrasts IRC's minimalism and it's lightweight clients written in C. It doesn't appear to require any specific service though so at least it has that.

Well we are moving to a web first world, and passing the terminal days of IRC. Trying to avoid web technologies isn't going to do anyone good. Best we can do is try to make them better are secure. Light weight clients can be written in C if you want. There's nothing that needs a web browser

Here's the spec if you're interested[1].

There's also a weechat script if you want a command line client[2]

[1]: https://matrix.org/docs/spec/

[2]: https://matrix.org/docs/projects/client/weechat.html

Re: Why Slack is inappropriate for open source communications

#237

What drives me nuts is that there are so many of these things. I know groups that (for business or pleasure) use Slack, Discord, Skype, Google Hangouts, IRC, etc. All of these clients are a bit more obstrusive than they need to be in terms of pop-up notifications, software updates, cpu, memory, transfer, etc. They all screw up enough that there's always a little apprehension that something will go wrong when you get…

I just use Franz: http://meetfranz.com/

https://xkcd.com/927/

Re: Why Slack is inappropriate for open source communications

#238
post #233
post #213

A great alternative to Slack, in the spirit of IRC, is matrix[1]. It has lots of clients, and a great vision. You use an online client called riot[2] which uses the matrix protocol. There are other clients available[3] including desktop clients. There's E2E encryption coming to more of the clients which is inspired from signal protocol (double ratchet part of it specifically), without Forward secrecy so as to maintai…

"in the spirit of IRC" is a bit of a stretch. This is all a massive blob of web technologies which contrasts IRC's minimalism and it's lightweight clients written in C. It doesn't appear to require any specific service though so at least it has that.

"Web technologies" makes it sound like it requires WebRTC or something. It's a set of HTTPS endpoints that you shove JSON-encoded messages at. Certainly a bit "fluffier" than IRC (no prefix-length binary protocols here, sadly), but much more interoperable in the modern world (i.e. you can write a browser extension that can speak directly to a Matrix server using the built-in JSON+AJAX APIs; Matrix servers won't need specific egress exceptions in enterprise firewalls; etc.)

HTTP2 (if used) already makes the metadata parts of the protocol pretty concise and low-overhead; it's just the messages themselves that are large. So it'd be nice if—at least for the message bodies—there was an optional binary layer-6 encoding (e.g. CBOR, BERT-RPC) that clients and servers could try to negotiate with their Accept headers, with an expectation that many servers would implement it, and an allowance for constrained clients that implement that encoding but not JSON.

Re: Why Slack is inappropriate for open source communications

#240
post #213

A great alternative to Slack, in the spirit of IRC, is matrix[1]. It has lots of clients, and a great vision. You use an online client called riot[2] which uses the matrix protocol. There are other clients available[3] including desktop clients. There's E2E encryption coming to more of the clients which is inspired from signal protocol (double ratchet part of it specifically), without Forward secrecy so as to maintai…

> A great alternative to Slack, in the spirit of IRC, is matrix[1]

Does it have Android and iOS clients?

If not, it's not a great alternative to Slack. It's not even an alternative to Slack.

Post reply on HN