Live data from Hacker News

Why Slack is inappropriate for open source communications

dave.cheney.net

521–530 of 536 posts

Re: Why Slack is inappropriate for open source communications

#521
post #382

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…

> But if you deploy an open source service to the cloud, it's going to cost you more than a few pennies, and if a million people try to use your service you have two headaches: financial and operational. This is exactly where I am with https://landscape.io - can't keep it running for free, can't get people to pay.

I don't know anything about your market, but your plans seem awfully expensive and they're differentiated weirdly. I wouldn't choose to pay for a tool that would limit how much trend data I get based on how much I paid.

Re: Why Slack is inappropriate for open source communications

#522

Earlier quoted context omitted.

> What it implies is what people want: persistent logs, signing in from their phone logging them into the same session as signing in from their desktop, etc. Okay, to me that is the same thing as 'persistent sessions', but without belaboring the point... can IRC do those things? Right, it depends on the server and client. What servers and clients can? I think it's pretty rare, if it exists. If your answer is "well, I…

You're missing the point. This subthread is not about what IRC does do, it's about whether a chat protocol with support for persistent sessions, search, etc. can still be simple. Maybe actually read the thread next time? So don't "so what?" me. This isn't about whether IRC can do those things.

Okay, good luck convincing people not to use slack because some hypothetical thing that doesn't exist could have the features they want, while being simpler than Slack and open source. That's your point?

Re: Why Slack is inappropriate for open source communications

#523
post #373

Earlier quoted context omitted.

> * 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 clients may actually see your message truncated in different locations, based on how long their local server's name is. Well, doesn't that mean the li…

Responding to a couple points: > Well, doesn't that mean the limit is 510 characters including the command? No. The limit is on what the server sends to other clients when a message is delivered. For instance, if you send: PRIVMSG #channel :some long message the server will proceed to send everyone else in that channel something along the lines of: :your@hostmask PRIVMSG #channel :some long message which will be limi…

Re: message length, this does still sound like a limit on the implementation, and you could easily make IRC servers that have either longer messages (ircv3 has 1024) or no limit at all (although perhaps that's not a great idea)

> DCC file transfers work on a chunk-by-chunk basis. The sending client sends one block of data at a time, then waits for an acknowledgement before sending the next one. (This is why I describe it as being like TFTP.)

You're right, I was not aware of the acknowledgments. But this in previous response I said that a lot of issues could be fixed on a client side. DCC is also completely implemented with clients and similarly can be fixed this way. There apparently is already DCC XMIT standard which fixes latency caused by the ACKs (assuming our client wouldn't do same thing as Slack does which is upload files to S3 and share the URL)

Re: Why Slack is inappropriate for open source communications

#524
post #436

Earlier quoted context omitted.

If you have a nonprofit for your project, you can also get on their nonprofit plan. At https://hackclub.com we get unlimited archival without paying for this reason.

Last I checked they only offered 85% discounts for non-profit teams. Has this changed?

We're on a completely comped plan with them. Not sure if we were grandfathered or have some sort of special deal.

Re: Why Slack is inappropriate for open source communications

#525

Earlier quoted context omitted.

What you're looking for is email. Multi-user chat simulates a real life conversation, and in real conversations it's also awkward to say "hey so going back to what we were talking about 15 minutes ago..." after the conversation has moved on.

No, email is terrible. There's no history. You can't "scroll up" to see what people were talking about. You can't link to another specific email to reference it (yes, there's archive services, but then you have to go dig through an archive to try to find a horridly formatted email to link to, which is completely separate from the normal consumption platform).

You're correct, but Usenet does provide those features and is very similar to email from a user standpoint.

Re: Why Slack is inappropriate for open source communications

#526

Forums. I don't know why the internet got tired of them, even when they sometimes fit the bill so well. Slack is chat. Mailing lists are far too outdated. Forums are good, and some good people out there are still developing them.

Probably because you would need to remember what the addresses were, what your credentials were (for each forum you joined) in order to participate. Also, administrators could disrupt discussions any time they wanted or restrict people from posting in the same vein.

Usenet, on the other hand, didn't have these problems, though it pretty much ended up the same way.

Re: Why Slack is inappropriate for open source communications

#527

Forums. I don't know why the internet got tired of them, even when they sometimes fit the bill so well. Slack is chat. Mailing lists are far too outdated. Forums are good, and some good people out there are still developing them.

They're generally fucking terrible in terms of UI. I much prefer Google Groups over older forums. Discourse is even better but there's no easy way to setup a forum for free. The last time I looked into it it would be roughly $10 a month for a DigitalOcean droplet to run a small forum, but that was more than I wanted to spend myself. And accepting money is a non-zero amount of work too. Probably the main reason why Sl…

> I much prefer Google Groups over older forums.

Interestingly enough, most people I know found the Google groups interface significantly worse compared to their Usenet client.

Re: Why Slack is inappropriate for open source communications

#528
post #427

Forums. I don't know why the internet got tired of them, even when they sometimes fit the bill so well. Slack is chat. Mailing lists are far too outdated. Forums are good, and some good people out there are still developing them.

Forums. I don't know why the internet got tired of them I have recently been participating on Reddit and I still like HN, but I am spending less time of late on another forum I still belong to. For me, part of the answer is that forums are heavily influenced by moderators and most of them are not anywhere near as good as what you see on HN. So, if you have personal friction with the mods, good luck with that! The int…

> the [forum] admin structure very often gets you stuck in "I shot the sheriff" * hell, where no matter what you fucking do, some asshole who doesn't like you and is in charge rides your goddamn case and deletes your shit for bs reasons and so on.

That's why I preferred Usenet over forums. All filtering is done by the client and is under your sole control (outside of moderated groups).

Re: Why Slack is inappropriate for open source communications

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

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

Gmane actually works really well at addressing the problems you describe in terms history. Their NNTP gateway allowed me to download and search the git mailing list messages since 2009 in my email/news client.

Re: Why Slack is inappropriate for open source communications

#530

Earlier quoted context omitted.

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

> Slack, fortunately, has bridges built in for IRC and XMPP clients, so I can use my already working clients

Unfortunately, the Slack gateway implementation is subpar. In my experience, it will send me the last message I sent before I disconnected when I reconnect, but it won't send any of the other messages that were sent in the meantime. The other problem is that group chat only works over the IRC gateway, not the XMPP one (at least I could join it from my XMPP client, but I couldn't send any messages to it).

In contrast, the old XMPP server we used would just replay messages in group chat when you reconnected, so at least you wouldn't miss anything when you weren't connected.

Edit: s/Slack implementation/the Slack gateway implementation/

Post reply on HN