Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Slack is inappropriate for open source communications

dave.cheney.net

Post reply on HN
Print view View original

161–170 of 536 posts

Re: Why Slack is inappropriate for open source communications

#161

Post by djhworld »

giancarlostoro wrote: post #154
PaulHoule wrote: post #47

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/

Two questions spring to mind that are not immediately obvious from the website - how do they get access to your messages in different accounts?

Are they using some API? Or do they ask you for your username/password for each service and "helpfully" login for you?

Re: Why Slack is inappropriate for open source communications

#162

Post by CJKinni »

uiri wrote: post #132
drey08 wrote: post #81

Earlier quoted context omitted.

Just a note: if you go from free to paid, you can recover those lost messages. They're never actually deleted, you just can't view messages after the 10k limit in the free version.

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) ?

I doubt it's a bandwidth issue. It's probably that they have to keep more servers/servers with more ram up to index all the messages. Keeping something on a disk that never gets read is far less expensive than keeping it in RAM and indexed so that it can be quickly and easily searched.

Re: Why Slack is inappropriate for open source communications

#163

Post by beamatronic »

PaulHoule wrote: post #47

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…

Also Hipchat

Re: Why Slack is inappropriate for open source communications

#164

Post by jay-anderson »

dade_ wrote: post #108
piquadrat wrote: post #20

Is that really happening that open source communities use Slack as their primary communications channel? I haven't seen that happening in the communities I participate in (Python/Django/...). What I do see is that more and more communities switch from IRC to Slack as the primary "sync" channel (while still maintaining mailing lists, bug trackers and the like). And as much as I hate it, the success can't be denied. Es…

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 dealing with IRC.

Re: Why Slack is inappropriate for open source communications

#165

Post by jasonjayr »

VLM wrote: post #86
kuschku wrote: post #57

Earlier quoted context omitted.

> The real advantage of slack isn't even client its stuff like massive logging for e-discovery and single sign on integration. Admittedly not terribly appealing for FOSS but once you use it at work... Which can also be done with IRC clients. This is a video of a search system I built for the Quassel IRC client: https://dl.kuschku.de/videos/2016-09-16_04-03-36.mp4 Quassel is a distributed system, so you have a bouncer…

Encapsulates this era as the battleground of silo'd "as a service" vs "can be done" For example I can have jenkins email build fails to slack in, oh, probably less than two minutes, I've done it before. From memory I make a custom email addrs in slack and tell slack which channel to feed it into, and then add that address to my jenkins that already sent buildSpam. In IRC I could do it... google implies there's a ZenI…

Jenkins has a IRC plugin, already in the stock distribution. Jenkins bot idles in channel, and logs all sorts of failures or successes, or whatever. With the irc server + channels setup, this also takes less than 2 minutes.

Re: Why Slack is inappropriate for open source communications

#166

Post by bacongobbler »

uiri wrote: post #132
drey08 wrote: post #81

Earlier quoted context omitted.

Just a note: if you go from free to paid, you can recover those lost messages. They're never actually deleted, you just can't view messages after the 10k limit in the free version.

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) ?

It's not evil nor is it about the bandwidth costs, it's just business. It's how they get you to spend money on a freemium product after you reach a certain cap. They've determined that you should pay if you're hitting the 10k messages limit.

Re: Why Slack is inappropriate for open source communications

#167

Post by throw2016 »

xfalcox wrote: post #44

Discourse offers free hosting for big Open Source projects, and you can self-host it on a $5 VPS too. Full Disclosure: I work at Discourse.

I doubt Discourse will run on a $5 VPS. The last time I checked its crashes on 512MB RAM, needs at least 1GB just to start. Have the minimum requirements changed? 1GB minimum and 2GB is recommended by Discourse itself.

Discourse is also not easy to setup, its quite involved and complex and you need some Ruby and systems expertise. Infact I think Discourse only supports Docker installs. So you need to know Docker too.

Given the complexity you should be pretty comfortable with Ruby to run it with any amount of confidence. The hosted option seems much better than trying to run it yourself.

Re: Why Slack is inappropriate for open source communications

#168

Post by LeifCarrotson »

AsyncAwait wrote: post #151
27182818284 wrote: post #58

Earlier quoted context omitted.

>It is one thing to deal with one of these things, but when you have to install ten to get The modern office large office is pretty bad in this respect. Really not uncommon to see things like • Need to have Slack open • Need to keep an eye on Basecamp/pm software • Need to have Outlook open / check in on for email and calendar invites • Need Skype open because not everyone uses Slack • GitLab is open in another tab I…

As a freelancer, I have EXACTLY this problem, so I started hacking away on my own solution. Don't want to shamelessly promote myself here, but if you're interested, link is in my profile.

A few comments that I hope are constructive. Looking at your page, I'm not confident you're avoiding the issue by which these tools proliferate:

https://xkcd.com/927/

Your users and their clients are still going to be using Slack and email, but it seems like you're giving me one more thing to log into. You write:

> Schedule your time spent and group distracting reminders and notifications in one place

If this "one place" is a separate silo from Slack, Outlook, Basecamp, Skype, SMS, Discord, Hipchat, IRC, and Github...it's not the one place I'll need to check. It's the n+1th place.

Now, if I can put my credentials into Calmbird (securely would be nice, but you can have the plaintext if you can make this insanity stop) and have it do the API connection to - or, if necessary, the nasty DOM-manipulation, Windows message hacking, and client-impersonating - to put all these services and their notifications in one place, that would be a solution to the proliferation problem.

Also:

> schedule automatic emails to your clients with updates

My clients don't want automatic emails, especially from templates/digests. They want me to hand-craft them as if it was the most important thing in my life. And while they can understand a curt update message or a missed daily status notification, the real point of these updates are to confirm that I'm still on the project. If a message accidentally went out with a placeholder like "I'm still working on {todo-insert-task-here}", and I didn't know about it, that would be...bad.

Re: Why Slack is inappropriate for open source communications

#169

Post by scrollaway »

uiri wrote: post #152
scrollaway wrote: post #103

Earlier quoted context omitted.

Nobody changes clients if Slack disappears and is replaced by another webapp. It's all in browser. The UI might change, but the UI also changes when you go from a Mac IRC client to a Windows one, which doesn't happen with web apps. I say this as someone who's used IRC a crapton and is a strong advocate for open protocols (and for more than just ideological reasons): Realistically , if Freenode disappears, IRC will mo…

If Freenode disappears, people will join Debian over on OFTC. I'm not sure if Mozilla and GNU/FSF use Freenode or run their own infrastructure but if the former, then they may set up their own network(s). Other IRC networks than Freenode and OFTC exist too. As far as security goes, SSL is an option for client server connections. I hope that at this point it is default for server server connections. What else are you…

SSL is not required and it's certainly not default in most clients.

IRC won't survive the loss of Freenode. With Quakenet dying off (its userbase went from ~65k in 2013 to 23k today), Freenode is the last central bastion that keeps the protocol in people's minds.

FOSS projects today are migrating off IRC, onto Slack and Discord instead. This is why you have an article here talking about it and it's not the first one. If Freenode disappeared, this would accelerate massively. The projects won't bother going to another network because the topic of "Where do we go now?" is going to be asked and in most cases is going to be answered with "Well, we wanted to move to Slack/Discord anyway...".

There will be a few projects left on OFTC, certainly. But they'll give up and go elsewhere eventually as well when they'll see their userbase shrinking 5-10x due to other projects migrating elsewhere and taking their users with them. They'll probably end up on Matrix.

Re: Why Slack is inappropriate for open source communications

#170

Post by hehheh »

ntaylor wrote: post #11
maxxxxx wrote: post #4

Earlier quoted context omitted.

I have recently started using slack and I see the same. Once a conversation has moved on it gets awkward to move back to the previous topic.

This may be a shortcoming of the UI, more than anything else. There's definitely room for improvement here as I often miss updates to threaded conversations even as I'm looking for them.

I think they could make threads work with some simple changes:

* Optionally show thread replies in-line with chat, as they come in, just like regular chat but with some special annotation to indicate they're part of a thread.

* Allow the user to collapse a thread so they no longer see it in-line.

* Auto-close threads after they're idle for more than 1 hour (or some site-policy-configurable timespan).

* Allow the user to navigate between threads using only their keyboard.

As they are now, I think threads are bad for business. They hide useful information away and slow conversation (responses dragged out because they're no longer in your face).

Post reply on HN