Live data from Hacker News

Why Slack is inappropriate for open source communications

dave.cheney.net

171–180 of 536 posts

Re: Why Slack is inappropriate for open source communications

#171
post #159

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…

> 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. You aren't paying "someone" you're paying an entire company that is dedicated to making the application highly available, with all the bells and whistles, with zero hassle. Really, if you think IRC is so similar to Slack, then why…

> Really, if you think IRC is so similar to Slack, then why are so many companies, organizations flocking to it? There has to be a reason.

If HN has higher discussion quality than reddit, why are not all devs on HN instead? If Linux is better for servers, why are people still starting projects on Windows? etc...

The power of marketing, directly or word-of-mouth, is important. And a decentral community can never do as perfect marketing as a company can do.

There are IRC clients and apps, and third party integrations as powerful as Slack, and as easy to use. But you have to find them, install them separately – there’s no single combined effort to market a single "just works" solution, yet ;)

Re: Why Slack is inappropriate for open source communications

#172
post #108

Earlier quoted context omitted.

I was at a dev meetup for Python: I really thought he was joking when he said, what is IRC? And then I realized that we have a whole generation of devs that have no idea what IRC is or how to use it. Amazing the amount of knowledge and experience lost between a single generation.

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

Re: Why Slack is inappropriate for open source communications

#173
post #145

Earlier quoted context omitted.

How does it do this? When you use IRCCloud to go to a channel for the first time, where does IRCCloud get the history for that channel from? (You say "they're a client too" - I confess, I don't know what they are apart from a client.)

Like I was saying, IRCv3 has support for replaying the channel's history, as long as it's stored serverside. But I don't know if anything actually implements it, even IRCCloud which is v3-compatible. At the moment if you join a channel you can't read its backlog, no. They could implement it though if they used logs from their users... kinda wish they would. But hey.

> At the moment if you join a channel you can't read its backlog, no.

Then I'm not entirely sure what you were referring to, when you said "IRCCloud can". Backlog from before you joined the channel is the specific feature that I was saying couldn't be done.

It's interesting to know that IRCv3 does have that support, so I was wrong about it not being possible. But if nothing implements it, it's not very helpful.

Re: Why Slack is inappropriate for open source communications

#174
post #91
post #78

Earlier quoted context omitted.

If a group has the choice between realtime and asynchronous channels there needs to be a guideline for this. If my org takes pride in consensus for everybody, everybody needs to have the time to submit input. It's not uncommon that some active users in a chat go for an ad-hoc decision just because they are more than one and want to work _now_. In the long term this damages the culture, splits the participants and is…

I completely agree. Unfortunately, what I've seen more than once is that mgmt (or even someone from the rank-and-file) sees / experiences a new tool like Slack (or Campfire, or Hangouts, or...) and says "hey, great new tool we should use!" and that's the 'decision'. No thought given to how async comms biases development when developers are spread world-wide. I gripe because I am a US left-coaster who works with a tea…

I feel ya, it's frustrating. Although I did not yet have a problem with time zones, I experienced being left out simply by joining the chat later in the evening.

Re: Why Slack is inappropriate for open source communications

#175

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/

Or better yet, Rambox ;)

http://rambox.pro/

Re: Why Slack is inappropriate for open source communications

#176

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/

[deleted]

Re: Why Slack is inappropriate for open source communications

#177

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.

For me it's probably selfishness. I'm an infinite inboxer, who prefers synchronous communication (if any). If I need something, I'm going to walk up or call, and yet my door stays closed. So the two preferences aren't mutually exclusive, but in my experience these generally ARE different people altogether.

Re: Why Slack is inappropriate for open source communications

#178

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…

If I can't use my own client (pidgin/finch), then I'm just not going to use the chat-service. I don't mind being logged into $chat_client_of_the_week, I mind logging into all of the $chat_clients_of_last_week though.

Re: Why Slack is inappropriate for open source communications

#179
post #132

Earlier quoted context omitted.

Wow, that is kind of evil. I could understand if Slack kept, say, the last 20k or 50k and only showed the most recent 10k. For them to store all the messages indefinitely for all free servers means that they are incurring the same storage costs whether the server is free or paid. Are the bandwidth costs really that high to justify hiding all those messages (likely on the order of 100k or 1M for many servers) ?

No, they hold your data hostage because they can. Welcome to capitalism.

!? Except hostages don't know they're being kidnapped. Slack's pricing is no secret.

Re: Why Slack is inappropriate for open source communications

#180

Earlier quoted context omitted.

The problem is though, that some people like to be the local expert on IRC/Slack with all the answers. They don't want to document it elsewhere.

Fix your group's culture. Document things. If people refuse to document things, then do it for them and shove your docs in their face. Do it until they write the documentation themselves.

> Fix your group's culture.

Culture-change is about the hardest thing to achieve.

Post reply on HN