Earlier quoted context omitted.
How many open source slack alternatives before someone writes one that actually utilizes the IRC protocol? Is there a defensible argument against using IRC?
The IRC protocol isn't pretty, and there are plenty of incompatible server implementations, but if you're controlling both the server end and the client end it's certainly where I'd start. My first thought when I saw Slack was "someone did a pretty web irc client finally, cool" (I have no idea if they use irc internally? but it seemed such a direct match)
Mattermost: Open-source, on-premises, Slack alternative
21–30 of 222 posts
Re: Mattermost: Open-source, on-premises, Slack alternative
#22One thing I really like and appreciate is that there's a dockerfile right in the root of the project, which makes spinning up a container a relatively nice experience... haven't run it or looked into the code though... that just struck out at me... Looking at the dockerfile, it seems pretty big, and it also strikes me slightly that they have dependencies on node, ruby and go, along with mysql and redis. The UI appear…
The way it's done now makes it inherently unscalable. Also, there are so many steps that it makes pushing an image to a Docker repository a massive pain.
Re: Mattermost: Open-source, on-premises, Slack alternative
#23One thing I really like and appreciate is that there's a dockerfile right in the root of the project, which makes spinning up a container a relatively nice experience... haven't run it or looked into the code though... that just struck out at me... Looking at the dockerfile, it seems pretty big, and it also strikes me slightly that they have dependencies on node, ruby and go, along with mysql and redis. The UI appear…
Re: Mattermost: Open-source, on-premises, Slack alternative
#24I don't really get why there is so many Slack alternatives coming up these days. On every post like this there is tons of comment linking to other Slack alternatives, it's not like this is gonna be _the_ Slack-alternative. Here is a non exhaustive list : RocketChat : https://news.ycombinator.com/item?id=9624737 Let's Chat : https://news.ycombinator.com/item?id=9040841 Friends : https://news.ycombinator.com/item?id=94…
Re: Mattermost: Open-source, on-premises, Slack alternative
#25I don't really get why there is so many Slack alternatives coming up these days. On every post like this there is tons of comment linking to other Slack alternatives, it's not like this is gonna be _the_ Slack-alternative. Here is a non exhaustive list : RocketChat : https://news.ycombinator.com/item?id=9624737 Let's Chat : https://news.ycombinator.com/item?id=9040841 Friends : https://news.ycombinator.com/item?id=94…
Does anyone know if these or any others have native desktop and/or mobile clients?
Re: Mattermost: Open-source, on-premises, Slack alternative
#26One thing I really like and appreciate is that there's a dockerfile right in the root of the project, which makes spinning up a container a relatively nice experience... haven't run it or looked into the code though... that just struck out at me... Looking at the dockerfile, it seems pretty big, and it also strikes me slightly that they have dependencies on node, ruby and go, along with mysql and redis. The UI appear…
I definitely appreciate projects having Dockerfiles included, but yeah, that's not a good one. They should simply include instructions about how to link it to MySQL/Redis, or use something like docker-compose. The way it's done now makes it inherently unscalable. Also, there are so many steps that it makes pushing an image to a Docker repository a massive pain.
Re: Mattermost: Open-source, on-premises, Slack alternative
#27One thing I really like and appreciate is that there's a dockerfile right in the root of the project, which makes spinning up a container a relatively nice experience... haven't run it or looked into the code though... that just struck out at me... Looking at the dockerfile, it seems pretty big, and it also strikes me slightly that they have dependencies on node, ruby and go, along with mysql and redis. The UI appear…
Looks like it's only being used for their scss files.
Re: Mattermost: Open-source, on-premises, Slack alternative
#28I don't really get why there is so many Slack alternatives coming up these days. On every post like this there is tons of comment linking to other Slack alternatives, it's not like this is gonna be _the_ Slack-alternative. Here is a non exhaustive list : RocketChat : https://news.ycombinator.com/item?id=9624737 Let's Chat : https://news.ycombinator.com/item?id=9040841 Friends : https://news.ycombinator.com/item?id=94…
Re: Mattermost: Open-source, on-premises, Slack alternative
#29Earlier quoted context omitted.
Why would that be a problem?
I haven't worked for a company in four years that permits the installation of AGPL software because the ramifications are still unclear and largely untested. MongoDB asserts, for example, that just using MongoDB doesn't require you to do anything, even though the license text is in clear contradiction to the assertion. I do not think MongoDB understands its own license. Chris DiBona has spoken in public about Google'…
Re: Mattermost: Open-source, on-premises, Slack alternative
#30Earlier quoted context omitted.
The IRC protocol isn't pretty, and there are plenty of incompatible server implementations, but if you're controlling both the server end and the client end it's certainly where I'd start. My first thought when I saw Slack was "someone did a pretty web irc client finally, cool" (I have no idea if they use irc internally? but it seemed such a direct match)
The IRC protocol might not be pretty, but what protocol is? HTTP? AMQP? XMPP? Protocols are not meant to be pretty, just efficient and robust enough to support the desired feature set. It's a shame that none of Slack, Hipchat, now Mattermost support IRC. They're all just IRC clones, drawing on the same ideas, just giving you a crappy (but pretty!) web interface.
And it's a pain in the neck! It means that some of the participants in the channel are not able to read what's happened while they were away. Some of them get encoding errors. The IRC people do not get the same graphical elements as everybody else. They can't use custom /-commands.
In conclusion, in order to communicate the most effectively, you have to know who's on IRC and think about the differences in user experience for these people versus everybody else.
IRC has weaknesses (namely lack of centralized logging and unspecified text encoding) and fixing these weaknesses means forgoing support for existing IRC clients.