[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...
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.)
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.
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/
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.
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.
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.
