We should start by admitting that Slack beat IRC. Beat it like a cheap hallway rug. IRC was always a terrible experience for novices, and it wasn't a great experience for experts. That it had any users at all is a testament not to IRC, but to what it enabled. Slack found a way to provide the same value but with a much better user experience. And then they rapidly iterated on that experience, making it better and better.
They started out with IRC and XMPP bridges. But they eventually shut those down because they were a drag on improving the product. When faced with the same choice, IRC kept the original protocol and shut down improving the product. This was an understandable choice, but one that set up the situation where commercial developers could come in and do something radically better. Open source needs to figure out how to compete with that, or things like this will keep happening.
If we want people to use principled technology, then we need to be able to honestly advertise products as "it's just as good as X, and also doesn't violate [your privacy|human rights|the environment|etc.]" If we have to say, "It's not quite as good, but..." then we're dead in the water. (Side note: I switched to Firefox out of principle and I'm hopeful it will hold the line on market share, since it really is just as good as Chrome.)
The issue is that we're dealing with corporations who aren't just rich and powerful, they are also innovative, agile, and laser-focused on providing consumer value. Slack is doing an amazing job at serving their users!
You wrote, "we have to find ways to make better apps built on top of open protocols." It's a really interesting dilemma and I suspect it's one that isn't solved by better technology, better design, etc., but rather by addressing the base economics of the situation. We need a scenario where principled, open-source, ethical technology is generating the kind of investment we're seeing in Silicon Valley unicorns so they can innovate the same way.
What I find a lot of people miss when comparing Slack to IRC, is that not everyone using Slack is a developer. The world doesn't consist solely of developers - and if your company is 30% of engineers, and the other 70% doesn't have the reserve to wrestle with XML, then your company is using Slack. Otherwise, you are simply choosing to sell out your friends and family in the name of "principle" as well.
Personally, I'm tired of the comparisons to IRC and XMPP. Both are garbage - time and time again its been show how difficult it is to create greate software on these protocols. Contrary to your final statement, there have been better open source applications - gitter and riot come to mind.
I know plenty of non-technical people who chatted on IRC who were not developers. They just used the mIRC client on windows to do that. They also managed to configure their email and news clients to send and read email and browse usenet.
I simply don't understand where the idea of needing a technical background came from for using something like IRC.
You don't have to be a developer but you do need a level of technical background higher than that of the average computer user. There are plenty of tech-savvy, non-developers who can get up and running with things like IRC. There are plenty more non-technical users who can't. Or at least wouldn't given the learning curve time commitment.
I'm the only person in my family who would be able to sign on to IRC in under an hour whereas they'd all be able to have slack up and running in a matter of minutes.
Unless the technical skill of the average computer user has decreased substantially in the last 10 to 15 years, that shouldn't really be the case.
It's amazing that when it comes to computers, it is somehow acceptable to be dumb. It's acceptable to not learn new stuff. It's acceptable to not read in order to understand stuff. As can be read in the comments here.
The whole ethos of startups and Silicon Valley has been around finding a market for your product. If people don’t want to use it then you can’t blame anyone but yourself.
Feel free to chat with yourself using an ideologically pure system... it’ll be lonely though.
Disclaimer - A FLOSS dev here.
If you were talking about using these protocols over a telnet session, then I would be more inclined to agree with that statement, but just installing an application, entering a server name and account credentials (the latter of which aren't needed for IRC), and connecting isn't any more difficult than creating an account on slack and connecting by entering the address in the browser.
Regular users have amazing blind spots. Also you’re not giving slack enough credit for their smooth onboarding process.
Of course, but I don't think that Slack has done a better job with this compared to previous solutions. In a lot of ways, it's worse given its performance issues. For example, I never experienced UI lag in a chat application until I used Slack (comparing it with UIs like a GUI IRC application, AIM, ICQ, MSN messenger, Yahoo messenger, Skype, etc). Second, auto-completion and search do not work like they do in previous chat applications (or other applications in general) due to infinite scroll and the default of doing a global search instead of just limiting it to the chat or group. Third, the fact that you're forced to join some channels because you were invited or can't leave a channel because you're the last one in it are other issues that come to mind.
As much as it annoys me too, it appears that people actually using it have enough tolerance for it that it doesn’t matter.
Granted, I have not used IRC for a while, but last time I checked, the story for getting message history was "start a irc client inside a screen session on a server you own". And there were no mobile at all.
(I remember writing a script which exported chat logs from my desktop client to text files available over HTTP... I'd then visit those pages from cell phone to see if I had any more messages. This is not the experience I would wish on anybody)
It was pretty much the same thing with newer chat services like ICQ, AIM, MSN messenger, etc. (though I think they started offering offline messages in later versions).
As for mobile, my older Nokia phone had a Symbian IRC/XMPP client that I could use without any issues.
In the same breath though, saying, "I'm not willing to sacrifice convenience in the name of principle" is also a privileged position, because Iranians who live in the US/Canada are currently being banned. Convenience is something we can address in the future, but bans aren't.
The concerns people raise about Slack -- that until very recently it wasn't blind-friendly, that it takes away control of user data, that it can arbitrarily ban companies and users for any reason; none of those are theoretical deontological postering. They are entirely practical in the sense of, "there are people who are affected by this who can't join your community because you're not using a tool that's accessible to them."
I think that it's easier and preferable to teach my friends and family members to use open tools than it is to use something that blocks people of Iranian descent from participating in my community. Yes, that means my communities will be less accessible to tech-unsavy people. But that's a problem I can try to address in the future. I'm OK making their life harder for right now if it means not permanently banning people based on a random company's whims.
That is selling people out, in the sense that it's making a calculated decision about which people are most important to support right now. But if the Go community is using Slack, they're making the same exact same decisions to prioritize accessibility for some people. They're just choosing different people.
An example of how it might be possible to push this in the right direction is LEED. It didn't matter what the individual environmental ethics of people manufacturing electronics and designing houses was. Environmentally efficient building practices cost more, and there was no way for all the companies involved to form an opaque conspiratorial cabal to secretly impose the cost on consumers who would rather not pay it. Instead, they created LEED and used marketing to teach end consumers that LEED stood for more environmentally responsible practices.
Right now computer privacy and security are huge in the headlines, and a large number of people in the public and in industry want to do the right thing. But consumers don't know how to make the right choices, and companies aren't going to spend extra on the right thing if users are just as likely to choose something horrible. What companies need in order to invest extra capital in privacy and security is a plausible story of how to get users to choose the right thing and pay a bit more for it, if the industry builds it. They need a LEED standard for privacy and security. Then they can promote it and use it as a way to justify their investment in better, more ethical software. Corporations, schools, nonprofits, and other organizations can be pressured to make public commitments to use, or at least prefer, software that meets the standard. This won't drive horrible software out of the market, but it will create a sub-market where good software can survive.
Obviously laws and regulation are the bedrock, but in areas where consumers have a choice, we need to make it easy for them to make the right choice if they want to.
Honestly, at this point, I can't really tell the difference between Slack and most "Slack clones" -- the interface of Slack has basically been copied by most people and to be honest it really wasn't that hard. Mattermost and Rocket.chat both look exactly like Slack to me.
Matrix could have done the same thing, but they chose to waste time and money reinventing the wheel (and doing a bad job of it) instead of focusing on the service and the clients.
If you have legitimate grievances with the protocol and feel you can see flaws in it, make an issue on the tracker now while its still a 0.x release, doesn't have the broad adoption you describe, and while the team (knowingly) can make breaking changes simultaneously released to matrix.org and riot.im and cover 95% of the users still.
There are no stable servers.[1] The reference server is being completely rewritten.
Matrix bridges work about as well as XMPP bridges in my experience.
[1] https://matrix.org/docs/projects/try-matrix-now
The Matrix developers are familiar with XMPP, and have it covered in their FAQ: https://matrix.org/docs/guides/faq#what-is-the-difference-be...
Finally someone gets it! A chat service should value each message and it should never lose messages due to connectivity problems.
Thank you for sharing that link, I learned something new today.
- Person-to-person chat system. This requires offline messages: "when you get to work, please take a look at ABC-1234". Some people have cell phone as well, so this needs multi-delivery to all the clients (so you can read the message on the phone, then read it again from work PC)
- Support system: one person posts "I cannot run TOOL_Z", people who know reply. This requires offline history -- if I maintain TOOL_Z and I come in late, I was to see the question asked, answers, and maybe I want to contribute an answer as well. By the way, slack threads are super helpful for this.
- Knowledge archive: next person to have TOOL_Z problem would search the channel history, and find previous answers.
- Announcement with discussion: someone posts "New version of TOOL_Z is released! New features: ...". People might respond by discussing the new features.
All of those basically require "global database" -- those messages are not volatile things; it is not OK if the announcement is lost, or if you did not see the help request because there was something wrong with the system.
And I know that XMPP does not work for that because back when my workplace used to use XMPP (a few years ago), I went to https://xmpp.org/software/clients.html , installed "gaijim", and found out it has no offline message history, no message searching, and half-broken multi-delivery.
So we ended up building scaffolding - set up our own search engine, archive system, use different methods for communication. This was a lot of pain and very little gain. So when we had to re-do infrastructure from scratch, we went with Slack.
(Note that you can't just say: "I don't need those features". As long as there is a single person in the company who does not have history, the whole company cannot use pure XMPP for support system or knowledge archive anymore -- or that person would be excluded.)
As you said in other messages, things are better now -- there are compliance suites. So "XMPP Advanced Client 2018" does do what you want. Unfortunately, I cannot find a list of clients which support "XMPP Advanced Client 2018".
Also, there are people who confuse matters by saying that "XMPP does everything Slack can, and has tons of clients". No. "XMPP Advanced Client 2018" does everything Slack can but has very few clients. Regular XMPP has tons of clients but does not support everything that Slack can. It is very important to distinguish between the two.
The FAQ skirts around the fact that it doesn't matter if they're slightly different: you shouldn't make up your own new thing to force adoption of your commercial product. Use and improve the existing technologies that are "good enough" and stop splitting effort and making yet another standard that everyone has to try and support or run bridges for. This is unacceptably bad engineering. Saying "this is subjective" is true, but just an excuse for "we have not-invented-here syndrome".
Pure-XMPP simply would not have worked.
(I have my issues with the matrix protocol, mind, but they had good reasons to create a protocol even so)
Edit: I also wouldn't be surprised if this is why facebook messenger switched from XMPP to a custom MQTT-based system.
I run an ejabberd server and for example the Client State Indicator (XEP-0352), which is one of the extensions that improve battery life for mobile clients, was experimental for a long time but at the same time also available for major servers (e.g. community edition of ejabberd) and mobile clients like Conversations (open source too).
So in my experience, the battery consumption of a modern XMPP client is quite good. When people are complaining about the bad mobile experience they are mostly referring to the time before the mobile extensions were built.
So apparently not everybody shares your definition of 'solved' - I appreciate the alternative opinion, but simply declaring it a myth is, I suspect, unlikely to convince remaining skeptics.
simply declaring it a myth is, I suspect, unlikely to convince remaining skeptics
It's hard to provide specific counter-arguments to anecdotal evidence repeated since back when gtalk was a thing.
[0] https://gultsch.de/xmpp_2016.html
[1] https://wiki.xmpp.org/web/index.php?title=Myths#Myth_Three:_....
More to the point, there is always going to be some value-added service a profit-seeking enterprise is going to be able to provide over what's freely available. If we built IRC 2.0, then Slack 3.0 will provide what everyone hates about IRC 2.0 and then the dynamics of profit seeking will drive Slack 3.0 to divorce from the free alternative.
We see this pattern over and over and over again. It doesn't happen necessarily because businesses are being ruthless, but because there's always going to be a market space, even in the face of a fantastic free service. That's just how a market economy works.
A good example here is Firefox. When it started out, it was better than the competition. Chrome pulled ahead for a while, but Mozilla responded and now it's competitive again. And Firefox has done this while advocating energetically for an open web.
Another one that interests me is WhatsApp. They built a messaging product that was clearly superior to the alternatives. They eventually sold out for billions. But there's no reason they couldn't have done that as a nonprofit. And Signal has shown that a nonprofit can still jump into the space and do good things.
I guess it lacks persistence and access to history? But there are surely ways to solve that.
persistence, history, search, rich formatting, image previews, synchronization between devices, usable mobile clients, group/here/channel mentions, channel directory/search, channel descriptions, file upload/sharing (XDCC is not this), multi-line/expandable messages (eg, paste code or logs without flooding the channel), user status (away/DND).
Some of this can be approximated with bots, of course, but there's a lot of extra work then required to make that work (namely, setting up, writing and maintaining the bot). Some of this can be done client-side, but then you have inconsistent experience.. you don't know if the other user is going to get the image preview or if their client understands markdown or some other formatting, or is going to interpret and display your message using some other markup format. Some of this you can also work around with one of those persistent IRC connection proxies, provided each user gets one and that is also maintained by somebody.
Eventually someone packages this stuff all together for simple deployment.. and basically creates a bad clone of Slack, but with 10x maintenance requirement and so many more things that can break.
For example my app https://quasseldroid.info/ which requires you to run the https://quassel-irc.org/ bouncer, but provides all that. As well as IRCCloud and Weechat-Android, which are also very awesome and provide a similar amount of functionality.
The other features are atm a work in progress.
I wish I could do more, but in the end, I’m just a single developer improving the usability of a single app in my free time.
For open source non-centralized solutions to compete with the proprietary options, you need lots of devs and even more funding. Matrix/Riot.im has that, and even they aren’t close to where Slack is. Most of us IRC devs are either getting nothing, or, as e.g. in my case, the donations don’t even cover the server costs.
In the end, if people want open solutions to grow, they need to put their money where their mouth is.
I hate Slack for open communities as much as the next person, but IRC or fixes on top of it aren't really the solution.
Are we complaining about price or are we complaining about proprietary services?
Doesn't IRC file sharing involve directly connecting to individual users to transfer the file, instead of those users choosing to download it at their leisure? And if you happened to be offline at the moment the user shared the file, can't you never download it unless you ask them to resend? For large, asynchronous groups, that is untenable. Slack's file sharing works because Slack hosts the file.
Also, basic messaging features are indeed missing from IRC. How do you do a private group chat? Like an SMS group thread? Doesn't it only support channels and then individual 1:1 DMs? Slack has ad-hoc group DMs. On IRC you'd have to make a new channel every time. It's like getting a conference room every time you want to talk to more than one person at once.
Slack also does voice and video calls, and screen sharing, and it's really quite good at it (feels light, not bloated). Sometimes talking with someone needs to turn into a face-to-face call.
Yep.
> there are surely ways to solve that
Most common solution is to use something else.
You could say IRC could do anything any other chat program does, but it doesn't.
And re IRC, I gather that Sabu got doxed based on EFnet logs from the late 90s.
The obvious advantages versus classic IRC clients: it's always online and the connection happening through their servers you get good push notifications on mobile.
The obvious advantage versus Slack: they don't own the IRC networks you're connecting to, so if you have issues with IRCCloud you can just change to another client.
It has some missing features, most notably search in archives, but they are working on it.
>> "admitting that Slack beat IRC"
Sure but are we talking about a fundamental limitation of the IRC protocol, or are we simply talking about implementation details that can be fixed?
We can talk about all the other issues around persistence and UX but just getting started is something beyond the vast majority of computer users.
It’s really hard for us to remember and empathize with this.
Google SSO/SAML
Threads
But mostly access to history and search. (Note that it's not coincidence that this is what differentiates the free from paid Slack.)
That being said, I wish there was a better open source alternative.
No. They shut it down because they want people to use their (crappy) UI.
Even Comic Chat was based on IRC, and that's as far from "user-unfriendly" as you can get https://en.wikipedia.org/wiki/Microsoft_Comic_Chat
In which world does it beat IRC? Number of users? That's not even sure, since there are dozens of thousands of IRC servers worldwide. And that's not even counting the private, self-hosted IRC servers.
IRC runs everywhere and does not need a fat browser or a RAM-and-CPU hungry application to enable "chat".
As for the user experience, this would merit a whole post in itself, but Slack sucks in many ways: threads are completely unusable, channels are hard to discover unless you know about them, and now Slack makes you pay for searching thru your past messages.
I'd say there is a lot more to this topic than "Slack beat IRC".
As far as I can tell, Slack has an order of magnitude more users. They were at 8m DAU back in May: https://techcrunch.com/2018/05/08/slack-hits-8-million-daily...
IRC was in long-term decline even before Slack: https://royal.pingdom.com/2012/04/24/irc-is-dead-long-live-i...
So my best guess is that Slack has at least an order of magnitude more users.
But users is not exactly the metric I'm thinking of. It's when people say, "We need some way for us to communicate," Slack is the popular option. Even though I'd rather not use it, I'm in 8 right now. If you look through this thread, you'll find plenty of people concerned about how prominent it is in the open-source world, IRC's home ground.
> IRC runs everywhere and does not need a fat browser or a RAM-and-CPU hungry application to enable "chat".
I get this in theory. But RAM and CPU power are fantastically cheap. Conserving them to get a worse user experience is optimizing for the wrong thing.
> but Slack sucks in many ways
Sure. There are no perfect things. But Slack doesn't have to be perfect. It just had to be better than the competition. And for most people it manifestly is.
Who the hell cares? I figured out IRC when I was about 12 and I'm no genius. If that bar is too high for people in tech then we have serious problems.
I too figured out all sorts of computer things at 12. By standardized tests, I'm also in the top 1% of ability for things like that. And my dad was a programmer then, so I had a leg up.
At some point, I realized I had a choice. I could feel smug about my (narrow) genius and focus on tools for my (narrow) cohort. While grumping, of course, about how stupid everybody else was. Or I could recognize my luck and use it to make things that were good for everybody.
You know what helped me make this choice? Realizing how bad I was at so many other things. And how generous other people were in not only putting up with that, but helping me along.
Our school had nothing blocked, and the computers weren't locked down at all.
But Slack isn't solely used by technical people. Where I work, everyone is on slack - product people, lawyers, tech people, etc.
[1] https://datatracker.ietf.org/wg/mls/about/
Wire is open-source today and usable by regular people, with E2E encryption and email-only accounts.
Why not just use XMPP? Yes, everyone hates XML, but the protocol is well designed, has sustainable funding (via the IETF and XSF), and there's lots of experience out there, and it's flexible enough to develop services like Slack on top of.
https://signal.org/blog/the-ecosystem-is-moving/
"XMPP is an example of a federated protocol that advertises itself as a “living standard.” Despite its capacity for protocol “extensions,” however, it’s undeniable that XMPP still largely resembles a synchronous protocol with limited support for rich media, which can’t realistically be deployed on mobile devices. If XMPP is so extensible, why haven’t those extensions quickly brought it up to speed with the modern world?
Like any federated protocol, extensions don’t mean much unless everyone applies them, and that’s an almost impossible task in a truly federated landscape. What we have instead is a complicated morass of XEPs that aren’t consistently applied anywhere. The implications of that are severe, because someone’s choice to use an XMPP client or server that doesn’t support video or some other arbitrary feature doesn’t only affect them, it affects everyone who tries to communicate with them. It creates a climate of uncertainty, never knowing whether things will work or not. In the consumer space, fractured client support is often worse than no client support at all, because consistency is incredibly important for creating a compelling user experience."
But I do tend to agree in general that we need fewer features and less complexity and to push more for basic profiles that everything should implement and that have a clear compliance label.
Now we have uncertainty around which networks people use, which devices they use them on, and which features each network supports.
You cannot just tell people "go choose any XMPP client, and it will work fine". Instead, it is more like "get XMPP client, but make sure it supports XEP-1111, XEP-2222 and XEP-3333". And if you have multiple platforms (Android, iOS, Win, Linux), let's hope you can find a client for each.
For example, I used to use Mcabber with HipChat at work. Mcabber doesn't support even basic modern XMPP things (history, for example), but it was plenty good enough for me to chat with my coworkers.
For your work: Are you connecting Mcabber to HipChat server? Do you use native HipChat client as well?
From your link.
I tried to download and run Jitsi a couple months ago for a project and it's voice quality was terrible. Skype just works. I sometimes have weird quirky bugs with Adium, and it's getting harder to justify telling my team to use it.
Get hacking folks. This space needs better tools.
I tend to think that we don't need more small community projects, we need one or two entire services like Slack to build themselves on the base protocols and federate. Even if they only allowed their own clients so that they controlled the entire experience, if they just federated with other servers it would give users a choice and largely solve the Slack problem.
How did Slack figure out this guy's ethnicity / citizenship / status? Why are they allowed to access that information and unilaterally act on it? Sounds like there's a valid question being asked here to me.
Slack is protecting their multi-billion dollar business and their investors which are both based in the U.S. If they do not, they could run into trouble and put far more at risk. This does not only affect Iran, it affects other countries too which the U.S. has active sanctions against.
Now, I admit that visiting the countries on the list aren't on my to-do-list, but if for example I decided to make a vacation trip to Cuba I really shouldn't lose my account at any US-based service just because of that.
So you would make people suffer and think that they would blame their own government for that and not the US?
Don't you think that makes you and your country evil?
Using a proprietary protocol that doesn't allow any form of federation is an unacceptable way to build a global community. Please consider using an IRC based service for group chat or an XMPP based service where 1:1, history, rapid reconnects, and other more complex chat features are required (yes, if you're a dev you have to use XML which is annoying, but overall it's a well designed protocol, so get over it). This lets you host your own, and (in the case of XMPP at least) if one person wants to use a U.S. based service and another is in Iran they can just sign up for a Belgian account (or wherever). We can't afford to let he internet splinter off into siloed tiers based on nationality.