Comment by coldtea

11 years ago

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.

20 comments

coldtea

Reply
scrollaway  11 years ago

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.

[1] https://plus.google.com/u/0/+JeromeLeclanche/posts/icC6gDToB...

  • coldtea  11 years ago

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

    • scrollaway  11 years ago

      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.

      2 replies →

    • zyxley  11 years ago

      > 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".

      4 replies →

  • rdtsc  11 years ago

    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.

  • chc  11 years ago

    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.

    • scrollaway  11 years ago

      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.

      3 replies →

    • lips  11 years ago

      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.

joesmo  11 years ago

We have cross-organization Slack users in our company slack channels and I also have multiple 'organizations', so fragmentation is sometimes an issue.

  • epmatsw  11 years ago

    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.