Five Open-Source Slack Alternatives
blog.okturtles.com
blog.okturtles.com
Instead of building a walled garden that is merely accessible via an open protocol, it would be more interesting to build a thin layer on top of an XMPP server that could even be removed or replaced later, if desired.
Now, Matrix allows arbitrary transports to actually put that over the wire - but mandates only the most comically simple (and inefficient) as a mandatory baseline. This is a plain HTTP PUT request of the above data encoded as JSON and a few URI parts. The reason for this is that HTTP is insanely ubiquitous and well understood; any random device or language these days can trivially send and receive messages.
However, there is nothing stopping you from using a more efficient transport for the data between your client and your server - we've been experimenting with everything from boring old JSON over WebSockets to COAP or MQTT and even capnproto. We haven't specced any of these yet, but we'll probably add them as optional profiles to the spec in future. Meanwhile plain old REST actually works pretty well in practice :)
The fun stuff in Matrix is all about the eventually consistent decentralised conversation history between servers rather than obsessing about the most efficient way to shove some key value pairs between a client and a server.
If this comment is serious (and I have my doubts), I'm left speechless... Don't even know where to start. I'll just leave it here http://www.theverge.com/2015/10/28/9625062/facebook-2g-tuesd...
Oh please. Without even knowing much about the protocol, I am almost positive that it's bandwidth requirements are well below even a relatively light modern webpage and likely well within 2G range.
> "I am almost positive that it's bandwidth requirements are well below even a relatively light modern webpage and likely well within 2G range."
I'm pretty sure this this is almost certainly the least, or at least within range of, quite likely the least definitive statement I might have ever read (or at least one of the lesser definitive of statements I've read within the past year, or at least the last few months, or so).
Yes, and that's the gripe with Slack - because it should be IRC underneath, but it isn't. Instead of using an open, standard protocol they fragmented the communications space even further.
But yeah, that's how SV rolls these days. Locking people in.
There's some startups like https://grove.io/ that do it.
I think the biggest problem is the people who use IRC aren't the type of people to pay. Additionally, walled gardens are pretty nice when it comes to making a cohesive experience. As soon as you build on top of something else, you're beholden to its limitations.
There's also the whole way notifications work... basically Slack and IRC are only the same (or even similar) on an extremely superficial level.
They have: http://getkaiwa.com
Open, federated protocol, multiple client and server implementations, integrated IRC bridge.
See more:
https://twitter.com/patio11/status/660931499680657409
https://twitter.com/patio11/status/660931665275916288
https://twitter.com/patio11/status/660931949645533184
https://twitter.com/patio11/status/660932099742957568
Yes, I understand that it's still friendlier to use than IRC, but there's a middle ground between "easy to use" and "still looks and works like a proper, professional desktop application." In fact, HipChat is pretty close, even though it's just a wrapped web page too.
It's kind of frustrating to see that all of these Slack alternatives are pretty much taking the same crappy UI cues from Slack. It's kind of like how, until the last few years or so, many common Unix/Linux desktops looked like Win95 rip-offs… You don't need to strive for familiarity if what people are familiar with sucks.
UX includes the cold experience. If you sign up with just one user, Slack creates a couple rooms and has a bot talk to you.
UX includes history management. Slack makes everything searchable and is good enough that most people can find what they want.
UX includes ways to level up your proficiency with the tool. Slack doesn't force integrations, defaults to 1-click OAuth integrations, and lets you explore writing code to integrate, without getting in your way before you're ready.
I don't think it's perfect, but having recently switched from Hipchat and hated on IRC-for-companies for years, they've done a lot of things right.
That is unacceptable, especially when you look at the alternatives it replaces: IRC, XMPP/Jabber and whatnot.
I guess it mostly comes down to Slack choosing the "wrong" stack here: Web-technology is, as is shown quite often, simply not ready for such heavy UX/UIs. Sure, it can be done, but when compared to the simplicity and speed of "native" it simply does not cut it. Yet.
Slack is not replacing IRC or XMPP at all. Slack uses these protocols as part of a groupware suite. As discussed elsewhere in the thread, IRC-at-companies draws mixed reactions. XMPP is a protocol that has seen very wide adoption in the enterprise, with many implementations from a variety of vendors, with a variety of resource consumption issues. XMPP is very much a web technology in the sense you're talking about.
And you are correct that it proved to be a very bad stack for something like Slack, when Google first tried it in 2009: https://en.wikipedia.org/wiki/Apache_Wave
If you really think Slack has made poor technology choices, I'd suggest reading what Stewart had to say on the subject in this interview: http://www.gamasutra.com/view/news/182287/The_story_of_Glitc...
This differs for everyone. For me, it merely replaces XMPP/IRC: group-chat. That is in the last 3 teams where we used slack.
Others, and I guess mostly people who live in their email-inbox, may see Slack as a replacement for their Mail Suite. Again others may see it as a replacement for teleconferencing/skype.
It really depends where you come from. Me, I come from a simple, integrated IRC and XMPP client. Now we all use Slack and I have a poor experience compared to the Just Works[tm] chat (through empathy) on Ubuntu.
* Slack crashes 2, 3 times per week. Mostly memory issues. Empathy never crashed on me, that I can remember.
* Empathy is, AFAIK always on. I switch off Slack when not working because (1) it abuses resources and (2) it addds another icon to my toolbar (empathy integrates in Ubuntu's message icon).
* Empathy starts whenever I start my OS. Slack can be configured to do so. But when it does, its slow startup time and CPU-gobbling while starting makes my desktop appear sluggish.
I'm comparing it to a well integrated, thin and snappy XMPP client, which is what Slack replaces for me. And Slack comes out poor. All over.
What many people seem to miss about Slack, is that it isn't a replacement for IM/IRC. It is a replacement for email. (Email is pretty embedded infrastructure though, so it still exists as a lower layer system protocol.)
The reason the UI design of these tools looks like Slack is because they are trying to get some of Slack's thunder. But the wannabes are making the mistake of copying the UI without trying to copy the UX.
I do not give a shit what Slack's buttons look like. I can't do that with IRC. Even if we're all standardized on a modern OSX IRC client, we're still going to end up "sharing" URLs.
Of course, what you mentioned is only one of many things that Just Work in Slack and are at best a pain on IRC, but still.
I do care what Slack looks like though - the chat window has so much wasted whitespace that it doesn't show a lot of comms; add in a space-guzzling integration or two and it gets really hard to follow a conversation. Hipchat uses space a lot more efficiently.
At any rate, on Slack, I once drag-and-dropped a text file with the output of a shell script that a colleague wanted to see. He started telling me how it was strange that the output seemed to cut off right in the middle of a line. lol, just kidding, Slack was just cutting it off like that, since Slack apparently can't show more than the first few K of a text file for some reason SO WHY IS IT SHOWING IT AT ALL ARGH
Not every organization needs this kind of workflow though, so the best available tool depends on what your organization has to integrate. (Disclosure: I've never tried HipChat.)
In MY experience, it is Certainly good UX to not have to learn multiple ways of doing things, one for the in-browser experience, and one for the desktop experience.
Which is also an erroneous statement. I use vi(m) on OSX. vi's UI "does not match the standard appearance and interface of the rest of the operating system."
Thus, I predict that VI has a horrible UX. However, I am incorrect.
Why is this so?
* personal opinion, yes, but it seems quite obviously true.
Otherwise, you have a noisy and unhelpful comment.
Do you remember having to hand write your Xorg.conf files to setup a Linux desktop back in the day? Wasn't that a colossal waste of time? Aren't you glad that's not a thing anymore?
Sure, I could try to set up an IRC server and the relevant bots and scripts to attempt to emulate what Slack provides natively, and then look for mobile apps that will connect to IRC and send me push notifications on relevant activity, or I could just use Slack.
This rubbish about people worrying about Slack having access to your internal communications is just that -- rubbish. It's paranoid nonsense. The last thing anyone at Slack wants to do is read through 80 million lines of emojis and notifications and some private conversation about adding a counter cache to the Products table.
And obviously one doesn't actually "read" the conversations, we're not in the 80s anymore, we have software to identify the juicy bits.
Slack is sold as a replacement for email, in many cases - so I fail to see how it's any worse than sending unencrypted emails all over the interwebs.
And this tin-foil hat conspiracy insanity about how you shouldn't use external services like Gmail, or Slack because "Oh noes, they have our data" is just that - insanity.
Sure, if you're paranoid, you're free not to use those services.
But let's be honest, most of aren't working at Lockheed Martin, or the NSA. Our personal lives are inane and boring, and the majority of our work discussions are probably, outside of the context of our work groups, inanely boring as well. Nobody cares (which is fine).
On the list of things to worry about, from meteorite strikes to global warming, I'd put, my chat provider trawling through my personal chats fairly low on the list.
1. Nerds (like me) have to talk to non-nerds.
2. Nerds (unlike me, but not unlike my wife) aren't interested in complex solutions to simple problems.
And frankly, who is the "tender" of the "well-tended" IRC server? I don't want to maintain it.
My wife and I used slack as the primary means with which we communicate for "couple stuff." We've used it to: Plan our Wedding Ceremony. Plan our Wedding Party. Plan our Honeymoon. Plan for our first child. Plan our next house purchase. Manage our Finances. Plan Dates. Plan our Meals. Archive Recipes.
There would be no way my wife (a nerd) and I (a different type of nerd) could do this on IRC.
I should probably expand that IRC for us is pretty stateful, since we both run our own irssi instances in screen on a VPS.
Admission: my wife is pregnant, so she really only wants me to make one thing. http://www.epicurious.com/recipes/food/views/corn-and-lobste...
Also Slack gives you $25 in credit for each person you add.
For me, the biggest problem was when my computer was turned off overnight, I had to go to some external source to read the transcript of the conversations that transpired rather than having it available immediately, in my application. DMs can also be sent when the user is offline, which is great for "hey, get back to me when you're back on."
I was able to solve some of these issues by setting up my own Quassel or ZNC server, but these were hacks and the clients were no where near as refined as Slack or HipChat.
I lament the passing of the age of new open protocols too, trust me, I really do. But IRC+ecosystem just isn't that good these days, and getting stuff done matters more.
I haven't frequented IRC much since the mid to late 90's so perhaps it has those features now.
The standard answer is "pastebin" but that raises the barrier to entry, so to speak. We use Hipchat at work but I assume Slack has feature parity here: If I want to paste a code block to discuss, I literally press paste (ctrl+v) and send (enter). The first few lines show up for everybody, with an "expand" button so they can see the whole thing.
No one has to have a specific client, no one has to visit a separate website (including me). It. Just. Works.
Same goes for images, by the way: I can post a URL ending in jpg/png/gif and it shows up for everybody, inline (and intelligently: resized, and animated gifs are hidden by default). I can also screenshot an image and paste it into chat, and it automatically converts to an uploaded file: take screenshot, press ctrl+v, enter, image is there.
Other important missing features are ease of use in terms of creation of topic-focused channels, private channels, and high quality mobile and desktop clients.
A channel stays a channel until nobody's in it. It's trivial to make a bot that sits in a channel and logs it. And it's trivial to hook up a search engine to that bot.
> Other important missing features are ease of use in terms of creation of topic-focused channels, private channels, and high quality mobile and desktop clients.
Like on freenode #reprap , #3dscanning , and thousands of other topic based channels?
And setting private bit is easy as a channel operator to limit who shows up.
And with completely public and open protocols, anyone can make an awesome IRC client. I have one already on my phone.
And there's also bots that can store and send files via http or ftp. I could also make one that saves/retrieves via Box, Dropbox, or any other storage medium trivially. Node-red makes that easy.
I have actually done that, and I know it's not trivial.
Few want to spend time tinkering with bots and hooking together archiving services. They want a nice Slack-type experience.
Here you go. http://webchat.freenode.net room #hntesting
Files end up on Dropbox here: https://www.dropbox.com/s/ukffgmwntypfg4m/ircchatlog.txt?dl=...
Searching wouldn't be too difficult. That's just loading the data up in a Hadoop and then regurgitating it. The only 'doop cluster I have now is a semi-production one. Working on getting a 150 node set up at the hackerspace.
__________________________
Edit: Added time date stamps, and indication/handling for private messages to the bot.
Privs now allow me to extend the functionality of the bot to do all sorts of things, like upload to MongoDB, email all logs, kick users, save to BOX, or manipulate the neopixel strip in my room.
No matter how much you push and say that everything Slack offers is doable in IRC, doesn't change the fact that you still have to go through the troubles of setting that stuff up.
While I agree that setting up a bot isn't hard, I've done it for the IRC channel I created and still sit in daily, but fact of the matter is Slack is a matter of signing up and enabling a couple of features.
My job for my company is to build our product, not an internal chat tool. That's what Slack is for.
Where is a Slack that can do "sensitivity calculation" to alert users of possibly hostile tone? That's right. Not created yet. Give me a half hour and I could have the beginning of that. I also could get translation facilities built in so that English/French/German/Spanish could be seamlessly translatable.
The sky's the limit. And your negativity diminishes your ideas.
If that's your thing, that's your thing and go do it. But it's not a lot of peoples, and that's why Slack is so popular.
But that's not what I'm doing.
Company A does really good semantic analysis. Company B does chat, say Slack. Company C file storage. Company D does search.
Now, I'm spinning up or using a current server. In this case, lets do IRC to Company Chat, B (bidi bridge). I connect to Company B with my user, and a user on IRC. Logging is turned on and saved, to Company C.
Whenever messages are sent, they are run through API from company A, checking semantics and feel. Score applied personally to help devs be more humane.
While all this is happening, search D is going through files presented and making a searchable DB of date/time, channel, user, and text.
And, I just created a new product.
That's exactly the point. Is this what your day job is paying you to do?
Someone set up Slack for the company. The same person could have set up an internal IRC server.
I'm also one of the leads for IoT rollout. In essence, I look at many sectors and areas at the same time, and determine how it can be used in our org.
I was looking at message passing using IRC as a form of command and control. The hackers have used it successfully for controlling a force of DDoS clients; why not a server farm? I know that Ansible, chef, and others exist. But IRC is human readable, meaning status messages can be passively read.
Pretty much, I have a dream job. I can get funding for pretty much anything I want, have access to petabyte FS, access to 3 supers(HPC, not clusters), multiple clusters, and more. And then I'm asked, "what can you make with that?"
You learn quick in those situations.
It's a fools errand to extend a private platform like Slack. They're already adding IRC features to their system, along with running a modified IRC bouncer.
Why play catch-up or copy-target when I can just use IRC directly?
Hell, I could do what they're doing for $1/user/month just by hooking a RADIUS server up to my nickserv. Easy peasy.
Come to https://webchat.freenode.net/ room #hntesting
I'm kefka, and my bot is hn_kefka_bot talk and PM, and then check the Dropbox log.
eh... slack has consistently said that large communities shouldn't use its services. - http://blog.freecodecamp.com/2015/06/so-yeah-we-tried-slack-...
Go talk to the hundreds of FOSS communities that use IRC. they have all fixed the persistence / search problem, and there is quite a few high quality mobile and desktop clients for IRC.
Apart from the tech problems with 1000+ sized teams, it's insane even considering the free tier with a 10'000 message limitation for 8000+ users.
So the team size isn't itself the problem; instead, it's the idea of wanting 8000 active subscribers in the same single channel that doesn't scale. Doesn't work on Slack; doesn't work on IRC, either.
At the scale of 8000 "viewers", you need the sort of specialized "presentation" software used for managing MOOC lectures and corporate shareholder calls, with fan-out servers, voting indicators, and the ability to "raise your hand" to ask the presiding officer to grant you a temporary +v.
That has nothing to do with Slack-like apps, and everything to do with Slack.
> Go talk to the hundreds of FOSS communities that use IRC. they have all fixed the persistence / search problem
I am part of many FOSS communities on IRC. None of them have "fixed" that problem. There might be one or two that archive the channel somewhere. That is no substitute for real in-app persistence and search.
There is a reason slack has a problem with that - scaling is hard.
There is also the advantage of not having silos - if I have a problem with a dependant library I can "/j #libname" and ask a question, instead of searching for what slack, or slack like tool they use, signing up, installing whatever app is needed to access it, and asking the question (and remembering what app they used, so I can keep it open for issues that run over a few days.)
Detachable screen sessions make up somewhat for it, but they're still pretty limited (you might have /joined the channel only later), and it requires a personal service running, that must be attended to & etc.
A well-tended IRC server has those via bots.
Other important missing features are ease of use in terms of creation of
> topic-focused channels
wut? This is totally easy in IRC: /join #topic-channel makes the channel
> private channels
I'm tempted to say that a bot can provide that... but sure.
> and high quality mobile and desktop clients.
Not buying that, sorry, I've been happy with my mobile/desktop clients; they are relatively full-featured.
[1] http://colloquy.info [2] http://colloquy.mobi/bouncers.html
At very least for the persistence part, there is a proposal to add CHATHISTORY batch type[1] to IRCv3 which should allow the server to replay chat history on join (or on request). Search is something else that probably need a little bit more work (especially for a server-side search), though.
I use mumble for voice (encrypted to server, server is weakpoint), irc for chat on open networks (do it from a VPS, and use screen/tmux with irssi/emacs-erc for persistence), and am using bitmessage more and more. Haven't tried tor chat yet.
Tried Slack, and even for business purposes, adoption was horrible and it ended up being a wasteland. Honestly, I think this statement from the Slack twitter sums it up: "The idea is to have a public-facing channel that a user can participate in without being a team member!"
To me, webchat plugins for IRC accomplish this just fine, and to me, is more likely to get a user directly connected with a dev/engineer.
Maybe I'm just a leftover of the 90's though... I mean usenet is disappearing so fast, even though I still love it... but as a FOSS proponent, I will use a GPL product over proprietary even if it's harder, unless absolutely necessary.
The open source team (which I would prefer to win) would do much better if their message was "use this one, canonical, excellent option."
The reason there's competition is because ~"let's only field one perfect option" sounds great if you think you're the one with the perfect product, or you're a user whose needs are exactly like that product's pitch. In reality, user needs are diverse: there's no singular perfect product.
In this particular case though, note the title of the article. Wouldn't it be much more convincing as "A Superior Alternative to Slack (Which Happens to be Open Source)"?
EDIT: You're second point definitely does apply here though.
All of this is a response mostly to buzz. Slack looks great, and is absolutely popular. So we (the open source community) want something "equivalently buzzworthy" while forgetting that we are, in fact, the entrenched monopoly already.
I'm not losing much sleep, nor will I be retiring my IRC client or pastebin links any time soon.
---
Anyone wanting to know more about Olm & Matrix's Axolotl support might be interested to flip to the end of https://matrix.org/~matthew/2015-06-26%20Matrix%20Jardin%20E...
(p.s. hi!)
Are there any plans for formal standardisation, review or the like? The docs look cool but at this point I'm suspicious of any single-vendor cryptography.
The only obvious solution, right now, is running your own private server if you want private indexes.
But the One True Way to solve this problem, in the fullness of time, is for every enterprise to run their own little PaaS with a standard API, and for SaaS providers to launch their app instances into the enterprise's PaaS using that API. This would be the cloud equivalent of the SaaS-provider selling the enterprise an "appliance" they can keep within their data-center. The enterprise gets full control of the data: their PaaS can be set up to not allow the SaaS-provider any way to exfiltrate the data the app creates, to determine rollout schedule for new app versions, etc.
(And note that when I say "enterprise", I could just as well mean that any individual user could own their own completely-automated black-box micro-PaaS, living "across" various IaaS providers and migrating to new ones as necessary, brought into existence for them by the first SaaS vendor to try launching something into it. Effectively, the ultimate evolution of a personal VPS, providing you with a "management interface" that looks like a cross between Heroku's dashboard and the Windows "Programs and Features" pane.)
In other words, if I really wanted to have discussion secret enough to warrant e2e I probably wouldn't be using company/project chat for that no matter what sort of promises it gives.
That being said, of course e2e chat would be beneficial addition, and might help especially in larger enterprise deployments.
Why not, though? Assuming logging is disabled by both parties and the E2E is working as intended, you have something that's almost as secure as in-person conversation. The only weakness is if someone has malware actively on their machine recording the conversation as it's occurring... but then you also have many other issues.
Also, peerio.com, but they don't have a 'channels-like' interface, so maybe not what you're looking for.
I will make a separate post once the source is released, but for now anyone that is interested can take a look at a small demo system I set up here: http://potato.dhsdevelopments.com/
The server is written in Common Lisp, client in Clojurescript. Storage backend uses CouchDB, messaging using RabbitMQ and the search uses Solr. More technical details here: http://blog.potato.network/
Is anyone going to argue that if I'd sent out the irc channel that anyone would have tried to connect?
Anyway, wasn't Gitter open-source in the beginning though [0]?
You get great apps for all devices (e-mail clients), notifications, encrypted direct messages, ability to send images/binaries/whatever, threaded communication, search, censorship resistance, filters, etc.
Real time chat channels are much better for fast moving ephemeral discussions and neither would I want that sort of thing in my inbox.
Not everybody wants to pay to put their potentially sensitive data onto somebody else's systems, where they can't control the security of that data.
Their reason that they couldn't search through data if it were encrypted is not true. They are using AWS, and can simply use EBS encrypted volumes (http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryp...). Should be an easy flag to turn on.
Both Slack and Amazon can steal all the data without being detected, regardless of whether the servers are encrypting it or not, since if the server can decrypt it, so can Amazon (just scan VM memory for the key from the hypervisor).
Their ToS is also as abusive as it can possibly be, trying to take away your right to sue them in favor of arbitration (!), allowing them to terminate your service at any time, send your data to anyone unencrypted, disclaiming all liabilities and warranties, disallowing any content that is "objectionable", etc.
1. they don't want to depend on a third party's existence. If Slack Inc. goes under or gets sold to eBay, the team won't have Slack anymore, and
2. they want privacy. They don't want conversations being watched or sold, especially to competitors.
I'm pretty sure that's all it is. Someone correct me if I'm wrong though please.
If it's an open source project then shouldn't everything be out in the open anyways? If that's not the case then it implies it's a private project in which case there should be a budget...
Maybe Im wrong though?
"very affordable" is up to each person to define. One of those premium features is a history with more than 10,000 messages.
I frequently interact with at least 25 people just to do my job. The cheapest paid plan is $6.67 per user per month. That works out to $2000 a year. And that's only for the people I work with on a regular basis. Sure, I could afford that, but it's certainly not trivial. Email looks like a good alternative at that price.
That's an trivial amount to pay for effective communications in my book.
Frequently, not ten messages in total.
Email works fine for non important sporadic communication.
If slack didn't "re-invent" IRC, it wouldn't exist.
Also, not everyone is comfortable having data exist on a 3rd party system, that they have no audit access to. This is the fundamental difference between "founders" and people who know how systems work.