Only Slack and Zulip are for specific teams/companies, not for the public at large. So there's no "fragmentation" issue, any more that there's one when a company uses Bugzilla and the other uses JIRA.
This is a very short sighted view. There is a real need for an alternative to IRC - and closed source products do not cut it when we are talking about communication.
What parent is talking about is a real problem. There's micro-ecosystems out there around specific closed source products, all of them centralized, none of them compatible... and in the mean time, the only real decentralized, open source group chat solution (IRC) has a lot of issues [1] which shouldn't exist in 2015.
>This is a very short sighted view. There is a real need for an alternative to IRC
There might be one -- but this is absolutely not what this and Slack are aiming to do.
>and closed source products do not cut it when we are talking about communication.
Not sure about that. As it seems, for 99% of the world who only uses "closed source products" for chat, they do cut it.
(Interoperability is orthogonal of course).
Slack and IRC are room-based, semi-synchronous, topic-centered communication protocols with support for direct messaging.
Slack literally took the concept of IRC and put a bunch of cool bells and whistles on it. They updated it, centralized it and sold the idea as an enterprise solution. It works great, and the tech could be a kickass replacement to IRC, done correctly.
I don't really disagree with you... but I often wonder how much Slack actually adds to IRC. We use it at work (and as a 100% remote person in a mostly co-located team, it is a godsend). I can't really think of anything in Slack that wouldn't be easy to implement with IRC bots.
Persistent history is easy. Email notification is easy. Storage of various assets like text snippets and pictures is easy. I've never used any, but I'm assuming that at least one of the web interfaces for IRC works well...
I think the main thing that Slack has done is package it up so that you don't need to cobble together 100 different things -- which is, of course, very valuable. Or at least more valuable than the monthly cost that they charge ;-)
To be honest, I would really rather be using free software. I would be quite happy to pay for a service that made it easy for me (as Slack does), but software freedom is valuable to me.
I've wondered the same. Like you said, though, there is value in packaging useful features together.
IRC is "You could do that ...", while Slack is "You can do that". So like you're saying, you could set up a bunch of channel bots (And for what it's worth, I think channel bots are fairly ugly. If I say "Let's work on #133", I want #133 to be linked, I don't want a different user spewing 3 lines of noise and a long link). But most people won't do that because it's too much of a hassle. So most of IRC does not showcase what's really possible.
Like I mentioned in the g+ rant I linked above, it'd be possible to improve this by adding scripting features and such to IRC servers. But nobody's doing that. The harsh reality is that "could" is a long, long way from "can".
> To be honest, I would really rather be using free software.
Me too, man. Me too. I don't use Slack out of principle, and I'm a heavy IRC user. Sadly it doesn't often compare :/
> There might be one -- but this is absolutely not what this and Slack are aiming to do.
That's kind of a weird statement to me, because every time I've sold a techie-type person on Slack it's been by describing it as "private IRC with persistent history and a bunch of other neat things".
You're missing the point. Just because it's not what they're aiming to do doesn't mean the tech isn't appropriate for it.
You're commenting on their business model rather than the tech. For all you know, Slack could be planning to expand their business to hosting public chat rooms, then your comment wouldn't make any sense anymore.
You can already get a hacked up public chat via Slack. There's a package (which is all set to run on Heroku) that automates the process of sending an invite to the Slack organization so that anyone on the public web can do it.
I noticed this when the Bootstrap 4.0a announcement had a link inviting you to join their Slack:
> For those jamming on v4 with us, we also have a dedicated v4 Slack channel. Jump in to talk shop and work with your fellow Bootstrappers. If you haven’t yet, join our official Slack room![0].
The problem is not just the open vs closed source. Even if Google, Yahoo, Slack all open source their products. You'd still not be able to send messages from one to another unless they also federate at the protocol level.
So you can be connected with a universal "messaging" client to any of the available servers then send messages to someone on Google, or Slack etc.
As noted in the OP, Zulip is not a closed-source product anymore. But I'm not sure that really helps so much with the immediate problem, since it's more the proliferation of protocols rather than the scarcity of source that causes issues.
Yes, that's the title of the thread, you can assume I read that far at least ;) I'll give you I wasn't very clear.
I'm super excited Zulip is going open source. And it's both the proliferation of protocols and the closed-sourceness(?) of the products that is problematic.
Open source has two coupled benefits:
1. If the product becomes popular, it's easy to integrate with it, extend it, modify it, etc rather than just write an alternative from the ground up. This prevents the proliferation of new protocols just for the sake of an alternative. Right now, it makes no sense for me to go and build a FOSS alternative to Zulip. It would've made sense a few weeks ago. FOSS web services encourage/promote self-hosting. This also counts for something.
2. When extending a foss product, writing a gateway is a lot easier. Gateways don't slow down proliferation as much, but they do keep protocols somewhat close to one another and make it easier for users to migrate from one another. For example: It's been several years now and there is still no reliable open source XMPP-to-Hangouts gateway. But a Zulip/IRC gateway? If one doesn't exist already, I bet you there'll be one within weeks.
To dive a bit deeper, while XMPP/IRC exists, and it wouldn't be hard to make the Zulip server natively speak XMPP to clients, that in-and-of-itself wouldn't be quite useful. A message sent to stream "ops" with topic "prod deploy" might look like this†:
But one more protocol on the stack with mac/windows/iphone/android clients is, IMHO, an entirely different ball of wax than a libre project with only a single platform under its belt. In my situation, the existence of mobile clients is clinch for actually pitching it to any org I participate in.
Yep, we have a channel for developers that integrate with our product instead of having them email us. It's pretty efficient, but the fragmentation risk is there.
