Live data from Hacker News

Why Slack is inappropriate for open source communications

dave.cheney.net

441–450 of 536 posts

Re: Why Slack is inappropriate for open source communications

#441
post #440
post #438

Earlier quoted context omitted.

Can you clarify what you are driving at with these questions? First off, a lot of people prefer hosted source repositories other than github (e.g. hub.darcs.net, gitlab.com, My Own Private Server). Github naturally imposes various limitations on their "free" plans.

I'm not getting at anything. I'm genuinely curious. Personally, I self-host everything on my personal www homepage. If I did not self-host everything, I assume I would put it up on github, right ?

At the risk of prolonging a pointless line of discussion: what does github have to do with anything in this context?

Re: Why Slack is inappropriate for open source communications

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

Yeah but no one seems to be making anything but web apps. I guess I come from a time just before this but I honestly can't understand how people think these things are better than their native counterparts.

Re: Why Slack is inappropriate for open source communications

#443

Mailing lists really are preferable for a number of reasons but unfortunately Google Groups or worse, mailman is the interface, and they're both pretty bad.

> Mailing lists really are preferable for a number of reasons What reasons?

The biggest reason is that it's asynchronous. Not everything needs an answer right now this instant, and in order for there to be an instant reply, someone has to be on the other end of the keyboard and continual interruption is a way to get nothing done real fast.

Re: Why Slack is inappropriate for open source communications

#444

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…

Potential solutions: Urbit, Maidsafe

Re: Why Slack is inappropriate for open source communications

#445
post #429

Mailing lists really are preferable for a number of reasons but unfortunately Google Groups or worse, mailman is the interface, and they're both pretty bad.

"Mailing lists really are preferable for a number of reasons but unfortunately Google Groups or worse, mailman is the interface, and they're both pretty bad." How in the world would you improve mailman ? Not enough js for you ? Not enough on-hover events ? Too much plain text and obvious links ? Please, please - to everyone reading this today and into the future - do not fix mailman . Go "fix" something else.

Well, not emailing me a password in the clear once a month would be a start. Needing yet another username and password for a site they already has its own some sort user login system is another wart that is easy enough to solve, but for some reason or another, hasn't been fixed on any sites in recent memory.

My email address was already validated with main site sign up, I shouldn't need to repeat that for every mailing list I want to subscribe to on top of that.

If you're reading this from the future, please let me know if any open federated systems managed to come into being, or if spammers finally managed to kill off email so important business is conducted via Snapchat.

Re: Why Slack is inappropriate for open source communications

#446

Earlier quoted context omitted.

forbid creating an off platform archive I'm not sure that's a substantively enforceable idea. Just try and stop me?

Break the terms of service, and you'll be booted off. Be a large enough problem, as they see it, and you'll get the entire project booted off. Probably they don't care enough to enforce, but surely you see it's part of the problem that they could?

Right, but they do still permit the capacity to read accessible history, which is open to scraping and archiving. They can't completely kill the concept of doing that, realistically.

They can't stop someone from creating an archive that's inaccessible to them, if they don't know of its existense. Anyone can create an archive of something they can read and hide it, and selectively share it.

Such an agreement on curtails specific forms of automated crawling and public-facing archives.

Re: Why Slack is inappropriate for open source communications

#447

I am the lead developer of Zulip (zulip.org), an open source Slack alternative built around a better threading model. I strongly agree with both criticisms of using Slack for open source, and I am impressed that Dave wrote this post, given that some of those criticisms apply to his own product. However, I think the proposed solution of relying on mailing lists, issue trackers, and forums is the wrong solution. Suppor…

The threading model in Zulip is genius. It's the perfect marriage between instant messaging and email.

Other things I like about it:

- e-mail addresses in addition to nicknames

- working full text search over everything

- plenty of well thought out keyboard shortcuts

- high quality production tooling (they even have Nagios checks, out of the box!)

Re: Why Slack is inappropriate for open source communications

#448
> This means that the content inside those systems is closed. I cannot link to a discussion in a Slack channel in a tweet.

Such a shame that you can't make a link in one closed system to another closed system.

> The tools that fit this requirement best are; mailing list, issue trackers, and forums.

Mailing lists suck. They're hard to read, hard to follow, and create an endless supply of unresolved issues that everyone forgets about. Big projects using mailing lists seem to do so out of inertia rather than choice.

Re: Why Slack is inappropriate for open source communications

#449

Earlier quoted context omitted.

I'm not sure it's fair to call it a massive blob of web technologies (although I'm biased, given I work on it). To compare sending a message on IRC versus sending one on Matrix: $ telnet irc.freenode.net 6667 ... NICK Ara4n USER Ara4n Ara4n irc.freenode.net :Matthew Hodgson ... JOIN #matrix PRIVMSG #matrix :test versus: curl "https://matrix.org/_matrix/client/r0/rooms/!cURbafjkfsMDVwdRDQ%3Amatrix.org/send/m.room.mess…

(that said, I think the point of Dave Cheney's article is more that sync realtime chat is bad for FOSS collaboration relative to mailing lists and forums. So until Matrix finally lands threading & forum semantics and smtp/nntp bridges, I suspect it's part of the problem he's complaining about :D)

Threading I know is being worked on, but is SMTP/NNTP anything other than a jape?

Re: Why Slack is inappropriate for open source communications

#450

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…

I think slack calls them gateways, not bridges. And if you compare to matrix bridges, gateway seems like a suitable name.
Post reply on HN