Funnily enough there are actually multiple Slack-like chat app projects underway in the Meteor community. I guess building a chat app is the new building a todo list app?
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.
I tend to agree. Instant messaging seems to be dying out in the workplace. I used to find it a highly effective mode of collaboration, especially in large enterprises. Small shops seem to leave it off the list. We cranked up Slack for my team of 15 devs, but since we are co-located it didn't add any value. I guess if you were trying to make a buck off the cloud an IRC SaaS solution might look like a good idea. I don't think Freenode has to worry. :)
A chat application is pretty much the canonical "Hello, world!" of socket programming. No wonder it is becoming the "Hello, world!" of web sockets too.
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! :-)
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.
So you set this up and you use it for a few hours and everyone on your team is like hey this is kinda cool.
* 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!
Unless you know they never used Slack, so there are no expectations.
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.
Well it's not just Slack that sets expectations but pretty much every SaaS webapp out there.
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...
What if you can't run slack because your company doesn't allow chat services that are externally hosted?
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?
It's certainly one of my major griefs with Slack. I don't want my entire company's internal communications to be hosted by some third party startup I can't at all trust.
I would say this traditionally case but I think things are slowly changing even in the Enterprise world, where they too are starting to realise it's not realistic to be good at everything as well as their employees demanding better services.
Also, there's nothing stopping your company from making the product better.
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.
When you are running a business, you use tools to make your life easier.
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.
So...don't use it. Honestly, there are other people here that will see this link and go "hey I want to add this feature in this" and the tool becomes better. Once it does I am sure you're gonna come back and leech on it.
Obviously I have the option not to use it, but we can still have a discussion about the pros and cons.
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.
Another company offering SaaS products is not a plus by itself either. The idea of "pay us so you don't have to push upstream fixes" is just another spin on the usual marketing agenda for cloud-based companies. Either way when running a business you need to consider what kind of infrastructure you're investing in.
This. Was about to respond with a comment like this, but I think it's just better not to devolve into that argument (which has definitely been done before, countless times).
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.
Right, so then... pay for Slack. Leaving negative comments about such a general "problem" with open source software isn't really productive or warranted, I think.
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).
> people tend to flock over to the propietary option
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)
In the case of something like Slack though, there's a huge business risk: Storing your confidential internal discussions with a random startup of questionable security practice.
True, but it also gives you an out if customer data is breached. You, with good faith, contracted a thirdparty to manage and secure your data. If you run your own Letschat and some exploit is found that dumps your chat db, you're/your company is on the hook.
FWIW, I don't and likely will never use or promote Slack for intracompany chat.
The opposite. If you install opensource software on you own servers, and make it available only for your company's intranet, you are perfectly safe from outside attackers. Proprietary software can also exploited or they can just sell your data for bucks, when they are about to bankrupt.
> Because it Just Works(tm) and there's no fiddling or faffing about necessary.
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'.".
Then you put on a great deal of risk in terms of owning your data, having unwanted changes in the product, or Google acquiring (and closing down) your service provider.
Well for one thing, there's the hassle of maintaining it.
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)
about the security issue, you're wrong: if you want to host it for your company, put it behind a VPN or defend the site with a password on the HTTP level. This prevents all attacks from outside.
That also hinders remote access and promotes a sense of false security with users who don't know better. Better to tell them to use a secure channel for sensitive things. Then again if you thought slack was really secure I could set how you might think that.
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!
They're more interested building their own little walled gardens. If they spent as much effort improving their products as they did breaking integrations then there wouldn't be a Slack.
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.
> Everyone else is busy "improving" gmail if you're Google, or monetizing voip/video chat
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.
Agreed. If you still want to use it however just enter somerandomstring@mailcatch.com and then check the mail at http://somerandomstring.mailcatch.com/. Very useful when you want to bypass such useless logins, just know that the mail is public.
One of the devs said yesterday that API integrations are coming soon. After this, replacing Meteor's Blaze for something like React could make this a serious slack alternative...
What specifically would a user notice with the difference between Blaze and React? I get react is a bit faster under the hood. Its not something that would make this a 'serious' alternative?
I'm an avid react user and I completely agree. It wouldn't make it a 'serious' alternative just from that, although I would always love to see react used :).
The serious alternative is having both: API integrations + react, specially the first one... Like you say, react alone won't make a big difference, but it could potentially make the UI less laggy.
It's planned. You can see whatever is planned or not in GitHub issues. Also, you can create some feature request there or either contribute with something.
Are you asking if people would consider to a better but cheaper version of Slack? Because the answer is probably yes. Gotta get the integrations right though.
Go to https://www.meteor.com/ and Start tutorial.
After installed you can go through the tutorial in an hour or two depending how deep you go, and it comes with a number of examples (show with "meteor create --list").
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.
this. I've been looking for something to replace facebook messenger to use with my friends. Whatever it is, it would need mobile push notifications. Currently I'm using tinfoil facebook so not getting push messages causes me to miss long portions of conversations in my group chat and I don't want to just use another service, I'd rather host it
It's written in meteor. Meteor is for writing web and mobile apps. Rolling a mobile version goes something like $meteor add-platform android and $meteor run android-device. (you can replace android with ios).
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.
Using someone else's wrapper library is like (insert sufficiently disgusting analogy for doing something with a pile of excretia).
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 is better and actually more popular. IRC solved the problem of instant messaging over 20 years ago, and solved it very well. This is a problem that everyone and their mother attempts to re-solve and they always end up with a solution that's inferior to IRC. Just deploy an IRC server folks!
IRC solved basic communication, but the necessity of bots for things like authentication for usernames, logging, and retaining permissions are inelegant kludges, in my opinion. If XMPP has problems, so does IRC.
I don't think it'd be very difficult to set up some sort of web UI for account creation, combined with existing in-client features for usernames/passwords. That'd be more worthwhile than building a new solution from scratch.
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.
Once you realize that everything on an IRC service is tied to a user account, it makes a bit more sense. And extending from there, different user accounts are responsible for different things. (The *serv accounts on most networks).
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.
I appreciate the separation of concerns, but I meant more that "agents and clients sharing the same channel of control" is inelegant. It can lead to race conditions in netsplits, even, from what I recall!
Bouncers. They aren't an ugly hack, are easy to deploy, and make the experience way better. I'd prefer to host that sort of thing on my own infra, too.
matrix (https://matrix.org/) is a more modern messaging protocol than XMPP; it revolves around HTTP and JSON because it's the most logical today the way XMPP is based on XML because it was the most logical at the time. Let's hope they can achieve something here !
I also wanted to come in here and promote matrix. You can use it internally, or you can federate it. It takes a lot of concepts from XMPP, and is essentially json over http with an "eventually consistent" synchronization between clients and servers.
I did a containerized deployment for the project: https://github.com/giantswarm/swarm-rocket. Still has some issues that need to be resolved, including configuring the mail server, long build time, and a handful of other issues. If someone finds it useful, let me know!
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 :)