I have had good experience communication with the Aurelia.js community using Gitter. I strongly recommend it.
Why Slack is inappropriate for open source communications
71–80 of 536 posts
Re: Why Slack is inappropriate for open source communications
#72Earlier quoted context omitted.
IRC and mailing lists have worked for 20? 30? years and continue to work today.
Well, then we can all turn off our computers and go home, because something that "works" is obviously good enough and the entire software industry doesn't need to exist anymore. Most things we have today "work" but we're still improving on them because "good enough" isn't good enough.
The question you're not asking is whether your replacement is better than the existing solutions. Slack isn't. It's closed source, proprietary, and tied to a third party's servers. I'm not going to tie my projects or company to that kind of anchor.
Re: Why Slack is inappropriate for open source communications
#73Does Slack's terms of use forbidden creating an off platform archive? If not, given that searchable archives are one of the ways Slack makes money, makes me wonder why there's not an open source way to pull the chats and archive them in a way that's cheaper and independent of Slack.
Yes, but chat logs are logs of ... chat. By nature, it's disorganised, free-wheeling, contains lots of casual meandering (as any conversation would). Not very useful to a third party.
How often do you find solutions in public archived mailing list posts when Googling problems? I imagine often. While some e-mails are more terse than others, fundamentally e-mail list posts demand a certain structure. Can you imagine having to pour through a 25-page chat log instead?
And with that, the entire idea of "search the archives before asking a question" would go to pot.
Re: Why Slack is inappropriate for open source communications
#74Earlier quoted context omitted.
> It just has a good interface But this is such a big deal. You make it sound like a good interface is trivial. It isn't, and it makes a huge difference.
irssi is a significantly better interface than any slack application.
Slack's users would disagree.
Re: Why Slack is inappropriate for open source communications
#75Forums work better.
Using IRC/Slack in place of forums is like using a wiki in place of real documentation.
Re: Why Slack is inappropriate for open source communications
#76I don't know why didn't just evolve irc. Feature wise slack doesn't really bring much new. It just has a good interface. If someone made an irc client as easy to use as slack then we'd have our answer.
Because adding a feature to a standard means you have to get everyone on board. Slack as an IRC client would basically be Slack as it is now, and the server protocol would be an implementation detail.
Except, we got everyone on board. Every major client and server dev, every major bot dev and every major network.
Check out ircv3.net
Re: Why Slack is inappropriate for open source communications
#77Earlier quoted context omitted.
Slack chat provides a number of nice features that IRC (at least out of the box... I know there have been attempts) does not. IRCCloud at least lets you see chat history, which IRC doesn't have out of the box but Slack does.
So get a better IRC client? Really not hard to do things like syntax formatting and auto link follow (GUI versions of IRCII had plugins for this in the late 90s, so it's not like it's even a novel idea).
IRC as a protocol is very outdated. If I log in at home and forgot out log out at work, I need another username.
IRCv3 has a lot of enhancements that should move IRC out of the 1990s as far as a communication protocol, but there's not a whole lot of movement on it. I think FreeNode has some v3 support.
We don't have a lot of developers dedicating time to this. I'd love to myself, because it's something the OSS community needs, but it's also very difficult to contribute to projects when you're already doing 40 hours a week at a day job.
Today I feel like most of the OSS projects that are getting support are ones that are corporately supported:
http://penguindreams.org/blog/the-philosophy-of-open-source-...
Re: Why Slack is inappropriate for open source communications
#78I must've missed the memo which says any conversation around the globe is waiting for my input before it proceeds.
Well put. But you may have missed the memo because you're in the wrong time zone, and with Slack, your possibly-relevant input is ignored because you can't participate in real time. This is my beef with chat. As the OP says, it biases all conversation to those in the same time zone. Fine for some things (like baked goods arriving in some far-off kitchen), but not for others (like a design decision that should have in…
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 difficult for newcomers.
Re: Why Slack is inappropriate for open source communications
#79Mattermost is an open source alternative to Slack btw. And Discourse is pretty great, though much more like a forum.
We have been using http://rocket.chat at work and it works beautifully. Slack was never an option for it was not self-hostable
Re: Why Slack is inappropriate for open source communications
#80Earlier quoted context omitted.
Just run your IRC client in screen/tmux like we've done for a quarter century. 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... Also integrations in general are smoother in slack than in IRC. Someone has already written the bot and its a click away to install and it gen…
> 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…
This is the first I've heard of an IRC bouncer. That's a great idea. It still seems like it's and extra step you have to add though, when really it'd be nice to see some work on IRCv3 so you could have multiple clients connect to one IRC server with the same username and sync without the need of a proxy.