Mattermost 1.0 released – open-source Slack alternative(mattermost.org) |
Mattermost 1.0 released – open-source Slack alternative(mattermost.org) |
Note, I'm not especially praising for this product, but I am for slack vs irc.
XMPP MUC is not perfect, but I believe would be a better match.
(Not sure if Mattermark provides them, but it's one of the reasons I use Slack)
I actually use slack via the IRC gateways, and the push notifications from IRC are nearly always 2-3 mins ahead of the slack ones.
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.
A bouncer? Usually pretty straightforward to install, and quite mature in features.
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.
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).
[1] http://about.psyc.eu/Jabber#Technical_Issues_in_Jabber
[2] http://josephg.com/blog/xmpp-in-wave-in-a-box/
[3] https://news.ycombinator.com/item?id=2069810
[4] https://www.reddit.com/comments/rvzdp
[5] https://news.ycombinator.com/item?id=10040302
For some balance, there are contrary opinions. This one seems to revolve around project governance.
[6] http://about.psyc.eu/Jabber#Technical_Issues_in_Jabber
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.
Community has asked this for a while, we want to build an effective, well documented API to let the community create what they want: http://mattermost.uservoice.com/forums/306457-general/sugges...
I'd honestly be more interested in seeing Mattermost try and write a really solid solution, and then work to standardise their protocol.
And the blog on why Dropbox decided to OSS it:
https://blogs.dropbox.com/tech/2015/09/open-sourcing-zulip-a...
Threads! Hooray.
I tweeted it at Slack and they seemed surprised actually. (I didn't get the vibe like they're shipping it anytime soon.)
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.
http://www.mattermost.org/why-we-made-mattermost-an-open-sou...
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.)
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.
Wrong. Slack has a target market. Mattermost should specify that market, along with its desire to be an open source Slack.
https://github.com/glowing-bear/glowing-bear https://latest.glowing-bear.org/
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.
Depending on the Scale, I'd personally go with an own Kaiwa Fork, backed by an Erlang MongooseIM Backend and LDAP.
That's a move that seems like it may push Gitlab ahead of GitHub in some ways (well, to me at least).
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.
This is a huge missing piece of the web.
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)
Why just the compiled version?
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.
There is also no mention of it in the "getting involved" section, just a link to github issues
This is not how you do open source.
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.
Let's be constructive.
1 http://www.mattermost.org/why-we-made-mattermost-an-open-sou...
It would be very difficult for us to move because of this, we talk a lot on the move.
We're working on shipping a high quality set of APIs. We're doing these in parts so we can design and document them well.
Mattermost v1.1 ships on October 16 and offers incoming webhooks as a start: http://www.mattermost.org/webhooks/
You'll find a link there to an open source sample app for customizing how you want webhook events from GitLab to appear.
Mattermost incoming webhook support ships with GitLab 8.1 on October 22.
For Mattermost v1.2 (November 16), we're working on outgoing webhooks, which could offer the ability to fire off console commands.
We had dozens of community members upvote a feature to add markdown and we added it because it made sense.
Now we really love it and can't go back: http://www.mattermost.org/open-source-slack-alternative-adop...
Headings have a lot of uses for emphasizing text, and there's fun uses too like creating different sized emoticons: http://www.mattermost.org/wp-content/uploads/2015/09/sheep.p...
##### :sheep:
#### :sheep:
### :sheep:
## :sheep:
# :sheep:
What made sense? Is there a use case that requires full Markdown support? If so, what is it?
A non-docker implementation would be nice.
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.
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.
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.
We had non-interoperable web services, and then businesses offering aggregation of those (like various social media aggregators, or even Slack) had appeared.
Now we have non-interoperable mobile apps.
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've used Slack and HipChat previously, and AFAIK the integration methods are all roughly equivalent - post a message to a URL with a token.
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
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.
It may be nice to combine them in one place but it won't prevent anyone from using them.
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.)
http://www.npr.org/sections/money/2015/09/23/442921757/episo...
IRC, mattermost, email, Gitlab, Wekan, Skype/Google Hangouts/BigBlueButton.... there are plenty of tools to communicate without spending loads of cash.
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.
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.
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 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.
