http://getkaiwa.com/ is another Slack alternative that uses an XMPP backend, which IMO is much better than a custom backend. So far the only open source Slack clone I've seen that uses an existing standard for the backend
There are a slew of developers who tangled with XMPP and came away with very negative, well-founded reasons to dislike the protocol. Do you want XMPP because it is a standard, or you also have a contrary experience to these developers?
And links [4] and [5] have a lot of people piping up saying they like XMPP just fine.
To be fair to XMPP, I strongly suspect it is a protocol trying to solve a very large, very messy problem space, and too many developers are trying to wrestle with it "raw" in its totality, unaware that for their specific problem domain, they only need a subset, and a specialized protocol/library that exposes only that subset to them. It's almost as if too few understand that XMPP is kind of the assembly language (or microcode?) of its problem domain, and most people need a $High_Level_Language_of_Choice instead.
I just like jabber because it's a standard. I have an app on my phone that'll do Jabber already. There's a lot of server software already out there to host Jabber, it's pretty robust, all we need is a reasonable frontend for desktop
The counter to that—and no doubt a factor for many like Slack—is that when you use a custom protocol/API you get to control the whole experience. You don't have to deal with bugs in third-party clients, wait for clients to get emoji support, and can control the look-and-feel (many of the Jabber apps I've seen aren't great).
This is obviously not ideal for everyone, but I suspect that outside of tech that using a custom client is possibly even a plus.
I'd rather have it the other way around: start from a solution that works (like Mattermost) and progressively plug XMPP into it. Mattermost and its friends have the huge advantage of having everything built-in and well working together, and if you take a good look at it XMPP should be more like a "compatibility protocol" on top of a working solution.
Mattermost v1.1 (ships Oct 16) has incoming webhooks support with samples (www.mattermost.org/webhooks/), and we're planning outgoing webhooks v1.2 (Nov 16), which provides the ground work for XMPP
https://rocket.chat/ built with Meteor and with WebRTC videocalls, is another great open source alternative... The list of current and upcoming features is quite impressive:
There's a lot of standards out there. Open is better than closed, and standard is better than ad hoc, yes...but that doesn't mean XMPP is automatically the best solution.
I'd honestly be more interested in seeing Mattermost try and write a really solid solution, and then work to standardise their protocol.
The takeaway I'm getting from this story, and Mattermost, is:
1. Export your critical data from SaaS services if you're business cannot exists without them.
2. Test that this works before putting years of data into a service.
There's nothing wrong with SaaS services, they just mean users must do their due diligence in any business partnership. I can't see how a game company can put their resources into delivering this as an open source project with no future plans for monetization. Frankly, without monetization, open source projects generally wither up and disappear. Then you're no further ahead.
>Export your critical data from SaaS services if you're business cannot exists without them
You know, my thinking on this has really changed. Consider how many relatively successful life-forms cannot exist without a very specific other species of life. It is also a good strategy to be flexible with your dependencies - but I think nature proves it's not required to survive and thrive.
Taking the long view, it's interesting to consider the possibility (which I'm sure has already happened multiple times in tech and elsewhere) when a company has absorbed it's dependency, and also when a dependency absorbs what was, at first, it's host, and successfully so.
The one thing that throws a monkey wrench into all of this is centralized human control, and a single mind is notoriously ephemeral, changing, and emotional. The CEO of your dependency might wake up one day from a terrible dream of humiliation and failure, and decide that he can't and won't just exist to serve his wretched, ungrateful customers in some insignificant and petty way, and will instead take a completely different path! (This risk is why greedy sociopaths make excellent corporate leaders: their drives are stable, predictable and unemotional, which makes them both competent and, ironically, safe.)
> Consider how many relatively successful life-forms cannot exist without a very specific other species of life.
Let's ignore how "many relatively successful [extant] life-forms" versus the ones that had "evolutionary challenges." There is an enormous difference between a species survival depending on the existence of a prey species and a species survival depending upon the existence of another species for uninterrupted, cooperative and coordinated behavior. Your relation to your SaaS provider is not similar to the blue whale's relationship with krill, it is more like the goby and the shrimp.
Why do I have to go to slack.com to learn what this is?
I clicked on this link, no explanation. I checked mattermost.org, no explanation. I went to slack.com, no explanation. Then I clicked on a "Product" link on top of the webpage. Finally some information what this actually is.
Even open source projects could benefit from a little bit of marketing.
It's marketed as an "open source Slack clone". I suspect that if you don't know what Slack is, you aren't really the target market (at least for this version)
Did Apple market the iPhone as "a blackberry with a bigger screen"? No, and by not limiting themselves to an existing competitor's market, they kind of crushed them.
i beg to disagree. i'm in the market for notification, chat, etc. service for an internal application that doesn't have any cloud dependencies and we'd be most happy if it could stay this way. apparently this thing fits the bill at least in some capacity.
If what you really want is a pretty web-based way to access IRC, then you might want to check out Glowing Bear -- it connects to your WeeChat IRC client via websockets and works nicely on the Desktop and on mobile. It doesn't have a voice recorder, but it gives you the infinite possibilities of a mature IRC client. It's a project I've been contributing to for a while now and I still absolutely love using it.
There was a time when I thought something like this was a good idea. But after using Slack for about a week, there's no way I would give up all the benefits of a well-integrated centrally controlled service. All the clients work together perfectly. We have Slack channels with customers. It just all works much better than I can imagine any self-hosted, decentralized service would.
Yeah, but is kind of expensive if you don't live in a developed country. If I lived in the US I would happily pay what they charge, but here in my country I would end up paying almost as much in Slack as in the office rent.
Really? that's cheap for you? that's some thousands a year for any mid-size company. I always saw them as really expensive for something I'm used to get for free. And the paid alternatives like hipchat are like $2/month. I guess it's all a matter of perception.
"Thousands a year" is a rounding error for any company that has the 20+ employees it takes to get to "thousands a year" in Slack bills. Those employees are costing tens to hundreds of thousands of dollars per month.
I think you are seeing it from the strongly-VC-backed startup perspective. In any company I've worked for that kind of expense needs to be justified. Sure, that's a small fraction compared to salaries, but there will be many such "needs" for many small fractions, and if they are not watched after they add up pretty quickly.
I think you are seeing it from the strongly-VC-backed startup perspective.
I feel I can pretty authoritatively answer "Betcha not" here. </cofounder>
It's trivial to justify Slack's pricetag at any software company. Your entire team lives in it continuously and it becomes the nerve center of the company... for freaking pennies. It's ludicrous. If you add it up the non-Starfighter companies I run spend like $50k a year on SaaS/hosting/etc ("everything with an API attached") of which Slack is like ~1%, and probably the most underpriced-relative-to-value service which does not quote its pricing in picodollars.
That's how you get bloated budgets. Why spend thousands of dollars per year on a communications platform if you don't need to spend it?
IRC, mattermost, email, Gitlab, Wekan, Skype/Google Hangouts/BigBlueButton.... there are plenty of tools to communicate without spending loads of cash.
None of those tools work as well as Slack out of the box. Some of them require significant work to integrate with other web services. That's time your staff is spending on those projects rather than your core product.
Seriously, Slack was the EASIEST things to justify as an expense when we proposed it to upper management earlier this year. And they are known to be very stingy.
why use macs (or Dells) instead of a cheap china-built off-brand PC? Why use fancy Pilot G2s instead of 10/$1 bic pens? Why use ${SuperiorProduct} instead of ${InferiorProduct}? Because it has value outside of the immediate short-term economic value.
Of course, it is always a matter of perceived utility. I buy really nice food sometimes, because my happiness gained from the delicious steak is worth it.
I might hypothetically use an open source tool instead of Slack because it's not worth $2000 of productivity for 15 people per year.
I'm located in Brazil. 30 users x $8/user/month x 4 R$/US$ = R$ 960/month (as a ballpark figure, a R$ is worth for a Brazilian about the same as a US$ is worth for an american)
U$ 240 / month is not cheap, and I'd seriously consider an alternative or asking for a discount, but it's nowhere near the price of an office in Sao Paulo or Porto Alegre (I live in Uruguay and was looking for office space in Sao Paulo earlier this year).
If you have to pay for customers, then it's way too expensive.
I've seen a remote-based company put Slack to VERY good use, integrating it very tightly with their development process, I believe it definitely pays itself then.
If it's just a glorified IRC/XMPP, then definitely not.
How a self-hosted service prevents you from having channels with customers or whatever else Slack offers?
The only upside of third-party SaaS is that you don't have to bother yourself to set things up and maintain them. Otherwise, I really don't see any limits that Slack can do but a self-hosted system can't.
I'm involved in a few communities that have slack setups. One of the other nice things that Slack offers is that I only need to have one login to all of them. That's something that none of the self-hosted systems can do right now.
What prevents you from using a same identity to log in to multiple self-hosted instances?
I think it's the same. As far as I get it - haven't used Slack much - with Slack you either have to use different email address to create account for each team (subdomain), or you have to be explicitly invited. Or maybe I got a wrong idea. Either way, while I'm not sure all self-hosted alternatives have options to consume external identities (be it third-party leased ones like Google account or self-originating ones), at least some have those. Which means the authentication is fairly transparent.
I'm talking about using slack as a member of various groups, with very different focuses. The fact that it is centralized means I don't need to have Yet Another Server I have to remember the address to, the username, the password, etc, and enter in on my desktop, my laptop, my mobile, etc. Plus, if one of those decentralized instances has a mobile app, chances are, I'd have to put in configuration info there for each and every service. Self-hosted communications services quickly become a pain in the ass when you end up needing to deal with more than a couple, and sometimes centralizing things a bit is an actual benefit.
You still have to create accounts on all of them. And if you mistype your password on one, you'll have to change it, and either you have to remember that there's one with a changed password, or go and change your password on all of them. And what if someone's taken your regular name on one of them?
That's not really a problem though. Everyone uses 20 different communications platforms. SMS, Hangouts, Hipchat, Slack, Facebook, Twitter, Snapchat, Whatsapp, etc all have different logins.
It may be nice to combine them in one place but it won't prevent anyone from using them.
The problem is, there is no standard for truly owned identities besides usernames and passwords, and those are frowned upon as "different accounts". And many services seem to not want any interoperability at authentication layer and to accept third party (esp. competitors') assertions as credentials.
This applies to Slack too - to best of my knowledge, one can't log in there, using, say, GitHub identity assertion as a credential.
But I'm not sure how Slack has anything to do with this. You're right. They're just a yet another platform with its own non-interoperable account system. Don't see how it's better than anything other, except when everyone is already there, which I find hard to believe. (But any other platform that knows how to consume external credentials is wins in this regard.)
Maybe then this product isn't for you. Even that's a maybe. Fair to say it's needlessly discouraging.
Somebody made something, and is giving it out for free so that people can learn code, improve it or just use it. They haven't made the claim that this beats Slack today, but with a community of users and developers, it just might. Btw, it can be a success even if it doesn't fully outclass Slack.
Your comment is equally valid for the Linux kernel if it were 1991. Who would use a baby OS when they can get a well rounded commercial OS that crashes less often? Look at where we are now.
Or someone who likes to freely express their political views, maybe even extremist opinions, but still would like to peacefully visit the US as a tourist some day.
I came here to say exactly this. We host a Slack team for local freelancers, and I'm part of a few communities.. and I currently can't imagine me using two different clients for this (2 desktop apps, 2 mobile apps, 2 admin web apps). So, Slack it's gonna be.
We had non-interoperable web services, and then businesses offering aggregation of those (like various social media aggregators, or even Slack) had appeared.
I think Slack serves its stated purpose very well (smaller, business oriented teams), but many groups have started using it for larger communities, mostly because it has unlimited users for free. But it isn't made for that and there is no way that most of these groups would ever be able to pay for a premium subscription due to the per-user costs. 10K messages across all channels is surprisingly easy to hit, need the ability to ignore users, etc. I think this project has great potential to fill that niche if it is marketed properly. Slack is so close to working well in that area but really needs to pivot to be able to serve it well and make money doing it.
Yes, recently Slack even told Reactiflux that they need to move to another service as more than a few thousand users can not be handled by the Slack infrastructure.
That isn't true. My office slack has a few thousand users and it works just fine. I'm not saying it can scale to infinity, but it does handle a few thousand users without any issues.
We tried Mattermost at work, and it was pretty terrible. Things like "show new messages" didn't work, which sort of defeats the purpose of a chat app. After that we tried RocketChat, which seems a lot closer to Slack in terms of features and appearance. From our perspective they were just too rough around the edges for functionality, with a lot of things almost-working-but-not-quite. The caveat to all of this is that we wanted something that JustWorks, so while we did put in some effort to fix configuration and even some bugs in the software, we didn't commit to them 100% so YMMV.
We started up on Zulip when it came out a few weeks back, and it's been much better and more consistent. Streams and topics take a while to get used to, but they make it easier to have public conversations with some semblance of organization. If you don't like / can't afford Slack, or if you have privacy needs that make it a non-starter, I would recommend giving Zulip a try.
do you know if Zulip exposes an API ? We are currently using Slack as a chat dashboard for operations .. and we do some funky stuff like create channels,etc through the API. I wonder if Zulip allows that.
Channels don't exactly exist, but you can programmatically create topics within streams. Sometimes it gets to be overwhelming, like out GitHub bot that posts every PR for every repo under its own topic within the GitHub stream. It's definitely a new way of thinking about chat, and there's a learning curve of about a week, but so far it's been fantastic.
I've used Slack and HipChat previously, and AFAIK the integration methods are all roughly equivalent - post a message to a URL with a token.
There are many OSS alternatives to Slack. Some are clones and some are different approaches and many of them are quite good.
The thing these and all other similar efforts miss is the importance of network effects. Everyone uses Slack because everyone uses Slack.
The real problem that needs to be tackled is one layer down: providing an open, distributed alternative for authentication, identity management, and data interchange that is secure and robust enough to provide a backplane for things like this and that is easy enough for anyone to use that it can be pushed out to the mass market. I can't stress the last point enough. It must be stupid simple easy to use or it will fail. It also must offer a good and simple developer experience (DX) or it will fail. DX is part of UX. Things like XMPP are nightmares for devs and sysadmins and fail badly here.
Mattermost server is made available under two separate licensing options:
- Free Software Foundation’s GNU AGPL v.3.0, subject to the exceptions outlined in this policy; or
- Commercial licenses available from Mattermost, Inc. by contacting commercial@mattermost.com
"To simplify licensing, we’ve responded to community feedback and the compiled version of Mattermost v1.0 is now under the MIT open source license" (Emphasis mine)
I guess the compiled version as MIT is to make it easier for people to deploy in enterprises that might have issues with AGPL, given that the consequences of MIT are easier to evaluate.
Sure, maybe they should have never released this useful software at all. /S
Mattermost started, and is still developed AFAIK, as an internal app from a for-profit company, that they've generalized and started releasing to the community.[1]
Considering that they only just hit 1.0, maybe your tone is a bit harsh compared to their ever-so-slight mis-steps.
Since we are talking about open source software, maybe the guys that own the Mattermost account on Github could create a placeholder repo for Android (I wonder if this idea would work for iPhone, too) and accept Pull Requests until there is at least a beta native app.
Doesn't this have some heavy hardware requirements? Three machines with at least 2 GB of RAM? Is that really necessary if I'm going to chat with five people?
This looks very nice. Is there any plans for an API/client protocol? Web client is all well and good, but I'd want to have a solid console client, as well as some command line tools (eg: "echo "Some message" | xmpp user@host -- where the equivalent for Mattermost would allow to set the topic, or message a group via a bot etc.)?
Overall I like it because they closely follow Slack's UI. However I question the choice of fully supporting Markdown. A comment isn't supposed to be documentation. Supporting things like bold, italic makes sense for emphasis or making code easier to read. But headings? When would one ever want really large text in a comment?
I use Slack's 'Posts' feature which is a full Markdown post that you can embed in a chat in Slack.
The reasons I use these are:
1. Rich content, organized & clean lists with outbound links for status updates about things I'm working on, linking to Asana/Github
2. Notes from one on ones, or general progress updates that I keep in a private channel and save basically as a stream-of-consciousness/reality log, having them there makes them readily accessible in product and having them in Markdown makes them very readable when I'm browsing through.
In short, I treat Slack rooms almost like I would treat a folder in Dropbox, they just happen to also include some chat between people :P
Headings don't actually imply really large text. They imply differentiation for different levels of text introducing the following section, which can be useful in similar ways as bold and italic. Most stylesheets for markdown do seem to implement the top couple headings with uncomfortably large text, though, which is a bummer. It would be great to see configurable styles for markdown in tools like this.
In my past job, I was desperately looking to get an open source Slack alternative. The ones I tested then (few months back) didnt hold up nicely against Slack. I'm happy to see that finally there's some good competition.
The blog post is dated October 2nd; Is HN just learning of this announcement late, or is their blog displaying the draft date rather than the publication date?
Ubuntu might be the problem there I'm guessing. On CentOS 7 or Fedora 22/23 it takes less than 15 seconds to install to a complete, working state. Then the command line tools are very basic to work with.
The main issue with IRC is that you have to stay connected all the time to recieve messages, and you have to leave your IRC client to see and search the logs (unless you have some intermediate IRC client server that runs all the time). It's just not as nice.
Yet it's not something that IRC provides out of the box.
I've got no issues running my own ZNC bouncer, but when you're choosing a product that an entire organization will use (including people who have no idea what "ZNC" means other than 3 letters), IRC is lacking a lot of features that get mentioned in every HN chat solution thread.
Yeah but if you suspend your machine doesn't it stop accepting connections? I personally set up a tmux window on a raspberry pi for this, but it's too much to expect a whole company to manage this (vs. a nice simple web GUI like slack)
Slack has seriously changed the way we work at my company and it's boosted our productivity by 100x.
Yes we had a IRC server for a while and no one was using it, so we always had to use emails for important communications.
You just got to try it to feel it. Some features on paper don't match with the experience of a product.
If you're worried about using it for large community projects (e.g OSS), then maybe IRC is still the better child for that particular audience, although there's already a couple of communities who have successfully moved to Slack entirely (Gopher comes to mind).
Protocol limits, I suppose. For example, how IRC handles channel history? IIRC, the only way to reliably have it is to serve logs over HTTP or alike (i.e. outside of IRC).
XMPP MUC is not perfect, but I believe would be a better match.
In return for stopping short on features, it's incredibly easy to extend (and the work has already been done in most cases). For example, there have been build and log IRC bots for many years before Slack existed.
Slack is even easier to extend than IRC, and all those IRC bots can be plugged straight into Slack.
A sufficiently advanced IRC client may be able to catch up to Slack in some of its essential features, such as formatted code sharing, image sharing (for screenshots and other things), document sharing, comments on uploads. etc.
But at that point, why not just use Slack or Mattermost.
And IRC is not even close to an adequate solution for what Slack does when it comes to non-devs. If you only ever talk to people who code, then perhaps you can work around IRC's deficiencies. But by using Slack, the conversation can be opened up to all sorts of non-technical people, and it enables them to communicate effectively so much better than IRC ever could. These non-technical people's contributions are essential to the functioning of almost all serious companies, meaning that for most teams, IRC will not work and Slack will.
IRC is a telegram network operating on Morse code compared to Slack's cellular network.
You're not too far wrong, though IRC could do with some updating to get rid of some of its more severe limits and issues which prevent it from as useful as it could be for less technical users.
