Issue #2, that slack is based on synchronous communication, is something that is always ignored. Sometimes I log in to slack and see a conversation that I want to add something to, but it is 4 hours old with 50+ new messages on varying topics. Even with Slack's new threaded messages it is hard to evolve the conversation after all the synchronous folks have moved on to other topics.
> Chatting is having to write the same thing a million times.
If you find yourself repeating the same thing a lot in chat, it would be a good idea to document it somewhere and just paste a link. With a link to the relevant documentation, a lot of people will just do the rest of the legwork on their own, and will now be able to quickly reference it going forward, and hopefully bug you less in chat (you can always be explicit and refuse to answer people, asking them to read the docs instead).
If you find you're pasting too many links too frequently, then it's time to make an FAQ with those links, and start linking to that.
Fix your group's culture. Document things. If people refuse to document things, then do it for them and shove your docs in their face. Do it until they write the documentation themselves.
It's also the most important thing. If your culture is bad, changing what tool you use isn't going to fix everything. You're just going to have a new tool everyone uses poorly.
This may be a shortcoming of the UI, more than anything else. There's definitely room for improvement here as I often miss updates to threaded conversations even as I'm looking for them.
I think they could make threads work with some simple changes:
* Optionally show thread replies in-line with chat, as they come in, just like regular chat but with some special annotation to indicate they're part of a thread.
* Allow the user to collapse a thread so they no longer see it in-line.
* Auto-close threads after they're idle for more than 1 hour (or some site-policy-configurable timespan).
* Allow the user to navigate between threads using only their keyboard.
As they are now, I think threads are bad for business. They hide useful information away and slow conversation (responses dragged out because they're no longer in your face).
If I really wanted to bring up a topic that had passed, I would break out to a separate channel and invite the relevant people and drop a note in the main channel with a "bringing things back up about $conversation in #newchannel". This works better than writing to threads in my experience.
Chats (of whatever type) have never been a good solution for this, that's why mailing lists exist. Improvements there would be nice, sure, but are unlikely to come from a chat service. They just solve different problems.
What you're looking for is email. Multi-user chat simulates a real life conversation, and in real conversations it's also awkward to say "hey so going back to what we were talking about 15 minutes ago..." after the conversation has moved on.
No, email is terrible. There's no history. You can't "scroll up" to see what people were talking about. You can't link to another specific email to reference it (yes, there's archive services, but then you have to go dig through an archive to try to find a horridly formatted email to link to, which is completely separate from the normal consumption platform).
I actually argued here recently that email was hard to switch away from because of the history. You can keep your emails forever. I have emails from 2007 sitting in my inbox. And if I want to keep them, I can download them with IMAP or POP. If I send an email to five people and they remember to hit "reply all", well that's a conversation, isn't it? And if I need to show someone an email they weren't party to originally, I can forward it to them.
That puts the onus on every single person to maintain the history of the project. Lots of people delete mail (not me, but lots of people). Also, you can't retain history of what was sent before you joined. Also, emailing individual documents means people can't research by themselves.
I mean, email isn't meant to be a document repository. Slack (or other chat) is great for immediate conversations with many people. Email is great for slower conversations with a more limited number of people. A wiki is great for a very slow conversation. An actual document repository is great to be able to link to when using any of the other conversation methods.
Just because Slack isn't good at slow conversations doesn't mean it's bad. Just because email is bad at including people who joined after the fact doesn't mean it's bad. Those aren't their strengths, and that's fine. They still serve their own purpose just fine.
I never used Slack, but in IRC I'd quote what the user said (a format like "<user> message", optionally with a time) if it's really relevant; and in Telegram it's a simple matter to rightclick and reply (which allows people to click/tap it to jump back to context) which I feel much less bad about.
This is more of a usage problem that anything else. If your organization makes decisions based on synchronous communications, without stopping to notice who wasn't included and get their input before final decisions are made, that is a cultural problem, not a tooling problem.
Good points but the bigger problem for me is the lack of an archive.
You only have the last 10k (?) messages and that includes public and private messages. If you have a mildly active project, messages may only be available for a month and you lose the history of the project. That makes it an awful support option too.
Just a note: if you go from free to paid, you can recover those lost messages. They're never actually deleted, you just can't view messages after the 10k limit in the free version.
Wow, that is kind of evil. I could understand if Slack kept, say, the last 20k or 50k and only showed the most recent 10k. For them to store all the messages indefinitely for all free servers means that they are incurring the same storage costs whether the server is free or paid. Are the bandwidth costs really that high to justify hiding all those messages (likely on the order of 100k or 1M for many servers) ?
Third choice: Slack exists, but doesn't hold your data hostage until you pay. I mean, on my list of things I care about ideologically, this is lower than my concern for warm gin and my dislike of sweatpants. It's legal and totally within their right, but it's a crappy way to behave.
They might be shunted to a disk somewhere and removed from search indices while on the free plan, reducing their costs but allowing them to recover things after.
> Are the bandwidth costs really that high to justify hiding all those messages (likely on the order of 100k or 1M for many servers) ?
Given that the cost to you is 0, what cost to them is required for it to be justified to you?
It seems odd that providing a free but limited service is evil, based only on it being slightly more expensive to give you an even better service for free.
I doubt it's a bandwidth issue. It's probably that they have to keep more servers/servers with more ram up to index all the messages. Keeping something on a disk that never gets read is far less expensive than keeping it in RAM and indexed so that it can be quickly and easily searched.
It's not evil nor is it about the bandwidth costs, it's just business. It's how they get you to spend money on a freemium product after you reach a certain cap. They've determined that you should pay if you're hitting the 10k messages limit.
Ok, well the alternative is no free version. Yeesh, people are so entitled. They're trying to give you a mostly full featured version of their software in hopes that you'll pay them someday.
I completely agree with this. I'm part of a group that's trying to help people in the local community learn programming and we're using Slack to chat outside of any scheduled sessions. We're at over 1000 members in Slack now and are seeing messages disappear before the two-week mark. We don't collect any money from our members and Slack's pricing model makes it unfeasible for us. At this point, Slack's search feature is hit or miss when searching for anything over a week old.
With respect - you are reading something that wasn't necessarily there, the person you were responding to said nothing about expecting Slack to change their business model.
That still doesn't make Slack an appropriate choice for open source. Even if the project didn't mind paying, Slack's business model is wholly incompatible with the traffic that an open source project would expect (lots and lots of not very active users)
If you have a nonprofit for your project, you can also get on their nonprofit plan. At https://hackclub.com we get unlimited archival without paying for this reason.
Sometimes there's just general trash talk or real time chat and Slack is perfect for that.
We who use it don't want to have low value info pollute google search results. And we also have a public forum for info that should be searchable and requires asyn comms.
Of course like with anything if you're a fool and use it wrongly, you want get good results with it.
It seems to me that Slack could position itself to provide free and open access to certain types of communities like open source projects, charities, etc. Enable the "pro" features so long as the community follows the rules.
The value of synchronous communication is very real and it should not be precluded, but the points are totally valid. Slack is a closed-garden and it does not contribute to the global conversation if the access and historical record is controlled from within.
This is the point that I can't get anyone to see. So what if they provide history? They can take it away at any point too. So what have you accomplished?!
This applies to Freenode as much as it applies to Slack. If freenode disappears, people using its channels for foss will have similar issues and inconvenience as if Slack/Discord disappear and in both cases, it's recoverable.
Nobody changes clients if Slack disappears and is replaced by another webapp. It's all in browser.
The UI might change, but the UI also changes when you go from a Mac IRC client to a Windows one, which doesn't happen with web apps.
I say this as someone who's used IRC a crapton and is a strong advocate for open protocols (and for more than just ideological reasons): Realistically, if Freenode disappears, IRC will most likely die as a protocol as all major projects switch to non-IRC solutions, which is happening today anyway. A protocol needs users.
The only thing IRC has got going for it is federation and openness. It's not easily extensible, it's not secure, it can't benefit from most of the advances we've made in comms and protocols since the 90s, and there isn't even a common format for your messaging history - most clients just use text logs!
If you want to advance the state of comms and ensure humans are using open protocols to communicate rather than walled gardens, you first have to acknowledge these flaws and needs. Propping up IRC as something it's not doesn't do anyone any favours.
If Freenode disappears, people will join Debian over on OFTC. I'm not sure if Mozilla and GNU/FSF use Freenode or run their own infrastructure but if the former, then they may set up their own network(s).
Other IRC networks than Freenode and OFTC exist too.
As far as security goes, SSL is an option for client<->server connections. I hope that at this point it is default for server<->server connections. What else are you expecting for security?
SSL is not required and it's certainly not default in most clients.
IRC won't survive the loss of Freenode. With Quakenet dying off (its userbase went from ~65k in 2013 to 23k today), Freenode is the last central bastion that keeps the protocol in people's minds.
FOSS projects today are migrating off IRC, onto Slack and Discord instead. This is why you have an article here talking about it and it's not the first one. If Freenode disappeared, this would accelerate massively. The projects won't bother going to another network because the topic of "Where do we go now?" is going to be asked and in most cases is going to be answered with "Well, we wanted to move to Slack/Discord anyway...".
There will be a few projects left on OFTC, certainly. But they'll give up and go elsewhere eventually as well when they'll see their userbase shrinking 5-10x due to other projects migrating elsewhere and taking their users with them. They'll probably end up on Matrix.
> Nobody changes clients if Slack disappears and is replaced by another webapp. It's all in browser.
You aren't serious, are you? Because the new client runs on the same virtual machine, you are not changing clients? That does not really make sense to you, does it?
> The UI might change, but the UI also changes when you go from a Mac IRC client to a Windows one, which doesn't happen with web apps.
(1) I haven't ever heard of a computer changing its operating system from MacOS to Windows because anyone but the owner of that computer decided to make that switch. How would that happen?
If the UI changes, the client has effectively changed for the user. Otherwise you might as well argue that clients are all equivalent if they are running on the same OS.
>but the UI also changes when you go from a Mac IRC client to a Windows one
Only if you use clients that don't look the same.
> if Freenode disappears, IRC will most likely die as a protocol as all major projects switch to non-IRC solutions
No supporting evidence that they would drop IRC if this happened. You must have missed the part about a network switch being literally a config change. Compare that to dropping irc which is all of your tooling.
>most clients just use text logs!
There is nothing wrong with a text log. Also, which common format is your browser storing your slack messages in?
Most of your complaints apply just as equally to chat inside of a web browser (other than the security issues).
>Propping up IRC as something it's not doesn't do anyone any favours
Tell me how my comment is incorrect. You literally change a config to change networks, that's it.
There is a lot of vendor lock in for git these days, everything from CI integration to git clients hard coded for github. We spent most of the 90's and 00's breaking vendor lock in and then forgot it was a thing.
I feel like more and more people are coming around to seeing the relevancy of distributed federated chat and breaking out of the walled gardens. My person money is on Matrix[0] taking off but I think the general theme of people pulling away from interesting their communication to corporations is a positive.
[0] matrix.org
Everyone should be using Matrix. Not just open source developers.
It's near feature parity with Slack and it's also one of the best IRC clients around. I used to run ERC in a tmux session just so I could stay connected and not lose messages. No more.
The ease of bridging is great. We've got a minecraft server bridge of all things; being liberated to actually have universal chat is the future for sure.
Yes, Matrix has great momentum. It is somewhat sad that XMPP is falling behind. There is no technical reason, why Matrix should be superior, but they are winning.
Similarly, the huge buzz over the past few weeks about Mastodon as a distributed/decentralized micro-blogging service has been positive. People starting to learn more about federation and decentralization. Good to see.
But you may have missed the memo because you're in the wrong time zone, and with Slack, your possibly-relevant input is ignored because you can't participate in real time.
This is my beef with chat. As the OP says, it biases all conversation to those in the same time zone. Fine for some things (like baked goods arriving in some far-off kitchen), but not for others (like a design decision that should have input from stakeholders around the globe).
If a group has the choice between realtime and asynchronous channels there needs to be a guideline for this.
If my org takes pride in consensus for everybody, everybody needs to have the time to submit input. It's not uncommon that some active users in a chat go for an ad-hoc decision just because they are more than one and want to work _now_. In the long term this damages the culture, splits the participants and is difficult for newcomers.
I completely agree. Unfortunately, what I've seen more than once is that mgmt (or even someone from the rank-and-file) sees / experiences a new tool like Slack (or Campfire, or Hangouts, or...) and says "hey, great new tool we should use!" and that's the 'decision'. No thought given to how async comms biases development when developers are spread world-wide.
I gripe because I am a US left-coaster who works with a team that is increasingly based in Western Europe. By simply deciding to rely on Slack, they have essentially cut me from development conversations other than the weekly live session.
I feel ya, it's frustrating. Although I did not yet have a problem with time zones, I experienced being left out simply by joining the chat later in the evening.
You're never going to move large groups of people by just yelling "xxx is terrible!" You have to make something better that people want to use to get them to switch. Unfortunately, Slack is better than IRC in many ways that matter to a lot of people. Ignoring all of those things doesn't make IRC better, and it's not going to make people want to use IRC over Slack.
It's been going one since the first companies tried to monopolize Internet chat by centralizing it on their infrastructure in the 90ies.
The argument for AOL/MSN etc back when the Internet was new openness for the unwashed masses just a dream is exactly the same being made by slack i.e. that by making it locked and taking away the complexity introduced by the existence of cross vendor compatibility new users face less confusion.
Well, this one was supposed to be a little different, as instead of open vs closed, it was sync vs async. But when the topic of OS projects and closed tools comes up...
Because the things that are driving people to use Slack are the same as existed five months ago, and arguments like this do nothing to prevent people moving.
Well, then we can all turn off our computers and go home, because something that "works" is obviously good enough and the entire software industry doesn't need to exist anymore. Most things we have today "work" but we're still improving on them because "good enough" isn't good enough.
The question you're not asking is whether your replacement is better than the existing solutions. Slack isn't. It's closed source, proprietary, and tied to a third party's servers. I'm not going to tie my projects or company to that kind of anchor.
I don't know why didn't just evolve irc. Feature wise slack doesn't really bring much new. It just has a good interface. If someone made an irc client as easy to use as slack then we'd have our answer.
It really is. Slack's interface is good enough and easy enough to understand that even the least technical people can pick it up in a few minutes after you show it to them and explain the difference between public and private channels. A week or two of use is enough to master everyday Slack use. Slack may not bring much to the table in terms of new functionality, but it does make it insanely easy for the average person to easily use the system and be involved, which really cannot be overstated when working at a company with a varying level of technical abilities.
Because adding a feature to a standard means you have to get everyone on board. Slack as an IRC client would basically be Slack as it is now, and the server protocol would be an implementation detail.
Get a good GUI client, enter some parameters into a text bar, click 'ok', then chat. exactly the same process as a web browser..
The real problem is the 'endless summer' of tablet-era people who confuse the 'interweb' with the 'internet'. There used to be much more general community advocacy and understanding of promoting open communications 'baked in' to the internet culture which has been eroded by crass commercialization - this is the real problem that needs to be attacked...
Can you easily share multi-line code, formatted in a proportional font and syntax highlighted, in any IRC client? That's something I want to do almost every hour I'm working.
Some clients will intercept multi-line messages and let you POST the content to a pastebin. That way, supported clients show pretty-printed code and unsupported client just see a URL.
Is that really happening that open source communities use Slack as their primary communications channel? I haven't seen that happening in the communities I participate in (Python/Django/...). What I do see is that more and more communities switch from IRC to Slack as the primary "sync" channel (while still maintaining mailing lists, bug trackers and the like).
And as much as I hate it, the success can't be denied. Especially when looking at some conferences I've been to over the years. If they even had an IRC channel, it was mostly dead, but the Slack channels were buzzing with activity during the conference. I'm not sure why that is. Ease-of-use? The fact that many attendees are familiar with Slack from work, but not with IRC?
So get a better IRC client? Really not hard to do things like syntax formatting and auto link follow (GUI versions of IRCII had plugins for this in the late 90s, so it's not like it's even a novel idea).
Just run your IRC client in screen/tmux like we've done for a quarter century.
The real advantage of slack isn't even client its stuff like massive logging for e-discovery and single sign on integration. Admittedly not terribly appealing for FOSS but once you use it at work...
Also integrations in general are smoother in slack than in IRC. Someone has already written the bot and its a click away to install and it generally works.
> The real advantage of slack isn't even client its stuff like massive logging for e-discovery and single sign on integration. Admittedly not terribly appealing for FOSS but once you use it at work...
Quassel is a distributed system, so you have a bouncer and client which integrate tightly, with clients for Linux, Windows, Mac, Web, Android, iOS, which stores backlog in a database.
This search system is a very simple one, and simply uses postgres’ fulltext word vector search.
This is the first I've heard of an IRC bouncer. That's a great idea. It still seems like it's and extra step you have to add though, when really it'd be nice to see some work on IRCv3 so you could have multiple clients connect to one IRC server with the same username and sync without the need of a proxy.
When I was a wee lad I was always envious of people on IRC who had these things called "shell accounts" that let them stay connected to IRC 24/7.
They could schedule downloads to their remote boxes and wouldn't have to tie up the home phone line for three days downloading the latest warez from that guy who had an ISDN line and let 10 people(!) simultaneously download from his bot at a screaming 5k/s.
Now I can have all those things (including the equivalent of 1000 ISDNs), and I don't really use IRC anymore, young me would be so jealous.
Encapsulates this era as the battleground of silo'd "as a service" vs "can be done"
For example I can have jenkins email build fails to slack in, oh, probably less than two minutes, I've done it before. From memory I make a custom email addrs in slack and tell slack which channel to feed it into, and then add that address to my jenkins that already sent buildSpam.
In IRC I could do it... google implies there's a ZenIRCBot project on github and probably many others. Probably there are bots and tools that google didn't immediately find.
Its not rocket surgery to use fetchmail and some kind of Perl IRC library to simply POP everything out of a mailbox into a directory /tmp/wtf and probably about 3 lines of perl to read all the files in /tmp/wtf, connect to irc on some channel, output what it found, and if successful delete the emails from /tmp/wtf. Then put fetchmail and the 3 line perl script into cron and away we go.
Looks like Zapier is kinda in between "I could do it" and "AAS"
Jenkins has a IRC plugin, already in the stock distribution. Jenkins bot idles in channel, and logs all sorts of failures or successes, or whatever. With the irc server + channels setup, this also takes less than 2 minutes.
> There's a reason people like slack so much. It does a ton of stuff out of the box with no headaches. Nobody wants to maintain all that stuff.
So instead of paying someone to maintain it, you pay someone to maintain it who keeps all your data from you and prevents you from accessing it, and who admits he’ll read all your stuff.
How is that better again?
That said, IRCCloud already does it for free, in the cloud, just works™, and the Quassel people are also working on improving ease of use and deployment.
> So instead of paying someone to maintain it, you pay someone to maintain it who keeps all your data from you and prevents you from accessing it, and who admits he’ll read all your stuff.
You aren't paying "someone" you're paying an entire company that is dedicated to making the application highly available, with all the bells and whistles, with zero hassle.
Really, if you think IRC is so similar to Slack, then why are so many companies, organizations flocking to it? There has to be a reason.
> Really, if you think IRC is so similar to Slack, then why are so many companies, organizations flocking to it? There has to be a reason.
If HN has higher discussion quality than reddit, why are not all devs on HN instead? If Linux is better for servers, why are people still starting projects on Windows? etc...
The power of marketing, directly or word-of-mouth, is important. And a decentral community can never do as perfect marketing as a company can do.
There are IRC clients and apps, and third party integrations as powerful as Slack, and as easy to use. But you have to find them, install them separately – there’s no single combined effort to market a single "just works" solution, yet ;)
How many people maintain their own email servers vs. use gmail?
Slack doesn't prevent you from accessing your data, in fact they explicitly built exporting features.
We're talking about open source, so reading your stuff shouldn't be a problem. For proprietary, maybe, but even then, reading someone's private slack info would be highly damaging to their brand, and to what benefit?
Slack, Hipchat, Campfire, etc. are all just IRC for normal people. There is without a doubt a barrier to entry to IRC that actually requires a bit of understanding of how the protocol works. "I'm in #this-channel-you-told-me-about, but no one else is in here, wtf?". "Oh, you're on the wrong network - it's EFNet, not Freenode".
There is no such barrier for the current set of chat apps. Download > Login with google, start chatting with the person who invited you. Search history? File sharing? No need to remember anything about dcc/xdcc, no need to manage servers running bots, no need to manage anything, really; it's all taken care of by the nerds that run the service.
I think one might actually be able to build a business by building a Slack that runs on top of IRC, and releasing client apps that actually significantly reduce the flexibility that a standard IRC client gives you. If you can get the on boarding flow to invite -> download -> log in -> start chatting with the people you want to chat with, you could crush slack (assuming you had the marketing budget to compete with theirs).
I think, however, that IRC will remain in some ways as a small haven from eternal September (haha, yeah, I know). The barrier to entry is a feature, not a bug.
> I think one might actually be able to build a business by building a Slack that runs on top of IRC, and releasing client apps that actually significantly reduce the flexibility that a standard IRC client gives you. If you can get the on boarding flow to invite -> download -> log in -> start chatting with the people you want to chat with, you could crush slack (assuming you had the marketing budget to compete with theirs).
Someone did, it's called IRCCloud.
That's the entire problem I've been talking about above: Anything you can imagine regarding IRC already exists. The only issue is that you don't know about it yet, and have to find it. And without marketing, or any lists of what is good and not, this is hard.
Then start actual marketing. And make sure that I can switch from Slack to your product without any hangups, and have exactly the same feature parity, especially for non-technical users.
with respect to something like e-discovery its all a matter of perspective. If this were true, which it isn't, I wouldn't necessarily mind, as the financial worth of combined ancient IRC logs is unquestionably a net negative value.
A few people have replied, saying how to get chat history with IRC, but as far as I can tell, none of them work like Slack. With Slack, you can see history from before the first time you connect. It looks like none of the IRC solutions enable that; the IRC protocol doesn't make it possible, without the server (or a channel member) keeping logs.
(I haven't used either very much, so please correct me if I'm wrong.)
IRCCloud can, they're a client too :) I highly recommend them if you are serious about IRC.
But yes you're right, nothing in the IRC protocol for it. There is something in IRCv3 to provide chat history but I don't know if it's even in the current version of the spec.
Like I was saying, IRCv3 has support for replaying the channel's history, as long as it's stored serverside. But I don't know if anything actually implements it, even IRCCloud which is v3-compatible.
At the moment if you join a channel you can't read its backlog, no. They could implement it though if they used logs from their users... kinda wish they would. But hey.
> At the moment if you join a channel you can't read its backlog, no.
Then I'm not entirely sure what you were referring to, when you said "IRCCloud can". Backlog from before you joined the channel is the specific feature that I was saying couldn't be done.
It's interesting to know that IRCv3 does have that support, so I was wrong about it not being possible. But if nothing implements it, it's not very helpful.
We are talking Open Source Project Communication not small group communication.
IRC and FreeNode channels have been the standard for communication and not for archival purposes. I use an IRC bouncer with my home server and I never look back through the thousands of communications except to see a reply to my question.
Why does a Open Source Community channel need archived communication unless it is just a few developers only chat?
IRC as a protocol is very outdated. If I log in at home and forgot out log out at work, I need another username.
IRCv3 has a lot of enhancements that should move IRC out of the 1990s as far as a communication protocol, but there's not a whole lot of movement on it. I think FreeNode has some v3 support.
We don't have a lot of developers dedicating time to this. I'd love to myself, because it's something the OSS community needs, but it's also very difficult to contribute to projects when you're already doing 40 hours a week at a day job.
Today I feel like most of the OSS projects that are getting support are ones that are corporately supported:
The problem is that you might be running a nicer IRC setup, but almost nobody else is. Doesn't do you much good if everyone else logs off the second they close their laptop lid, or can't scroll back up to see what you just said because they had to relaunch their client.
Chatting is interesting because of other people. That's why I'm chatting.
In Slack, I can ping people that are offline. And all they have to do is open Slack again or reconnect to the internet and they get notified. I don't need to count on them being an IRC veteran.
All these people pointing out ways to enhance your personal IRC experience are missing the point.
That "bit of history" goes a long way, though. In particular, it means you don't lose context when you disconnect temporarily, which makes a huge difference for both mobile and laptop use cases. (Obviously, this is also one of the reasons why bouncers were invented for IRC - and why they're popular. But Slack having it out-of-the-box is a huge yak saver.)
And other projects, including the GPL project Quassel, do have mobile clients (although Quasseldroid, which I maintain, isn’t exactly the best client in the world).
I've seen it, but it's nothing like even Quasseldroid. And quasseldroid is already a horrible codebase (mostly because I took over maintenance when I knew nothing about code quality).
Yet even Quasseldroid manages to be better.
That said, there is truly a need for a really good, FLOSS irc client ob mobile.
You're saying they're nothing like each other but are providing no examples. Besides one being an app and one being a website, what are the differences? Neither quasseldroid or Lounge have push notifications or searchable messages yet, so they seem to be pretty identical feature-wise.
EDIT: and we aren't talking about code-base, are we? If so, Lounge's is pretty solid (although it is in a pretty constant state of transition from ES5 -> ES6)
Quassel has them, doesn't mean Quasseldroid does :P
And I don't think you can say due to it's nature it's faster... I run Lounge in 20+ active channels on my iPhone SE and it runs perfectly. Native != more performant (and if the code base is as bad as you say I wouldn't expect it to be).
The bad part of the codebase is bugginess, and RAM usage. Especially because it always keeps all messages in RAM.
But what I consider a bug is already the best case scenario for the web client.
And 20+ active channels is nothing.
I'm in 460 active channels, with combined 40'000 users, and I get about a hundred to 200 messages a minute, while using the app on 64kbps connection.
(That's my test case for what should usable)
And quasseldroid already has code for those two, and a rewrite is almost done, I'm just waiting for the core changes to happen, and then release version 2.0
If not primary, at what percentage is it a core form of collaboration?
WordPress.org seems to fully integrate Slack into its processes. And as a now outsider, intuitively, it seems they've been able to scale their community more and continue their rapid development.
The OP does make a fantastic argument on the open/public point, but synchronize communication is also a necessity for collaboration.
> WordPress.org seems to fully integrate Slack into its processes. And as a now outsider, intuitively, it seems they've been able to scale their community more and continue their rapid development.
The WordPress community Slack forced Slack to implement some server-side changes when it hit ~5,000 people though (I don't remember the exact number, but I remember when things started to not work), and I suspect it's the largest resource-consuming instance in my Slack client.
I was at a dev meetup for Python:
I really thought he was joking when he said, what is IRC?
And then I realized that we have a whole generation of devs that have no idea what IRC is or how to use it. Amazing the amount of knowledge and experience lost between a single generation.
I don't think it's necessarily a generational thing. I know people in their 30s who don't know what IRC is (or who at least haven't used it), and I know people in their 20s who DO use it (or at least know what it is). And it's not as though the knowledge is lost; IRC still exists and there exists plenty of information about it. It's just not carried around in people's heads as much. None of this is good or bad; it just is.
I don't think it's a generational thing either. I know how to use IRC and how to connect with it. The problem is the difference in the amount of energy demanded by the set-up process. Connecting to Slack is extremely simple and I don't have to fiddle with the settings in order to get a decent experience.
Compared to IRC, I have to:
- Figure out how to configure my client.
- Figure out how to interact with the user account and moderation bots on Freenode or $other_server.
- Figure out how to set up something like ZNC in order to federate the client on my phone with the client on my laptop so I don't miss messages.
- ...
It's an epic yak shave that sucks massive amounts of time and energy a from the thing I joined the community to do: improve a piece of software that isn't IRC.
The benefit, though, is once you are set up with IRC, joining new channels is a breeze, especially since most open source software uses a single network (Freenode). All I have to do is type something like
/join #rust-lang
and I'm in the new channel. Compare this with Slack, where, no matter how many teams you've joined in the past, you have to go through the exact same rigamarole to join a new Slack team.
Discord avoids that issue by having a global identifier, similar to your connection to an IRC network.
However, having that global identifier / IRC network connection is a tradeoff - it forces you to use a single consistent identity for every single interaction on that network. For some people this is a plus; for others it is a negative. Slack's teams option allows people to use different identities for different instances.
> I know how to use IRC and how to connect with it.
> [...]
> - Figure out how to configure my client.
> - Figure out how to interact with the user account and moderation bots
I disagree with your initial claim. :P
Those are irc basics, things you only have to learn once, and there is documentation online and on the web. It's worth it to spend the time to learn a tool that you can use throughout your profession, even as the proprietary flavor-of-the-month services come and go.
That still ignores the existence of a huge usability problem. The investment of time may pay off in the long run, but IRC is large enough investment (and ongoing maintenance, ZNC doesn't just take care of its self forever) that people will take a route of less resistance when presented.
This all reminds of a few years ago when folks were banging on about how we needed to use Gitorious instead of GitHub for Open Source hosting. Gitorious is dead now and it wasn't until GitLab came along and recognized the usability problem that we got a viable Open Source alternative.
Same thing has happened in gaming with the introduction of Discord. No one wants to bother with mumble, team speak, or vent.
Trying to get everyone in our group setup with mumble was a pain for the people who only use their computer to game. When we switched to Discord it took maybe 10 minutes to get our group of ten all in one chat.
I've tried to give IRC a chance a few times, but it always felt like there were a few too many odd little things to learn before I could be productive and comfortable. I didn't get used to it and dropped it. It never felt inviting.
I use slack at work and love it. I fully agree that it isn't that different from IRC and I hate that it's another walled garden (of sorts), but it fixes a lot of the little annoyance in dealing with IRC.
Grep isn't a difficult skill to acquire but I wouldn't hire someone that didn't know it. Some skills can be good proxies for a range of other skills an experience and a lot of developers are in that "don't know what they don't know" range.
Sure, I just have to disagree on IRC being a good indicator for that.
Also, fwiw, most of my colleagues use IDE "search project for string" in places where I use grep. Also, if I'm being honest, you should hire nearly all of them before you hire me.
I've been IRCing for 24 years. I know about bouncers, different clients, etc., and I still prefer Slack to IRC.
I like knowing that it's going to handle unicode properly, in all cases, for everyone on the Slack channel. I like that it handles right-to-left text for everyone reading.
I like not having to ever think about, is my bouncer down? I also like not having to think about, where am I going to run my bouncer? It's nice not having to think about that stuff at all. I've got a lot on my plate, keeping a bouncer up and running somewhere (just so I don't lose history!) doesn't need to be another thing I do.
I like the plugins, the integrations with various other services. I like the convenience and polish. No IRC client compares to Slack for integrations and polish. It takes friction out of my daily chat experience.
I've even moved some private irc channel chats to Slack channels, because it's just a more pleasant experience in 2017. No regrets about any of that.
I think these are all key points. The user experience in Slack is so easy, convenient and polished. It takes friction away from communication, allowing effort to be focused on the tasks at hand.
I used IRC a lot as a teen back in the late 80s early-to-mid 90s. This was back when to make a private channel you would have to join a channel that was a negative number and hope nobody else wandered in on a guess (which was unlikely to happen since the number of users was literally under 200 at peak times). Pre-Eris, Pre-EFNet, etc.
Despite the nostalgic kick of it, I never used it as a serious work tool at any of my jobs, haven't used IRC at all in probably a decade, and totally agree that options like Slack are just plain better work communication tools.
I used IRC a bit in the mid 90s when I first encountered this whole internet thingy. Even though I was young and dumb, it struck me as a bit lame: nerd bullshit with fiddly setup. The async aspects of usenet and email struck me as more scalable, and the web had, you know... graphics.
I had to use IRC again in 2015, and pretty much nothing had changed, except now I was 20 years older.
Most of the criticisms of Slack seem to boil down to: this (whatever it is) is something IRC could do. But it (whatever it is) is virtually always something IRC doesn't do, something it does in some half-arsed fashion (that requires a huge amount of fiddly setup), or something that's supported by only a few clients. How is this not obvious? I'm perpetually mystified that anybody would admit in public to not understanding why Slack is taking a massive dump on IRC.
(Criticisms of Slack's closed nature are valid. It's also worth asking why it has to take up 2GBytes of RAM just to show a tree view, an HTML view and a text box! But don't tell me that you can't understand why Slack is winning anyway.)
"And then I realized that we have a whole generation of devs that have no idea what IRC is or how to use it."
It's not a generational thing - it's a "lifer" vs. "non-lifer" thing.
Some people are coding with computers because it's an exciting, lucrative career with great benefits!
Other people are coding with computers because they can't imagine doing anything else, and would do it for free if IT wasn't central to business in the 21st century.
On one large free software project, we adopted Mattermost (an open source / self-hosted equivalent of Slack). We went from ~12 active users and ~50 lesser active users, to ~ 100 active and ~ 500 lesser active users. I agree that more folks should consider moving away from IRC.
The sign-up process for Mattermost is easy. It's intuitive, cross-platform, mobile-friendly, etc. While we geeks are used to IRC, onboarding people to IRC is no different than any other product: the smallest glitch, weird UI, confusing elements will make people drop off pretty quickly. I have always had to sit down with someone to show them how to connect to IRC. We would waste time at code sprints showing people how to connect.
With Mattermost, we have unlimited logs (so we can cross-ref/permalink conversations in the issue trackers), threaded conversations (great for when the channel is noizy), emoji reactions (friendlier atmosphere), etc.
However, I agree with the article: Slack is inappropriate for open source communities. Mattermost and Rocket Chat are good alternatives. Between my IRC habits and what I can do with Mattermost, I find Slack very frustrating (and I don't use it anymore). Then again, as much as I like IRC, it's not an alternative either.
We migrated from IRC to Mattermost and haven't looked back. It integrates so well with our Gitlab/Jenkins flow, too. It's been great.
The biggest benefits for us:
- Easy to use web push endpoints w/ API keys (great for scripting with curl)
- Integration with Gitlab / Jenkins
- Chat Logs (see what happened while you were away)
- Public listing of channels (no more "oh you have to join #whatever to see that")
- Mobile Web App (I can't get the Android app to work with our self signed cert, but that's OK).
How do you like mattermost compared to rocket.chat? My group switched from flowdock to rocket.chat to save money and we've definitely seen a dip in participation. Rocket.chat's mobile app constantly seems to have issues with remembering what server you were logged into between updates and the desktop version doesn't recognize when you're caught up with a channels messages leaving it marked unread unless you go out of your way to manually tell it. Plus I really miss threads...
Slack is successful because IRC web clients are so cumbersome and annoying. Most of the things Slack provides easily could've been provided in a web-based IRC client, but where's the upside for Slack in that?
By adopting an incompatible web model, they lock people and their messages in, and can charge per user in the room. As a good IRC client, the most they could get away with is a subscription charge per client, which has the downside of creating a barrier to entry that limits adoption (requires everyone who wants to use it to pay, v. a central employer or organization that can compel people onto a chat platform).
Users like web-based because it means that they just click a button and the thing they want magically appears with no install process. Companies like web-based because it allows them to box all the secret sauce behind a server that can't be introspected. There's no risk of someone cracking their program and distributing it for free, and they get to keep complete control over the crown jewels, which are now and always have been the data that the program purports to manage.
It might be more useful to speak in general terms than call out Slack in particular. The concerns expressed here aren't limited to Slack (despite the link-baity title), but any form of communication that:
(a) Can't be referenced or linked from the Web, and
(b) Is a form of synchronous communication
The same factors, BTW, apply equally to in-person discussions held at open source conferences. I wonder what the author thinks of the value of those insofar as "open source communications" are concerned.
Except with both Slack and Gitter (not sure about others) you can link to specific messages. Sure you still need membership to view the content (a serious downside), but saying you can't link at all is disingenuous.
With Slack, at least, channel history is truncated for free accounts; so it's quite possible that a specific conversation could become practically inaccessible after a while.
You are able to export your entire public history, regardless of the status of your account. I was able to do this to rescue the chat history for Hyperledger[0][1] before we moved to Rocket.Chat.
Does Slack's terms of use forbidden creating an off platform archive?
If not, given that searchable archives are one of the ways Slack makes money, makes me wonder why there's not an open source way to pull the chats and archive them in a way that's cheaper and independent of Slack.
Right, but they do still permit the capacity to read accessible history, which is open to scraping and archiving. They can't completely kill the concept of doing that, realistically.
They can't stop someone from creating an archive that's inaccessible to them, if they don't know of its existense. Anyone can create an archive of something they can read and hide it, and selectively share it.
Such an agreement on curtails specific forms of automated crawling and public-facing archives.
The problem isn't creating an archive, it is
a) synchronizing the archive properly to account for your feeds connectivity issues, and
b) providing the archive usefully once it gets large and/or popular
(a) is fiddly and a bit technical but has been solved-ish for ages before slack existed
(b) is fundamental though. If it's a big archive, it costs real money to provide access & search to. If you break it up, search-ability tends to suffer.
None of this is new, slack is just the latest flavor
Yes, but chat logs are logs of ... chat. By nature, it's disorganised, free-wheeling, contains lots of casual meandering (as any conversation would). Not very useful to a third party.
How often do you find solutions in public archived mailing list posts when Googling problems? I imagine often. While some e-mails are more terse than others, fundamentally e-mail list posts demand a certain structure. Can you imagine having to pour through a 25-page chat log instead?
And with that, the entire idea of "search the archives before asking a question" would go to pot.
I was [breifly] part of a project that used slack as the primary communication medium. I can second all the points in the article. IRC is a terrible format for open source collaboration. Flame wars can get out of control really quickly via text.
I was expecting Stallman-style advocacy against closed-source as a principle; pleasantly surprised by the arguments.
Synchronous communication, indeed, is bad for the main communication channel. However, as a secondary communication channel, it can serve important needs.
When people are looking not to just get a single issue resolved, but to form a community, this community is often based on informal communication and emotions. Seeing the same people in the member list every day, exchanging little inside jokes, getting to know individual members of the community on a personal basis — this is something completely irrelevant for the user of the open-source product, but can be an important emotional component that motivates people to stay in the community and continue to put in effort into the project.
And, of course, a synchronous channel, where you can get more lax on moderation, is a much more suitable tool for this purpose.
> I was expecting Stallman-style advocacy against closed-source as a principle; pleasantly surprised by the arguments.
Is this a problem?
Ostensibly one should hope to be able to communicate online in the same
manner that one does offline: without paying an intermediary
Further, if the 'natural trend' of economics is towards commoditization
of products, why then are we abandoning those things which facillitated decentralization in order to support another entities profit motives?
> Further, if the 'natural trend' of economics is towards commoditization of products, why then are we abandoning those things which facillitated decentralization in order to support another entities profit motives?
your point fails to address this point; similarly 'better' has varying metrics.
> Seeing the same people in the member list every day, exchanging little inside jokes
...about what other people are writing in the main communication channel, creating precedents about what should be discussed with "individual members of the community on a personal basis" and deciding the content that should be written on the main channel for the benefit of outsiders asleep in other time zones, ...
How can you generally prevent a subgroup "deciding the content that should be written on the main channel for the benefit of outsiders asleep in other time zones" even in an 'asynchronous' communication channel? There's nothing stopping them from responding to each other quickly enough to effectively communicate 'synchronously'.
I've intended to reply to communications before only to discover that someone else replied first while I was asleep in my other time zone.
Free software and open source software are synonyms. Even Stallman agrees on this. He cares about the use of the terms because of their other implications.
Ok, that's interesting. My impression from watching his talks is that he does not consider the two ideas as synonymous, in that a software can technically be closed-source but have licensing that is libre-free so that it can be used by whomever however. But perhaps I got it wrong.
It is the other way around: just because the source is available free of charge does not make the software free as in freedom. For example, there are licenses that prohibit you from running the software for commercial use even though you have access to the source. This would not fit the FSF's definition of free software because the user should have the right to use the software as they wish.
Those licenses also aren't open source. 'Open source' doesn't mean 'you can view the source', it means you can view, run, compile, modify and distribute the source, and distribute modified copies.
As I posted on twitter[1], Slack is linkable. Not public, but if you can chat you see them. Gitter: public AND linkable. Async is a good argument; linkability is not.
Slack's UI is good. Not perfect, but it's quite usable compared to all the alternatives[2]. People always underestimate the value of good UI.
Slack doesn't have public links and an archive of posts, it's a stream behind a login, which might go away at any time on an active project. It's a terrible idea for anything other than ephemeral communications which don't need to be logged or kept. Re the UI, for a chat app it's fine, most conversations around an open-source project should not be held in a chat format however, but in a format that respects participants not being in the same time zone or having the same time pressures (that means an async format, not a linear chat).
If you want to have an open process (for discussions around proposals, bugs etc), you need an open, linkable, archivable format, ideally hosted somewhere you control. That means mailing lists or a public html server, not a private chat service which may or may not be around, which may delete data or change policies at any time. For this reason Github isn't great either, but at least it has public links and you could scrape the data if required.
> [2] I've been on IRC on and off since 1993. It's much worse.
So? There are services offering that, too. Linkability is easy to add to IRC as soon as you are using logging systems and modern bouncers such as IRCCloud or Quassel.
Have you never replied to an old forum post and been accused of 'necromancy'?
Have you never been late to reply to an email chain or a thread on a mailing list or forum?
There's no clear line dividing asynchronous versus synchronous communication. Even phone calls can be (partially) asynchronous – "hold on, let me check" let alone "let me call you back in <some amount of time>".
And similarly, if a group of people are responding to each other quick enough, even using an 'asynchronous' medium, then they're basically communicating 'synchronously'.
I doubt Discourse will run on a $5 VPS. The last time I checked its crashes on 512MB RAM, needs at least 1GB just to start. Have the minimum requirements changed? 1GB minimum and 2GB is recommended by Discourse itself.
Discourse is also not easy to setup, its quite involved and complex and you need some Ruby and systems expertise. Infact I think Discourse only supports Docker installs. So you need to know Docker too.
Given the complexity you should be pretty comfortable with Ruby to run it with any amount of confidence. The hosted option seems much better than trying to run it yourself.
I did just run across a cloud provider with $5 VMs with 1 GB of RAM (somewhere), but the last time I checked it's at least $10 per month to host Discourse on DigitalOcean or similar.
What drives me nuts is that there are so many of these things.
I know groups that (for business or pleasure) use Slack, Discord, Skype, Google Hangouts, IRC, etc.
All of these clients are a bit more obstrusive than they need to be in terms of pop-up notifications, software updates, cpu, memory, transfer, etc. They all screw up enough that there's always a little apprehension that something will go wrong when you get a number of people together for a meeting.
It is one thing to deal with one of these things, but when you have to install ten to get your work done you have a problem. I have a high performance computer and I want to keep it that way.
>It is one thing to deal with one of these things, but when you have to install ten to get
The modern office large office is pretty bad in this respect. Really not uncommon to see things like
• Need to have Slack open
• Need to keep an eye on Basecamp/pm software
• Need to have Outlook open / check in on for email and calendar invites
• Need Skype open because not everyone uses Slack
• GitLab is open in another tab
I've started counting the minutes that I use in a day just logging in to things with our SSO, because it has started to actually add up, haha. It has gotten silly.
> I've started counting the minutes that I use in a day just logging in to things with our SSO, because it has started to actually add up, haha. It has gotten silly.
If you need to log in more than once, can you really call it SSO? =)
If it's anything like my experience, the trip from clicking on the button to open the app and wait for the myriad of redirects, before clicking through to the page you actually want to monitor is non-trivial (and sometimes doesn't occur if the tab isn't in the foreground).
I don't have that many open, and it still takes me around 5 minutes every day to open them back up.
At least you have SSO! Imagine what if you had different credentials to each of these services (even logins)! There are big companies that operate like that...
There are also lots big companies that have "SSO" but it is half-baked or incomplete with regards to which services and you end up with MSSO - multiple single sign on.
Having different credentials would actually be faster. One key chord to ask 1Password to fill in my password and log in, and I'd be done. Instead, with SSO, every time I need to log in, I need to type in my email address, go through a bazillion redirects to Google where it asks me which of my accounts I want to use (even though I already typed in my email, and even though I only ever use one of those accounts for SSO), click it, often have to then enter my Google password and/or OTP code, then go through a bazillion more redirects back to the app.
I don't even bother logging out, ever. I just have them open in different tabs.
Imagine having about 7 tabs open. By the time I'm finished with the last tab, something new has come up on the first tab I checked. Huge waste of time. I'm trying to wean myself from all these services, but it's not easy.
This or that project is on GitHub, but join the developers on Slack. And I hate Slack.
I turned all of my notifications off and use Pomodoro timers.
If it really can't wait <25 minutes, they can call me or come to my desk. It's amazing how many things aren't "immediate" if you create a slight cost with requesting attention.
This is exactly what I do! I find it very simple and effective. I set mine for 60 minutes. It really helps focus. 60 minutes is about as long as I can focus without a break anyway.
As a freelancer, I have EXACTLY this problem, so I started hacking away on my own solution. Don't want to shamelessly promote myself here, but if you're interested, link is in my profile.
Your users and their clients are still going to be using Slack and email, but it seems like you're giving me one more thing to log into. You write:
> Schedule your time spent and group distracting reminders and notifications in one place
If this "one place" is a separate silo from Slack, Outlook, Basecamp, Skype, SMS, Discord, Hipchat, IRC, and Github...it's not the one place I'll need to check. It's the n+1th place.
Now, if I can put my credentials into Calmbird (securely would be nice, but you can have the plaintext if you can make this insanity stop) and have it do the API connection to - or, if necessary, the nasty DOM-manipulation, Windows message hacking, and client-impersonating - to put all these services and their notifications in one place, that would be a solution to the proliferation problem.
Also:
> schedule automatic emails to your clients with updates
My clients don't want automatic emails, especially from templates/digests. They want me to hand-craft them as if it was the most important thing in my life. And while they can understand a curt update message or a missed daily status notification, the real point of these updates are to confirm that I'm still on the project. If a message accidentally went out with a placeholder like "I'm still working on {todo-insert-task-here}", and I didn't know about it, that would be...bad.
>or, if necessary, the nasty DOM-manipulation, Windows message hacking, and client-impersonating - to put all these services and their notifications in one place, that would be a solution to the proliferation problem.
This isn't possible for web services due to the state of U.S. law. Speaking to a server without the consent of the server's owner is both a crime and a tort under the CFAA. There is also liability for copyright infringement, among other things.
If you publicly advertise your service I can probably assume your consent to speak to it. I don't have to wear a funny hat while doing so just because some hidden legalese on your website says so.
At least in Europe, news organizations pushed this kind of argument in their campaign against adblockers and failed in front of the courts. US law may differ, of course.
>If you publicly advertise your service I can probably assume your consent to speak to it.
The implied access and license is probably valid as long as you're abiding the ToS. If you're violating the ToS after agreeing to it ("agreeing" means that proper notice is given to make the ToS binding, etc.), the implied license would probably not work. If you've been specifically asked to stop, either directly or indirectly (e.g., through an IP ban), any implied license or access privileges would almost definitely be revoked at that point.
>At least in Europe, news organizations pushed this kind of argument in their campaign against adblockers and failed in front of the courts. US law may differ, of course.
Ad blockers differ because they alter the payload after receiving it under legitimate terms (though this could still probably be considered copyright infringement under the argument that the license is for viewing only, not alteration). The CFAA would not be applicable because when the adblocker comes into play, you're not accessing someone's network (which is what the the CFAA addresses).
If a site clearly disallowed AdBlock users in their ToS and adequate notice was given to users that they were to be bound by these terms, it would be "unauthorized access" to the server, which is not allowed under the CFAA.
- Your users and their clients are still going to be using Slack and email, but it seems like you're giving me one more thing to log into
That is not the aim, the real goal here is exactly what you state next i.e you'll be able to (securely via OAuth, so you can also revoke access anytime) log into your Slack, Basecamp etc. and Calmbird will be the one 'dashboard' where you log into, kind of like having a social network client that supports Twitter, Facebook etc.
> My clients don't want automatic emails, especially from templates/digests. They want me to hand-craft them as if it was the most important thing in my life.
That is very true from personal experience, this is a feature where you'll craft a sort of an 'emergency' email yourself in advance and when you indicate in calmbird that you're working, it'll send if off to your client if there's an email from them, optionally with the latest updates. It's not a 'machine-generated' email in the traditional sense and this feature is in my current version entirely optional, which is how it will stay at launch, (if it stays at all, I'll certainly be thinking a lot about how can this be improved, there's no point if it's not going to be useful.)
Well, perhaps but I am more trying to develop a service to avoid the Slacks and Basecamps of the world, while still being aware of what's going on, rather than just being a multi-network client.
As an aside out of curiosity, is the client/freelancer graphic representative? Are you really in the Kimberleys with a client in Western Sahara? Just struck me as odd as there are few places on earth that are less-densely populated (while still being populated) :)
I don't have a need for the product myself, but I do like the name for it.
> I've started counting the minutes that I use in a day just logging in to things with our SSO, because it has started to actually add up, haha. It has gotten silly.
I have a similar setup, and I don't waste any time logging into all of them because I simply always have them running. Why would you need to login every day? Are you shutting them down at the end of every day... if so, why?
I feel the same way. Standardization is a feature, but it also comes with its costs (difficulty of extending features). In many places lack of standardization is okay, but I feel like for most chat purposes (especially about programming), plain text over IRC works just fine.
I don't mind Gitter though, because it has a useful feature (code snippets) and it is available through a web app as opposed to a separate install.
It appears to be just a wrapper around web interfaces. Electron or some such nonsense. Truckloads of megabytes - binary size as well as memory consumption.
If I can't use my own client (pidgin/finch), then I'm just not going to use the chat-service. I don't mind being logged into $chat_client_of_the_week, I mind logging into all of the $chat_clients_of_last_week though.
In the good old days of ICQ and Jabber you could install a client that would integrate several protocols into a single lightweight UI (e.g. Miranda IM). Unfortunately the new wave of messengers is much more successful at guarding their protocols against such integrations.
That said, I wonder what's Discord's official stance on such things. Their bread and butter is voice chat, and they seem to be fairly open minded. Maybe they will eventually provide a public API for basic text messages.
What if software engineering as a skillset hit its peak within the last 5 years and now it is just going downhill in general? The quality of "companies" isn't going down - companies are made of people, and some of those people are in charge of creating and testing its technology...
I think one of the strengths of matrix (in addition to federation) is first-class bridging. I already communicate to several IRC networks, gitter and slack via matrix. I only have to use one matrix client and it enables me to communicate with people on several different networks/services. No monstrous electron apps that load the web UIs of several services in different tabs. The server-side in matrix handles the bridging and I can use any matrix client I like.
I hear this a lot, in terms of older tools being considered obsolete.
Other than the natural human tendency towards novelty and the network effects, what, exactly, is obsolete about mailing lists or IRC?
What features are missing in IRC that Slack has for synchronous discussion? (I'll start: animated dancing pigs out of the box and the need to write/plug in your own archiver.)
What limitations do mailing lists impose on open source development that are not present in other tools?
> What limitations do mailing lists impose on open source development that are not present in other tools?
None, in my opinion. On the contrary, they are the only tool that demand a structure — just by the nature of e-mail messages — that is coherent enough to be highly useful when searching archives later.
> On the contrary, they are the only tool that demand a structure — just by the nature of e-mail messages
Newsgroups also have this structure and they have the advantage of easily doing an archive search (by being able to download part of or the entire message archive of a given group and using the search features of your mail/news client).
> Quoting is still a problem. Most answer above. Some below. Many nitpick in between.
One thing I've noticed on Hacker News, Slashdot, and even reddit is that if someone quotes the post they're responding to, they'll invariably post their response below it. And if they quote multiple parts of the parent post, they'll interleave their responses. I don't recall ever seeing a response where the quoted text is below it.
I've really never understood the rationale behind top-posting. It makes it much more difficult to understand the context of the response without having to jump between the original message and the response.
> Threading is easily broken. Especially if Outlook users are involved.
That's because Outlook does not follow the relevant RFCs in terms of maintaining a message through through the In-Reply-To and References headers.
> Formatting is an issue. There is no markdown or whatever for links.
Most GUI clients will make links clickable. There are also conventions such as using astericks, _underscores_, or /slashes/ for bolding, underlining, or italicizing text, but a lot of clients don't render them consistently, IME.
> Some people insist on line lengths and other stuff.
There is an RFC that adds format=flowed to the Content-Type header. Then every line that ends in a single whitespace character will be joined with the next line and wrapped at screen width instead of at the position of the CRLF characters. Clients that don't support it will still see the wrapped text.
To have all the features you get for free out of slack, you have to do a lot of work and maintenance to get out of IRC and mailing lists.
Mailing lists by themselves are terrible, because there's no history. You can't scroll up to find context for the conversation. You can get public archives, but then where you actually use the mailing list and where you go to look at history are completely separate, which is a terrible UX. Google groups mostly fixes this because they're really just a forum that supports emails.
IRC is terrible because everyone has their own client, so you never actually know what someone will see when you post something. Post a link, - will it get auto-expanded? How will it look? Will it get auto-linked? If you @ someone, will they get notified? if so, how visibly?
IRC also has the multi-login problem - it gets confused if I log in from my phone and my laptop. To get a persistent history of IRC requires running an external service which is way beyond most users.
Slack has mindshare, which leads to having a ton of integrations with other platforms, which just multiplies its effectiveness.
I 100% agree that I wish they offered a publicly visible option, so anyone can view without logging in. I also wish they natively supported self-registration.
I have to echo another commenter on here. If you want the best of all worlds, a forum is what you're looking for. Publicly visible, easily linkable, long form, asychronous communication. Whether that's google groups or something else is up to you.
> IRC also has the multi-login problem - it gets confused if I log in from my phone and my laptop. To get a persistent history of IRC requires running an external service which is way beyond most users.
This part I really do find annoying about IRC. I use IRC by far the most but this still gets me. Even if you run it in a screen somewhere it's a hassle from a mobile device. There's solutions for all of it, but you have to string a series of things together to get to something just about every other option offers you out of the box. Unless you have a particular need for IRC or have used it for a while and know how to deal with it, the other options are more appealing to newcomers. Depending on how young your project or community is that can make all the difference.
Slack gets a lot worse once you want to start dealing with two teams using it. With most IRC clients, I can have connections to multiple servers running, and able to see at a glance everywhere that there's activity. With Slack/Discord/etc, that involves a frenzy of clicking as you look through each group of chats individually. I can lay things out how I want, move things around, etc. Slack, fortunately, has bridges built in for IRC and XMPP clients, so I can use my already working clients instead of having to keep another web page open to another javascript-laden nightmare.
> Slack, fortunately, has bridges built in for IRC and XMPP clients, so I can use my already working clients
Unfortunately, the Slack gateway implementation is subpar. In my experience, it will send me the last message I sent before I disconnected when I reconnect, but it won't send any of the other messages that were sent in the meantime. The other problem is that group chat only works over the IRC gateway, not the XMPP one (at least I could join it from my XMPP client, but I couldn't send any messages to it).
In contrast, the old XMPP server we used would just replay messages in group chat when you reconnected, so at least you wouldn't miss anything when you weren't connected.
> Mailing lists by themselves are terrible, because there's no history. You can't scroll up to find context for the conversation. You can get public archives, but then where you actually use the mailing list and where you go to look at history are completely separate, which is a terrible UX.
Gmane actually works really well at addressing the problems you describe in terms history. Their NNTP gateway allowed me to download and search the git mailing list messages since 2009 in my email/news client.
The primary benefit of 'Slack' over "older tools" is that the former are free – not just financially but in terms of how much time, effort, and energy is required to set them up and maintain them.
Sure, there's lots of freely available alternatives, but even tiny (but non-zero) costs in time and money are the difference between widespread usage and relative non-use.
I setup Gitter on a GitHub repo for a project by clicking a button and accepting a pull request that Gitter auto-generated for me to add a link to the repo's Gitter channel in my project's README. That's the competition that every older tool is failing miserably to meet, let alone exceed.
> The primary benefit of 'Slack' over "older tools" is that the former are free – not just financially but in terms of how much time, effort, and energy is required to set them up and maintain them.
You are ignoring the costs that come from lock-in (inflated prices, lack of innovation) and migration in case the proprietary solution shuts down. That's the psychological tendency of humans that these companies exploit.
Lock-in is a cost of any solution tho. Whatever solution one picks, it's going to cost time and energy and, probably at least indirectly, money to migrate to another.
Non-proprietary solutions 'shut down' too, e.g. because the unpaid developers burn out and quit.
A lot of people reasonably believe that 'free' solutions are inherently riskier, all else being equal, because (generally) no one is being compensated to maintain and support it.
> Lock-in is a cost of any solution tho. Whatever solution one picks, it's going to cost time and energy and, probably at least indirectly, money to migrate to another.
That's not lock-in. Lock-in is when you are dependent on a (quasi-)monopoly, not just any potential migration cost.
> Non-proprietary solutions 'shut down' too, e.g. because the unpaid developers burn out and quit.
No, actually, they don't. The point, as above, is that it's not the sole decision of another party when a 'shut down' happens, that is, again, there is no monopoly. First of all, if you have free software running on your own machine, there is noone but you who can decide to just shut it down today, but also, in the long run, you can just take over maintenance of the software yourself, or you can buy/hire a software developer to do it for you, or you can get together with other users of the software to hire a developer.
Also, more generally, with regards to open interfaces/protocols rather than necessarily free software: No, email cannot be "shut down" because "the unpaid developers burn out". And changing my email client or server or hosting service does not necessitate everyone else I want to communicate with to do the same.
None of that guarantees that you can keep using things indefinitely at an arbitrarily low price, but that's besides the point: The price is determined by a market, and not by a (quasi-)monopoly.
> A lot of people reasonably believe that 'free' solutions are inherently riskier, all else being equal, because (generally) no one is being compensated to maintain and support it.
Well, yeah, those people are just clueless, if only because they confuse freedom with not paying for something. If you want to have something maintained, how about you pay for it? How does it make any sense to say that you prefer being forced to pay for something because you otherwise fear that it's not being maintained if you don't pay for it?
Also, none of this has anything to do with open protocols (which was the primary topic of this thread, kindof): Microsoft is being paid very well for maintaining Outlook and Exchange, which is both proprietary software. They still speak SMTP with the rest of the world, instead of forcing everyone to buy Outlook and Exchange to be able to communicate with their users.
What really needs to die is the view that old tools are bad tools. In my experience, the most useful tools I use (standard unix utilities, vim, emacs, lisp, etc) are the oldest ones while the newer ones are the ones I could most easily replace.
It's much worse. A wiki still consists of pages of documents, even if they're kind of improvisational and perhaps incomplete. A chat log is just a log of people chatting, with all the free-wheeling and meandering conversational style that entails.
Forums fall apart when you're trying to do things like realtime debugging. With a chat client, I can leave a window open in a corner and keep an eye on it while doing other things. With a forum, that becomes a game of hitting refresh every thirty seconds waiting for new messages.
I massively disagree with #2. Unless your project has very little activity, synchronous or pseudosynchronous communication is a lot more efficient than async through email/discourse. It's also a lot more friendly to your contributors, it makes things less formal and more human.
Async shines when you have a lot of users, but only if it's very accessible (searchable). Otherwise it's just people repeating themselves constantly.
Also, longer rant on the IRC thing. For the past decade I've been using IRC as my central mode of group communication for all open source work. Last year and as part of my (open source) company, I've completed the switch to Discord.
I'm an open source die-hard and it bugs me that Discord isn't open source yet, but I believe this has a fairly high chance of changing (MUCH higher than Slack has at any rate). I would heartily recommend Discord for open-minded open source communities.
I'm now using Discord for everything. It has given me a unified interface for all my personal and group communications, easily searchable, with voice chat too (and video chat very soon, I cannot wait to never open Hangouts again). Needless to say, I'm a huge, huge fan.
Slack has none of that. The #1 thing that bugs me with Slack is the forced separate accounts for every single Slack instance. And you can't delete any of those accounts, you can only "deactivate" them.
Our open source community uses it. It works really well for us because we're a gamer-oriented open source community, so Discord is already pretty well known in that circle. On an ideological level, its API gives enough control over everything that goes in in it that I'm satisfied I could move to another service, should I need to. If anything, it's harder to move off IRC because there's no public logs, easy point of contact for the regular users, etc.
Also, I'm using Matterbridge to mirror our public channel to IRC: https://github.com/42wim/matterbridge/ (highly recommend everybody here checks it out; it supports a lot of protocols)
IRC has really disappointed me the past few years. I had a lot of hope that irccloud.com would offer a solution to IRC becoming irrelevant in the face of Slack and Discord, but it just hasn't happened. They're understaffed and don't have enough money coming in.
There's also a lot of ideological purity in recommending against SaaS "centralization" for comms but the truth is, it's not better. Last year my HDD crashed and I lost the logs for my organization's original channel going back to its creation... I'm very, very sad about that. Had I been using IRCCloud (or Discord) at the time, I wouldn't have lost all that. Granted, those companies could have, but the chances are lower than me fucking up.
This is the same reasoning why email is usually better off handled by companies whose livelihood depends on offering you the service, than by yourself.
Also like I said elsewhere in this thread, for a project using a Freenode channel and another using a Discord/Slack server, there is no difference between Freenode disappearing and Discord/Slack disappearing. Your host disappears, you have to find a new one, update tons of references and contact lots of users to let them know. On IRC, that's even harder. You can run your own IRC server, but very few do that, and those that do get less mindshare because connecting to yet another server is very annoying on IRC. It also costs you more, both in money and maintenance.
The biggest problem I have with discord is that the client is complete and absolute balls if you want to be in more than one group at once and keep up with notifications and the like. With IRC, my one client shows the activity of all of the networks I'm in, with discord, the only notification I get is that there's "something" going on in another group, without telling the channel, etc. It's much more interrupting and frustrating.
The article, at the end (spoilers) states that async communication should be preferred for open source work. And I agree that async is important. But there are times where you do need that synchronous, let's talk now communication. And for that, Slack is great.
Forums. I don't know why the internet got tired of them, even when they sometimes fit the bill so well. Slack is chat. Mailing lists are far too outdated. Forums are good, and some good people out there are still developing them.
Reddit IS a forum platform. Anyone who wants to create a subreddit can do exactly that. Reddit did not replace forums, just the software that they run on.
Reddit is distinctly different from a typical forum due to how heavily it weighs time and popularity. A normal forum can have multiple threads of thought active at the same time without interference, and sometimes a thread can live for a long, long time. There's no need for a thread to be super popular to survive, a thread can literally live off of two users.
On reddit, if the time is not right, the discussion will not be had and ends up in oblivion.
The forums I visited all died, but none replaced them (and I kinda miss forums). There are still some active forums that I know of, like Factorio's (a modern game, not one from 2001 when forums were still hot). They have a subreddit which is active as well (though less), but the forum format still works fine for them.
New services replaced many things that forums were used for, but not all.
They're generally fucking terrible in terms of UI. I much prefer Google Groups over older forums. Discourse is even better but there's no easy way to setup a forum for free. The last time I looked into it it would be roughly $10 a month for a DigitalOcean droplet to run a small forum, but that was more than I wanted to spend myself. And accepting money is a non-zero amount of work too.
Probably the main reason why Slack – and Gitter, and IRC too still – are widely used by open source projects is that they're free, financially, and mostly free in terms of maintenance.
> Mailing lists are far too outdated. Forums are good, and some good people out there are still developing them.
WTF?
How is it even remotely sane to provide a user interface instead of an API/protocol?
I don't care to learn your forum's user interface, and I don't care to poll your forum for new content. I have a mail user agent that's configured to fit my needs and that I know well how to operate, and that's where all the mailing lists that I am subscribed to push their new content into this one unified interface for me to interact with them. Web forums for the most part are just a pile of broken usability.
> How is it even remotely sane to provide a user interface instead of an API/protocol?
It's the way of the world. 20 years ago we had NNTP, POP, and IMAP, and you could read them all with Gnus, customized with finely-tuned filtering and killfiles. But it's hard to "unlock value" from these things, so then there were ad-strewn forums, and now SaaS abominations, because how dare you not change your mail client when its developer thinks you should?
Yeah, sure, provide as many user interfaces as you like, just not instead of an API/protocol. The whole point is that everyone can choose the UI they prefer, or build their own if they like.
Forums. I don't know why the internet got tired of them
I have recently been participating on Reddit and I still like HN, but I am spending less time of late on another forum I still belong to. For me, part of the answer is that forums are heavily influenced by moderators and most of them are not anywhere near as good as what you see on HN. So, if you have personal friction with the mods, good luck with that!
The internet is this awesome opportunity to rub elbows with people around the world. Then the admin structure very often gets you stuck in "I shot the sheriff" * hell, where no matter what you fucking do, some asshole who doesn't like you and is in charge rides your goddamn case and deletes your shit for bs reasons and so on.
I don't know how to solve this problem. Most forums don't seem to be able to get it right.
* This is an old song where the plot is that the sheriff was making his life unbearable and there was no other way out, so he finally shoots him.
> the [forum] admin structure very often gets you stuck in "I shot the sheriff" * hell, where no matter what you fucking do, some asshole who doesn't like you and is in charge rides your goddamn case and deletes your shit for bs reasons and so on.
That's why I preferred Usenet over forums. All filtering is done by the client and is under your sole control (outside of moderated groups).
It's such a disappointment that social networks killed forums! The experience is so much poorer now. There's insane amount of fragmentation (everybody wants to run their own thing because likes), no search, no discoverability, no ways to conveniently track the discussions.
But the main huge drawback, from my point of view, is that non-anonymous model of conversation means people more inclined to judge you from looking at your profile and not from the specific local reputation, which was a thing with forums.
Probably because you would need to remember what the addresses were, what your credentials were (for each forum you joined) in order to participate. Also, administrators could disrupt discussions any time they wanted or restrict people from posting in the same vein.
Usenet, on the other hand, didn't have these problems, though it pretty much ended up the same way.
535 comments
[ 4.6 ms ] story [ 322 ms ] threadIf you find yourself repeating the same thing a lot in chat, it would be a good idea to document it somewhere and just paste a link. With a link to the relevant documentation, a lot of people will just do the rest of the legwork on their own, and will now be able to quickly reference it going forward, and hopefully bug you less in chat (you can always be explicit and refuse to answer people, asking them to read the docs instead).
If you find you're pasting too many links too frequently, then it's time to make an FAQ with those links, and start linking to that.
Culture-change is about the hardest thing to achieve.
* Optionally show thread replies in-line with chat, as they come in, just like regular chat but with some special annotation to indicate they're part of a thread.
* Allow the user to collapse a thread so they no longer see it in-line.
* Auto-close threads after they're idle for more than 1 hour (or some site-policy-configurable timespan).
* Allow the user to navigate between threads using only their keyboard.
As they are now, I think threads are bad for business. They hide useful information away and slow conversation (responses dragged out because they're no longer in your face).
Just because Slack isn't good at slow conversations doesn't mean it's bad. Just because email is bad at including people who joined after the fact doesn't mean it's bad. Those aren't their strengths, and that's fine. They still serve their own purpose just fine.
You only have the last 10k (?) messages and that includes public and private messages. If you have a mildly active project, messages may only be available for a month and you lose the history of the project. That makes it an awful support option too.
> Are the bandwidth costs really that high to justify hiding all those messages (likely on the order of 100k or 1M for many servers) ?
Given that the cost to you is 0, what cost to them is required for it to be justified to you?
It seems odd that providing a free but limited service is evil, based only on it being slightly more expensive to give you an even better service for free.
Ok, well the alternative is no free version. Yeesh, people are so entitled. They're trying to give you a mostly full featured version of their software in hopes that you'll pay them someday.
Sometimes there's just general trash talk or real time chat and Slack is perfect for that.
We who use it don't want to have low value info pollute google search results. And we also have a public forum for info that should be searchable and requires asyn comms.
Of course like with anything if you're a fool and use it wrongly, you want get good results with it.
The value of synchronous communication is very real and it should not be precluded, but the points are totally valid. Slack is a closed-garden and it does not contribute to the global conversation if the access and historical record is controlled from within.
Slack extended their not profit pricing to 501(c)(6) not profit organizations which covers CNCF projects like Kubernetes.
Nobody changes clients, tooling, etc. That's the difference between a closed walled garden like slack and an open protocol.
The UI might change, but the UI also changes when you go from a Mac IRC client to a Windows one, which doesn't happen with web apps.
I say this as someone who's used IRC a crapton and is a strong advocate for open protocols (and for more than just ideological reasons): Realistically, if Freenode disappears, IRC will most likely die as a protocol as all major projects switch to non-IRC solutions, which is happening today anyway. A protocol needs users.
The only thing IRC has got going for it is federation and openness. It's not easily extensible, it's not secure, it can't benefit from most of the advances we've made in comms and protocols since the 90s, and there isn't even a common format for your messaging history - most clients just use text logs!
If you want to advance the state of comms and ensure humans are using open protocols to communicate rather than walled gardens, you first have to acknowledge these flaws and needs. Propping up IRC as something it's not doesn't do anyone any favours.
Other IRC networks than Freenode and OFTC exist too.
As far as security goes, SSL is an option for client<->server connections. I hope that at this point it is default for server<->server connections. What else are you expecting for security?
IRC won't survive the loss of Freenode. With Quakenet dying off (its userbase went from ~65k in 2013 to 23k today), Freenode is the last central bastion that keeps the protocol in people's minds.
FOSS projects today are migrating off IRC, onto Slack and Discord instead. This is why you have an article here talking about it and it's not the first one. If Freenode disappeared, this would accelerate massively. The projects won't bother going to another network because the topic of "Where do we go now?" is going to be asked and in most cases is going to be answered with "Well, we wanted to move to Slack/Discord anyway...".
There will be a few projects left on OFTC, certainly. But they'll give up and go elsewhere eventually as well when they'll see their userbase shrinking 5-10x due to other projects migrating elsewhere and taking their users with them. They'll probably end up on Matrix.
You aren't serious, are you? Because the new client runs on the same virtual machine, you are not changing clients? That does not really make sense to you, does it?
> The UI might change, but the UI also changes when you go from a Mac IRC client to a Windows one, which doesn't happen with web apps.
(1) I haven't ever heard of a computer changing its operating system from MacOS to Windows because anyone but the owner of that computer decided to make that switch. How would that happen?
(2) Erm, no, not necessarily?
If the UI changes, the client has effectively changed for the user. Otherwise you might as well argue that clients are all equivalent if they are running on the same OS.
>but the UI also changes when you go from a Mac IRC client to a Windows one
Only if you use clients that don't look the same.
> if Freenode disappears, IRC will most likely die as a protocol as all major projects switch to non-IRC solutions
No supporting evidence that they would drop IRC if this happened. You must have missed the part about a network switch being literally a config change. Compare that to dropping irc which is all of your tooling.
>most clients just use text logs!
There is nothing wrong with a text log. Also, which common format is your browser storing your slack messages in?
Most of your complaints apply just as equally to chat inside of a web browser (other than the security issues).
>Propping up IRC as something it's not doesn't do anyone any favours
Tell me how my comment is incorrect. You literally change a config to change networks, that's it.
But that said, I don't put anything on Github if I can avoid it. Disgusting organization with awful management.
It's near feature parity with Slack and it's also one of the best IRC clients around. I used to run ERC in a tmux session just so I could stay connected and not lose messages. No more.
But you may have missed the memo because you're in the wrong time zone, and with Slack, your possibly-relevant input is ignored because you can't participate in real time.
This is my beef with chat. As the OP says, it biases all conversation to those in the same time zone. Fine for some things (like baked goods arriving in some far-off kitchen), but not for others (like a design decision that should have input from stakeholders around the globe).
But it's often used for the reverse.
If my org takes pride in consensus for everybody, everybody needs to have the time to submit input. It's not uncommon that some active users in a chat go for an ad-hoc decision just because they are more than one and want to work _now_. In the long term this damages the culture, splits the participants and is difficult for newcomers.
I gripe because I am a US left-coaster who works with a team that is increasingly based in Western Europe. By simply deciding to rely on Slack, they have essentially cut me from development conversations other than the weekly live session.
The argument for AOL/MSN etc back when the Internet was new openness for the unwashed masses just a dream is exactly the same being made by slack i.e. that by making it locked and taking away the complexity introduced by the existence of cross vendor compatibility new users face less confusion.
I'm just saying that IRC+Mailing lists aren't good enough.
But this is such a big deal. You make it sound like a good interface is trivial. It isn't, and it makes a huge difference.
Check out ircv3.net
That's a pretty huge feature. Never underestimate how making something more usable increases it's popularity.
Get a good GUI client, enter some parameters into a text bar, click 'ok', then chat. exactly the same process as a web browser..
The real problem is the 'endless summer' of tablet-era people who confuse the 'interweb' with the 'internet'. There used to be much more general community advocacy and understanding of promoting open communications 'baked in' to the internet culture which has been eroded by crass commercialization - this is the real problem that needs to be attacked...
Ex: https://blog.irccloud.com/pastebins/
And as much as I hate it, the success can't be denied. Especially when looking at some conferences I've been to over the years. If they even had an IRC channel, it was mostly dead, but the Slack channels were buzzing with activity during the conference. I'm not sure why that is. Ease-of-use? The fact that many attendees are familiar with Slack from work, but not with IRC?
IRCCloud at least lets you see chat history, which IRC doesn't have out of the box but Slack does.
The real advantage of slack isn't even client its stuff like massive logging for e-discovery and single sign on integration. Admittedly not terribly appealing for FOSS but once you use it at work...
Also integrations in general are smoother in slack than in IRC. Someone has already written the bot and its a click away to install and it generally works.
Which can also be done with IRC clients.
This is a video of a search system I built for the Quassel IRC client: https://dl.kuschku.de/videos/2016-09-16_04-03-36.mp4
Quassel is a distributed system, so you have a bouncer and client which integrate tightly, with clients for Linux, Windows, Mac, Web, Android, iOS, which stores backlog in a database.
This search system is a very simple one, and simply uses postgres’ fulltext word vector search.
It's a web/android/iphone client only, but it's IRC. The moment someone grows tired of the client, they can get their own.
They could schedule downloads to their remote boxes and wouldn't have to tie up the home phone line for three days downloading the latest warez from that guy who had an ISDN line and let 10 people(!) simultaneously download from his bot at a screaming 5k/s.
Now I can have all those things (including the equivalent of 1000 ISDNs), and I don't really use IRC anymore, young me would be so jealous.
For example I can have jenkins email build fails to slack in, oh, probably less than two minutes, I've done it before. From memory I make a custom email addrs in slack and tell slack which channel to feed it into, and then add that address to my jenkins that already sent buildSpam.
In IRC I could do it... google implies there's a ZenIRCBot project on github and probably many others. Probably there are bots and tools that google didn't immediately find.
Its not rocket surgery to use fetchmail and some kind of Perl IRC library to simply POP everything out of a mailbox into a directory /tmp/wtf and probably about 3 lines of perl to read all the files in /tmp/wtf, connect to irc on some channel, output what it found, and if successful delete the emails from /tmp/wtf. Then put fetchmail and the 3 line perl script into cron and away we go.
Looks like Zapier is kinda in between "I could do it" and "AAS"
There's a reason people like slack so much. It does a ton of stuff out of the box with no headaches. Nobody wants to maintain all that stuff.
So instead of paying someone to maintain it, you pay someone to maintain it who keeps all your data from you and prevents you from accessing it, and who admits he’ll read all your stuff.
How is that better again?
That said, IRCCloud already does it for free, in the cloud, just works™, and the Quassel people are also working on improving ease of use and deployment.
You aren't paying "someone" you're paying an entire company that is dedicated to making the application highly available, with all the bells and whistles, with zero hassle.
Really, if you think IRC is so similar to Slack, then why are so many companies, organizations flocking to it? There has to be a reason.
If HN has higher discussion quality than reddit, why are not all devs on HN instead? If Linux is better for servers, why are people still starting projects on Windows? etc...
The power of marketing, directly or word-of-mouth, is important. And a decentral community can never do as perfect marketing as a company can do.
There are IRC clients and apps, and third party integrations as powerful as Slack, and as easy to use. But you have to find them, install them separately – there’s no single combined effort to market a single "just works" solution, yet ;)
Slack doesn't prevent you from accessing your data, in fact they explicitly built exporting features.
We're talking about open source, so reading your stuff shouldn't be a problem. For proprietary, maybe, but even then, reading someone's private slack info would be highly damaging to their brand, and to what benefit?
There is no such barrier for the current set of chat apps. Download > Login with google, start chatting with the person who invited you. Search history? File sharing? No need to remember anything about dcc/xdcc, no need to manage servers running bots, no need to manage anything, really; it's all taken care of by the nerds that run the service.
I think one might actually be able to build a business by building a Slack that runs on top of IRC, and releasing client apps that actually significantly reduce the flexibility that a standard IRC client gives you. If you can get the on boarding flow to invite -> download -> log in -> start chatting with the people you want to chat with, you could crush slack (assuming you had the marketing budget to compete with theirs).
I think, however, that IRC will remain in some ways as a small haven from eternal September (haha, yeah, I know). The barrier to entry is a feature, not a bug.
Someone did, it's called IRCCloud.
That's the entire problem I've been talking about above: Anything you can imagine regarding IRC already exists. The only issue is that you don't know about it yet, and have to find it. And without marketing, or any lists of what is good and not, this is hard.
with respect to something like e-discovery its all a matter of perspective. If this were true, which it isn't, I wouldn't necessarily mind, as the financial worth of combined ancient IRC logs is unquestionably a net negative value.
Wait... did you just tell me to go fuck myself?
(I haven't used either very much, so please correct me if I'm wrong.)
But yes you're right, nothing in the IRC protocol for it. There is something in IRCv3 to provide chat history but I don't know if it's even in the current version of the spec.
https://www.irccloud.com/
(You say "they're a client too" - I confess, I don't know what they are apart from a client.)
At the moment if you join a channel you can't read its backlog, no. They could implement it though if they used logs from their users... kinda wish they would. But hey.
Then I'm not entirely sure what you were referring to, when you said "IRCCloud can". Backlog from before you joined the channel is the specific feature that I was saying couldn't be done.
It's interesting to know that IRCv3 does have that support, so I was wrong about it not being possible. But if nothing implements it, it's not very helpful.
IRC and FreeNode channels have been the standard for communication and not for archival purposes. I use an IRC bouncer with my home server and I never look back through the thousands of communications except to see a reply to my question.
Why does a Open Source Community channel need archived communication unless it is just a few developers only chat?
That's not even wrong.
IRCv3 has a lot of enhancements that should move IRC out of the 1990s as far as a communication protocol, but there's not a whole lot of movement on it. I think FreeNode has some v3 support.
We don't have a lot of developers dedicating time to this. I'd love to myself, because it's something the OSS community needs, but it's also very difficult to contribute to projects when you're already doing 40 hours a week at a day job.
Today I feel like most of the OSS projects that are getting support are ones that are corporately supported:
http://penguindreams.org/blog/the-philosophy-of-open-source-...
That’s as wrong as you can get.
Networks with support, ranked by amount of supported features, are: InspIRCd Testnet, EsperNet, IRCCloud Teams, Snoonet, Rizon, IRCHighWay, freenode: http://ircv3.net/support/networks.html
Clients with support, ranked alphabetically, are:
Desktop: AdilIRC, BitchX, ChatZilla, Colloquy, Conspire, Hexchat, IceChat, Instantbird, Irssi, Konversation, KVIrc, LimeChat, mIRC, Mozilla Thunderbird, Quassel, Textual, WeeChat.
Web: IRCCLoud, Iris, Kiwi IRC, The Lounge, Mibbit, Quassel-Webserver
Mobile: AndChat, IRC for Android, AndroIRC, Colloquy, IRC7, IRCCloud, LimeChat, Palaver, Quasseldroid, YAAIC
Bouncers: Quassel, ZNC
Bots: Limnoria, Sopel, Moon Moon
http://ircv3.net/software/clients.html
And libraries are: cinch, Communi, irc-framework, Kitteh IRC Client Library, Net::Async::IRC, pydle, Rust irc, Warren, zIRC
That’s quite a whole lot of movement. That’s every project related to IRC
You don't log into irc from your work or your home or your anything.
You run screen in your shell account and log into irc once and never log in again.
Christ - do we need a refresher course here in how to use the Internet for the incoming freshman class of 1994 ?
Chatting is interesting because of other people. That's why I'm chatting.
In Slack, I can ping people that are offline. And all they have to do is open Slack again or reconnect to the internet and they get notified. I don't need to count on them being an IRC veteran.
All these people pointing out ways to enhance your personal IRC experience are missing the point.
Oh yeah, and I can post code in Slack.
TheLounge and ircanywhere are missing a lot in comparison.
And other projects, including the GPL project Quassel, do have mobile clients (although Quasseldroid, which I maintain, isn’t exactly the best client in the world).
Yet even Quasseldroid manages to be better.
That said, there is truly a need for a really good, FLOSS irc client ob mobile.
EDIT: and we aren't talking about code-base, are we? If so, Lounge's is pretty solid (although it is in a pretty constant state of transition from ES5 -> ES6)
Quassel actually has both of those, but they’re still in separate projects atm: https://dl.kuschku.de/videos/2016-09-16_04-03-36.mp4, and will only be integrated into the main codebase in the next version.
That said, the performance of Quasseldroid, due to the nature of the thing, is a lot better.
And I don't think you can say due to it's nature it's faster... I run Lounge in 20+ active channels on my iPhone SE and it runs perfectly. Native != more performant (and if the code base is as bad as you say I wouldn't expect it to be).
But what I consider a bug is already the best case scenario for the web client.
And 20+ active channels is nothing.
I'm in 460 active channels, with combined 40'000 users, and I get about a hundred to 200 messages a minute, while using the app on 64kbps connection.
(That's my test case for what should usable)
And quasseldroid already has code for those two, and a rewrite is almost done, I'm just waiting for the core changes to happen, and then release version 2.0
WordPress.org seems to fully integrate Slack into its processes. And as a now outsider, intuitively, it seems they've been able to scale their community more and continue their rapid development.
The OP does make a fantastic argument on the open/public point, but synchronize communication is also a necessity for collaboration.
The WordPress community Slack forced Slack to implement some server-side changes when it hit ~5,000 people though (I don't remember the exact number, but I remember when things started to not work), and I suspect it's the largest resource-consuming instance in my Slack client.
Compared to IRC, I have to:
It's an epic yak shave that sucks massive amounts of time and energy a from the thing I joined the community to do: improve a piece of software that isn't IRC.However, having that global identifier / IRC network connection is a tradeoff - it forces you to use a single consistent identity for every single interaction on that network. For some people this is a plus; for others it is a negative. Slack's teams option allows people to use different identities for different instances.
> [...]
> - Figure out how to configure my client.
> - Figure out how to interact with the user account and moderation bots
I disagree with your initial claim. :P
Those are irc basics, things you only have to learn once, and there is documentation online and on the web. It's worth it to spend the time to learn a tool that you can use throughout your profession, even as the proprietary flavor-of-the-month services come and go.
This all reminds of a few years ago when folks were banging on about how we needed to use Gitorious instead of GitHub for Open Source hosting. Gitorious is dead now and it wasn't until GitLab came along and recognized the usability problem that we got a viable Open Source alternative.
Trying to get everyone in our group setup with mumble was a pain for the people who only use their computer to game. When we switched to Discord it took maybe 10 minutes to get our group of ten all in one chat.
I use slack at work and love it. I fully agree that it isn't that different from IRC and I hate that it's another walled garden (of sorts), but it fixes a lot of the little annoyance in dealing with IRC.
Also, fwiw, most of my colleagues use IDE "search project for string" in places where I use grep. Also, if I'm being honest, you should hire nearly all of them before you hire me.
I think you've picked two false flags.
I like knowing that it's going to handle unicode properly, in all cases, for everyone on the Slack channel. I like that it handles right-to-left text for everyone reading.
I like not having to ever think about, is my bouncer down? I also like not having to think about, where am I going to run my bouncer? It's nice not having to think about that stuff at all. I've got a lot on my plate, keeping a bouncer up and running somewhere (just so I don't lose history!) doesn't need to be another thing I do.
I like the plugins, the integrations with various other services. I like the convenience and polish. No IRC client compares to Slack for integrations and polish. It takes friction out of my daily chat experience.
I've even moved some private irc channel chats to Slack channels, because it's just a more pleasant experience in 2017. No regrets about any of that.
Despite the nostalgic kick of it, I never used it as a serious work tool at any of my jobs, haven't used IRC at all in probably a decade, and totally agree that options like Slack are just plain better work communication tools.
I had to use IRC again in 2015, and pretty much nothing had changed, except now I was 20 years older.
Most of the criticisms of Slack seem to boil down to: this (whatever it is) is something IRC could do. But it (whatever it is) is virtually always something IRC doesn't do, something it does in some half-arsed fashion (that requires a huge amount of fiddly setup), or something that's supported by only a few clients. How is this not obvious? I'm perpetually mystified that anybody would admit in public to not understanding why Slack is taking a massive dump on IRC.
(Criticisms of Slack's closed nature are valid. It's also worth asking why it has to take up 2GBytes of RAM just to show a tree view, an HTML view and a text box! But don't tell me that you can't understand why Slack is winning anyway.)
It's not a generational thing - it's a "lifer" vs. "non-lifer" thing.
Some people are coding with computers because it's an exciting, lucrative career with great benefits!
Other people are coding with computers because they can't imagine doing anything else, and would do it for free if IT wasn't central to business in the 21st century.
The sign-up process for Mattermost is easy. It's intuitive, cross-platform, mobile-friendly, etc. While we geeks are used to IRC, onboarding people to IRC is no different than any other product: the smallest glitch, weird UI, confusing elements will make people drop off pretty quickly. I have always had to sit down with someone to show them how to connect to IRC. We would waste time at code sprints showing people how to connect.
With Mattermost, we have unlimited logs (so we can cross-ref/permalink conversations in the issue trackers), threaded conversations (great for when the channel is noizy), emoji reactions (friendlier atmosphere), etc.
However, I agree with the article: Slack is inappropriate for open source communities. Mattermost and Rocket Chat are good alternatives. Between my IRC habits and what I can do with Mattermost, I find Slack very frustrating (and I don't use it anymore). Then again, as much as I like IRC, it's not an alternative either.
For anyone who'd like to try an open source Slack-alternative, you can start in less than a minute with auto-deploy via Bitnami: https://www.youtube.com/watch?v=AKqHWqrAgpk&t=9s
Goes to AWS, Azure, GCP, Oracle Cloud, all data under your control, Mattermost Team Edition runs under MIT license.
Also, check out our new React Native mobile apps: https://github.com/mattermost/mattermost-mobile
The biggest benefits for us:
For others, here's another article of replacing IRC with Mattermost in education: https://opensource.com/education/16/3/mattermost-open-source...
1) Person pushes to dev branch
2) Chat log shows the feature pushed
3) Chat log shows Jenkins received push and is downloading
4) Chat log shows whether tests were successful (yay) or not (boo).
^^ that's the basis. It helps keep everyone up to speed on what's going on, especially for testing.
One more example: Notifications when merge requests are made / merged in the chat.
By adopting an incompatible web model, they lock people and their messages in, and can charge per user in the room. As a good IRC client, the most they could get away with is a subscription charge per client, which has the downside of creating a barrier to entry that limits adoption (requires everyone who wants to use it to pay, v. a central employer or organization that can compel people onto a chat platform).
Users like web-based because it means that they just click a button and the thing they want magically appears with no install process. Companies like web-based because it allows them to box all the secret sauce behind a server that can't be introspected. There's no risk of someone cracking their program and distributing it for free, and they get to keep complete control over the crown jewels, which are now and always have been the data that the program purports to manage.
Just keep your hands off my mailman ...
(a) Can't be referenced or linked from the Web, and
(b) Is a form of synchronous communication
The same factors, BTW, apply equally to in-person discussions held at open source conferences. I wonder what the author thinks of the value of those insofar as "open source communications" are concerned.
[0] https://github.com/hyperledger/slack-archive
[1] http://slack-archive.hyperledger.org/html/index.html
If not, given that searchable archives are one of the ways Slack makes money, makes me wonder why there's not an open source way to pull the chats and archive them in a way that's cheaper and independent of Slack.
Just try and stop me?
Probably they don't care enough to enforce, but surely you see it's part of the problem that they could?
They can't stop someone from creating an archive that's inaccessible to them, if they don't know of its existense. Anyone can create an archive of something they can read and hide it, and selectively share it.
Such an agreement on curtails specific forms of automated crawling and public-facing archives.
(a) is fiddly and a bit technical but has been solved-ish for ages before slack existed
(b) is fundamental though. If it's a big archive, it costs real money to provide access & search to. If you break it up, search-ability tends to suffer.
None of this is new, slack is just the latest flavor
How often do you find solutions in public archived mailing list posts when Googling problems? I imagine often. While some e-mails are more terse than others, fundamentally e-mail list posts demand a certain structure. Can you imagine having to pour through a 25-page chat log instead?
And with that, the entire idea of "search the archives before asking a question" would go to pot.
Synchronous communication, indeed, is bad for the main communication channel. However, as a secondary communication channel, it can serve important needs.
When people are looking not to just get a single issue resolved, but to form a community, this community is often based on informal communication and emotions. Seeing the same people in the member list every day, exchanging little inside jokes, getting to know individual members of the community on a personal basis — this is something completely irrelevant for the user of the open-source product, but can be an important emotional component that motivates people to stay in the community and continue to put in effort into the project.
And, of course, a synchronous channel, where you can get more lax on moderation, is a much more suitable tool for this purpose.
Is this a problem?
Ostensibly one should hope to be able to communicate online in the same manner that one does offline: without paying an intermediary
Further, if the 'natural trend' of economics is towards commoditization of products, why then are we abandoning those things which facillitated decentralization in order to support another entities profit motives?
We're gravitating towards better products. Sorry, but having used IRC a lot, Slack is just better.
your point fails to address this point; similarly 'better' has varying metrics.
...about what other people are writing in the main communication channel, creating precedents about what should be discussed with "individual members of the community on a personal basis" and deciding the content that should be written on the main channel for the benefit of outsiders asleep in other time zones, ...
I've intended to reply to communications before only to discover that someone else replied first while I was asleep in my other time zone.
Slack's UI is good. Not perfect, but it's quite usable compared to all the alternatives[2]. People always underestimate the value of good UI.
[1] https://twitter.com/zellyn/status/851818007248678912 [2] I've been on IRC on and off since 1993. It's much worse.
If you want to have an open process (for discussions around proposals, bugs etc), you need an open, linkable, archivable format, ideally hosted somewhere you control. That means mailing lists or a public html server, not a private chat service which may or may not be around, which may delete data or change policies at any time. For this reason Github isn't great either, but at least it has public links and you could scrape the data if required.
So? There are services offering that, too. Linkability is easy to add to IRC as soon as you are using logging systems and modern bouncers such as IRCCloud or Quassel.
Have you never replied to an old forum post and been accused of 'necromancy'?
Have you never been late to reply to an email chain or a thread on a mailing list or forum?
There's no clear line dividing asynchronous versus synchronous communication. Even phone calls can be (partially) asynchronous – "hold on, let me check" let alone "let me call you back in <some amount of time>".
And similarly, if a group of people are responding to each other quick enough, even using an 'asynchronous' medium, then they're basically communicating 'synchronously'.
Full Disclosure: I work at Discourse.
Discourse is also not easy to setup, its quite involved and complex and you need some Ruby and systems expertise. Infact I think Discourse only supports Docker installs. So you need to know Docker too.
Given the complexity you should be pretty comfortable with Ruby to run it with any amount of confidence. The hosted option seems much better than trying to run it yourself.
Also the Official Install Guide[1] doesn't require any Docker-fu.
Also, we give hosted Discourse for free for open source projects with a big enough community to have a forum[2].
1: https://github.com/discourse/discourse/blob/master/docs/INST...
2: https://blog.discourse.org/2016/03/free-discourse-forum-host...
I know groups that (for business or pleasure) use Slack, Discord, Skype, Google Hangouts, IRC, etc.
All of these clients are a bit more obstrusive than they need to be in terms of pop-up notifications, software updates, cpu, memory, transfer, etc. They all screw up enough that there's always a little apprehension that something will go wrong when you get a number of people together for a meeting.
It is one thing to deal with one of these things, but when you have to install ten to get your work done you have a problem. I have a high performance computer and I want to keep it that way.
The modern office large office is pretty bad in this respect. Really not uncommon to see things like
• Need to have Slack open
• Need to keep an eye on Basecamp/pm software
• Need to have Outlook open / check in on for email and calendar invites
• Need Skype open because not everyone uses Slack
• GitLab is open in another tab
I've started counting the minutes that I use in a day just logging in to things with our SSO, because it has started to actually add up, haha. It has gotten silly.
If you need to log in more than once, can you really call it SSO? =)
I don't have that many open, and it still takes me around 5 minutes every day to open them back up.
Imagine having about 7 tabs open. By the time I'm finished with the last tab, something new has come up on the first tab I checked. Huge waste of time. I'm trying to wean myself from all these services, but it's not easy.
This or that project is on GitHub, but join the developers on Slack. And I hate Slack.
If it really can't wait <25 minutes, they can call me or come to my desk. It's amazing how many things aren't "immediate" if you create a slight cost with requesting attention.
My favorite application is Microsoft Outlook, which consistently takes up ~50% of my CPU on my 2015 maxed out Mac.
https://xkcd.com/927/
Your users and their clients are still going to be using Slack and email, but it seems like you're giving me one more thing to log into. You write:
> Schedule your time spent and group distracting reminders and notifications in one place
If this "one place" is a separate silo from Slack, Outlook, Basecamp, Skype, SMS, Discord, Hipchat, IRC, and Github...it's not the one place I'll need to check. It's the n+1th place.
Now, if I can put my credentials into Calmbird (securely would be nice, but you can have the plaintext if you can make this insanity stop) and have it do the API connection to - or, if necessary, the nasty DOM-manipulation, Windows message hacking, and client-impersonating - to put all these services and their notifications in one place, that would be a solution to the proliferation problem.
Also:
> schedule automatic emails to your clients with updates
My clients don't want automatic emails, especially from templates/digests. They want me to hand-craft them as if it was the most important thing in my life. And while they can understand a curt update message or a missed daily status notification, the real point of these updates are to confirm that I'm still on the project. If a message accidentally went out with a placeholder like "I'm still working on {todo-insert-task-here}", and I didn't know about it, that would be...bad.
This isn't possible for web services due to the state of U.S. law. Speaking to a server without the consent of the server's owner is both a crime and a tort under the CFAA. There is also liability for copyright infringement, among other things.
IANAL
At least in Europe, news organizations pushed this kind of argument in their campaign against adblockers and failed in front of the courts. US law may differ, of course.
The implied access and license is probably valid as long as you're abiding the ToS. If you're violating the ToS after agreeing to it ("agreeing" means that proper notice is given to make the ToS binding, etc.), the implied license would probably not work. If you've been specifically asked to stop, either directly or indirectly (e.g., through an IP ban), any implied license or access privileges would almost definitely be revoked at that point.
>At least in Europe, news organizations pushed this kind of argument in their campaign against adblockers and failed in front of the courts. US law may differ, of course.
Ad blockers differ because they alter the payload after receiving it under legitimate terms (though this could still probably be considered copyright infringement under the argument that the license is for viewing only, not alteration). The CFAA would not be applicable because when the adblocker comes into play, you're not accessing someone's network (which is what the the CFAA addresses).
If a site clearly disallowed AdBlock users in their ToS and adequate notice was given to users that they were to be bound by these terms, it would be "unauthorized access" to the server, which is not allowed under the CFAA.
- Your users and their clients are still going to be using Slack and email, but it seems like you're giving me one more thing to log into
That is not the aim, the real goal here is exactly what you state next i.e you'll be able to (securely via OAuth, so you can also revoke access anytime) log into your Slack, Basecamp etc. and Calmbird will be the one 'dashboard' where you log into, kind of like having a social network client that supports Twitter, Facebook etc.
> My clients don't want automatic emails, especially from templates/digests. They want me to hand-craft them as if it was the most important thing in my life.
That is very true from personal experience, this is a feature where you'll craft a sort of an 'emergency' email yourself in advance and when you indicate in calmbird that you're working, it'll send if off to your client if there's an email from them, optionally with the latest updates. It's not a 'machine-generated' email in the traditional sense and this feature is in my current version entirely optional, which is how it will stay at launch, (if it stays at all, I'll certainly be thinking a lot about how can this be improved, there's no point if it's not going to be useful.)
I don't have a need for the product myself, but I do like the name for it.
I have a similar setup, and I don't waste any time logging into all of them because I simply always have them running. Why would you need to login every day? Are you shutting them down at the end of every day... if so, why?
I don't mind Gitter though, because it has a useful feature (code snippets) and it is available through a web app as opposed to a separate install.
http://meetfranz.com/
Are they using some API? Or do they ask you for your username/password for each service and "helpfully" login for you?
http://rambox.pro/
Seems to be wrapping them all.
That said, I wonder what's Discord's official stance on such things. Their bread and butter is voice chat, and they seem to be fairly open minded. Maybe they will eventually provide a public API for basic text messages.
I hear this a lot, in terms of older tools being considered obsolete.
Other than the natural human tendency towards novelty and the network effects, what, exactly, is obsolete about mailing lists or IRC?
What features are missing in IRC that Slack has for synchronous discussion? (I'll start: animated dancing pigs out of the box and the need to write/plug in your own archiver.)
What limitations do mailing lists impose on open source development that are not present in other tools?
None, in my opinion. On the contrary, they are the only tool that demand a structure — just by the nature of e-mail messages — that is coherent enough to be highly useful when searching archives later.
Newsgroups also have this structure and they have the advantage of easily doing an archive search (by being able to download part of or the entire message archive of a given group and using the search features of your mail/news client).
Quoting is still a problem. Most answer above. Some below. Many nitpick in between.
Threading is easily broken. Especially if Outlook users are involved.
Formatting is an issue. There is no markdown or whatever for links. Some people insist on line lengths and other stuff.
One thing I've noticed on Hacker News, Slashdot, and even reddit is that if someone quotes the post they're responding to, they'll invariably post their response below it. And if they quote multiple parts of the parent post, they'll interleave their responses. I don't recall ever seeing a response where the quoted text is below it.
I've really never understood the rationale behind top-posting. It makes it much more difficult to understand the context of the response without having to jump between the original message and the response.
> Threading is easily broken. Especially if Outlook users are involved.
That's because Outlook does not follow the relevant RFCs in terms of maintaining a message through through the In-Reply-To and References headers.
> Formatting is an issue. There is no markdown or whatever for links.
Most GUI clients will make links clickable. There are also conventions such as using astericks, _underscores_, or /slashes/ for bolding, underlining, or italicizing text, but a lot of clients don't render them consistently, IME.
> Some people insist on line lengths and other stuff.
There is an RFC that adds format=flowed to the Content-Type header. Then every line that ends in a single whitespace character will be joined with the next line and wrapped at screen width instead of at the position of the CRLF characters. Clients that don't support it will still see the wrapped text.
Mailing lists by themselves are terrible, because there's no history. You can't scroll up to find context for the conversation. You can get public archives, but then where you actually use the mailing list and where you go to look at history are completely separate, which is a terrible UX. Google groups mostly fixes this because they're really just a forum that supports emails.
IRC is terrible because everyone has their own client, so you never actually know what someone will see when you post something. Post a link, - will it get auto-expanded? How will it look? Will it get auto-linked? If you @ someone, will they get notified? if so, how visibly?
IRC also has the multi-login problem - it gets confused if I log in from my phone and my laptop. To get a persistent history of IRC requires running an external service which is way beyond most users.
Slack has mindshare, which leads to having a ton of integrations with other platforms, which just multiplies its effectiveness.
I 100% agree that I wish they offered a publicly visible option, so anyone can view without logging in. I also wish they natively supported self-registration.
I have to echo another commenter on here. If you want the best of all worlds, a forum is what you're looking for. Publicly visible, easily linkable, long form, asychronous communication. Whether that's google groups or something else is up to you.
This part I really do find annoying about IRC. I use IRC by far the most but this still gets me. Even if you run it in a screen somewhere it's a hassle from a mobile device. There's solutions for all of it, but you have to string a series of things together to get to something just about every other option offers you out of the box. Unless you have a particular need for IRC or have used it for a while and know how to deal with it, the other options are more appealing to newcomers. Depending on how young your project or community is that can make all the difference.
Unfortunately, the Slack gateway implementation is subpar. In my experience, it will send me the last message I sent before I disconnected when I reconnect, but it won't send any of the other messages that were sent in the meantime. The other problem is that group chat only works over the IRC gateway, not the XMPP one (at least I could join it from my XMPP client, but I couldn't send any messages to it).
In contrast, the old XMPP server we used would just replay messages in group chat when you reconnected, so at least you wouldn't miss anything when you weren't connected.
Edit: s/Slack implementation/the Slack gateway implementation/
Gmane actually works really well at addressing the problems you describe in terms history. Their NNTP gateway allowed me to download and search the git mailing list messages since 2009 in my email/news client.
Sure, there's lots of freely available alternatives, but even tiny (but non-zero) costs in time and money are the difference between widespread usage and relative non-use.
I setup Gitter on a GitHub repo for a project by clicking a button and accepting a pull request that Gitter auto-generated for me to add a link to the repo's Gitter channel in my project's README. That's the competition that every older tool is failing miserably to meet, let alone exceed.
You are ignoring the costs that come from lock-in (inflated prices, lack of innovation) and migration in case the proprietary solution shuts down. That's the psychological tendency of humans that these companies exploit.
Non-proprietary solutions 'shut down' too, e.g. because the unpaid developers burn out and quit.
A lot of people reasonably believe that 'free' solutions are inherently riskier, all else being equal, because (generally) no one is being compensated to maintain and support it.
It's tradeoffs all the way down!
That's not lock-in. Lock-in is when you are dependent on a (quasi-)monopoly, not just any potential migration cost.
> Non-proprietary solutions 'shut down' too, e.g. because the unpaid developers burn out and quit.
No, actually, they don't. The point, as above, is that it's not the sole decision of another party when a 'shut down' happens, that is, again, there is no monopoly. First of all, if you have free software running on your own machine, there is noone but you who can decide to just shut it down today, but also, in the long run, you can just take over maintenance of the software yourself, or you can buy/hire a software developer to do it for you, or you can get together with other users of the software to hire a developer.
Also, more generally, with regards to open interfaces/protocols rather than necessarily free software: No, email cannot be "shut down" because "the unpaid developers burn out". And changing my email client or server or hosting service does not necessitate everyone else I want to communicate with to do the same.
None of that guarantees that you can keep using things indefinitely at an arbitrarily low price, but that's besides the point: The price is determined by a market, and not by a (quasi-)monopoly.
> A lot of people reasonably believe that 'free' solutions are inherently riskier, all else being equal, because (generally) no one is being compensated to maintain and support it.
Well, yeah, those people are just clueless, if only because they confuse freedom with not paying for something. If you want to have something maintained, how about you pay for it? How does it make any sense to say that you prefer being forced to pay for something because you otherwise fear that it's not being maintained if you don't pay for it?
Also, none of this has anything to do with open protocols (which was the primary topic of this thread, kindof): Microsoft is being paid very well for maintaining Outlook and Exchange, which is both proprietary software. They still speak SMTP with the rest of the world, instead of forcing everyone to buy Outlook and Exchange to be able to communicate with their users.
and Telegram and Wire and Riot and Semaphor and Tox and... Plenty of non-closed tools.
And Discourse is pretty great, though much more like a forum.
Using IRC/Slack in place of forums is like using a wiki in place of real documentation.
Async shines when you have a lot of users, but only if it's very accessible (searchable). Otherwise it's just people repeating themselves constantly.
Also, longer rant on the IRC thing. For the past decade I've been using IRC as my central mode of group communication for all open source work. Last year and as part of my (open source) company, I've completed the switch to Discord.
I'm an open source die-hard and it bugs me that Discord isn't open source yet, but I believe this has a fairly high chance of changing (MUCH higher than Slack has at any rate). I would heartily recommend Discord for open-minded open source communities.
I'm now using Discord for everything. It has given me a unified interface for all my personal and group communications, easily searchable, with voice chat too (and video chat very soon, I cannot wait to never open Hangouts again). Needless to say, I'm a huge, huge fan.
Slack has none of that. The #1 thing that bugs me with Slack is the forced separate accounts for every single Slack instance. And you can't delete any of those accounts, you can only "deactivate" them.
Our open source community uses it. It works really well for us because we're a gamer-oriented open source community, so Discord is already pretty well known in that circle. On an ideological level, its API gives enough control over everything that goes in in it that I'm satisfied I could move to another service, should I need to. If anything, it's harder to move off IRC because there's no public logs, easy point of contact for the regular users, etc.
Also, I'm using Matterbridge to mirror our public channel to IRC: https://github.com/42wim/matterbridge/ (highly recommend everybody here checks it out; it supports a lot of protocols)
IRC has really disappointed me the past few years. I had a lot of hope that irccloud.com would offer a solution to IRC becoming irrelevant in the face of Slack and Discord, but it just hasn't happened. They're understaffed and don't have enough money coming in.
There's also a lot of ideological purity in recommending against SaaS "centralization" for comms but the truth is, it's not better. Last year my HDD crashed and I lost the logs for my organization's original channel going back to its creation... I'm very, very sad about that. Had I been using IRCCloud (or Discord) at the time, I wouldn't have lost all that. Granted, those companies could have, but the chances are lower than me fucking up.
This is the same reasoning why email is usually better off handled by companies whose livelihood depends on offering you the service, than by yourself.
Also like I said elsewhere in this thread, for a project using a Freenode channel and another using a Discord/Slack server, there is no difference between Freenode disappearing and Discord/Slack disappearing. Your host disappears, you have to find a new one, update tons of references and contact lots of users to let them know. On IRC, that's even harder. You can run your own IRC server, but very few do that, and those that do get less mindshare because connecting to yet another server is very annoying on IRC. It also costs you more, both in money and maintenance.
On reddit, if the time is not right, the discussion will not be had and ends up in oblivion.
Doesn't work with reddit.
New services replaced many things that forums were used for, but not all.
Probably the main reason why Slack – and Gitter, and IRC too still – are widely used by open source projects is that they're free, financially, and mostly free in terms of maintenance.
Interestingly enough, most people I know found the Google groups interface significantly worse compared to their Usenet client.
WTF?
How is it even remotely sane to provide a user interface instead of an API/protocol?
I don't care to learn your forum's user interface, and I don't care to poll your forum for new content. I have a mail user agent that's configured to fit my needs and that I know well how to operate, and that's where all the mailing lists that I am subscribed to push their new content into this one unified interface for me to interact with them. Web forums for the most part are just a pile of broken usability.
It's the way of the world. 20 years ago we had NNTP, POP, and IMAP, and you could read them all with Gnus, customized with finely-tuned filtering and killfiles. But it's hard to "unlock value" from these things, so then there were ad-strewn forums, and now SaaS abominations, because how dare you not change your mail client when its developer thinks you should?
[1] https://github.com/CyberShadow/DFeed
[2] https://forum.dlang.org/
I have recently been participating on Reddit and I still like HN, but I am spending less time of late on another forum I still belong to. For me, part of the answer is that forums are heavily influenced by moderators and most of them are not anywhere near as good as what you see on HN. So, if you have personal friction with the mods, good luck with that!
The internet is this awesome opportunity to rub elbows with people around the world. Then the admin structure very often gets you stuck in "I shot the sheriff" * hell, where no matter what you fucking do, some asshole who doesn't like you and is in charge rides your goddamn case and deletes your shit for bs reasons and so on.
I don't know how to solve this problem. Most forums don't seem to be able to get it right.
* This is an old song where the plot is that the sheriff was making his life unbearable and there was no other way out, so he finally shoots him.
That's why I preferred Usenet over forums. All filtering is done by the client and is under your sole control (outside of moderated groups).
But the main huge drawback, from my point of view, is that non-anonymous model of conversation means people more inclined to judge you from looking at your profile and not from the specific local reputation, which was a thing with forums.
Usenet, on the other hand, didn't have these problems, though it pretty much ended up the same way.