Live data from Hacker News

Why Slack is inappropriate for open source communications

dave.cheney.net

181–190 of 536 posts

Re: Why Slack is inappropriate for open source communications

#181
post #108

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 don't even know how to shoe a horse.

Re: Why Slack is inappropriate for open source communications

#182

Issue #2, that slack is based on synchronous communication, is something that is always ignored. Sometimes I log in to slack and see a conversation that I want to add something to, but it is 4 hours old with 50+ new messages on varying topics. Even with Slack's new threaded messages it is hard to evolve the conversation after all the synchronous folks have moved on to other topics.

I never used Slack, but in IRC I'd quote what the user said (a format like " message", optionally with a time) if it's really relevant; and in Telegram it's a simple matter to rightclick and reply (which allows people to click/tap it to jump back to context) which I feel much less bad about.

Re: Why Slack is inappropriate for open source communications

#183

Earlier quoted context omitted.

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

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

This isn't possible for web services due to the state of U.S. law. Speaking to a server without the consent of the server's owner is both a crime and a tort under the CFAA. There is also liability for copyright infringement, among other things.

IANAL

Re: Why Slack is inappropriate for open source communications

#185
post #152

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…

Mozilla has its own server, irc.mozilla.org, distinct from freenode.

Re: Why Slack is inappropriate for open source communications

#186

It might be more useful to speak in general terms than call out Slack in particular. The concerns expressed here aren't limited to Slack (despite the link-baity title), but any form of communication that: (a) Can't be referenced or linked from the Web, and (b) Is a form of synchronous communication The same factors, BTW, apply equally to in-person discussions held at open source conferences. I wonder what the author…

Are there any open source projects that coordinate development or provide support primarily through in-person discussions at conferences?

I don't know about "primarily", but it's certainly an important aspect overall for many projects.

Re: Why Slack is inappropriate for open source communications

#188

Earlier quoted context omitted.

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?

They pretty much wrap the website versions of the services.

Re: Why Slack is inappropriate for open source communications

#189
Many of these complaints are just as valid for any business or organization trying to function as a modern software-based org in this day and age.

You have remote workers, flexible schedules, people traveling everywhere, all doing knowledge work that depends upon sustained focus and reaching a flow state. All of which Slack and synchronous chat detract from.

Slack just happens to be easy and convenient, so orgs end up using it by default.

Obligatory link to 37 signals post on this topic: https://m.signalvnoise.com/is-group-chat-making-you-sweat-74...

Re: Why Slack is inappropriate for open source communications

#190

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.

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

Chats are much less interrupting. When someone walks in, you have to look at them (it's rude to keep typing and look at your screen), your brain starts to assess who it is and their mood and pulls into an appropriate facial expression, and you have to start listening because your audio buffer is much more volatile than your chat client's message log. Even if you're just finishing the "hope to hear from you soon" of an email, you typically have to acknowledge someone's presence and already detect who it is (someone two levels above your paygrade, you'd not want to keep waiting, while you would let a peer wait for that email to get sent out). I don't know how much of that subconscious activity really interrupts flow, but I notice it's annoying.

For chat, group messages don't trigger notifications and they just get looked at when I have a second. If someone needs me specifically, they'll mention me or send a private message. In those cases, I will notice the notification but will (depending on how concentrated I am) either not process it beyond "there's something" or not beyond judging whether it's urgent (based on the first five words, or whatever makes it into the notification). I catch myself thinking "wait, someone sent me something, I totally forgot" and it turns out there are no unread chats. What must have happened is that I alt-tabbed back and forth to make the unread-message counter go away (and give them the double tickmark to indicate I saw it) because what they sent did not need further processing (something like a final "okay"). That did not interrupt flow.

---

On top of that, what others have said: external people (at clients', at home, whatever) can follow chats along; you can do stuff in between messages; you can pick your nose during conversations; and you can have an 80 second meeting between five people.

I think an uninterrupted private office and "instant" messaging are not mutually exclusive things.

Post reply on HN