Yesterday at Meteor's main meetup Devshop this was presented: http://spacetalkapp.com/ and the speaker mentioned that there's a big community effort underway to keep improving it.
Let's see which one wins the race :)
Normally, the progression is time-server, echo-server (with timestamps, sometimes), "selective echo server" (don't reply to sender, allow multiple recipients/subscribers) -- aka "chat".
What fun is message passing if you've got no one to pass messages to, or receive messages from? And when you're doing that, you have chat! :-)
So they're not eating their own dog food?
I think the reason there are a few of these popping up is that it's a lot of fun to build a chat application with meteor. I never intended to be a 'clone' of slack as as much as rocketchat or spacetalk.
I've been running it for a small group (~10 active daily users) for about 6 months - it has more social features like rich embeds, mentions, notifications, sms gateway, giphy search etc.
Demo Instance: http://nullchat.space
* a month or so passes *
Now everyone is invested in the tool and since the expectations have been set by things like Slack they expect integrations to work flawlessly, search to be infinitely fast, 99% uptime, Google OpenID authentication, and a slew of other features and before you know it you have someone spending two hours out of every day keeping it running.
As a personal project for kicks? Sure it's cool. Would I let me company run it? Hell no!
And your company wants to run OSS, so "has a guy" that already maintains the other pocketful of apps to company is using.
And since it is OSS, you can add Google OpenID auth if required.
And the slew of other features you want to add, but can't to Slack even if you knew about Slack.
Don't crap on the idea just because Slack is Slack and this isn't. Apply your "a month or so passes and now everyone is invested in the tool" scenario to any OSS alternative and your argument just comes off as fanboying.
Of course, you can add features but do not underestimate how much work it is to do so and is it even worth the effort? It is what you should be spending your time on as a company if that's not your business?
And let's remember Slack is going to video and voice soon...
EDIT: This seems like something that never gets brought up in any discussion of Slack. No company I have worked for would have allowed an externally hosted chat service. Have I just been unlucky, or is it just the people in my situation never speak up?
You shouldn't be spending 2 hours each day solving the same problems. If you make fixes, push them upstream (and others will too), then everyone gets a better product.
The reason I pay for Slack is precisely so I _don't_ have to push fixes upstream.
Tools are a means to solving a problem. Something being open source is not by itself a plus. I don't want to be developing a chat client so I can use it, I want to build my own fucking company.
What I'm saying is that "pull requests welcome" is a really lazy way of telling someone to support themselves. That's fine if you have a unique set of needs, in that case you should be building things out specific to you.
For something like chat, most people have a very similar set of requirements, paying Slack a couple of dollars per month to handle it is awesome. Would it be cool if Slack were opensource? Maybe, but that isn't why people would use it even if it were. It works really well, there is a team behind it that is paid full time to develop new features, and we can focus on building our own company instead of using bandwidth building tools for basic functionality.
That doesn't mean there isn't room for improvement, but the places for improvement in Slack aren't that it isn't open source.
When Slack doesn't have some feature you need, what do you do? switch? pay some other company? develop it yourself? both positions have tradeoffs.
But by all means, if you don't have time to contribute to open source, then... don't, and buy the pre-packaged service -- I'm glad people think this way because it makes it easy for SaaS startups to profit -- which moves the industry forward anyway.
It's not the open source project's job to make themselves appealing to you, you're just looking to use and use and not give back.
Also, the benefits (intrinsic or otherwise) of open source is a completely different discussion (that people have by and large already had).
Dunno why people tend to flock over to the propietary option though. :(
Because it Just Works(tm) and there's no fiddling or faffing about necessary. I'm all for [FL]OSS applications, but sometimes proprietary solutions, even if they do the same task, are just easier to use and integrate (both technically and bureaucratically)
FWIW, I don't and likely will never use or promote Slack for intracompany chat.
That's what marketing would have you believe. For example Hangouts broke the ecosystem horrible, and now xmpp and hangout users can no longer intercommunicate (and wonder why their messages are silently dropped).
Users complain that they need 6+ apps to keep in touch with friends.
The real answer, IMHO is "Because they market it as 'just works'.".
Don't get me wrong, I maintain lots of things. It's my full-time job. I count it as a victory every time I can gain some capability without adding some additional thing to maintain. Double victory even better every time I can take something I thought I needed to maintain and throw it on the scrap heap, eg because its functionality was subsumed by something else I need more.
Then there is security. If I take this open-source app and deploy it on my servers, and there is a vulnerability that results in privilege escalation, I have just opened up my network. Skilled admins will balk, but if I chat over Slack and there is a security vulnerability in Slack, even something related to my own (or my users' own) incompetence, I've just exposed... worst case is Slack, and Slack's network, and whatever my users already saw fit to expose to Slack.
It should already be eminently clear to my users that data in Slack's hands has left the garden of our own control, and is not to be trusted.
I am a proponent of other and opener Slack alternatives (to put it mildly), but I prefer things that come in a bigger stack, so when I waste my time setting them up, I get something back better than... my own watered-down version of Slack that I need to add to the maintenance charts.
(Insert small, shameless plug for Urbit, which has a centralized talk server and stores backlogs)
You're confusing FLOSS with self-hosted.
You can use free software, but hire it as a service. Example: https://githost.io/
There are both arguments. We have a VPN but don't let just any user on it. Then again I'm not sure if I want those people on slack with me either. The times when we want to use slack can tend to not overlap with the times we want to worry about whether the VPN works or if I can connect to it. We even use slack to organize a distributed disaster recovery and coordinate it!
I know this is serious, but maybe I misread your intention. The thing that makes Slack greater than all of the dominant IMs is that IM is their whole business.
Everyone else is busy "improving" gmail if you're Google, or monetizing voip/video chat, or (whatever it is that SalesForce does besides Chattr), meanwhile Slack is just chat, and whatever else you expected chat to encompass.
Yes. Instead of improving, they do voice, video, profile pages, silly pictures replacing your text and all that crap.
The only actual innovation I've seen to IM is ability to edit your last message.
Last people that tried to improve the actual IM chat were Google Wave but it crashed and burned because they fixated on everybody seeing as what everybody is writing when they write it (which was something nobody wanted).
Today, almost 20 years after ICQ people default to Skype even though it's closed crap for that purpose.
Any IM company that had some users had potential to become twitter or even facebook, but instead someone fresh came and stolen their lunch while they were playing with crappy voice and sponsored news feeds while accumulating bloat on their software.
I suppose I could download it myself and try it out that way, but that's a ton of effort for something I may not even want in the end.
Rocket.Chat devs, if you're listening, please provide a way to demo the program without giving up real information.
Do any of these new-fangled open source Slack alternatives offer notifications for people on the go?
Congratulations guys for the project! From what I saw, you're all Brazilians, this is very cool :)
What are some resources for getting started with meteor. Being able to build a chat apps like these seems powerful.
Discover Meteor has some more; they were giving their book away
(see https://www.discovermeteor.com/blog/we-made-our-book-free/ -- first 4 chapters are free).
That may be enough for the basics. Then look at telescope, or one of the chat apps listed here or search on github. Also plenty of conference talks on youtube.
For something I might host for my employees or people I intend on collaborating with I guess it makes sense.
edit: just saw where you want to host it...
It's really a shame when people can't look past the surface, and just emit vague subjective rebukes like this. XML may not be fashionable today, but really it poses no technical issues compared to the kinds of actual hard technical issues involved in making an open and decentralized IM network that XMPP has been solving for 15 years.
At the end of the day, the underlying product is still an overwrought, overly verbose mess, and the wrappers only serve to hide that. And following the law that all abstractions are leaky, you're going to have to touch it eventually.
A better replacement would be IRC. It serves almost all of the XMPP use cases with no extension, and i'd wager all of them with the right daemon and right plugins.
IRC has advantages over XMPP by having a much wider variety of clients and the fact that you can create your own integrations for things like build automation in a very short period of time thanks to the simple text-based protocol.
I always thought it made sense in a way - it makes for a very neat separation of concerns and makes the stack more modular, since you can now use almost any combination of IRC daemon and services package.
Don't answer "bouncers" for IRC. It is an ugly hack. With XMPP the server MAY provide history, which makes it unreliable.
From the same developers who designed and built XMPP.
No, not this one though: http://xmpp.org/extensions/xep-0231.html
XML also makes extensibility a lot less painful.
What is Slack?
What is Meteor?