Live data from Hacker News

Why Slack is inappropriate for open source communications

dave.cheney.net

321–330 of 536 posts

Re: Why Slack is inappropriate for open source communications

#321
post #290

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…

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.

Re: Why Slack is inappropriate for open source communications

#322

Earlier quoted context omitted.

Matrix is an extremely heavy protocol, not suitable for business use imo. Riot is really obnoxious to use and get set up, and is also extremely resource hungry. I don't think you're very familiar with chat protocols if you think it's even remotely suitable as a replacement for IRC.

Given Matrix & Riot are entirely FOSS, please do spell out its obnoxiousnesses (rant here, or file on http://github.com/vector-im/riot-web/issues ) so we and the wider community can go fix it. Agreed that Riot is too heavy; we're currently doing a performance blitz on it. In terms of Matrix itself being too heavy... we're still waiting for anyone to contribute a more efficient transport, but turns out HTTP+JSON works…

> 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.

Re: Why Slack is inappropriate for open source communications

#323
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…

Why is there not a web based IRC app?

Lounge is very good

Re: Why Slack is inappropriate for open source communications

#324
post #172

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 probably wouldnt hire a developer that didn't use IRC

Because in the skillset of developers, IRC is such a difficult one to acquire?

Re: Why Slack is inappropriate for open source communications

#325

Earlier quoted context omitted.

There's nothing inherently 'web' or 'slow' or 'ajaxy' about Gzipped-JSON-over-HTTP2. I agree that the web is slow and crap a lot of the time, but chat using gzipped JSON over HTTP/2 would be just as fast as IRC as long as it's only sending the same level of info as IRC.

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 a million different application protocols.

Because otherwise you'll get to the same place as we were with HTTP/1.1: your nice 'simple' protocol will need to be replaced with one that can support multiple streams, etc.

Re: Why Slack is inappropriate for open source communications

#326

Earlier quoted context omitted.

"log in to slack" vs. "deploy 3 services in the cloud by yourself and force everyone to use a specific irc client (good luck)" 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.

> 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.

Re: Why Slack is inappropriate for open source communications

#327

Earlier quoted context omitted.

"log in to slack" vs. "deploy 3 services in the cloud by yourself and force everyone to use a specific irc client (good luck)" 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.

> 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…

"prevents you from accessing it"

with respect to something like e-discovery its all a matter of perspective. If this were true, which it isn't, I wouldn't necessarily mind, as the financial worth of combined ancient IRC logs is unquestionably a net negative value.

Re: Why Slack is inappropriate for open source communications

#328

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 costs for an Free / open source developer haven't changed in this "new" world. Distribution of software is the same as it ever was.

I'm having a bit of cognitive dissonance trying to understand what an "open source service" is. If it's "open source", in terms of the OSI definition, your "million people" could just download and self-host it. To my mind, at least, if it can't be self-hosted it's not "open source".

If you're talking about selling access to servers running an instance of the application then you're talking about running a service bureau, not distributing software. The economics are completely different.

Re: Why Slack is inappropriate for open source communications

#330
post #13

Feel like this argument happened 5 months ago and 5 months before that too

and it needs to continue to happen until OSS communities ditch Slack.

You're never going to move large groups of people by just yelling "xxx is terrible!" You have to make something better that people want to use to get them to switch. Unfortunately, Slack is better than IRC in many ways that matter to a lot of people. Ignoring all of those things doesn't make IRC better, and it's not going to make people want to use IRC over Slack.
Post reply on HN