Slack's bait and switch(opkode.com)
opkode.com
Slack's bait and switch
https://opkode.com/blog/slacks-bait-and-switch/
359 comments
Okay, I'll take the bait. I'm about as good a representative sample of the people you're talking about as anyone else.
I'm 39. I've been in technology in a professional capacity for 22 years, longer now than perhaps a few folks on HN have been alive. I wrote my first computer programs over 30 years ago, started online with local BBSs and then eWorld and then the internet.
I've seen a lot of stuff come and go. The tech industry as a whole has, over the last decade, adopted an especially frenzied pace that looks an awful lot like someone lost in the woods, freaking out, running in different directions trying to figure out where they've been and where they're supposed to be going.
There's nobody I can wag a finger at and say, "see, you didn't learn the last time 'round", because with a constant influx of new people, there's always a big group of folks that will adopt the latest thing because it's the latest thing, and have no memory of the last 30 years of latest things, and haven't been stung before when the latest thing fizzles out and takes a chunk of your time or infrastructure investment along with it.
Slack had advantages, sure. But it's hardly the first time that some service has come along and offered advantages over the tired old thing -- all except for a public, common protocol -- and then decided to take their ball and go home and to hell with everyone else. My staid desire for things being built on open protocols and available to people who want to self-host it doesn't come from some hardnosed ideology, it comes from years of, "oh no, this shit again."
Unfortunately, comments like yours tend to dismissively shout down the comments from the been-there-done-that folks, and so we're locked in a particularly self-defeating Eternal September that's costing the tech industry an incalculable amount of money.
In my more cynical moments, I wonder if a cadre of old farts oughtta start getting together and giving the less experienced folks the advice they want to hear, just to see how long it takes them to catch on: "building infrastructure out of walled gardens is a good idea, because they are commercial businesses and will be able to offer you more features than the slow-moving open source alternatives that haven't changed much in a long time".
I'm 39. I've been in technology in a professional capacity for 22 years, longer now than perhaps a few folks on HN have been alive. I wrote my first computer programs over 30 years ago, started online with local BBSs and then eWorld and then the internet.
I've seen a lot of stuff come and go. The tech industry as a whole has, over the last decade, adopted an especially frenzied pace that looks an awful lot like someone lost in the woods, freaking out, running in different directions trying to figure out where they've been and where they're supposed to be going.
There's nobody I can wag a finger at and say, "see, you didn't learn the last time 'round", because with a constant influx of new people, there's always a big group of folks that will adopt the latest thing because it's the latest thing, and have no memory of the last 30 years of latest things, and haven't been stung before when the latest thing fizzles out and takes a chunk of your time or infrastructure investment along with it.
Slack had advantages, sure. But it's hardly the first time that some service has come along and offered advantages over the tired old thing -- all except for a public, common protocol -- and then decided to take their ball and go home and to hell with everyone else. My staid desire for things being built on open protocols and available to people who want to self-host it doesn't come from some hardnosed ideology, it comes from years of, "oh no, this shit again."
Unfortunately, comments like yours tend to dismissively shout down the comments from the been-there-done-that folks, and so we're locked in a particularly self-defeating Eternal September that's costing the tech industry an incalculable amount of money.
In my more cynical moments, I wonder if a cadre of old farts oughtta start getting together and giving the less experienced folks the advice they want to hear, just to see how long it takes them to catch on: "building infrastructure out of walled gardens is a good idea, because they are commercial businesses and will be able to offer you more features than the slow-moving open source alternatives that haven't changed much in a long time".
>Okay, I'll take the bait. I'm about as good a representative sample of the people you're talking about as anyone else.
This starts off strong, but then ...
>I'm 39. I've been in technology in a professional capacity for 22 years, longer now than perhaps a few folks on HN have been alive. I wrote my first computer programs over 30 years ago, started online with local BBSs and then eWorld and then the internet.
If I were typing this in slack, this is where the first :facepalm: emoji would appear.
This is the mentality that caused the now-semi-famous HN post in the early days of dropbox, arguing that it was useless because with a combination of [ simple CLI tools that nontechnical people have never even heard of ], you could create the "same" functionality.
Say it with me: Being so simple that utterly nontechnical people can use (edit: not just 'use', but 'deploy and administer') IS important functionality. That's what made Dropbox, and it's what's made Slack. You don't have to be an IT pro to deploy it successfully. You don't have to be a programmer. You just click half a dozen buttons, all of which are helpfully color coded so that your unwillingness to read any text on the screen won't be an obstacle.
Yes, there are things you lose when you "build infrastructure out of walled gardens" -- but the reason some people prefer cathedrals vs bazaars is that they often have much lower barriers to entry, and for many people that is a worthwhile tradeoff.
This starts off strong, but then ...
>I'm 39. I've been in technology in a professional capacity for 22 years, longer now than perhaps a few folks on HN have been alive. I wrote my first computer programs over 30 years ago, started online with local BBSs and then eWorld and then the internet.
If I were typing this in slack, this is where the first :facepalm: emoji would appear.
This is the mentality that caused the now-semi-famous HN post in the early days of dropbox, arguing that it was useless because with a combination of [ simple CLI tools that nontechnical people have never even heard of ], you could create the "same" functionality.
Say it with me: Being so simple that utterly nontechnical people can use (edit: not just 'use', but 'deploy and administer') IS important functionality. That's what made Dropbox, and it's what's made Slack. You don't have to be an IT pro to deploy it successfully. You don't have to be a programmer. You just click half a dozen buttons, all of which are helpfully color coded so that your unwillingness to read any text on the screen won't be an obstacle.
Yes, there are things you lose when you "build infrastructure out of walled gardens" -- but the reason some people prefer cathedrals vs bazaars is that they often have much lower barriers to entry, and for many people that is a worthwhile tradeoff.
What mentality are you talking about? That so-called falepalm-worthy quote is just them describing their experience. You're reading way too much into this.
> the reason some people prefer cathedrals vs bazaars is that they often have much lower barriers to entry
There's nothing inherit about these "cathedrals" that require them to be walled gardens. Slack could have been an open protocol, but they decided not to be.
> the reason some people prefer cathedrals vs bazaars is that they often have much lower barriers to entry
There's nothing inherit about these "cathedrals" that require them to be walled gardens. Slack could have been an open protocol, but they decided not to be.
Just curious, don't you think it'd be much harder to justify their valuation if it's just an open protocol?
Yes, I do think so. But I also think fundamental functionality like team chat should be a solved problem by now, and shouldn't be so concentrated to a single company.
Obviously, having a captive userbase to extract revenue from is good for their valuation. It probably isn't so great for the users though.
Also allows them to invest more in the product, which is great for the users
Which is why they fixed their resource hog of a client right?
By no means am I calling the product perfect. Resource hogging is an issue that is particularly important to most HN users.
But would you say that they're _not_ investing in the product? They're improving on search, their API, adding new integrations with Github, etc. Those might not be the things that matter the most to you or other HN users, but they are investments in the product.
But would you say that they're _not_ investing in the product? They're improving on search, their API, adding new integrations with Github, etc. Those might not be the things that matter the most to you or other HN users, but they are investments in the product.
> There's nothing inherit
nit: inherent.
nit: inherent.
> This is the mentality that caused the now-semi-famous HN post in the early days of dropbox, arguing that it was useless because with a combination of [ simple CLI tools that nontechnical people have never even heard of ], you could create the "same" functionality.
That's a strawman - no one said dropbox was useless to everyone: this is not about how simple it is to replicate the functionality, but who controls the data. The point gp was raising is that surrendering control your data to a 3rd party company has costs most people do not consider until it's too late - and this happens time and again ("oh no, this shit again"). How many stories have you read about downtime, account bans/freezes, and companies winding down or sold with little or no notice and no way to retrieve your data? Is it a worthy tradeoff for a shiny UI?
That's a strawman - no one said dropbox was useless to everyone: this is not about how simple it is to replicate the functionality, but who controls the data. The point gp was raising is that surrendering control your data to a 3rd party company has costs most people do not consider until it's too late - and this happens time and again ("oh no, this shit again"). How many stories have you read about downtime, account bans/freezes, and companies winding down or sold with little or no notice and no way to retrieve your data? Is it a worthy tradeoff for a shiny UI?
Exactly, thank you. I wasn't FWIW one of the folks on HN who responded to Dropbox with "but rsync...". (And I was on HN when it debuted!) I did express concern about the privacy and security implications of storing sensitive information with them, and if I remember right, they did have a partial breach early on.
But, they handled it well and they've never screwed over their users and they have partially resolved the long-standing file transfer problem (https://xkcd.com/949/).
So I still have those concerns, but overall it's a great service and I've recommended it to a few folks over the years.
It helps also that there are some open alternatives on the scene now, so if you make Dropbox some critical part of your infrastructure, it's feasible to switch to something else if Dropbox suddenly decides they want to focus only on the smartphone market.
Slack had the ease-of-use and feature advantages -- which I acknowledged -- but it was too young and there were no open alternatives that matched it feature-for-feature. That made it dangerous to rely on too much. i.e., I'd still use it, but I wouldn't make it the de facto communication system for a company.
But, they handled it well and they've never screwed over their users and they have partially resolved the long-standing file transfer problem (https://xkcd.com/949/).
So I still have those concerns, but overall it's a great service and I've recommended it to a few folks over the years.
It helps also that there are some open alternatives on the scene now, so if you make Dropbox some critical part of your infrastructure, it's feasible to switch to something else if Dropbox suddenly decides they want to focus only on the smartphone market.
Slack had the ease-of-use and feature advantages -- which I acknowledged -- but it was too young and there were no open alternatives that matched it feature-for-feature. That made it dangerous to rely on too much. i.e., I'd still use it, but I wouldn't make it the de facto communication system for a company.
First off, thanks for the reply. I've been going through a bit of deja-vu myself with this. While I came to the "game" quite a bit later than you, I've been stung by the google and facebook xmpp stunts and so I never bought into slack as some sort of new solution to communication "because you can just log in from IRC."
So yes, a bunch of "old farts" are a good a necessary corrective in our hype-driven environment. I agree with the assessment that slack is just another walled garden and comes with all the problems those bring. I even agree with the "open protocol, optionally self-hosted" conclusion. I just don't like the conclusion (not explicitely stated by you, but definitely by others) that that open protocol should be IRC and email, and that the UI for them needs to be pure text.
Put a bit shorter: the people have chosen between $SLACK over $OLD_STUFF, so if you want to use something open and still sway them then you'll have to change what's on offer vs slack.
Converse.js looks like a prime example of doing just that, as does e.g. conversations. I'd much rather we get our shit together and build jabber into something usable and beautiful than go back to IRC and email.
So yes, a bunch of "old farts" are a good a necessary corrective in our hype-driven environment. I agree with the assessment that slack is just another walled garden and comes with all the problems those bring. I even agree with the "open protocol, optionally self-hosted" conclusion. I just don't like the conclusion (not explicitely stated by you, but definitely by others) that that open protocol should be IRC and email, and that the UI for them needs to be pure text.
Put a bit shorter: the people have chosen between $SLACK over $OLD_STUFF, so if you want to use something open and still sway them then you'll have to change what's on offer vs slack.
Converse.js looks like a prime example of doing just that, as does e.g. conversations. I'd much rather we get our shit together and build jabber into something usable and beautiful than go back to IRC and email.
> I just don't like the conclusion (not explicitely stated by you, but definitely by others) that that open protocol should be IRC and email, and that the UI for them needs to be pure text.
I work with a guy like that. I've got a lot of respect for him, but yes, his approach to things causes a lot of headaches for other techs in the company. (He likes to send config files by email ... inline, after gzipping and base64-ing them.)
There's a middleground. If more people tried harder to rely on software they could truly own, vs SaaS, it would force more companies to release open source APIs and libraries and all but the crankiest old farts would shut up.
I like things to be easy too, but not so much when it bites me in the ass later.
Your suggestion for extending jabber seems reasonable.
I work with a guy like that. I've got a lot of respect for him, but yes, his approach to things causes a lot of headaches for other techs in the company. (He likes to send config files by email ... inline, after gzipping and base64-ing them.)
There's a middleground. If more people tried harder to rely on software they could truly own, vs SaaS, it would force more companies to release open source APIs and libraries and all but the crankiest old farts would shut up.
I like things to be easy too, but not so much when it bites me in the ass later.
Your suggestion for extending jabber seems reasonable.
I'm an older fart than you and as my remaining years drift away I just want to get things done and Slack helps with that like irc never did. Despite running Linux at home, I also like Jira, Confluence and MS Project at work for the same reasons.
Year of the Linux desktop never happened, KDE semantic desktop never happened, Python in Chrome never happened, Self never took off, Lisp never took off, we're still writing coffee like we did in the 90s. Nothing happened as much as we hoped it would and we have to just go with what we've got.
This year I'm dropping Linux at gone and going to Windows, after 15 years.
Year of the Linux desktop never happened, KDE semantic desktop never happened, Python in Chrome never happened, Self never took off, Lisp never took off, we're still writing coffee like we did in the 90s. Nothing happened as much as we hoped it would and we have to just go with what we've got.
This year I'm dropping Linux at gone and going to Windows, after 15 years.
> This year I'm dropping Linux at gone and going to Windows, after 15 years.
Kinda funny since I feel like windows is taking more and more weird turns since windows 8 regarding UX, UI consistence etc. From win 95 to win 7 it mostly felt like consistent evolution, but now it seems they tried to modernize different parts of the OS over night and none of the designers and devs involved were allowed to talk to each other.
I think the "fuck it I'm old, don't care anymore, just want it to work and look nice" goto solution is still the Mac, even in 2018, even after all those recent os x mess ups (I'm old, don't care, etc., get it?)
Kinda funny since I feel like windows is taking more and more weird turns since windows 8 regarding UX, UI consistence etc. From win 95 to win 7 it mostly felt like consistent evolution, but now it seems they tried to modernize different parts of the OS over night and none of the designers and devs involved were allowed to talk to each other.
I think the "fuck it I'm old, don't care anymore, just want it to work and look nice" goto solution is still the Mac, even in 2018, even after all those recent os x mess ups (I'm old, don't care, etc., get it?)
Apart from Jira and Confluence, Atlassian also has a team communication product called Stride, which is free to used under certain plans. Are there any advantages to using Slack over Stride? I've heard a lot of people complain how Slack is Electron based and a resource hog.
Mainly the ecosystem effect. Lots of integrations are slack only for quite a while. Not sure if hipchat integrations are compatible w/ stride or not.
It totally is a hog; but most of all you miss the tight integration with Jira/Confluence offered by Stride. But then Slack is a cool so it has that going for it
slack's desktop client is electron based, and while people may bitch about it they don't actually have to use it. the web ui (which is just shoved in an electron wrapper for the desktop client) lacks a few of the desktop features but nothing major. it's pretty usable for anyone who hates electron.
The thing is, no one is arguing that propietary and closed is better than public and open. The problem comes when propietary and closed become the "better" option to the masses (faster, easier to use, more user friendly, more available, etc); at that point, you can protest, but average users don't like to give up convenience for ideology, hence on the long run the only way to beat closed and propietary is to have something public and open that can compete.
> The tech industry as a whole has, over the last decade, adopted an especially frenzied pace that looks an awful lot like someone lost in the woods, freaking out, running in different directions trying to figure out where they've been and where they're supposed to be going.
I think there's a simpler explanation: people are trying to find new business models. The old model of individuals paying tens or hundreds of dollars for software is slowly dying, and it's on full display in the iOS app store where even $5 is perceived to be a lot to charge for an app. So we need new models. The rise of SaaS is tied to that shift. in-app purchases and related psychological shenanigans are related to that shift.
The SV elders, like Peter Thiel of Palantir, now more than ever seem to favor rent-seeking business models and started selecting for those businesses 5 years ago. To course-correct, someone in technology will have to discover a new business model. I'm personally betting that we'll see a backlash and new models wherein people pay so there is no chance of data harvesting (going back from SaaS to standalone software)
I think there's a simpler explanation: people are trying to find new business models. The old model of individuals paying tens or hundreds of dollars for software is slowly dying, and it's on full display in the iOS app store where even $5 is perceived to be a lot to charge for an app. So we need new models. The rise of SaaS is tied to that shift. in-app purchases and related psychological shenanigans are related to that shift.
The SV elders, like Peter Thiel of Palantir, now more than ever seem to favor rent-seeking business models and started selecting for those businesses 5 years ago. To course-correct, someone in technology will have to discover a new business model. I'm personally betting that we'll see a backlash and new models wherein people pay so there is no chance of data harvesting (going back from SaaS to standalone software)
Yes, when everything from Word, to CAD/CAM, to espionage is being priced on a yearly (soon to be monthly) a la cart SaaS subscription basis, you know that it's all about cash flows and lock-in. As you point out it really started after 2010 and has accelerated since 2015.
Good points, and it doesn't make Slack or anyone else look any better. They aren't doing what they do for the good of communication and long term retention. They are making themselve a single vendor point of failure on purpose, like so many companies have tried and will try to do with their customers.
I don't believe there is a dichotomy between IRC and Slack. In fact, Rocket Chat and Mattermost show that locally hosted platforms can be developed openly and serve a similar purpose.
I don't believe there is a dichotomy between IRC and Slack. In fact, Rocket Chat and Mattermost show that locally hosted platforms can be developed openly and serve a similar purpose.
[deleted]
The reason they're shooting down the "been-there-done-that" folks is because the "been-there-done-that" folks, despite having been there and done that, insist on sticking to things like IRC and email, despite constantly seeing this mass dissatisfaction with those tools.
As one of the been-there-done-that crowd, when we see these "new" tools coming out, many of us have this "here we go again" reaction. I'm not a religious person but by damn, the Christian Bible can be relevantly quoted here:
What has been will be again,
what has been done will be done again;
there is nothing new under the sun.
I'm pretty sure that email and sms represent the lowest common denominator. IRC is a fringe protocol, and while there may be "mass dissatisfaction" with those tools, they are omni-present, and central to most business.
The truth is that no closed platform will ever reach the universality that email has. The prevalence of various chat platforms looks like a race to replace sms. At the current rate, there may be no winners, and only losers.
The truth is that no closed platform will ever reach the universality that email has. The prevalence of various chat platforms looks like a race to replace sms. At the current rate, there may be no winners, and only losers.
That is not everything. Otherwise we would be still using physical mail.
Did you read the article to the end? The author isn't sticking his head in the sand, he puts his money where his mouth is and it currently developing a Slack-like client built on XMPP. The protocol can support many of the Slack-style features you cite, but a lot of the clients are currently lagging behind. Also, if you let hatred of other people's imagined smugness drive your technical and tooling decisions then ... well, I'm not sure it's the most effective metric to use.
> The author isn't sticking his head in the sand
I think he was talking about HN users who argue that IRC does everything slack does.
I think he was talking about HN users who argue that IRC does everything slack does.
> One of the sad things that has come out of Slack's meteoric rise to success, has been how many free and open source projects have jumped over to using it (after previously using IRC or XMPP).
He's definitely honing in on a group of people who should support federated solutions and instead evangelized the opposite. Ironically there's a similar frustration with using the proprietary GitHub service rather than open source git sites like GitLab
He's definitely honing in on a group of people who should support federated solutions and instead evangelized the opposite. Ironically there's a similar frustration with using the proprietary GitHub service rather than open source git sites like GitLab
Apples to oranges, GitHub provides Git as a service and Git is open source, so you can take your repo any time and host it yourself in number of different ways. It just happens that GitHub is most popular (for now) Git As A Service, probably due to the fact that GitLab had few horrible outages regularly every few months for past 2-3 years and hosting it yourself is/was also a bit of nightmare. Anyway, it's not like that. ;)
The problem with GitHub silo is not the repo hosting per se but the ancillary services. Issues are not easily exported. The milestones and related metadata are not easily exported. Even the identities are not easily exported since you can use noreply email addresses in git actions if you turn off public email
Neither of these are Git features. Vote with your legs if you think what you want should be available in a service like this.
My company has gone through three different milestones and issue apps. Sure its mot manually exportable but thats why we pay for data entry staff.
There are many different reasons to choose a service provider. Being FOSS should factor in, but it should hardly be the major factor. Currently, Slack and Github are better choices (Slack is far easier to get started using than IRC, and Github currently has more of a network effect than anything out there). While yes, it would be nice for open source projects to use open source solutions, they should be choosing the best tools for the job. If those aren't open source solutions, so be it.
Yeah anytime Slack is mentioned at work someone brings up IRC. So I get what he’s saying.
Nobody argues that. But they may very well argue that IRC doesn't everything they want it to do.
My argument is that IRC is better because it doesn't do a lot of things. I really don't feel my day would be enhanced by people pasting images or animated emojis into my IRC channels.
Ugh I messed up my post, "doesn't" was supposed to be "does".
See the replies to my comment 10 days ago: https://news.ycombinator.com/item?id=16495893
Most of the replies are criticising the ghastly inefficient app. What is wrong with that?
I know people who literally argue that. Needless to say, I don't agree with them. :P
Thanks for clarifying this for me while I was afk. :)
I wouldn't constrain it to HN only, but yes, that's my point.
Interesting if it ends up supporting Emoji Reactions (note, this is not just Emoji, but Emoji Reactions to messages) and Threads
That's the right answer, I'm very skeptical of people saying "this can be done in XMPP" but when it comes to the actual implementation it falls short
Edit: also note the author updated the article and Emoji Reactions are still not supported in XMPP but are in development
That's the right answer, I'm very skeptical of people saying "this can be done in XMPP" but when it comes to the actual implementation it falls short
Edit: also note the author updated the article and Emoji Reactions are still not supported in XMPP but are in development
> but a lot of the clients are currently lagging behind.
^ this.
A lot of people are so mad at Slack and extolling the virtues of XMPP and IRC and fully forget that there are about zero clients for either XMPP or IRC that have the same functionality (consistent across multiple platforms) as Slack.
Yes, I'm fully aware of exactly one client for Android (Conversations) that supports mobile-friendly XEPS. And yes, I'm fully aware of IRCCloud, a closed-source, proprietary 100% web-based product on top of IRC (all the things that people seem to hate about Slack. Go figure)
^ this.
A lot of people are so mad at Slack and extolling the virtues of XMPP and IRC and fully forget that there are about zero clients for either XMPP or IRC that have the same functionality (consistent across multiple platforms) as Slack.
Yes, I'm fully aware of exactly one client for Android (Conversations) that supports mobile-friendly XEPS. And yes, I'm fully aware of IRCCloud, a closed-source, proprietary 100% web-based product on top of IRC (all the things that people seem to hate about Slack. Go figure)
> And yes, I'm fully aware of IRCCloud, a closed-source, proprietary 100% web-based product on top of IRC (all the things that people seem to hate about Slack. Go figure)
My understanding is that many of IRCCloud's Slack-like features are based on the open IRCv3 standard. If this standard ever takes off (fingers crossed...), IRCCloud will have a lot less vendor lock-in than Slack does.
My understanding is that many of IRCCloud's Slack-like features are based on the open IRCv3 standard. If this standard ever takes off (fingers crossed...), IRCCloud will have a lot less vendor lock-in than Slack does.
> If this standard ever takes off
Hard to imagine it will for Slack's audience. Slack is serving the case for the non-technical folk extraordinarily well right now. A significant amount of their user base doesn't care about standards or IRC channels. They just want a consistent, well-designed product that does the things they need it to for work. They've never opened a terminal in their life and they don't need the terminal-irc-gateway that this recent change has killed off.
Hard to imagine it will for Slack's audience. Slack is serving the case for the non-technical folk extraordinarily well right now. A significant amount of their user base doesn't care about standards or IRC channels. They just want a consistent, well-designed product that does the things they need it to for work. They've never opened a terminal in their life and they don't need the terminal-irc-gateway that this recent change has killed off.
All of that is true, not to mention that Slack is free (up to a certain point).
But many IT departments require on-premise hosting, which Slack doesn't offer. Users don't care about open standards, but maybe their sysadmins do. If IRCv3 can capture this audience, it has a chance to co-exist with Slack.
But many IT departments require on-premise hosting, which Slack doesn't offer. Users don't care about open standards, but maybe their sysadmins do. If IRCv3 can capture this audience, it has a chance to co-exist with Slack.
> But many IT departments require on-premise hosting, which Slack doesn't offer.
Less and less IT departments do that now, since so many things move to the cloud. When you have all your stuff in Gmail and Google Docs already, having Slack is a no-brainer.
Less and less IT departments do that now, since so many things move to the cloud. When you have all your stuff in Gmail and Google Docs already, having Slack is a no-brainer.
IRCv3 has the same problems as XMPP's XEPs [1]. You need servers capable of handling these standards, and then you need clients capable of handling these standards.
In the meantime people will chose other platforms that provide better and more consistent experiences.
[1] https://gultsch.de/xmpp_2016.html
In the meantime people will chose other platforms that provide better and more consistent experiences.
[1] https://gultsch.de/xmpp_2016.html
That's entirely possible, but commercial products are not infallible either. I remember a time before Slack when many companies were using Skype for intra-company chatrooms. Then Microsoft managed the product to death and people started looking for new solutions again.
E-mail is about as terrible as IRC and yet it just won't die.
E-mail is about as terrible as IRC and yet it just won't die.
> E-mail is about as terrible as IRC and yet it just won't die.
At least with email you're able to send messages to those on different "networks".
At least with email you're able to send messages to those on different "networks".
> Then Microsoft managed the product to death and people started looking for new solutions again.
That's very true. Products fail. So instead of blaming others for failing to provide integrations, I would look at what made these products popular in the first place. Unfortunately most discussions around XMPP and IRC rarely actually discuss this.
Speaking of Skype. You can actually see how management fails to understand the popularity and features of other communication platforms in each release. It's funny and sad at the same time.
That's very true. Products fail. So instead of blaming others for failing to provide integrations, I would look at what made these products popular in the first place. Unfortunately most discussions around XMPP and IRC rarely actually discuss this.
Speaking of Skype. You can actually see how management fails to understand the popularity and features of other communication platforms in each release. It's funny and sad at the same time.
Sorry if I keep repeating myself. If you suddenly feel that IRC is too feature free or outdated for your needs, have some courtesy and consider a modern, federated and open solution instead. Matrix/Riot.im roughly has the pros of Slack (yes, including IRC bridges).
https://riot.im/
https://matrix.org/
https://riot.im/
https://matrix.org/
>"sticking your head in the sand and screaming "you can do all of that in IRC" won't get you anywhere and is equivalent to complaining about the very nature of humanity."
Did we read the same article? This article had nothing do do with IRC knee-jerk reactionaries.
The author's main point is that Slack results in a walled garden and information silo'ing of our conversations.
The author then went on to provide a potential antidote to that problem by discussing a javascript project they been working on.
Did we read the same article? This article had nothing do do with IRC knee-jerk reactionaries.
The author's main point is that Slack results in a walled garden and information silo'ing of our conversations.
The author then went on to provide a potential antidote to that problem by discussing a javascript project they been working on.
I should have made this clearer: I am not talking about the author of that blog post but rather of a subset of the tech community discussing slack's move and business model.
[deleted]
> IMHO, if you want people to use anything else but slack, sticking your head in the sand and screaming "you can do all of that in IRC" won't get you anywhere and is equivalent to complaining about the very nature of humanity. It might feel good to scream out your weltschmerz, but it won't change anything.
This is not what the article says. The article says clearly that everyone knows we want these fancy UIs in open chat apps. But the problem is funding. You need to pay 10+ developers, each costing between $100k and $200k (50-100 without tax) for 1-3 years to get such a nifty UI and after that you still need 1-3 devs each year to keep up with all the changes in the IT world. Someone needs to PAY that to get such a nifty UI.
The article also argues correctly that you are currently paying for it by giving away your data which is worth a lot more than a few 100k USD/year. And all you get is a more nifty UI. Wow.
And instead of understanding that you are exploited you complain about how stupid the people are that fight for protection of your values. That is REALLY stupid. The same level a child complaining about needing to go to bed early than the parents while the loud and colorful ads try to keep the child in front of the TV until 2 am or longer.
Start acting like a grown up.
This is not what the article says. The article says clearly that everyone knows we want these fancy UIs in open chat apps. But the problem is funding. You need to pay 10+ developers, each costing between $100k and $200k (50-100 without tax) for 1-3 years to get such a nifty UI and after that you still need 1-3 devs each year to keep up with all the changes in the IT world. Someone needs to PAY that to get such a nifty UI.
The article also argues correctly that you are currently paying for it by giving away your data which is worth a lot more than a few 100k USD/year. And all you get is a more nifty UI. Wow.
And instead of understanding that you are exploited you complain about how stupid the people are that fight for protection of your values. That is REALLY stupid. The same level a child complaining about needing to go to bed early than the parents while the loud and colorful ads try to keep the child in front of the TV until 2 am or longer.
Start acting like a grown up.
Calling it just a "nifty UI" really, really downplays the advancements and ease of use added to it. To the point where the jab at Slack is just childish.
The author can start acting like a grown up by making enough money to fund the development or shut up. If he knew users are already paying for Slack, then obviously he can do what grown ups like Slack did to get paid users as well.
While I haven't checked for proof I wouldn't be surprised if the author is in fact spending a lot of his time not just blogging and informing about the situation, but also working on improving things.
I challenge you to do it better. Ah, screw that. I don't think you can, the way you talk. I challenge you to do something much simper: Read an RFC and try to provide interview style non-compiling code to implement it, then write a single blog post explaining what you did, applying a correct and reasonable free license to your source code and your blog post. That's something an untalented hobby programmer can do if he puts his mind to it.
I challenge you to do it better. Ah, screw that. I don't think you can, the way you talk. I challenge you to do something much simper: Read an RFC and try to provide interview style non-compiling code to implement it, then write a single blog post explaining what you did, applying a correct and reasonable free license to your source code and your blog post. That's something an untalented hobby programmer can do if he puts his mind to it.
I'm sure he is working on improving it. It's all in his article.
Still, he is stil "working on it". While Slack has already "delivered".
It is childish to say that whatever feature Slack has is "simply" something that can "just" be added to XMPP.
To me, the author's complaint of how Slack rips users of is the same as customer who complains when it takes month to "just" add a feature.
He himself hasn't even done it. He planned to do it, anybody can plan to do things. Anyone can be working on something that will change the world. Only few delivers. He complain about funding, while he is adding feature that he claimed was "simple".
Why does simple feature needs funding? And if Slack is ripping people of on feature that can simply be added on XMPP, then put your house on loan, create better XMPP client and earns millions of dollars. You don't need funding. That's what being adult is.
Still, he is stil "working on it". While Slack has already "delivered".
It is childish to say that whatever feature Slack has is "simply" something that can "just" be added to XMPP.
To me, the author's complaint of how Slack rips users of is the same as customer who complains when it takes month to "just" add a feature.
He himself hasn't even done it. He planned to do it, anybody can plan to do things. Anyone can be working on something that will change the world. Only few delivers. He complain about funding, while he is adding feature that he claimed was "simple".
Why does simple feature needs funding? And if Slack is ripping people of on feature that can simply be added on XMPP, then put your house on loan, create better XMPP client and earns millions of dollars. You don't need funding. That's what being adult is.
why would [enough people] pay for slack if they didn't need information in a silo?
> who just plain refuse (are unable?) to even see the difference between a chat like slack (or telegram, or mattermost, or or or...)
What if they do see the difference and don't see the value in it? This is worth considering.
> where I can post images/videos inline, use proper markup etc
I don't want someone else putting inline videos or markup into my feed. In IRC people post links, most of which I happily ignore at very low cost because they're not important to anything.
What if they do see the difference and don't see the value in it? This is worth considering.
> where I can post images/videos inline, use proper markup etc
I don't want someone else putting inline videos or markup into my feed. In IRC people post links, most of which I happily ignore at very low cost because they're not important to anything.
> I don't want someone else putting inline videos or markup into my feed.
That is of course your personal choice, no arguing with it. I'm thinking of projects where communicating with/about videos and images is an integral part of the work. Think image processing for example. In that context a message of the kind "Hey, I tried this new method, look what I got as a result [image]" can make tons of sense.
If you don't need images, you don't have to use them. If the person on the other end of the chat insists on sending them anyway, why are you talking to them? :P
That is of course your personal choice, no arguing with it. I'm thinking of projects where communicating with/about videos and images is an integral part of the work. Think image processing for example. In that context a message of the kind "Hey, I tried this new method, look what I got as a result [image]" can make tons of sense.
If you don't need images, you don't have to use them. If the person on the other end of the chat insists on sending them anyway, why are you talking to them? :P
So maybe the issue is just that this sort of features should really be enabled client-side. Which you could do fine with an intelligent IRC client.
If they don’t see the value but everyone else dies then they are an outlier.
That’s absolutely ok, as long as they understand that and that at some point the value is in network effects too
That’s absolutely ok, as long as they understand that and that at some point the value is in network effects too
The problem with IRC is that it's technically capable of being so much more than what people think it is but it's actually a real hurdle to set up and nobody is very good at it, plus the clients are stuck in the past. The right way to use IRC is to SSH into a screen/tmux session on a remote server that's always up and running; in theory it should be fully possible to send any files (images, videos etc) over DCC and use terminal plugins to display them but no clients can handle this right. DCC is perfectly capable of this as IRC piracy has been a thing for years and those files are much larger. The trouble is that FOSS is so often made by ascetics for ascetics and so most clients won't help you with any of this and people sniff at you if you use one that does.
So, how do I teach the non-technical users with whom I need to communicate to use IRC, SSH, TMUX, and and get the right things on their system?
We'd likely still need a client wrapper on top of it all.
We'd likely still need a client wrapper on top of it all.
I didn't say you should; rather, my point is that the problems with IRC mostly happen at the client level rather than the protocol level. Of course, it is also hard to ensure that a dominant client vendor does not start trying to add backwards-incompatible changes to the protocol. This has already happened once, and it's why the character U+0001 is now responsible for /me.
I think ideally such a client could be implemented as a plugin to an extensible terminal emulator, which might help to keep the project small and prevent Jabberification.
I think ideally such a client could be implemented as a plugin to an extensible terminal emulator, which might help to keep the project small and prevent Jabberification.
Something like Quassel had most of this functionality more than 5 years ago, while looking at least as good as Slack. I haven't used it in a long time but I'm pretty sure the setup was simple (not one click, but certainly easier than tmux, etc). It's a Qt app, so might be a better fit for non-technical users.
>post images/videos inline
There are quite a few IRC clients that do this automatically, fwiw.
There are quite a few IRC clients that do this automatically, fwiw.
This comment is on the money.
"..just plain refuse (are unable?) to even see the difference between a chat like slack. ...the user experience will be a different one."
Underlying this is (unusually) a way some technical people think, and the way most bureaucracies think. Bureaucracies will often "checklist" requirements, see that it does all the things "users have identified as important," use cases they think these apply to and go on that information alone. They only consider stuff that is tangible & legible.
By that checklist method email, whatsapp, Twitter, slack are IRC and such are essentially the same. Some may tick a.minor box that the other does not, but basically they all get messages from A to B (sometimes to B, C & D).
It's even worse in this case, because slack is social software and the conventions people form as users are very impactful on the UX. This compounds differences.
"..just plain refuse (are unable?) to even see the difference between a chat like slack. ...the user experience will be a different one."
Underlying this is (unusually) a way some technical people think, and the way most bureaucracies think. Bureaucracies will often "checklist" requirements, see that it does all the things "users have identified as important," use cases they think these apply to and go on that information alone. They only consider stuff that is tangible & legible.
By that checklist method email, whatsapp, Twitter, slack are IRC and such are essentially the same. Some may tick a.minor box that the other does not, but basically they all get messages from A to B (sometimes to B, C & D).
It's even worse in this case, because slack is social software and the conventions people form as users are very impactful on the UX. This compounds differences.
> But you can just send images by mail!" they shout.
When Dropbox was originally announced in a "Show HN" someone said:
When Dropbox was originally announced in a "Show HN" someone said:
You can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem.I don't like Slack not because it is slick and nice, but because it breaks my productivity. People think they're more productive, but they're not. They just chat. The great thing about email is that it is asynchronous.
I don't see anything conductive to actual work that slack has but IRC lacks. the software industries and choices of tools such as chat clients are fashion-driven and most people will be hard pressed to provide a reason why they prefer slack or discord or whatever the newest shiny toy is other than "it's popular". They're popular, in turn, because their owners have marketing budgets, and decentralized, superior alternatives don't, because they are not commercial products. Just accept that any choice of tools or technologies is typically at least 95% irrational and dictated by marketing, not by rational reasons or calculations of risks and benefits. It used to be that companies would never risk third parties getting hold of confidential internal communications, nobody cares anymore though.
“Sync’d read-state across multiple devices” is what sold me on Slack years ago. I had been trying to simulate it for a long time in IRC using various bouncers, but it never worked very well and was hard to set up for non-technical people at work.
I use irccloud for persistence in IRC, but it's not as good as slack overall.
Work had a private irc server that required all sorts of client certificates to join, forget non-technical people -- it wasn't very good for technical people either!
Work had a private irc server that required all sorts of client certificates to join, forget non-technical people -- it wasn't very good for technical people either!
Try IRCCloud.
Which is a centralized, proprietary, web-based client. All three of which HN loves to hate Slack for.
It does have a really easy way to extract your conversations as a log file though. An OSS version of irccloud you could just "apt-get install blahblah" with may have stemmed the rise of slack, at least in companies.
I expect this niche will be filled by Matrix in the near future. Host a Matrix homeserver + Riot.im web UI, then employees can use Riot mobile apps and any Matrix-supporting client.
For the record, I don't like Slack very much. I just disagree that IRC or IRCCloud are acceptable alternatives.
For the record, I don't like Slack very much. I just disagree that IRC or IRCCloud are acceptable alternatives.
IRCCloud was is its infancy when Slack came on the scene. If it had existed back then, maybe we wouldn’t have switched? I don’t know, but it’s way too late now. (I have never used it, and am just assuming the read state sync works as well as Slack, which may be a big assumption.)
Ease of use is a very important feature, extremely conductive to actual work. Do not downplay that.
> Slack, like so many others before them, pretend to care about interoperability, opening up just so slightly, so that they can lure in people with the promise of "openness", before eventually closing the gate once they've achieved sufficient size and lock-in.
On spot. People are lured in by hype and forget the long-term consequences. Always chose “open” by design, never by charity.
On spot. People are lured in by hype and forget the long-term consequences. Always chose “open” by design, never by charity.
Doing the reforge course this was something that really stuck out for me. These tech platforms promise the world then slowly cut things out or become inefficient over time to cater for enterprise clients. If you are interested read this https://medium.com/point-nine-news/the-lifecycle-of-lead-gen...
I'd be interested to know how widely used these gateways are, since the conventional wisdom on HN is so frequently "vote with your wallet/feet/personal data".
As they say: Use it or lose it.
As they say: Use it or lose it.
It's disabled by default. So enabling it requires effort. Then again, Slack didn't advertise those gateways.
It's designed with termination in mind.
It's designed with termination in mind.
Well, "... is designed with termination in mind" is an assumption, it certainly sounds designed to reduce adoption/use of it.
it stops being an assumption once the termination actually happens
No, it's still an assumption - the outcome perhaps is what a person expects will happen, however that doesn't then validate a past assumption - it does validate their past belief/prediction/expectation though.
It was an assumption before. Now it's a fact.
No it's not. You're conflating "it was terminated" with "it was designed with termination in mind". It's a fact that it was terminated, true, but this doesn't necessarily mean that it was designed with termination in mind. For all we know, it may have been designed with every intention of continuing IRC/XMPP support until yesterday when an executive decision suddenly said otherwise. Now, I don't believe that, but that doesn't matter: the fact that it was terminated is not the fact that it was designed with termination in mind.
If you believe so...
As a user, I was very disappointed to see that the gateways must be enabled by the project owner, not by the users themselves. In the end none of the Slack groups I've participated in allowed me to connect via IRC/XMPP.
Pretty sure enabling these by default would lead to a moderation nightmare in many groups.
Slack is an in-company chat product (their slogan is literally “where work happens” [1]) and it was never intended for public groups, which is why all invite automation tools for Slack are third-party. Slack doesn’t want you to use their product as a public chatroom and they try really hard to make that as unattractive as possible.
Given that, “moderation nightmare” is not really a concern for the target audience since if your company needs moderation in its work chat, you have much bigger problems.
[1] https://slack.com/
Given that, “moderation nightmare” is not really a concern for the target audience since if your company needs moderation in its work chat, you have much bigger problems.
[1] https://slack.com/
I don't see how. You would still need to authenticate with that group, so it wouldn't automatically allow anonymous participants from the Internets.
I can't answer the broader question, but I did attempt to use the XMPP gateway for a little while. Many features were implemented in ways that made them hard or impossible to follow when viewed via XMPP (threading was a big one), and there were a fair number of bugs. It very much felt like a tacked-on feature as opposed to something they would have expected to be used in a meaningful way.
[deleted]
The number of people who used slack because of the XMPP or IRC gateway is probably miniscule. If they accounted for a significant percentages of users, they wouldn't have shut it off.
Well, they did that the moment non-tech people started pushing for slack, and the decisions to adopt this was no longer in the techies hands.
The company I currently work for was very hesitant of adopting it, and they only did the moment our sales people started asking for it. And as a productivity tool it's great, but there is obviously a lock-in.
The company I currently work for was very hesitant of adopting it, and they only did the moment our sales people started asking for it. And as a productivity tool it's great, but there is obviously a lock-in.
> One of the sad things that has come out of Slack's meteoric rise to success, has been how many free and open source projects have jumped over to using it (after previously using IRC or XMPP). In so doing, they have closed off their discussions from search engines and they prevent people from accessing their past archives.
Additionally the traditional mailing lists are full of "please can I have an invite to the Slack workspace" spam
Additionally the traditional mailing lists are full of "please can I have an invite to the Slack workspace" spam
It's not even that discussions have been lost from search engines, actual slack users are loosing massive amounts of history. If you a free/OSS project then you likely have little budget so you're stuck using hte free tier of Slack, which means users can only see the last 10,000 messages. We're loosing vast swathes of our history/discussion/media.
This is the main reason why my team switched to use self-hosted Mattermost. Unlimited message history is important for us, but not worth what Slack would cost when something like Mattermost is available. If you're a tech team with people who know Linux, I don't understand why you would choose Slack over something like Mattermost. If you're a small business without a tech team, more understandable.
Some nice folks I know recently started http://relay-chat.com/ which is a hosted version of MatterMost. It allows both private instances as well as creating a team at http://open.relay-chat.com
I am more concerned about Mattermost long term future than Slack. If/when slack gets obsoloted and abandonned for the next big thing then what of Mattermost ? Will it have enough developpers's mindshare to ensure its existence considering if slack is gone then there's no need to provide an alternative ?
I suppose it'd be better to build a slack clone based on xmpp.
I suppose it'd be better to build a slack clone based on xmpp.
I'm not so concerned. I think the only thing that would kill Slack is financial factors (financing if it turns out people don't want to pay for it anymore) or bureaucratic factors (if it gets acquired and then mired in corporate stupidity). I think Slack did the favour of proving to the world that people wanted something more than IRC or Skype.
If Slack dies for any of the above reasons, that won't cause people's need for a solution to disappear. I imagine Mattermost would survive just fine. If Mattermost dies, it will be because something came along that's better, similar to how I started out with ICQ, then jumped to MSN Messenger, and now I'm on Whatsapp, WeChat, Kakao Talk, Slack, and Mattermost. Same for Slack. If Slack dies because of better competition, perhaps we'll shift to that away from Mattermost. Who knows?
Gah, how is it possible that the number of chat clients I use keeps growing?
edit: typo
If Slack dies for any of the above reasons, that won't cause people's need for a solution to disappear. I imagine Mattermost would survive just fine. If Mattermost dies, it will be because something came along that's better, similar to how I started out with ICQ, then jumped to MSN Messenger, and now I'm on Whatsapp, WeChat, Kakao Talk, Slack, and Mattermost. Same for Slack. If Slack dies because of better competition, perhaps we'll shift to that away from Mattermost. Who knows?
Gah, how is it possible that the number of chat clients I use keeps growing?
edit: typo
Mattermost is open and self hosted so if development stops it'll just continue to exist in an unchanging state. If people start communicating in another way, their Mattermost history will still be available and searchable.
How did the transition go? We're seriously considering on our end, and trying to anticipate any friction points that might occur.
Any caveats, gotchas or hidden complexities to be aware of?
Any caveats, gotchas or hidden complexities to be aware of?
Honestly, it was so smooth. Deleting old unnecessary channels seems impossible, but whatever. Have all of our chat history migrated over, no complaints. One team member missed the old Slack colour scheme, but he found a Slack skin for Mattermost that makes it look the same for him.
Have you tried their Zoom voice / screensharing plugin? If so, how well does it work?
If you are asking about Slack's Zoom plugin, I used it at a previous job, and it's pretty good. (We were a small team in Sunnyvale, CA, the bulk of the team was in Phoenix, some in Seattle)
I meant Mattermost - is the Slack one representative, i.e. it's the same client software behind a thin shim layer? Does it work as well as Hangout in terms of voice / image quality and stability? Can people click the screen and the presenter sees where they clicked?
Have not. We don't do much screen sharing among our own team, and external screen sharing is done using other tools. Interested in other people's opinions about it though.
How do I interact with Mattermost in Emacs?
So would there be a use-case for a combined bot+app that you can connect some storage to (S3, FTP) which archives all channel message history in a searchable form? It could make it visible to search engines, searchable by humans, linkable to people outside of slack, and shouldn't take up very much storage space.
Should be quite trivial to build also, and cheap enough to run as a bit of charity if projects pay for their own storage.
Should be quite trivial to build also, and cheap enough to run as a bit of charity if projects pay for their own storage.
For open source developers logs of private 1:1 discussions are also highly valuable, so this would only be a bandaid.
The last company I worked for used small channels for this issue instead of going 1:1, which was more or less reserved for private talk
Gotta admit, as a workaround for the deficiency of "doesn't have local client logging", that one's really funny.
Local client logging doesn't solve all problems (though yes, i still want to be able to grep text files if I choose).
The two I regularly encounter (which shared storage fixes) is either moving to a different device (or trying to remember which ones have which bits of history on) and also integrating new team members.
The latter is especially important if you're doing anything technical/support related; if you've had 2 days of discussions and want to add someone else in, they need the history, not for you to try and cherry pick the important bits of the last few hours to then fail to get them upto speed.
The two I regularly encounter (which shared storage fixes) is either moving to a different device (or trying to remember which ones have which bits of history on) and also integrating new team members.
The latter is especially important if you're doing anything technical/support related; if you've had 2 days of discussions and want to add someone else in, they need the history, not for you to try and cherry pick the important bits of the last few hours to then fail to get them upto speed.
This would be quite the workaround though, completely evading the root of the problem (slack).
It's trivial to write such a thing, but why would Slack allow that application in their apps?
It would be useless for private organisations - the entire purpose is to make ephemeral chat publicly available to search engines.
Slack might cut it off, but they gain nothing by doing it.
Slack might cut it off, but they gain nothing by doing it.
Several slack groups already do this.
That's why I use Discord, the free tier has _unlimited_ history. The client itself is lightweight, and it's an incremental improvement on IRC in many other areas, as you would expect. Still using IRC of course :)
Discord is an Electron app, so while it's not as bad as Slack, it's still hardly what I'd call lightweight, especially in comparison to IRC/XMPP clients.
There's a lot to like in Discord, and it rapidly became the go to client for all my gaming related friends and activities, but it suffers from the same root pitfalls that Slack always has. It will inevitably run out of VC money (or whatever they're spending now) at some point and start wanting to actually turn a profit.
There's a lot to like in Discord, and it rapidly became the go to client for all my gaming related friends and activities, but it suffers from the same root pitfalls that Slack always has. It will inevitably run out of VC money (or whatever they're spending now) at some point and start wanting to actually turn a profit.
I imagine this problem would be remedied by an acquisition.. or at least masked... Twitch (Amazon) seems a likely candidate, considering it's usage by Twitch users, and also the fact that Amazon doesn't really have skin in the game currently in the chat market (do they?), and could use a product like Discord in their ecosystem.
Some time ago, Twitch bought Curse, probably for the Curse App that already does voice and text chat. Also viewing streams and mod management for a handful of games.
If you're a free/OSS project and have set up a non-profit, Slack will upgrade you to unlimited messages for free. I know because I'm in such a slack channel (lichess.org).
The history isn't searchable, but the owners of the Slack can export the complete public history at any time. Here is an export that I did when we moved Hyperledger to Rocket.Chat: https://github.com/hyperledger/slack-archive
I see the hosted version is down, though.
I see the hosted version is down, though.
Key word: public history. Most of my interesting history is in private chats.
Exactly! As pointed out in the article: "Slack's business model is to record everything said in a workspace and then to sell you access to their record of your conversations."
Slack recognizes, unfortunately before most of it's customers, that the history is one of the most important assets of a company -- it is the shared institutional knowledge, the thousands of hard-won lessons of all the things that can go wrong that are now fixed, and how they were fixed. This institutional knowledge is not only in the heads of the workers, but also in the papers, and many would need, or at least benefit from, a lookup of the details to re-use that knowledge.
This institutional knowledge is a key competitive advantage of almost every company.
This business model of capturing it and rent-seeking on selling it back to them is a devil's bargain.
"Here's this really slick UI for free, only costs a bit later... nevermind that we'll own the soul of your company and you'll need to pay us tribute in perpetuity..."
Slack recognizes, unfortunately before most of it's customers, that the history is one of the most important assets of a company -- it is the shared institutional knowledge, the thousands of hard-won lessons of all the things that can go wrong that are now fixed, and how they were fixed. This institutional knowledge is not only in the heads of the workers, but also in the papers, and many would need, or at least benefit from, a lookup of the details to re-use that knowledge.
This institutional knowledge is a key competitive advantage of almost every company.
This business model of capturing it and rent-seeking on selling it back to them is a devil's bargain.
"Here's this really slick UI for free, only costs a bit later... nevermind that we'll own the soul of your company and you'll need to pay us tribute in perpetuity..."
The one slack I am in has had some discussion of limiting history further than the free limits.
It turns out that people don't necessarily want lots of records of everything everywhere.
It turns out that people don't necessarily want lots of records of everything everywhere.
you can use https://gitter.im/ , it's free for OSS/free communities
Just a heads up. If you suddenly feel that IRC is too feature free or outdated for your needs, have some courtesy and consider a modern, federated and open solution instead.
https://riot.im/
https://matrix.org/
https://riot.im/
https://matrix.org/
Let's imagine I'm on a small open source project using slack. We don't want to host anything. Which of the slack alternatives is the easiest dropping?
https://gitter.im/ was acquired by GitLab and thus likely to remain for quite a while. Also, it might even suit the needs of such a project better than Slack, as apparently it's aimed more at communities rather than teams, but I'm not sure what that means in practice.
… and it's open-source (https://gitlab.com/gitlab-org/gitter/webapp/).
https://riot.im/app/#/register
Register matrix.org accounts there. There's a web client, desktop clients and mobile clients (called Riot.im). It's open source and federated. And, there are IRC bridges!
Register matrix.org accounts there. There's a web client, desktop clients and mobile clients (called Riot.im). It's open source and federated. And, there are IRC bridges!
There are plenty of public matrix servers, most notably matrix.org hosted by the matrix developers. There is also a small list here: https://www.hello-matrix.net/public_servers.php
You don't have to host your own server.
You don't have to host your own server.
There is a large list of public XMPP servers one can register on ( https://list.jabber.at/ & https://xmpp.net/directory.php )
https://movim.eu/ is another option (has a fancy web client, android & linux client and of course supports any XMPP client)
https://movim.eu/ is another option (has a fancy web client, android & linux client and of course supports any XMPP client)
http://open.relay-chat.com is hosted MatterMost offered for free to open-source projects.
Also, for those still using IRC, and needing an easy way to get others on it: IrcCloud is an excellent service with a mobile client lightyears beyond any other.
I believe one of the problems there is an inaccessibility problem. Atleast for the mailing list.
Most mailing list archives lack fulltext search and a modern looking design (I'm not even asking for an SPA or anything JS, just a tiny bit of CSS could make a lot of difference).
It's also not as easy to onboard, integrate and host mailing lists.
Ideally a mailing list could be hosted with a few button clicks, people could join a mailing list like they join newsletters (instead of having to send an email to the mailing list application with some command in it) and people should be able to anonymously send emails.
Plus points if you can, optionally, manage emails like github issues and properly keep track of bug reports.
Most mailing list archives lack fulltext search and a modern looking design (I'm not even asking for an SPA or anything JS, just a tiny bit of CSS could make a lot of difference).
It's also not as easy to onboard, integrate and host mailing lists.
Ideally a mailing list could be hosted with a few button clicks, people could join a mailing list like they join newsletters (instead of having to send an email to the mailing list application with some command in it) and people should be able to anonymously send emails.
Plus points if you can, optionally, manage emails like github issues and properly keep track of bug reports.
I'm not a big fan of mailing lists either, for the reasons you describe
What I do dislike though is, as Slack is invite only (the software is designed for "Teams" in workplaces, not public forums) you have to explicitly request access from the admins and this is often via the mailing lists.
What I do dislike though is, as Slack is invite only (the software is designed for "Teams" in workplaces, not public forums) you have to explicitly request access from the admins and this is often via the mailing lists.
The invite-only nature of slack is probably why I never spend any serious amount of time in any slack, though some other factors may play a role too considering I quite enjoy Discord (OSS discords never seem to replace any discussion board, only supplement it, plus discord has unlimited search)
Services like gmane actually provide a email list to NNTP gateway that allow for searches and easy browsing.
I rarely see a big textbox on the top of the main page of any mailing list archive that says "Fulltext search" (and isn't totally crap). "NNTP Gateway" doesn't sound encouraging in that it is explained and available for the layperson to easily employ as search tool.
I'm actually of the opinion that it would have been better to have a NNTP server to host various newsgroups instead of having various mailing lists. This would have made it much easier to view previous messages posted to the group and would have made it much easier to browse by those who don't participate.
The disadvantage is that it would require one to create an account on another server instead of just using one's existing email account for communication.
As for explaining and availability, I believe the vast majority of people would use search engine to figure out what steps are involved once something like that is mentioned.
The disadvantage is that it would require one to create an account on another server instead of just using one's existing email account for communication.
As for explaining and availability, I believe the vast majority of people would use search engine to figure out what steps are involved once something like that is mentioned.
This. A thousand times this.
I think this is pretty silly. Anyone that has actually used Slack on their team - especially if they've built integrations - will know otherwise.
It is unbelievably painful to build integrations that cater to the regular client (users want forms, buttons, dropdowns, etc) that have clean fallbacks for text-only clients (at best 1% of your users). The real reason they're dropping support is because it will make it easier for developers to build in their ecosystem. That's it.
That said, we shouldn't let Slack off easy - there are many basic issues that seem to plague Slack and Slack alone (ex. I can't believe this is an issue, but it seems nearly every message I try to send through iOS rich notifications fails to send). We should demand better, but an IRC or XMPP gateway is not the fight to pick.
P.S. If you're in high school, you should join our relatively active Slack community at https://slack.hackclub.com - started as an IRC community and switched when our members started demanding a decent mobile client.
It is unbelievably painful to build integrations that cater to the regular client (users want forms, buttons, dropdowns, etc) that have clean fallbacks for text-only clients (at best 1% of your users). The real reason they're dropping support is because it will make it easier for developers to build in their ecosystem. That's it.
That said, we shouldn't let Slack off easy - there are many basic issues that seem to plague Slack and Slack alone (ex. I can't believe this is an issue, but it seems nearly every message I try to send through iOS rich notifications fails to send). We should demand better, but an IRC or XMPP gateway is not the fight to pick.
P.S. If you're in high school, you should join our relatively active Slack community at https://slack.hackclub.com - started as an IRC community and switched when our members started demanding a decent mobile client.
What's so difficult about providing a link to the slack client when the feature is incompatible with IRC? 99% of the messages are text and images anyway.
Sorry, I really don't see the "bait and switch" here. IRC/XMPP gateways were never a selling point of Slack. Bots were always supposed to use the proprietary WebSocket/HTTP APIs, and in all the companies I've worked in that use Slack, not a single person used the IRC or XMPP gateway.
Open-source project communities should not be using Slack, if for no reason other than the 10k message limit and the fact that it's annoying to be present in multiple Slacks. I prefer IRC or Gitter for those communities, as they're better designed around the flow of "drop in, drop out" than Slack.
Open-source project communities should not be using Slack, if for no reason other than the 10k message limit and the fact that it's annoying to be present in multiple Slacks. I prefer IRC or Gitter for those communities, as they're better designed around the flow of "drop in, drop out" than Slack.
So I'm a mid-level manager at a company with a few hundred developers.
The more developers you hire, the higher the chance you'll start collecting people with obscure (but usually reasonably easy to satisfy) tool preferences. You know, the guy who changes his IDE to emacs key bindings, the guy who does all his e-mail using mutt when everyone else uses gmail, the girl who uses a Dvorak keyboard layout, the guy who insists he works best on a 1024x768 screen, and so on. Having tried a variety of industry tools and thought about about how you work best is usually a good sign[1].
Their favourite tools aren't my favourite tools, but they work for me so if they're not happy, I'm not happy.
The bait and switch is we adopted a tool that would keep IRC users happy, and it dropped IRC support.
[1] Although I keep my settings conservative, as it's hard for others to pair program or assist you with problems if they can't operate your computer
The more developers you hire, the higher the chance you'll start collecting people with obscure (but usually reasonably easy to satisfy) tool preferences. You know, the guy who changes his IDE to emacs key bindings, the guy who does all his e-mail using mutt when everyone else uses gmail, the girl who uses a Dvorak keyboard layout, the guy who insists he works best on a 1024x768 screen, and so on. Having tried a variety of industry tools and thought about about how you work best is usually a good sign[1].
Their favourite tools aren't my favourite tools, but they work for me so if they're not happy, I'm not happy.
The bait and switch is we adopted a tool that would keep IRC users happy, and it dropped IRC support.
[1] Although I keep my settings conservative, as it's hard for others to pair program or assist you with problems if they can't operate your computer
The beauty of choice is that you and I can have different favorites - so long as we can get our work done, who cares?
____________________
(thanks to http://highscalability.com/blog/2018/3/16/stuff-the-internet... for finding this comment)
____________________
(thanks to http://highscalability.com/blog/2018/3/16/stuff-the-internet... for finding this comment)
The only good thing I've ever heard of Slack is that you can avoid the bloated client and use IRC instead.
Probably a great way to reduce friction when introduced.
Probably a great way to reduce friction when introduced.
> can
could.
could.
The author I think is confused about the meaning of Slack's "emoji reactions". They are "badges" that can be applied to messages by any one who is in the channel the message was sent. Discord also has this feature.
At any rate, that doesn't change the fact that it probably could have been implemented in XMPP.
As one of /those/ people still using IRC, I would personally have been totally fine continuing to use the IRC gateway without these features.
At any rate, that doesn't change the fact that it probably could have been implemented in XMPP.
As one of /those/ people still using IRC, I would personally have been totally fine continuing to use the IRC gateway without these features.
My company switched to a free slack account a couple years ago, from our own IRC server. The primary reason for the change was to get something a bit richer in abilities, and emoji reactions is something we make extensive use of. Just saying there are people out there that find these sorts of "XMPP breaking" features not only useful, but mission critical.
Would have been useful if their announcement included some of their data for reaching the conclusion, like "95% of channels use emoji reactions in more than 5% of their messages". The announcement, as it was, didn't read very well to me.
Would have been useful if their announcement included some of their data for reaching the conclusion, like "95% of channels use emoji reactions in more than 5% of their messages". The announcement, as it was, didn't read very well to me.
How do you use emoji reactions in a mission-critical way?
Someone says 'about to push this potentially breaking change to a shared resource, is that ok?'. Then everyone else posts a :thumbsup:
Obviously, this could be done differently. But it's easy to do it like this and come to depend on it.
Obviously, this could be done differently. But it's easy to do it like this and come to depend on it.
While that use case is certainly an example of a convenience, I don’t think it passes the “mission critical” bar.
I can’t think of any way that emoji reactions would be mission critical unless they are part of an API that can be used for automated execution of tasks. But maybe that sort of thing does exist?
I can’t think of any way that emoji reactions would be mission critical unless they are part of an API that can be used for automated execution of tasks. But maybe that sort of thing does exist?
[deleted]
And is that an acceptable paper trail? If you break something can you show your bosses "look, Jack thumbs-upped me on Slack!"
It is a perfectly adequate paper trail. It's much easier to check in a postmortem than shouting something across the desk. Like code review, because you know your approval will be recorded irrevocably, you just think it through that little bit extra before approving.
We typically do something similar in Hipchat - "Hey, I'm about to push to prod, any objections?" "No, go for it."
This is what I don't get; for someone wanting to use an irc client ":thumbs-up:" is as least as good as the actual graphic. Nothing is lost. And that goes for all the built-in emojis in slack.
Now if it was :4677: it'd be a different story - without some support it'd be hard to understand the constant identifiers.
/shrug
Now if it was :4677: it'd be a different story - without some support it'd be hard to understand the constant identifiers.
/shrug
We use it for an on the spot estimation outside of our normal grooming sessions.
I have to admit, this is the first time in my life I've ever read that someone (a company, no less) switched from one software product to another because the one they switched to had emojis. I somehow feel my life is more complete, like I checked something off my bucket list. Thanks!
Author here. Yes I was confused about "emoji reactions", thanks for explaining.
I've updated the article to clarify.
I've updated the article to clarify.
I agree, the author complains about something they actually do not understand. I'm sure many people will agree with the author, I'm not sure I do. If Slack changes something or does something that I don't agree with, I will find another solution. If it changes in a way that affects the workplace, we will find another solution. This is why other similar systems exist like Mattermost.
EDIT> Thanks for the downvote! Always fun when disagreeing with the echo chamber causes a loss in Internet points.
EDIT> Thanks for the downvote! Always fun when disagreeing with the echo chamber causes a loss in Internet points.
I'm trying to solve this walled garden problem by building a free native desktop client for Slack, Skype, XMPP, Twitter etc.
It doesn't have the 10 000 messages limit, it's very light (~100 KB) and fast:
https://eul.im
I recently started working on it full-time, so I expect a stable release to be out this month.
It doesn't have the 10 000 messages limit, it's very light (~100 KB) and fast:
https://eul.im
I recently started working on it full-time, so I expect a stable release to be out this month.
I will always cheer on someone building something cool, but here's the problem I have: Everyone wants to build an open source alternative, no one wants to make money. What is wrong with making money? Money is great -- it lets you buy clothes, food, shelter, water, and even a night out on the town or two. We need to be able to make money on software again, not just have user data be the product. This is partly to blame on the FOSS zealots. Sure they say it's "just fine" to make money on your software, but they never seemed to offer a method that is based in reality.
Hi,
I 100% agree with you. I want this product to make money so that I can devote my full time to it.
The basic functionality will always be free without ads and tracking. But there will also be a very affordable ($1-2/mo) premium plan. I haven't yet decided what it's going to have. Most likely an ability to add more than 5 accounts or multiple accounts on the same platform (e.g. 3 Slack profiles).
I 100% agree with you. I want this product to make money so that I can devote my full time to it.
The basic functionality will always be free without ads and tracking. But there will also be a very affordable ($1-2/mo) premium plan. I haven't yet decided what it's going to have. Most likely an ability to add more than 5 accounts or multiple accounts on the same platform (e.g. 3 Slack profiles).
It's perfectly fine to make money, nobody argues that. The point is that Open Source and making money don't contradict each other.
Examples:
- Conversations, the Android XMPP client, is GPL and sold on Google Play: https://play.google.com/store/apps/details?id=eu.siacs.conve... - There is also a paid hosted XMPP service on conversations.im.
- I have a paid+OSS app for amateur radio geolocation on Google Play myself. You can download the APK from the homepage or just directly buy it for some bucks.
- X-Chat, the OSS IRC client has a paid Windows version: http://xchat.org/windows/
You could OSS your app under whatever license you want, and still provide paid builds for any platform you want.
Examples:
- Conversations, the Android XMPP client, is GPL and sold on Google Play: https://play.google.com/store/apps/details?id=eu.siacs.conve... - There is also a paid hosted XMPP service on conversations.im.
- I have a paid+OSS app for amateur radio geolocation on Google Play myself. You can download the APK from the homepage or just directly buy it for some bucks.
- X-Chat, the OSS IRC client has a paid Windows version: http://xchat.org/windows/
You could OSS your app under whatever license you want, and still provide paid builds for any platform you want.
Don’t price your service so low! Anything below $5/mo gives the perception of having little value to offer. Plus you’re gonna lose a fat percentage to credit card processing.
To avoid credit card fees I was thinking about $12-24/year.
I don't want to charge a lot for a chat client, but these prices are not final. I know that charging too little is a mistake.
I don't want to charge a lot for a chat client, but these prices are not final. I know that charging too little is a mistake.
Open source and making money can be orthogonal
Well he didn't say he wasn't going to earn money from the project, just that the client is free. There are many ways to monetize something and the benefits of starting with free is that you get biggest growth and then you can find your "whales" and learn how to profit from them.
It doesn't seem like the parent wants to build an open source alternative. I remember reading about it over half a year ago (back then it was supposedly written in Go rather than C if I remember correctly) where there was also promise of open sourcing it.. His website also seems to indicate he now wants to go the route of SublimeText, so the open source promise should probably be interpreted as "I'll release the source code after I abandon the project, whether it takes one or ten years"..
FYI, I have nothing against closed source projects, but every discussion about eul.im seems to include the promise of open sourcing the project, which I'm sure is a great marketing ploy.
FYI, I have nothing against closed source projects, but every discussion about eul.im seems to include the promise of open sourcing the project, which I'm sure is a great marketing ploy.
> I'm trying to solve this walled garden problem
By building a closed-source client?
Cool project; it's really impressive and I'd love to use once it gets stable, but don't you think your claim is a bit incompatible with your method?
By building a closed-source client?
Cool project; it's really impressive and I'd love to use once it gets stable, but don't you think your claim is a bit incompatible with your method?
It's going to be open-sourced at some point, just not now.
What I meant is I'm building an alternative client that gives people a lot more freedom. For example, you can use XMPP as your primary messenger, and still communicate with your teammates via Slack.
You can also have access to all your history and a much, much better instant search.
In the future, an IRC/XMPP gateway will be built in as well.
What I meant is I'm building an alternative client that gives people a lot more freedom. For example, you can use XMPP as your primary messenger, and still communicate with your teammates via Slack.
You can also have access to all your history and a much, much better instant search.
In the future, an IRC/XMPP gateway will be built in as well.
Why not now?
Opening a project early to contributors can end in mixed milestones, and the project may never archieve an "stable" status.
I might not be using the best words, so I'll give examples: Dolphin, the GameCube/Wii emulator did not release it's source code until the program's structure was mature enough to start adding thirth party code without disrupting the project's core codebase.
I might not be using the best words, so I'll give examples: Dolphin, the GameCube/Wii emulator did not release it's source code until the program's structure was mature enough to start adding thirth party code without disrupting the project's core codebase.
The premise is cool indeed, but are you really going to solve "this walled garden problem" with a closed-source application?
Looks VERY promising! I wanted the Linux alpha but doesn't seem like it's there yet :(
I'll be following this for sure <3
I'll be following this for sure <3
Thanks! Linux beta will be out this month. Right now I'm working on fixing bugs and crashes and implementing missing crucial features.
Wrapping up the Linux GUI bit will only take a couple of days.
Wrapping up the Linux GUI bit will only take a couple of days.
Congratulations, we really need leaner IMs and from what I see it looks great!
If it supports some important features like file uploading, pinning and seeing pinned threads, etc. to reach Slack feature parity I'll surely take a shot.
Are you using QT for cross-platform compatibility or some other toolkit?
If it supports some important features like file uploading, pinning and seeing pinned threads, etc. to reach Slack feature parity I'll surely take a shot.
Are you using QT for cross-platform compatibility or some other toolkit?
If I was using Qt, it'd be at least 25 MB, not 100 KB :)
It's all native.
Pinning is supported, just temporarily disabled. File support is not great right now. Only inline images are supported.
But the goal is of course to have full feature parity and more, so follow the development :)
A lot is going to be done by the end of March.
It's all native.
Pinning is supported, just temporarily disabled. File support is not great right now. Only inline images are supported.
But the goal is of course to have full feature parity and more, so follow the development :)
A lot is going to be done by the end of March.
> If I was using Qt, it'd be at least 25 MB, not 100 KB :)
Not on Ubuntu/Arch/etc... :)
Not on Ubuntu/Arch/etc... :)
Well, Qt would still take up that space. It's just that on those platforms it's likely installed elsewhere and used by enough other things that it's closer to the "general userland size" category than it is to any one "specific application size".
Of course, that's what I meant, unlike at least as many copies of Chromium as electron apps.
Can you build it for all the 4 architectures supported by Windows (x86/x64/arm/arm64)? As it's not open source, recompilation cannot be done.
It's x86 right now, so it should run on x64. Is it possible to compile WinAPI apps for arm?
Yeah it is.
Looks cool, but do you have any intention on supporting macOS Sierra (or earlier versions)?
> You have macOS 10.12.6. The application requires macOS 10.13 or later.
> You have macOS 10.12.6. The application requires macOS 10.13 or later.
The macOS bundle is not set up correctly right now, that's why it doesn't work on older versions of macOS.
Run it from Terminal for now:
~/Downloads/eul.app/Contents/MacOS/eul
I'll fix this in v0.31.
Run it from Terminal for now:
~/Downloads/eul.app/Contents/MacOS/eul
I'll fix this in v0.31.
eul takes forever to start first time. maybe you should tell user in advance. I thought it couldn't start at all.
Yeah, it's a bug. Will be fixed soon. Shouldn't take too long unless you have a really slow connection. It downloads 300 KB of icons.
I don't know the numbers, but if there's not a lot of users/companies using these alternative protocols, it makes sense not to support them. I'd do the same thing.
The Facebook/Twitter analogy is flawed, because those are ad-supported businesses, so the company has a strong financial interest in having users on its own/primary platform, where it can deliver ads. I think that's not the case with Slack (?). But even there, I think the incentive to not support N protocols is not to get the +0.1% revenue from IRC/XMPP users, it's velocity/simplicity in product development, which is worth more money in the long term.
Disclaimer: I worked for FB previously, on Workplace, which is a direct competitor to Slack.
The Facebook/Twitter analogy is flawed, because those are ad-supported businesses, so the company has a strong financial interest in having users on its own/primary platform, where it can deliver ads. I think that's not the case with Slack (?). But even there, I think the incentive to not support N protocols is not to get the +0.1% revenue from IRC/XMPP users, it's velocity/simplicity in product development, which is worth more money in the long term.
Disclaimer: I worked for FB previously, on Workplace, which is a direct competitor to Slack.
I think it's even worse than "supporting" it, it was breaking their UX if certain users didn't have certain features (namely threads).
Disclaimer: I hate threads in slack
Disclaimer: I hate threads in slack
> Disclaimer: I hate threads in slack
When you already have too many channels, and then they give you the ability to have too many threads.
I feel like they do a worse job at the supposed value add of being able to archive and later refer to a topic of conversation than channels simply because they are so light weight and proliferate so many of them, potentially.
Plus it's really jarring to be pulled into a bunch of threads.
When you already have too many channels, and then they give you the ability to have too many threads.
I feel like they do a worse job at the supposed value add of being able to archive and later refer to a topic of conversation than channels simply because they are so light weight and proliferate so many of them, potentially.
Plus it's really jarring to be pulled into a bunch of threads.
I think the too-many-channels problem is a symptom of the excessive walled gardening.
Slack segregates by interests and social group, and bundles that with strict gatekeeping. There is no way for people to remix that to suit their own preferences. You can only fragment existing communities more.
I would love a slack multiclient where I can put channels I care about side by side, regardless of origin, and keep the rest out of sight. Instead now everyone has their own #random and #offtopic and so on. Cruising between Slacks and Discords is like navigating a hall of mirrors. If there is disagreement, the only solution is complete schism.
Slack segregates by interests and social group, and bundles that with strict gatekeeping. There is no way for people to remix that to suit their own preferences. You can only fragment existing communities more.
I would love a slack multiclient where I can put channels I care about side by side, regardless of origin, and keep the rest out of sight. Instead now everyone has their own #random and #offtopic and so on. Cruising between Slacks and Discords is like navigating a hall of mirrors. If there is disagreement, the only solution is complete schism.
Slack's use as a "community" chatbox is a mangling of its original intent to be used by teams. That's where your pain points are coming from, and some of my own (no /ignore feature, for instance).
I have some of the same issues, but I'm not part of any community slacks. I run my own consulting company, and as such, I've been invited to most of my client's slacks. So I've currently got 37 Slack workspaces going. But most of the time, I'm only concerned with the specific project channel that I'm working on for a client, and I might only be active in 2-3 projects at a time. So I'd love, like OP, to be able to just have those 3 channels front and center.
That's definitely a use case I hadn't considered.
The point is that with XMPP at least, they could add those features. They presented their case as if it couldn't be done with XMPP, which is not true.
Probably the subtext here is that they didn't feel it was worth the effort of doing double work for all their new features.
Then they could at least say so. Not making some BS excuses.
What difference would it make to anyone if they added "...and yeah, we could fix it, but we don't see it as worthwhile" to the end of the post?
Without the additional text it reads like it's the fault of XMPP/IRC.
I really recommend checking out Zulip. It's open source, and they do threading so much better than everyone else.
Making your UI so that it doesn't break is the very definition of supporting it.
The particulars of each one's business model is moot if they're all incentivized similarly (which is to lock-in users and to hoard their data).
Lockin could mean they use the service, or stronger, they use the service on the official UI (which may have ads). I think for Slack, the first type of lockin is enough (a paying user is a paying user, whether they use IRC or slack.com), whereas for FB the second type of lockin is better because only that can be monetized.
Yeah, I think this article is needlessly paranoid. I've seen no evidence that their protocol connectors pose any threat to their main business. Like you, I believe that the real problem is development velocity.
As much as I'd like to live in a world where open protocols and federated services evolve as quickly and turn out as well as proprietary solutions, that's apparently not the world I'm living in. Email, as much as I love it, is basically stagnant. IRC existed long before Slack, and if it had been truly successful, Slack would never have existed because there would not have been a market niche. And having recently written a bunch of XMPP code to talk to my vacuum [1], I was entirely underwhelmed. Whereas Slack is a product I use daily because it just works, and works well.
[1] http://github.com/wpietri/sucks
As much as I'd like to live in a world where open protocols and federated services evolve as quickly and turn out as well as proprietary solutions, that's apparently not the world I'm living in. Email, as much as I love it, is basically stagnant. IRC existed long before Slack, and if it had been truly successful, Slack would never have existed because there would not have been a market niche. And having recently written a bunch of XMPP code to talk to my vacuum [1], I was entirely underwhelmed. Whereas Slack is a product I use daily because it just works, and works well.
[1] http://github.com/wpietri/sucks
Oblique to the predictable Slack XMPP decision, but relevant to federation: Mastondon is a facinating federated social network. It addresses the identity/reputation issues without embracing fb-fascism or one-site-to-rule-them-all nonsense.
https://joinmastodon.org/
How it works Anyone can run a server of Mastodon. Each server hosts individual user accounts, the content they produce, and the content they subscribe to.
Each user account has a globally unique name (e.g. @[email protected]), consisting of the local username (@user), and the domain name of the server it is on (example.com).
Users can follow each other, regardless of where they’re hosted — when a local user follows a user from a different server, the server subscribes to that user’s updates for the first time.
https://joinmastodon.org/
How it works Anyone can run a server of Mastodon. Each server hosts individual user accounts, the content they produce, and the content they subscribe to.
Each user account has a globally unique name (e.g. @[email protected]), consisting of the local username (@user), and the domain name of the server it is on (example.com).
Users can follow each other, regardless of where they’re hosted — when a local user follows a user from a different server, the server subscribes to that user’s updates for the first time.
There is also GNU social; which is what Mastodon is based off of. I have been thinking about hosting a server for awhile. Pretty cool stuff.
I do host my own mastodon server with a small community, the initial setup is a bit complicated but once you get it going upgrades are nice and easy (each update contains all shell commands necessary outside `git fetch` and `git checkout v{VERSION}`)
Only downside of course is that if you selfhost alone, your federated timeline will be a bit empty, I do recommend either finding a community or starting one to get a bit more activity (Mastodon is essentially geared towards a sort of "community neighborhood" decentralization, where only one in a few hundred or thousand users needs to run a server, on average)
Only downside of course is that if you selfhost alone, your federated timeline will be a bit empty, I do recommend either finding a community or starting one to get a bit more activity (Mastodon is essentially geared towards a sort of "community neighborhood" decentralization, where only one in a few hundred or thousand users needs to run a server, on average)
Unfortunately ActivityPub (that powers Mastodon) has a lot of incidental complexity (including RSA signatures, JSON-LD, RDF normalizations to quads etc.)
But this is a very simple alternative, distributed "Twitter" for hackers: https://github.com/buckket/twtxt#twtxt
But this is a very simple alternative, distributed "Twitter" for hackers: https://github.com/buckket/twtxt#twtxt
It seems rather easy to impersonate other users, though. Similar to how one can impersonate domains by being one letter off or something like that.
I'm not sure how battle hardened Mastodon is, obviously they don't have the resources of Twitter or Facebook. Probably easy to DDOS an individual server. However, it might be possible for other nodes to transparently cache updates.
As to spoofing, we've got to move beyond humans memorizing unicode strings or profile pictures as a means of identity validation. Its shambolic enough that twitter users constanly change their display string, obscuring the twitter handle, but even without that problem, how many people send bitcoin/ethereum to @eloon_musk?
As to spoofing, we've got to move beyond humans memorizing unicode strings or profile pictures as a means of identity validation. Its shambolic enough that twitter users constanly change their display string, obscuring the twitter handle, but even without that problem, how many people send bitcoin/ethereum to @eloon_musk?
People do the same on other platforms. I've been impersonated on a social media platform via a two letter swap.
I don't think it needs a solution, administrators of instances have to solve this, first by asking to offending instance to ban the user, mute the user and if the instance doesn't do anything about repeated abuse, mute the instance.
I don't think it needs a solution, administrators of instances have to solve this, first by asking to offending instance to ban the user, mute the user and if the instance doesn't do anything about repeated abuse, mute the instance.
This will be a problem on any platform that allows users to choose their own names.
IIRC, for quite a while Slack even allowed two people in the same channel to have identical display names.
IIRC, for quite a while Slack even allowed two people in the same channel to have identical display names.
I, like many others, are starting to fall out of love with Slack. This may well be the straw that breaks the camels back.
- Resource hogging - Buggy iOS app (especially on iPhone X) - Missing accessibility features - Lack of native app
They've taken $0.75bn in funding over 10 rounds and still suffer from some _basic_ issues.
- Resource hogging - Buggy iOS app (especially on iPhone X) - Missing accessibility features - Lack of native app
They've taken $0.75bn in funding over 10 rounds and still suffer from some _basic_ issues.
Also:
- Mentions: Many times I've tried to mention someone but Slack goes and picks the wrong person. If I'm typing `@johnd`, then it should be fairly evident that I'm trying to mention `@johndoe`; don't make me go through that UI when you should have enough info already.
- Buggy snippets: Why do I have to go through a slow UI just to paste some code, when triple-backtick should be enough?
- Triple-backtick: No code highlighting. And just try to copy its content; you'll be surprised when your clipboard looks as if passed through an `s/\n/\n\n/g` filter.
- Scroll up: Scrolling up many pages above causes some weird jumps.
---
Incidentally, the Discord people got all these things right.
- Mentions: Many times I've tried to mention someone but Slack goes and picks the wrong person. If I'm typing `@johnd`, then it should be fairly evident that I'm trying to mention `@johndoe`; don't make me go through that UI when you should have enough info already.
- Buggy snippets: Why do I have to go through a slow UI just to paste some code, when triple-backtick should be enough?
- Triple-backtick: No code highlighting. And just try to copy its content; you'll be surprised when your clipboard looks as if passed through an `s/\n/\n\n/g` filter.
- Scroll up: Scrolling up many pages above causes some weird jumps.
---
Incidentally, the Discord people got all these things right.
- Terrible, unacceptable mobile performance. Often unusable over semi-reliable networks. "Connecting..."
750 million USD?
This article fusses about how big mean slack took advantage of people by providing a free service and then dropping support for a protocol. I think Twitter’s treatment of developers perpetuated a David-v-Goliath storyline in which developers inevitably get short shrift while corporations take the profits.
But this is different. Slack is a business and they’re making a business decision. I’ve never heard them imply that IRC would be a core part of their business. The vast majority of their user base has never even heard of IRC. It doesn’t make sense for them to spend money to support a feature used by 0.5% of their users.
If IRC support is so important, build a business that supports IRC and get people to pay for it.
Until then, can we stop acting like the mean boy on the playground stole our lunch?
But this is different. Slack is a business and they’re making a business decision. I’ve never heard them imply that IRC would be a core part of their business. The vast majority of their user base has never even heard of IRC. It doesn’t make sense for them to spend money to support a feature used by 0.5% of their users.
If IRC support is so important, build a business that supports IRC and get people to pay for it.
Until then, can we stop acting like the mean boy on the playground stole our lunch?
From the XMPP Foundation:
https://twitter.com/ralphm/status/971461404900372480
https://twitter.com/ralphm/status/971461404900372480
With this attitude of the XMPP Foundation, I doubt XMPP have any future. Better question would be to ask what should be improved in XMPP so that they could implement that properly.
Why? Facebook, google, slack are not using XMPP internally for chat products, because of technical reasons. They dropped XMPP gateway for mix of technical and strategic reasons. Instead of trying to be a warrior for technical correctness, XMPP foundation should rather seek feedback and try to make sure that developers integrating with XMPP will do everything correctly as easy as possible. Otherwise, more and more projects would be dropping XMPP support.
Why? Facebook, google, slack are not using XMPP internally for chat products, because of technical reasons. They dropped XMPP gateway for mix of technical and strategic reasons. Instead of trying to be a warrior for technical correctness, XMPP foundation should rather seek feedback and try to make sure that developers integrating with XMPP will do everything correctly as easy as possible. Otherwise, more and more projects would be dropping XMPP support.
Let me first turn this around. I actually personally tried to interact with the Slack team on how they implemented their XMPP gateway, early on. I pointed out how a relatively small missing protocol feature (server-side group chat bookmarking) was severely impacting the usability of the gateway, as it caused caused you to have to explicitly join the group chat room representing a Slack channel on every client (re)connect. In fact they violated protocol in case a client requested the list of bookmarks, causing clients to hang while connecting. It took them a year to start responding, and the problem was not fixed.
Additionally I had pointed that their statements on XMPP security were factually wrong. No useful response or changes were made.
That all said, I really like a bunch of things about Slack and have repeatedly pointed out in discussions in the XMPP community that there is a lot to be learned from Slack in terms of features (and how they work technically), UI consistency, and usability. As JC points out, this is surprisingly hard to achieve in open source projects. Even harder to pull off for a very diverse community around a set of protocols, rather than a single software product.
There are also things in Slack that I think would be a lot better if they were modelled after recent protocol proposals in XMPP. For example we are working on something called MIX, an evolution on group chat, based on Publish-Subscribe. This allows for orthogonal streams of information bound to a channel, besides just chat and presence, like merge request notifications, Twitter mentions, etc. that could be displayed in a side-bar or ticker, instead of (annoyingly) interleaved with chat messages.
I would have welcomed Slack interacting with the community, but they didn't.
Additionally I had pointed that their statements on XMPP security were factually wrong. No useful response or changes were made.
That all said, I really like a bunch of things about Slack and have repeatedly pointed out in discussions in the XMPP community that there is a lot to be learned from Slack in terms of features (and how they work technically), UI consistency, and usability. As JC points out, this is surprisingly hard to achieve in open source projects. Even harder to pull off for a very diverse community around a set of protocols, rather than a single software product.
There are also things in Slack that I think would be a lot better if they were modelled after recent protocol proposals in XMPP. For example we are working on something called MIX, an evolution on group chat, based on Publish-Subscribe. This allows for orthogonal streams of information bound to a channel, besides just chat and presence, like merge request notifications, Twitter mentions, etc. that could be displayed in a side-bar or ticker, instead of (annoyingly) interleaved with chat messages.
I would have welcomed Slack interacting with the community, but they didn't.
Thanks for adding more context! It's hard to get that from twitter, sorry.
Facebook and Google? They use IRC internally for technical reasons. IRC doesn't fall over. Googlers internally revolted when they were told to use Hangouts internally.
XMPP works great and I've used it at several employers. There's no technical reasons to avoid it; it really is all about lock-in and corporate planning.
I've watched Ralph struggle for years against corporate asshats. It's a real tragedy that all these companies don't participate in open standards. We shouldn't have ever expected good things from Slack.
XMPP works great and I've used it at several employers. There's no technical reasons to avoid it; it really is all about lock-in and corporate planning.
I've watched Ralph struggle for years against corporate asshats. It's a real tragedy that all these companies don't participate in open standards. We shouldn't have ever expected good things from Slack.
> Facebook and Google? They use IRC internally for technical reasons. IRC doesn't fall over. Googlers internally revolted when they were told to use Hangouts internally.
I was talking about implementation of Facebook messenger, or Google hangout (which does not use XMPP), not what is used internally for communication.
Also, at Facebook, messenger is most used product internally. IRC is still used, but not that much (depends on org, infra devs use IRC more than product devs). But IRC is still essential, in case of emergencies (where you don't want to use your own product, as it may be down).
I was talking about implementation of Facebook messenger, or Google hangout (which does not use XMPP), not what is used internally for communication.
Also, at Facebook, messenger is most used product internally. IRC is still used, but not that much (depends on org, infra devs use IRC more than product devs). But IRC is still essential, in case of emergencies (where you don't want to use your own product, as it may be down).
They could implement what properly? According to the tweet XMPP supports this. Slack just doesn't care.
I like the attitude of telling the truth. Compare to Torvalds.
I like the attitude of telling the truth. Compare to Torvalds.
> I like the attitude of telling the truth. Compare to Torvalds.
Care to elaborate?
Care to elaborate?
I just like it when people flame and insult when it's deserved. A nice contrast to the "happy world; I get triggered by everything" stuff.
> Otherwise, more and more projects would be dropping XMPP support.
Eve Online just abandoned their own in game chat server and replaced it with ejabberd.
Eve Online just abandoned their own in game chat server and replaced it with ejabberd.
> Slack's business model is to record everything said in a workspace and then to sell you access to their record of your conversations.
Whilst this is partially true, One of the key features enterprises need and that Slack supplies is the ability to fully export messages for transfer and compliance purposes.
One of the main differentiators between paid and unpaid slack is message retention. To my knowledge, I don't think the XMPP and IRC were used by anyone to overcome this limit but I'm pretty sure it's been done using their API.
They haven't shut of usage of their API for this purpose so I'm pretty sure that lost sales is the motivation behind this change.
The OP talks about the relevant ways Slack can implement features into their XMPP and IRC endpoints to allow new features. But this probably generates a lot of technical debt for a feature that isn't used by many people. (Also, anecdotally, I've found very few XMPP clients that actually support any of the proposed extensions).
Whilst this is partially true, One of the key features enterprises need and that Slack supplies is the ability to fully export messages for transfer and compliance purposes.
One of the main differentiators between paid and unpaid slack is message retention. To my knowledge, I don't think the XMPP and IRC were used by anyone to overcome this limit but I'm pretty sure it's been done using their API.
They haven't shut of usage of their API for this purpose so I'm pretty sure that lost sales is the motivation behind this change.
The OP talks about the relevant ways Slack can implement features into their XMPP and IRC endpoints to allow new features. But this probably generates a lot of technical debt for a feature that isn't used by many people. (Also, anecdotally, I've found very few XMPP clients that actually support any of the proposed extensions).
My biggest issue with Slack is that on the free plan they store everything forever, but only allow you to access the last 10,000 messages.
I'm fine with limits, but the users should be free to delete messages beyond the limit. It's my data that I entered in and they are preenting me from deleting it which is a pretty nasty thing to do.
I suspect this will all change in May when the GDPR comes into play. The policy is clearly not compliant. They will likely either need to allow for deletion, or give users access to the data (even on free accounts).
I'm fine with limits, but the users should be free to delete messages beyond the limit. It's my data that I entered in and they are preenting me from deleting it which is a pretty nasty thing to do.
I suspect this will all change in May when the GDPR comes into play. The policy is clearly not compliant. They will likely either need to allow for deletion, or give users access to the data (even on free accounts).
Existing EU data protection law since the mid 90s gives people the right to get a copy of their personal data, with big players, like Facebook, supporting it for years.
I don't know if Slack has any offices or entity in the EU, but you could try making an access request today./
I don't know if Slack has any offices or entity in the EU, but you could try making an access request today./
They take money from EU clients, in Euros, so they are bound by EU law. GDPR will tighten the net around this sort of business models.
> One of the main differentiators between paid and unpaid slack is message retention. To my knowledge, I don't think the XMPP and IRC were used by anyone to overcome this limit but I'm pretty sure it's been done using their API.
If I understand you correctly, you're saying that you don't know about any message retention facilities for IRC. irclogger and logbot do that.
If I understand you correctly, you're saying that you don't know about any message retention facilities for IRC. irclogger and logbot do that.
OP must have little idea or has given little thought to how hard it can be to maintain on-going support for a feature a very, very tiny percentage of customers use.
As far as I know, Slack never pitched as the guys who would rescue IRC out of obscurity and into mainstream. If they did, then you could perhaps fault them for giving up too easily without serious effort.
As far as I know, Slack never pitched as the guys who would rescue IRC out of obscurity and into mainstream. If they did, then you could perhaps fault them for giving up too easily without serious effort.
What do you guys think about using Discourse as an alternative?
It's not quite real time chat, but it almost is. You get the same attachments / decent UI benefits of Slack, it's open source, you can self host it without too much pain and it has a pretty nice API. No limitations on chat history too.
I think in some ways it's much better than Slack because you have proper categories and threads so I think Discourse is a million times better if you're looking to use it as a mailing list alternative.
In some ways it's worse than Slack because there's something very nice about just having to enter in 1 line of chat to get a message across, but with Discourse you would have to start a thread in some category.
I'm going to be using either Slack or Discourse to build a private community but I haven't decided on which one yet.
In case you've never heard of Discourse before, here's a live demo hosted on their official site https://try.discourse.org/.
It's not quite real time chat, but it almost is. You get the same attachments / decent UI benefits of Slack, it's open source, you can self host it without too much pain and it has a pretty nice API. No limitations on chat history too.
I think in some ways it's much better than Slack because you have proper categories and threads so I think Discourse is a million times better if you're looking to use it as a mailing list alternative.
In some ways it's worse than Slack because there's something very nice about just having to enter in 1 line of chat to get a message across, but with Discourse you would have to start a thread in some category.
I'm going to be using either Slack or Discourse to build a private community but I haven't decided on which one yet.
In case you've never heard of Discourse before, here's a live demo hosted on their official site https://try.discourse.org/.
If you can figure out how to bootstrap it, Discourse will provide your community with more long-term value as it becomes a valuable, organized store of community information new members or potential new members can browse to learn about the community.
Slack is great for realtime interaction and a short term dopamine hit, but is also a black hole for information. This is especially true when you're using it for a community and not paying to have access to your old messages.
Slack is great for realtime interaction and a short term dopamine hit, but is also a black hole for information. This is especially true when you're using it for a community and not paying to have access to your old messages.
Yeah, basically I have a bunch of people who signed up to my programming courses and I want to give them a place to hang out, ask questions and interact with each other.
I've used Slack with other organizations and it really is a black hole. Not just for the 10,000 history limitation, but it's really hard to find and read previous conversations.
I've used Slack with other organizations and it really is a black hole. Not just for the 10,000 history limitation, but it's really hard to find and read previous conversations.
Discourse has the advantage of having some sort of moderation tools included - people can have discrete permissions and rights, unlike Slack where everyone's equal - but the lack of a join/part for channels is annoying, and the inability for admins to create private channels is very frustrating.
When I try to sign up for https://inverse.chat, I'm given the following information:
> Create your account > Please enter the XMPP provider to register with: > Tip: A list of public XMPP providers is available here.
When I click on the XMPP providers, I'm taken here:
https://xmpp.net/directory.php
There's like a hundred options, so now I just close the tab and give up because I have no idea what to pick.
Can you instead provide a sign up form that let's me sign up directly to a default provider? The process should mirror how webmail works, e.g. when you visit outlook.com, gmail, fastmail etc. you also end up with an email account with them.
> Create your account > Please enter the XMPP provider to register with: > Tip: A list of public XMPP providers is available here.
When I click on the XMPP providers, I'm taken here:
https://xmpp.net/directory.php
There's like a hundred options, so now I just close the tab and give up because I have no idea what to pick.
Can you instead provide a sign up form that let's me sign up directly to a default provider? The process should mirror how webmail works, e.g. when you visit outlook.com, gmail, fastmail etc. you also end up with an email account with them.
The server input suggests conversejs.org, you can use that as a default.
Nope - conversejs is just the front end.
Even if I go to conversejs.org I still have to pick a public XMPP provider when trying to use this for the first time (what is that, what are the implications of picking one, why is one better than then other, which Geo should I pick, why do some have weird names, ...)
Even if I go to conversejs.org I still have to pick a public XMPP provider when trying to use this for the first time (what is that, what are the implications of picking one, why is one better than then other, which Geo should I pick, why do some have weird names, ...)
It's not just the frontend, there's also an XMPP server hosted under conversejs.org, so you can have an account like [email protected]
I can't understand HN's algo. This story is 5 hours old with 202 comments and 552 points, and currently ranked at 15 on my list. Whereas there's another story 8 hours old with 89 points that's at 4. It always strikes me as more than a coincidence when startups that YC is affiliated with (Slack has purchased a few YC alum companies) get their bad news briefly commented on, then buried.
Yeah this dropped off the front page very quickly. Came back to find the comments probably half an hour after viewing it at the 5th spot, but it was no longer there.
It's obvious why it's done but always serves as a reminder of HNs lack of impartiality on submissions.
It's obvious why it's done but always serves as a reminder of HNs lack of impartiality on submissions.
What are some highly recommended XMPP servers? I've only ever used one that would always crash on me. I'm looking for something that I can run on DO for $5 a month without issues.
Edit:
Also for anyone who wants a simple to setup IRCd I highly recommend ngIRCd. Setup is as simple as: sudo apt install ngircd
See:
https://ngircd.barton.de/
Edit:
Also for anyone who wants a simple to setup IRCd I highly recommend ngIRCd. Setup is as simple as: sudo apt install ngircd
See:
https://ngircd.barton.de/
Ejabberd and Prosody. Ejabberd has the most features and massive scalability (millions of concurrent connections), but it's not trivial to set up. Prosody is usually a five minute set up to get up and running and scales pretty well with luaevent installed.
For prosody you'll need the community modules repository from https://modules.prosody.im/ to have modern features.
Also please don't enable public registration on your server, or it will become a spam relay in a matter of weeks: https://yaxim.org/blog/2017/12/22/spam-reduction-on-yax-dot-...
It's perfectly fine to host XMPP for family&friends, and you can give them access directly if needed.
Also please don't enable public registration on your server, or it will become a spam relay in a matter of weeks: https://yaxim.org/blog/2017/12/22/spam-reduction-on-yax-dot-...
It's perfectly fine to host XMPP for family&friends, and you can give them access directly if needed.
A bunch of people I know run Prosody for that.
> Still, there's nothing fundamental about XMPP that prevents emoji reactions, and work is currently underway to add support for them.
> The protocol is designed to be eXtensible (hence the X in XMPP) and new features are continuously being added.
I would like to see an alternate history where Slack is built entirely on XMPP, with plenty of extensions to support all the customisations for every feature they have now.
My theory is that people would complain about how many extensions are required for third party clients to implement before you get a passable experience.
> The protocol is designed to be eXtensible (hence the X in XMPP) and new features are continuously being added.
I would like to see an alternate history where Slack is built entirely on XMPP, with plenty of extensions to support all the customisations for every feature they have now.
My theory is that people would complain about how many extensions are required for third party clients to implement before you get a passable experience.
> I would like to see an alternate history where Slack is built entirely on XMPP, with plenty of extensions to support all the customisations for every feature they have now.
Writing and maintaining a protocol and a client and a server is certainly harder than just having a private proprietary protocol.
For what it is worth it seems XMPP is cherry picking features proven in proprietary protocols and standardizing them. It seems like there is a small set of such critical features as can be seen by supported XEPs in modern clients (https://dino.im/ https://conversations.im/).
Writing and maintaining a protocol and a client and a server is certainly harder than just having a private proprietary protocol.
For what it is worth it seems XMPP is cherry picking features proven in proprietary protocols and standardizing them. It seems like there is a small set of such critical features as can be seen by supported XEPs in modern clients (https://dino.im/ https://conversations.im/).
Anybody using matrix protocol? And riot.im client? Thoughts?
Riot has everything Slack does, but it's more competent and free. And obviously the main selling point is compatibility with all kinds of other chats.
>Riot has everything Slack does
Gitlab integration?
Gitlab integration?
Yes, of course. But unlike Slack you are not limited to "official" "integrations", you can add arbitrary widgets and can write your own.
At my workplace we use Rocket.chat and it does have GitLab integration, so there's another possible alternative.
I'm running the reference Matrix server (Synapse) on my home computer, and I'm using the Riot.im client. I mainly use it to communicate with a group of three friends. They are using Android, and I'm using an iPhone.
It seems to work about as well as any other messaging app, which is impressive if you ask me, considering it's completely open and self-hosted.
It seems to work about as well as any other messaging app, which is impressive if you ask me, considering it's completely open and self-hosted.
It's better than Slack in terms of usability, performance and UI (subjective), but lacks some integrations that Slack has. Search engine is quite poor (not that Slack is any better, it's shit too).
> So they have to close everything off, to make sure that people can't extract their conversations out of the silo.
I totally agree with article itself, but this is rather moot point. Slack still provide full history export for free and it's rather easy to self-host said history. IRC and XMPP didn't made it any easier to extract that data.
I aware that export doesn't include private messages, but it's not what Slack used for mostly anyway.
I totally agree with article itself, but this is rather moot point. Slack still provide full history export for free and it's rather easy to self-host said history. IRC and XMPP didn't made it any easier to extract that data.
I aware that export doesn't include private messages, but it's not what Slack used for mostly anyway.
> Slack still provide full history export for free
Wrong. If you want to export messages earlier than the last 10k, Slack will extort you to the tune of $10 per user (even if they aren't active). And that's per fucking month. Does your startup/club/laboratory of 29 people have $290/mo of income to incinerate, when you could just host an AWS IRC server for 1% of that?
Wrong. If you want to export messages earlier than the last 10k, Slack will extort you to the tune of $10 per user (even if they aren't active). And that's per fucking month. Does your startup/club/laboratory of 29 people have $290/mo of income to incinerate, when you could just host an AWS IRC server for 1% of that?
Before making comment that you claim is false I went to our team management panel and exported full history for our team since 2016. It's not super active team we have, but it's still 20MB of logs in JSON and 64939 messages according to simple grep:
grep '"text"' "./VCMI Slack export Mar 12 2018" -rn | wc -l
[deleted]
Everytime someone mentions bait and switch it is always about someone who is not paying for the service/product.
You found a way to not pay for the service, they decided to close it, you are angry that either you have to pay or find alternative.
I'm a huge fan of increasing our freedoms. But truth is there are things a lot bigger than even a few humans together. e.g. a vulcano breaks out means you can't go on top of the Vulcano without dying. A big corp or government wants your data, they will get it one way or another. So the goal of freedom cannot be reached. You always depend on something.
However, that doesn't mean one shouldn't try to keep power over ones own life by accepting to work hard for it, by accepting to not use some maybe-nice-but-exploitative things, etc, by spending money and votes on people and projects and politicians who fight for freedom of everybody.
I feel at work Slack is really the right thing, because what you produce there is not free anyways. My company owns the data I produce at work. So why shouldn't they own the chat logs (and pay for it)? For opensource and spare time projects certainly IRC and XMPP are the way to go.
Therefore I'm not really pissed with Slack, but with the people who choose to use Slack for things where it's clearly not the right solution. It's a Sisyphean decision, though. Because you can't really make people not let themselves be exploited, especially if you try to give them freedom. The pain is that most people decide, totally freely, to sacrifice their freedom for a quick feeling of comfort.
However, that doesn't mean one shouldn't try to keep power over ones own life by accepting to work hard for it, by accepting to not use some maybe-nice-but-exploitative things, etc, by spending money and votes on people and projects and politicians who fight for freedom of everybody.
I feel at work Slack is really the right thing, because what you produce there is not free anyways. My company owns the data I produce at work. So why shouldn't they own the chat logs (and pay for it)? For opensource and spare time projects certainly IRC and XMPP are the way to go.
Therefore I'm not really pissed with Slack, but with the people who choose to use Slack for things where it's clearly not the right solution. It's a Sisyphean decision, though. Because you can't really make people not let themselves be exploited, especially if you try to give them freedom. The pain is that most people decide, totally freely, to sacrifice their freedom for a quick feeling of comfort.
My major preference for Slack was replacing Skype chats, so there was no loss in terms of open source.
Lots of people complain that it's just a fancy IRC client, but they don't realise how painless it is to get non-tech people to start using it.
But quite clearly there needs to be a fully open sourced alternative.
I think WordPress is a great example of how it should be done. Provide a super simple way to create xxx.slackclone.com in exactly the same number of steps as it takes to create a slack group whilst also providing something that you can download and install yourself.
I think any project would have to be in PHP. Perhaps that sounds stupid but I think again following the WordPress model is a good track. PHP is the most easy way for low-tech people to get their own up and running. It should be as easy as the 5-minute WordPress install to get your own server.
edit: Plus PHP is what Slack is built on and I quite like the irony. The further irony though is that WordPress use Slack now. Perhaps in a similar way that WordPress fought against the React licensing they might replace Slack if there was a good enough clone.
As far as I can tell the aim could be to create as close as possible a clone of slack, ripping off as many features as possible without stepping over a boundary where Slack could try and shut you down.
Lots of people complain that it's just a fancy IRC client, but they don't realise how painless it is to get non-tech people to start using it.
But quite clearly there needs to be a fully open sourced alternative.
I think WordPress is a great example of how it should be done. Provide a super simple way to create xxx.slackclone.com in exactly the same number of steps as it takes to create a slack group whilst also providing something that you can download and install yourself.
I think any project would have to be in PHP. Perhaps that sounds stupid but I think again following the WordPress model is a good track. PHP is the most easy way for low-tech people to get their own up and running. It should be as easy as the 5-minute WordPress install to get your own server.
edit: Plus PHP is what Slack is built on and I quite like the irony. The further irony though is that WordPress use Slack now. Perhaps in a similar way that WordPress fought against the React licensing they might replace Slack if there was a good enough clone.
As far as I can tell the aim could be to create as close as possible a clone of slack, ripping off as many features as possible without stepping over a boundary where Slack could try and shut you down.
I agree, no idea why you are downvoted.
At my job the Slack was forced on us by boss, probably because of the hype, we were using Skype before and we still use it because the team was used to Skype, it worked good enough, slack just added for us extra distractions.
I think that even a good alternative appears if the hype is not enough it won't catch, also before Slack we used Hipchat for a short time, same story, it was imposed to the team because of the hype, in the end Slack got a bigger hype I assume.
I think that even a good alternative appears if the hype is not enough it won't catch, also before Slack we used Hipchat for a short time, same story, it was imposed to the team because of the hype, in the end Slack got a bigger hype I assume.
Slack grew compared to IRC. That showed the world what people want out of real-time messaging. Email grew relative to walled-garden solutions. That only shows what people want out of asynchronous messaging.
My conclusion to all this is that people tend to use synchronous messaging in teams, and asynchronous messaging for everything else. Interconnectivity is more important for asynchronous messaging. Ease of use is more important for synchronous messaging.
Email could never have been unseated by any of it's would-be competitors, whereas IRC was always bound to get usurped. It could never have kept up with the needs of the market.
Now synchronous messaging is moving in the direction that web browsers started moving 15 years ago. The killer app has been found, now entrants are going to compete on ideology, while the standards people try to balance the profit motive with the need for interoperability.
edit: missing is SMS, which occupies a weird middle ground between synchronous and asynchronous messaging. But its openness is more akin to email than Slack.
My conclusion to all this is that people tend to use synchronous messaging in teams, and asynchronous messaging for everything else. Interconnectivity is more important for asynchronous messaging. Ease of use is more important for synchronous messaging.
Email could never have been unseated by any of it's would-be competitors, whereas IRC was always bound to get usurped. It could never have kept up with the needs of the market.
Now synchronous messaging is moving in the direction that web browsers started moving 15 years ago. The killer app has been found, now entrants are going to compete on ideology, while the standards people try to balance the profit motive with the need for interoperability.
edit: missing is SMS, which occupies a weird middle ground between synchronous and asynchronous messaging. But its openness is more akin to email than Slack.
If you want "takeout", getting the last 10,000 messages from slack is a pretty easy programming exercise. "channels.history" works really well in their API. Considering that one of the up-sells they provide is better searching and access to more messages, I was surprised it was so easy to grab your history.
My team at work is using Slack and likes it. But, honestly, I don't think we'd pay a grand a year for it. We'd probably switch to Mattermost, which we already have set up as part of our underused gitlab server, or maybe to one of Slack's less expensive competitors. Though, there is some incentive for us staying with Slack, we have a couple custom bots. Over the last 2 years of use, the free account has rarely been too confining. Though the message history search isn't very usable, that's probably our biggest pain-point.
My team at work is using Slack and likes it. But, honestly, I don't think we'd pay a grand a year for it. We'd probably switch to Mattermost, which we already have set up as part of our underused gitlab server, or maybe to one of Slack's less expensive competitors. Though, there is some incentive for us staying with Slack, we have a couple custom bots. Over the last 2 years of use, the free account has rarely been too confining. Though the message history search isn't very usable, that's probably our biggest pain-point.
> For example, email is federated. You can set up your own email server, and then send emails to people with their own email servers, or to people with Gmail or Yahoo! accounts.
Gmail actually does control somewhat inbound email by restricting certain mail and flagging it as spam according to their own arbitrary definition of spam. Oddly that even ends up flagging mail from one gmail account you own to another gmail account (both @gmail and @domain with google apps). And even in cases where it is clear there is an existing relationship between the parties. Other providers do that as well. And there is not an easy way to prevent it from happening either as a sys admin or a user (there are jump through hoop ways of course). And ultimately yes they do treat email (despite my own example) on their own network differently than email coming from a domain outside their network.
Gmail actually does control somewhat inbound email by restricting certain mail and flagging it as spam according to their own arbitrary definition of spam. Oddly that even ends up flagging mail from one gmail account you own to another gmail account (both @gmail and @domain with google apps). And even in cases where it is clear there is an existing relationship between the parties. Other providers do that as well. And there is not an easy way to prevent it from happening either as a sys admin or a user (there are jump through hoop ways of course). And ultimately yes they do treat email (despite my own example) on their own network differently than email coming from a domain outside their network.
XMPP is a good machine for bait and switching. I discovered it after building my own AOL-like chat systems from scratch in high school, in VB, C, PHP, etc (many iterations) and engaged heavily. To this day all I hear when people talk about why not XMPP are lazy excuses. No doubt they come out as blaming XMPP rather than the hard problems it's solving at scrum meetings. I built a chat app backend recently and was met by FUD from senior engs on the team when I proposed it, and hostility by the CEO who trusted them... forced to build an MVC-based node backend PoC which wouldn't have scaled if I didn't already know how to build chat systems (force="this discussion is over" and "if you don't like it you can quit" type comments... which I did).
I even hate the sound of "surveillance capitalism". It sounds so evil and insidious.
explain it like I'm 5 please: why can't.we just build an actually user friendly IRC client (including non technical people) that doesn't look like a dos app, and add client specific extensions for expanding image urls inline, etc... ?
In theory, we can. However, building a well-working multi-platform chat client is a significant task, imagine a 5-10 person team working over a year, plus the long-term maintenance support.
IRC might not be the right protocol for that, because you'll be adding quirks on top of quirks, but you could easily do that with XMPP. However, you won't find anyone willing to sponsor that development. Old protocols like IRC and XMPP just don't cut it in Silicon Valley.
Examples for creating a new IM solution out of nothing, provided funding, include Signal and Matrix/Riot.
IRC might not be the right protocol for that, because you'll be adding quirks on top of quirks, but you could easily do that with XMPP. However, you won't find anyone willing to sponsor that development. Old protocols like IRC and XMPP just don't cut it in Silicon Valley.
Examples for creating a new IM solution out of nothing, provided funding, include Signal and Matrix/Riot.
The centralized nature of Slack actually makes it a lot _easier_/cheaper to develop, than developing for true federation. See for instance: https://signal.org/blog/the-ecosystem-is-moving/ and https://lwn.net/Articles/687294/
Okay, could you implement some IRC extensions to provide some of the features Slack has, deploy them on your own central server cluster, and provide a client that has access to those slack-like features with a UI as good or better than Slacks, so long as you're using channels on that server?
Sure, you totally could. You could even take the extra time and energy to make those extensions open standards instead of just something you did (and it definitely is lots of extra time and energy to do that). A lot of work, but not a lot of unsolved problems, it's pretty straightforward. You could do it with IRC or XMPP.
Now who's gonna pay for all that?
Okay, could you implement some IRC extensions to provide some of the features Slack has, deploy them on your own central server cluster, and provide a client that has access to those slack-like features with a UI as good or better than Slacks, so long as you're using channels on that server?
Sure, you totally could. You could even take the extra time and energy to make those extensions open standards instead of just something you did (and it definitely is lots of extra time and energy to do that). A lot of work, but not a lot of unsolved problems, it's pretty straightforward. You could do it with IRC or XMPP.
Now who's gonna pay for all that?
I don't particularly care if the thing that companies use for private chat isn't open-source and doesn't have an open gateway, but it does worry me a bit that Slack has slowly started to replace IRC for open-source software support.
Typically if I need help with something FLOSS, I open up my Weechat and log onto Freenode, however increasingly I'm seeing FLOSS projects go to Slack (like Elementary OS). I understand that Slack is simpler, but it's also kind of antithetical to use a proprietary protocol for something open.
Typically if I need help with something FLOSS, I open up my Weechat and log onto Freenode, however increasingly I'm seeing FLOSS projects go to Slack (like Elementary OS). I understand that Slack is simpler, but it's also kind of antithetical to use a proprietary protocol for something open.
Seems like there is a opening for someone to start something similar to freenode but for XMPP. Or Freenode could run a XMPP<->IRC gateway.
Love the idea! XMPP was well on its way to dominate until Apple released the iPhone and killed XMPP with the APNS requirement. Here's hoping we can go back to the federated model.
There is some serious work on making federated XMPP work together with APNS.
The iOS client developer needs to run a proxy server that will accept notifications from XMPP servers and wake up the client via APNS (this is required by how APNS authentication works).
The client can connect to any server that supports XEP-0357: Push Notifications [0], and can register the respective push proxy with the XMPP server.
ChatSecure for iOS [1] has implemented this approach, but the client still needs some more polish.
[0] https://xmpp.org/extensions/xep-0357.html
[1] https://chatsecure.org/
The iOS client developer needs to run a proxy server that will accept notifications from XMPP servers and wake up the client via APNS (this is required by how APNS authentication works).
The client can connect to any server that supports XEP-0357: Push Notifications [0], and can register the respective push proxy with the XMPP server.
ChatSecure for iOS [1] has implemented this approach, but the client still needs some more polish.
[0] https://xmpp.org/extensions/xep-0357.html
[1] https://chatsecure.org/
[deleted]
Hard to believe this is the same people who once worked in Glitch[0] and I wager that long after Slack is dead and buried, people will probably remember "that one quirky online game" with more fond memories than their productivity and resource-sapping amnesiac-unless-you-pay-up abomination of a product.
[0] https://www.glitchthegame.com/
[0] https://www.glitchthegame.com/
Is there an open source IRC/XMPP (or Matrix) client with features similar to Slack (side-threads, pinned messages) and preferably not using electron?
Well Riot (Matrix and indirectly IRC client) has pinned messages and will soon have message threading but it is a web app (although it does have native mobile apps).
This is the same old model; give them something free, then monetize it. Thankfully, the internet allows us to just go somewhere else or write your own. https://medium.com/@benhansen/lets-build-a-slack-clone-with-...
[deleted]
Taking services away hurts everyone more than never giving them in the first place. The author of this article feels betrayed. However, I doubt anyone intended to bait customers with extra value added services just to take them away later. More likely, managers eventually addressed costs or developed new business models.
> You can set up your own email server, and then send emails to people with their own email servers, or to people with Gmail or Yahoo! accounts.
Well, there’s a good chance they’ll go straight to the SPAM folder if you just bring your server up, but yes, you can try.
Well, there’s a good chance they’ll go straight to the SPAM folder if you just bring your server up, but yes, you can try.
Everybody keeps talking about selling your data, but as a small startup prospect I have no understanding of this business model.
Why is the personal data so valuable? Is it valuable outside advertising? Who is the buyer of the data? What is the price?
Why is the personal data so valuable? Is it valuable outside advertising? Who is the buyer of the data? What is the price?
How is it a bait and switch if Slack never advertised itself as an open platform?
IRC is just so good because its flexible to the wish of the tools and type of desktop you use that people should get time to think before use that type of trap for geek.
Well there you go.
Not going to run a webapp that occupies a gig of ram or two for text chat, so goodbye to slack it is.
Not going to run a webapp that occupies a gig of ram or two for text chat, so goodbye to slack it is.
if there was an XMPP based hosted chat application that lets me create private rooms for my company (using google auth), I would migrate in a heartbeat.
however, XMPP mistakes open-ness in the protocol with openness in conversations. Every showcase XMPP product is public, open chat rooms.
however, XMPP mistakes open-ness in the protocol with openness in conversations. Every showcase XMPP product is public, open chat rooms.
I've added OAuth support for converse.js, it's not released yet, but the code is written.
I intend to release that soon to https://inverse.chat.
Rooms can be made private, members-only and non-searchable. This is standard XMPP behavior.
I intend to release that soon to https://inverse.chat.
Rooms can be made private, members-only and non-searchable. This is standard XMPP behavior.
its not just at the room level, its at the org level.
the standard practice is that people create rooms in a slack org - and they are guaranteed that they are private to the org. one more step is where i can create private rooms to a few people within the org.
XMPP obviously can support this, but the products built on top of XMPP are too open. The protocol doesnt have an issue - but the people building products on top of XMPP have an inherent distaste for organizational workflows.
the standard practice is that people create rooms in a slack org - and they are guaranteed that they are private to the org. one more step is where i can create private rooms to a few people within the org.
XMPP obviously can support this, but the products built on top of XMPP are too open. The protocol doesnt have an issue - but the people building products on top of XMPP have an inherent distaste for organizational workflows.
I'm not following. You can run a 'private'/'silo' xmpp server by turning off S2S.
There are various commercial solutions that offer this.
There are various commercial solutions that offer this.
what's wrong with freenode.irc? As far as I can tell it still works as it did before.
maybe this could be an opportunity for something like mattermost to pick up the torch
Embrace
Extend
Extinguish <-- YOU ARE HERE
Extend
Extinguish <-- YOU ARE HERE
Why do we fall for this behavior over and over again? As long as we trade freedom for convenience, this will continue.
After the Posterous downfall, I remember people here claiming the exact same thing. And yet we fell again for Medium.
I'm always amazed how easy it is to lure people with castrated fancy UI and things like emoji.
You're seriously downplaying the usability and simplicity improvements Slack brought to the table.
No, I'm not. For one, I've never used it. The parent comment was referring to how they provided endpoints for programs connecting through open protocols, and now that they have some sort of critical mass, just dismissing the users of the service that utilize it through those. And my comment supports the viewpoint that we fall in for UX and convenience and low/no cost, then get screwed like this.
"No, I'm not."
Yes, you are. That is a large reason why Slack became popular in the first place. Nobody "fell for" the UX and convenience; those were solid improvements that people took to because they made things better.
Yes, you are. That is a large reason why Slack became popular in the first place. Nobody "fell for" the UX and convenience; those were solid improvements that people took to because they made things better.
I'm not going to play this game of yes you are no I'm not, but even if you're right, then that's not actually the topic of the dicussion: both I and the initial commenter was talking about how they lured people in with UX stuff or solid improvements like you said, and now pulled of this move.
Each new iOS update comes with new emojis nowadays, which is a great way to nudge the mainstream user to keep their OS updated...
The Welcome to the Macintosh podcast has fascinating multi-part series on emoji, and why they are such a big deal.
We are suppose to act like the theoretical rational customer, yet concerns about potential bait and switch get called "conspiracy theory".
Long term thinking is so uncommon it's almost frowned upon.
Long term thinking is so uncommon it's almost frowned upon.
Off-topic. Every time I hear about XMPP I remember signal's moxie bashing it.
What is currently the mainstream opinion regarding XMPP and good security: is it possible? Is moxie an outlier in saying that it's not possible, or is that the mainstream opinion too?
What is currently the mainstream opinion regarding XMPP and good security: is it possible? Is moxie an outlier in saying that it's not possible, or is that the mainstream opinion too?
When Moxie wrote that blog post[1] he was only speaking on behalf of his business interests. Signal is a proof-of-concept application that Open Whisper Systems uses to show off and sell their technology to other chat companies like how they have been doing with WhatsApp[2], Google[3] and Microsoft[4].
He was not really speaking for what was best for the community, you can read the blog post as marketing material.
[1] - https://signal.org/blog/the-ecosystem-is-moving/
[2] - https://signal.org/blog/whatsapp-complete/
[3] - https://signal.org/blog/allo/
[4] - https://signal.org/blog/skype-partnership/
He was not really speaking for what was best for the community, you can read the blog post as marketing material.
[1] - https://signal.org/blog/the-ecosystem-is-moving/
[2] - https://signal.org/blog/whatsapp-complete/
[3] - https://signal.org/blog/allo/
[4] - https://signal.org/blog/skype-partnership/
> Signal is a proof-of-concept application that Open Whisper Systems uses to show off and sell their technology to other chat companies like how they have been doing with WhatsApp[2], Google[3] and Microsoft[4].
This is a very uncharitable interpretation. Signal is arguably more secure than the competitors you mentioned, not just a "proof-of-concept".
> He was not really speaking for what was best for the community, you can read the blog post as marketing material.
In the blog post Moxie mentioned usability concerns due to federation, which directly affect users.
This is a very uncharitable interpretation. Signal is arguably more secure than the competitors you mentioned, not just a "proof-of-concept".
> He was not really speaking for what was best for the community, you can read the blog post as marketing material.
In the blog post Moxie mentioned usability concerns due to federation, which directly affect users.
So your take is "what he said is not true"?
My take is that he makes it sound more dramatic than it is. The entire blog post loses credibility when you look at the Matrix.org project.
Why? The blog post was before Matrix.org even had encryption. The Signal project has limited resources, which it focused on the Signal protocol. Matrix builds on this work and invests in federation.
IIRC, the main criticism was against federation, and not XMPP itself.
Daniel Gultsch, the author Conversations (XMPP Android App), wrote a response:
https://gultsch.de/objection.html
Daniel Gultsch, the author Conversations (XMPP Android App), wrote a response:
https://gultsch.de/objection.html
So how do you propose they make money instead?
Their business model is fine for many groups of user. However - open source projects in particular should be thinking about archiving, accessibility, discoverability etc. Slack is a bizarre choice which I can only ascribe to "nice UI and good timing".
I'm personally getting a bit sick of it for another pragmatic reason. It's bloody slow to open, slow to switch accounts and even slow to switch channels.
I'm personally getting a bit sick of it for another pragmatic reason. It's bloody slow to open, slow to switch accounts and even slow to switch channels.
There is very little "nice" about their UI. UX isn't good (subjective, I know); it's not accessible at all; their "apps" take gigs of RAM and waste CPU, very slow search, not intuitive, etc.
I was able to search years of intensive mailing in both server and local cache in an almost instantaneous fashion in Outlook {2003, 2010 & 2016} for Windows, but Slack can't properly search a year and a half of history without choking. On almost every level, slack is a complete technological failure (where it matters).
I was able to search years of intensive mailing in both server and local cache in an almost instantaneous fashion in Outlook {2003, 2010 & 2016} for Windows, but Slack can't properly search a year and a half of history without choking. On almost every level, slack is a complete technological failure (where it matters).
Note that I said "nice UI" and not "nice UX" ;-)
I'm really not sure how the two can be separate. In user interface concepts, UI design and UX go hand in hand. As a matter of fact, they do not just for UI but almost everywhere else. Case in point, Apple's glass windows that caused people to hit their heads in them by mistake. Terrible design and terrible UX.
Emoji reactions are a different feature than sending emoji.
Also, the idea that e-mail predates the surveillance aspect of the Web... Well, that was baked in from the beginning, as detailed in Surveillance Valley.
Also, the idea that e-mail predates the surveillance aspect of the Web... Well, that was baked in from the beginning, as detailed in Surveillance Valley.
Bait and switch is a bit harsh, I guess most of their users don't use IRC and it's a huge waste of resource and time for them. Even Open Source projects drop support for old tech like debian dropped support for old SPARC architecture in 2015. Of course the difference is that with Open Source anyone can pick up where they left but that's an issue with any proprietary/close source software and it's a risk one takes when going with a solution such as Slack.
IRC is an acronym for "IRC is not dead"
Anyone can explain why I'm being so downvoted here? Is anything I stated wrong or offensive or something? Genuinely curious.
They never embraced IRC, they just had a gateway for people still using it. This would be valid if Slack's protocol was based on IRC and they later extended it and made it incompatible with IRC. This is not the case here.
I regularly speak to people like that, who just plain refuse (are unable?) to even see the difference between a chat like slack (or telegram, or mattermost, or or or...) where I can post images/videos inline, use proper markup etc, and a combination of IRC and email. "But you can just send images by mail!" they shout. Yes, you can. But the user experience will be a different one. And it doesn't even matter that I personally prefer the slack-like UX. Many other people seem to prefer it too, that's what matters. For anyone who's only mildly technical, setting up IRC is only a small hurdle, but it's one of many.
IMHO, if you want people to use anything else but slack, sticking your head in the sand and screaming "you can do all of that in IRC" won't get you anywhere and is equivalent to complaining about the very nature of humanity. It might feel good to scream out your weltschmerz, but it won't change anything.