Some are close, but I believe there will need to be serious investment in native mobile applications for the existing open source solutions to get there.
What Is Slack
Slack is incredibly popular, high growth, proprietary chat software.
You should probably try it if you haven’t already, it’s nice.
What IS Slack
It’s a little more than that. Key elements that make Slack Slack –
- real time chat
- asset hosting and sharing (images, links, etc)
- search of text and assets
- understandable authentication and permissions
- client software for web
- platform for automated users (bots)
- native mobile clients for iOS and Android with push notifications
- a bunch of social norms and behaviors around talking to coworkers (with emoji and gifs)
1-5 are nearly a commodity at this point in various forms, though generally not packaged very well together as a system.
The value of 6 can mostly be replicated by competing platforms as de facto standards emerge, but hasn’t.
7 is actually a competitive differentiator for Slack right now, and is the focus of the conclusion of this piece.
It may seem like I’m mocking 8 but I’m not. Setting the cultural context and norms for communication software matters a lot more than people think, and how software makes you feel is part of why people will or will not use it. (This is something that open source software, and software generally, ignores.)
All communication and social software is about people, and how they feel. When you breathe culture and personality into software, it has an impact on that. 1
Why Use Slack
Slack is a great way to get the above with very little hassle in a hosted, integrated offering with momentum.
I like the software! It’s nice. There’s an attention to detail, polish, and craftsmanship in what they’ve made that is very admirable.
I have friends that work there, and they’re all nice too.
Why Not Slack
Cost may be an issue, though for most business usage I doubt that will be the deciding factor.
For personal usage, it seems cost prohibitive if you want to keep access to your archives and get the “full” experience.
Bigger issues that may be important to you:
- data security and ownership
- long term viability of Slack Technologies Inc.
- cost structure in long term
- long term viability of proprietary protocols, closed source code vs. open protocols
- lack of control over your own communications archives and destiny
- uptime and stability
- government surveilance, end to end encryption, privacy
You can argue that exports and backups and documentation can mitigate a lot of the above but in 2016 it feels like real time chat communications platform should be something anybody can spin up and use without hassle, and without having to deal with a giant VC funded US corporation, no matter how benevolant you think those entities may or may not be.
Much of the above I think are just fundamentally not going to be addresseable with centralized, hosted solutions (privacy, surveillance, encryption, ownership). All the convenience of magical self-hosted centralized software comes at a cost, some people may deem the tradeoffs not worth it.
For me, while I work on proprietary software and have for many years, I choose to spend some of my free time pretending to be an open source curmudgeon, sometimes, and want to understand what the alternatives are.
The older I get, the more it seems like RMS was right more often than I ever thought.
Even if you don’t care about any of that, there’s probably viable businesses in getting open source slack alternatives up to parity and selling services or other complements around it.
Slack has hundreds of thousands of paying users and is growing – there’s hundreds of millions of dollars in annual revenue over the next few years in this space, it will be surprising to me if the open source community doesn’t capture some of it.
After limited usage my take is IRC is a glorious mess, Mattermost and Rocket Chat are both incredibly impressive efforts at this stage, though my personal take is Mattermost feels a bit disappointing, and Rocket Chat shows more promise and momentum.
I’ve been playing around with IRC lately and it’s, well, IRC. It’s a beautiful mess.
- tons of servers
- tons of clients
- tons of bot and automation tools
- tons of logging tools
- lots and lots and lots of options for everything!
Challenges with IRC to get it to be a reasonable Slack alternative:
- things may or may not work together
- everything feels incomprehensible
- very hard to integrate context / archiving / logs / search into client experiences
- authentication is difficult
- UX has a steep learning curve by default
- native mobile clients – protocol works poorly on mobile, slow connection/starts
- native push – extremely difficult to set up, non-standard
- non-text assets – hard to handle by default, need to go beyond protocol
- search – requires logging and external tools
If I were the CIO of a decent sized tech company that could recruit engineers, I might rather match the tens of thousands I’d spend on Slack with an internal open source effort to build out the capabilities of IRC to future proof and have full ownership of my data and processes.
Most of the above challenges are addressable, but it’s not trivial, and requires a lot of different kinds of work to come together (server, client, authentication integration, user experience) and by the time you’re done you end up making something that doesn’t work with most IRC software anymore.
For small teams, personal projects, and other things it feels like IRC is a lost cause at this point. Unless your audience is UNIX loving open source nerds, you’re in trouble.
Membership has been declining so it’s unlikely people are already using it - you’re probably trying to get people to use it from scratch.
(I tried and failed, but I didn’t try very hard, and I have no friends.)
As of this writing this piece, its github has 341 watchers, 8462 stars, 987 forks. It’s an active, impressive project.
Mattermost feels like the open source project most directly positioned to challenge Slack credibly, but my short time trying it was kind of disappointing.
For example, here’s me trying to upload an image and look at it and figure out why it doesn’t work:
I had a lot of trouble running it (mostly because I had a bunch of legacy 32-bit system libraries, but that’s a tale for another day.)
- written in Go – I love GoLang!
- core feature: real time communication, archiving, search basics seem to work
- nice platform for integrations
- single-sign-on authentication with GitLab
- projects a more enterprise, professional face and sells services
- limited deployment options documented
- felt buggy to me, almost immediately
- overall UX feels very janky, even on web
- authentication with GitLab but not others easily
- doesn’t feel like a fun, vibrant community project from their online presence
- weak native apps – wrappers around webviews lead to high latency and low usability
It’s an impressive piece of tech, but more fuzzily, Mattermost doesn’t feel like it has momentum and delight yet as a product, it feels more like enterprise software that is in development.
As of writing this piece, its github has 499 watchers 8099 stars, 1686 forks, so a similar level of activity as Mattermost.
But Rocket Chat feels like the most viable Slack open source alternative right now to me. It gets the fundamentals right of real time communication, asset sharing, and search. The community has made efforts to make it very easy to deploy in a whole lot of ways, and discussions around it seem like it has emerged organically and has a lot of passionate developers working on it.
- mostly seems to work with little tweaking
- lots of deployment options and one click deploys that work
- authentication, including social authentication on Twitter
- lots and lots of features popping in
- feels like a lively, active community
- some of those features seems half-finished, buggy or not well integrated
- buggy – a key push notifications feature didn’t work
- some docs are non-existent or hard to follow
- platform / integration tools are in flux, not easy to drop in arbitrary bots besides Hubot
- weak native apps – wrappers around webviews lead to high latency and low usability
Native Mobile As Leverage Point
The success and ascendance of chat applications has mirrored smartphones.
Chat is, in many ways, the ideal mobile use case and interface, and certainly one of its killer apps.
Webviews wrapped in a mobile app to handle push notifications are just not as responsive, fluid, or usable as native applications. They’re subpar experiences.
It’s going to be very hard to compete against Slack without high quality, fast, real mobile experiences.
A viable Slack open source competitor needs high quality native mobile applications that don’t exist today.
If I were advising one of these or other Slack alternatives, I’d encourage them to make native mobile top priority and invest in it. I think it’s the highest leverage point of any of them right now. 2
The rest (while not trivial) seems to be coming along OK. (Though there’s probably something in security and encryption that could be interesting too.)
The open source community is weaker in mobile, compared to its strength in server and web experiences (and desktop.) Given that both major mobile platforms are managed computing environments owned by giant corporations and come with lots of restrictions and strings attached, this is not surprising. But it is going to hamper adoption of new communications tools like this and let others take the market.
The next priority would be to emulate Slack’s APIs for third party integrations where possible – the webhooks and bot integrations Slack offers are very powerful and being able to re-use that ecosystem is very powerful.
· · ·
My guess is Slack understands how important their mobile clients are to their current usage and growth. If I were advising them, I’d suggest finding ways to keep the mobile experiences extremely performant (my experience is it feels like it takes a long time to get back to a chat when relaunching the app) and figure out how to stay dramatically ahead of whatever open source alternatives eventually come up. (As usual, advice is easier to give than to execute on.)
[ 1 ] A more interesting and perhaps more controversial piece would delve into this topic, in the context of soul-less enterprise software, but I’m trying to be positive here and if I hear one more person complain about brand x proprietary enterprise soulless software vs. brand y I may cry.
[ 2 ] I estimate a first version is doable with a 3-5 person team in 3-6 months, if that team has the right mobile expertise and scopes the project appropriately. Given Rocket Chat is built on Meteor, it may be (slightly) easier to get there by using existing software that bridges Meteor changes to CoreData. You still have to build the real UI, which isn’t trivial.)
· · ·
If you enjoyed this post, please join my mailing list