29 ms·

It's really difficult for me to take this point seriously if the only proposed alternative is IRC. I understand the benefits of IRC for FOSS and have used it ma

It's really difficult for me to take this point seriously if the only proposed alternative is IRC. I understand the benefits of IRC for FOSS and have used it many times in the past, but there's a reason why projects are adopting Slack over IRC. It's easier to use, it deals with on/offline states a lot more gracefully, it allows joining and inviting to rooms much easier, it has a clean and easy to use design and it's available pretty much anywhere using the same interface without having to install a client through their web interface (which is the exact same as their app interface). Along side that, there are hundreds of other minor to major features (File Sharing! Ticketing/build integration! Link Previews! Editing a message after it's sent!!!) that make it much more useful for many use cases than IRC. I think there is definitely room for competition with Slack for FOSS projects, but trying to pretend like IRC is that ultimate solution will ignore the problem completely.

ipozgaj 11y ago
IRC is constantly evolving as a protocol, and v3.3 is currently work in progress, so improvements are being made. See http://ircv3.net/ http://ircv3.net/
- justin_vanw 11y ago
  Except not really, and it hasn't changed in any significant way in over 20 years. Having a standard and a committee usually means that something has stagnated, not that it is alive and improving.
  - hardwaresofton 11y ago
    While standards and committees might be slow to implement changes, their existence certainly does not mean some language/technology has stagnated. By your logic, the web has stagnated. Most experienced engineers are glad about the existence of a standard/committee. This is what lets people build stuff that can inter-operate. Without such specifications written somewhere, people are going to build random shit that doesn't work together because of small differences in implementation
    - tptacek 11y ago
      This is a pretty silly comparison, because the web is changing so fast that people regularly express concern that it's evolving too quickly. IRCv3, meanwhile, hardly changes IRC at all. There's no indication from the IRC standards work that IRC is heading in the direction that people who use Slack need it to go: it's not going to index channels, it's not going to allow long message lines, it's not going to deliver previous messages to users who join channels, &c &c.
    - justin_vanw 11y ago
      you're ignoring that period between standardization and the release of google chrome where there were effectively no changes and no browsers that were compliant. Suddenly competition led to a huge uptick in the speed of change of the web.
    - hardwaresofton 11y ago
      @tptacek: > This is a pretty silly comparison, because the web is changing so fast that people regularly express concern that it's evolving too quickly. This only serves to prove my point -- standards/committees do not imply stagnation. Also, I think you're conflating common complaints about web development (frameworks, libraries, paradigms) with core work done by W3C and friends. > IRCv3, meanwhile, hardly changes IRC at all. > There's no indication from the IRC standards work that IRC is heading in the direction that people who use Slack need it to go: it's not going to index channels, it's not going to allow long message lines, it's not going to deliver previous messages to users who join channels, &c &c. Just because something changes doesn't mean it's necessarily getting better. If you have looked into WHY they do not make those changes, then it should be clear to you whether they will nor will not make those changes in the future. My bet is that someone (or multiple people) on the standards committee do not think that is the purview of IRC, and those are not features it should be concerned with. If there is no good reason for them not making those changes (in your mind), then you can go off, and make your own protocol built on top of IRC that implements those desired features. This is how you build an ecosystem of composable concepts. This is how the networking stack is built. It works. @justin_vanw > you're ignoring that period between standardization and the release of google chrome where there were effectively no changes and no browsers that were compliant. > Suddenly competition led to a huge uptick in the speed of change of the web. What's your point? Competition is pretty much always around unless it's suppressed. Your complaint is not against standardization, your complaint is against the suppression of competition.
hardwaresofton 11y ago
So all of the things you've noted, IRC is perfectly capable of doing. It's just that no one has built the interfaces (or the bots) for doing so. It sounds like someone needs to make an IRC client that is approachable to encourage a new generation of people to be interested? Also, the article is trying to make you aware of a fundamental reason to NOT use slack for FOSS -- it's closed source.
- tptacek 11y ago
  "Just build a bot" is such a cop-out. With the right "bots", you could make Unix talk(1) competitive. The things that Slack does better than IRC are integrated into Slack. They just work, and the whole system is designed to make them work smoothly. "Don't use Slack for FOSS projects because it's not FOSS" is an intellectually coherent argument. But "don't use Slack for FOSS projects because IRC is just as good" is not.
- publicfig 11y ago
  That's true that many of the things I mentioned (not all) are possible through clients building in the functionality on their end, but that leads to another problem that slack can avoid, which is a unified interface for all users. While file transfers may be made easier on one IRC client that some users are using, it has to be completely compatible with the user who is connected through Irssi or another less capable client. This limits the possibilities of a client (which, mind you, is actually a big selling point for a lot of IRC users including myself). And I agreed on the fact that it's closed source and that can be an issue. But like I said above, that means that there is room for FOSS solutions, not that IRC is the answer.
- hardwaresofton 11y ago
  @tptacek: Slacks growing usefulness is predicated on the fact that people build bots for it. It's not that IRC can be as good as slack -- IRC is NOT the same kind of thing as slack, they are different. IRC is a protocol, slack is not, slack is a product. My point is that the right product needs to be build AROUND IRC to make it viable/interesting. From the previous comment, it seems like the features people are loving slack for are: - Well designed interface - File sharing - Inviting/sharing channels with people - Functionality provided by bots Is that incorrect? I'm sure that list is incomplete, is there anything very significant I left off?
DanitaBaires 11y ago
Isn't there any way to "mount" a custom protocol on top of the IRC protocol, like Microsoft Comic Chat did in the nineties? If I recall correctly they encoded custom commands in plain text the client could correctly interpret to draw the comic panels. That way the slack-only features could be offloaded to another open source service or protocol.
- potatolicious 11y ago
  Incredibly hacky and fragile - the MSN Messenger protocol of yesteryear was similar. It was originally a plaintext-only protocol that was simple to implement, but many features were grafted on top over the years while trying to maintain backwards compatibility. By the time that protocol mercifully died the thought of implementing a client would rightly give programmers nightmares. The argument I see in this thread (not yours necessarily) seems to suggest that in order to implement modern features demanded by users we ought to favor grafting plugins and protocol extensions on top of IRC rather than use something that actually supports said features out of the box.
- ZenoArrow 11y ago
  > "Isn't there any way to "mount" a custom protocol on top of the IRC protocol" Why not just use Matrix.org? https://matrix.org/ https://matrix.org/
davidw 11y ago
The only big thing that Slack has over IRC is being able to catch up on what was said earlier. However, to be honest, for open source projects, 'chat' of any kind should be for quick and unimportant discussions, or help. Important decisions should be hashed out on mailing lists so that people in other time zones can participate, so they get archived, and so people can take their time to write something that is well-reasoned.
- yarrel 11y ago
  A screen session, a bouncer, Quassel, or ircCloud can all allow you to catch up with irc. And don't suddenly bite you at 10,000 messages. ;-)
- prg318 11y ago
  To be fair to your first point, if you set up a bouncer or use a client inside of screen/tmux you can absolutely catch up on what was said earlier in IRC.
  - bjt 11y ago
    And then you're back to the "easier to use" point. Maintaining an IRC bouncer is a chore that only an uber geek could love.
    - snuxoll 11y ago
      Really? I just leave irssi running on my linode, I don't even bother running a local client most of the time, I just SSH in and use it. The only exception is when I'm on mobile, and I have irssi-proxy running for that one special case.
      - hellofunk 11y ago
        Cool.. but I think you just underscored bjt's point.
      - davidw 11y ago
        I think part of this debate is that for some people, the above is a pretty normal and easy way of doing things, and for others, it's a large barrier to entry.
oddvar 11y ago
but there are alternatives! https://matrix.org https://matrix.org is an open standard defining a communication protocol. The goal is to have an open ecosystem where any app can talk to any other app. You can talk to Matrix either natively - or via a bridge. We already have written bridges to IRC, Slack, XMPP and libpurple - if you visit #matrix on freenode you are also talking in the #matrix:matrix.org (https://vector.im/beta/#/room/#matrix:matrix.org https://vector.im/beta/#/room/#matrix:matrix.org) room in Matrix (and vice versa). You can even connect to Matrix via your IRC client via http://pto.im/ http://pto.im/ Matrix is decentralised, you can run your own server (clone our server or write your own) and servers will create federated networks on a need-to-know per-room basis (see http://matrix.org/#about http://matrix.org/#about). Matrix is free software, all our code is Apache2 licensed, you can clone it (https://github.com/matrix-org https://github.com/matrix-org) and use as-it, modify it - or write your own client client and/or server (http://matrix.org/docs/spec/r0.0.1/ http://matrix.org/docs/spec/r0.0.1/)! disclaimer: I work for Matrix.org!
- thenomad 11y ago
  OK, I'm rather impressed. I was expecting this to be, shall we say, at usual FOSS levels of user-friendliness for non-technical users, but the new client (Vector) is very easy to get started with. I'd suggest making it clear that Vector is by far the most user-friendly way to use Matrix if you want to attract non-technical users to the service, but otherwise, well done.
  - oddvar 11y ago
    Thanks! Vector (http://vector.im http://vector.im) has had a lot of UI/UX focus - but the nice thing with Matrix is that it enables you to pick the type of app/client that you like - and whether that's a web client like Vector, a terminal client like weechat (http://matrix.org/blog/project/weechat-plugin/ http://matrix.org/blog/project/weechat-plugin/), a mobile app, or even a different service like IRC - that's entirely up to you! Check out http://matrix.org/blog/try-matrix-now/ http://matrix.org/blog/try-matrix-now/ for a list of clients/apps that support Matrix!
- deleted 11y ago
  [deleted]
at-fates-hands 11y ago
There were several listed in the comment section including: Matrix (as someone with the project has already replied to your comment) Zulip Mattermost LetsChat RocketChat
- akerro 11y ago
  http://mattermost.org/ http://mattermost.org/ is good. We will use it in our company with 300 devs.
  - at-fates-hands 11y ago
    Thanks for the heads up. I'm going to try this out. I have a small team of developers right now and Slack hasn't been working out as well as we had hoped. I also noticed a lot of the comments recommended Mattermost as well.
    - it33 11y ago
      Fantastic! Anyone interested, you can find Mattermost install guides here: http://www.mattermost.org/installation/ http://www.mattermost.org/installation/ Puppet, Docker, Cloud Foundry, Heroku, plus guides to install directly on Ubuntu, Debian and RHEL/CentOS/Oracle Linux, etc. Forums available for any help getting started beyond docs: https://forum.mattermost.org/ https://forum.mattermost.org/
exelius 11y ago
I love Slack, but I agree with the author. Slack's unsuitability is more around licensing terms and the ad-hoc nature of OSS. Slack borrows generously from IRC -- in fact, Slack is basically "Corporate IRC". It's a huge reason as to why Slack is so popular: IRC made sense in the 80s, and it still makes sense today. IRC is open (VERY open), easy to use, and less centralized than Slack. The only real benefit of Slack is easier file transfers; but even then you could probably just set up an IRC macro to send someone a link to the file on Dropbox. Now, the Slack client is much, much more slick than any IRC client I've seen. But if someone writes a great IRC client that looks like Slack (and has things like URL previews, etc), I doubt you'd have as many detractors.
- tomschlick 11y ago
  > The only real benefit of Slack is easier file transfers Also a good notification system, multiple session support, native mobile clients, easy third party integrations, baked in searchable history, team support, and easy enough for the non-techies to use.
  - throwaway2048 11y ago
    you don't every single feature for something to be a useful alternative.
  - exelius 11y ago
    The context of this discussion is open source projects. While I agree that these are all useful features, I'm not so sure they would be useful for open source projects whose membership tends to change relatively frequently. Also, many of these features are features of the client, not the protocol. > multiple session support There are web-based IRC clients that support this. In fact, I would not be surprised if under the hood Slack started out life as a web-based IRC client - it's a very similar (though much more polished) experience. > native mobile clients There are native mobile IRC clients; and Slack's mobile client is nothing to brag about - I've seen it take 10-15 minutes for messages to propagate to the mobile app. It also tends to hang frequently when using it. > easy third party integrations I don't know that it gets any easier than IRC - it's a plaintext protocol that's open and well-documented, and even easier to use than HTTP. As a kid over 25 years ago, I wrote an IRC bot in Perl - and the protocol hasn't changed a lot since then. There are mature IRC libraries for nearly every programming language / stack. > baked in searchable history Granted - this doesn't exist by default in the client - but an Open Source project could easily set up an IRC log bot (of which there are many, and they provide interface / search / etc). And then you can just search the history via private message with the log bot. > team support This is a management feature; you can also easily just create password-protected channels (yes, this is a feature of the IRC protocol and not any particular client). > easy enough for the non-techies to use IRC is a little more difficult than Slack, but then again I don't know that most open source projects have much reason to interact with people who are not technical enough to connect an IRC client (at least in the scope of the project).
3pt14159 11y ago
Why not Gitter? It's really easy and plugs right into your Github.
- thenomad 11y ago
  That's fine unless you're not a developer, don't have a Github account, don't know what it is and don't want one. For any wide-usage FOSS project, that'll describe quite a lot of their users.
  - Touche 11y ago
    How is Slack better? At least with Gitter you just need a GitHub account, with Slack you have to create a new account for every Channel you might want to use.
- hobofan 11y ago
  Did you read the article? > Gitter is bad for many of the same reasons Slack is. Please don’t use it over IRC.
davexunit 11y ago
When you, as a free software project maintainer, rely on proprietary software for your infrastructure, you send a bad message of "I expect my free software to be good enough for you, but your free software is not good enough for me." A lot of the features you mention are better served by email, and I am completely opposed to editing messages after they are sent (chat is append only!) There are IRC bots for ticketing/build integration, and they were around long before anyone used Slack! But ultimately, even if Slack has more convenient features, we cannot rightly use it because it doesn't respect our freedom. Centralized network services are increasingly removing our control over how we communicate, and we must reject them for our free software projects. The ethical replacements (not alternatives, because Slack cannot be considered as an option) aren't going to get better if people aren't using them!
- susi22 11y ago
  Linus Torvalds uses Google+ extensively to communicate.
  - ocdtrekkie 11y ago
    Linus has never been like... a Stallman-esque bastion of software freedom obsession.
    - ktRolster 11y ago
      Linus also spends a lot more time communicating via mailing list. Google+ is like a side thing for him.
      - petepete 11y ago
        Yes, and his G+ posts are seldom Linux-related.
  - username223 11y ago
    And I haven't bothered to figure out which parts of my creep-blocking software I need to disable to read whatever he writes, so his "extensive communication" gets ignored.
woah 11y ago
I used to think that too, but irccloud.com solves almost all of the issues you mention.
deleted 11y ago
[deleted]
wcummings 11y ago
I chat with non-technical people on IRC everyday. If setting up an IRC client is "too much work", contributing to FOSS is "too much work." Don't force everyone onto a proprietary platform because its modestly more usable than IRC.
- st3v3r 11y ago
  And don't dismiss your non-technical users out of hand like that. It's elitist, and it sends precisely the wrong message.
  - wcummings 11y ago
    I'm not dismissing non-technical users, I'm acknowledging that plenty of them seem to use IRC just fine, contrary to what people are saying itt. The barrier isn't skill or knowledge, it's investing a small amount of time in figuring out IRC. Anyone can do it, there's loads of resources about setting up IRC expressly written for a non-technical audience (which you can provide to new contributors).
    - st3v3r 11y ago
      "I'm not dismissing non-technical users" Yes, you are. You may think you're not, but you are
LinuxBender 11y ago
There is also Convos [1] a web front end client to IRC that addresses some of your concerns. It uses Redis to maintain state. [1] https://github.com/Nordaaker/convos https://github.com/Nordaaker/convos
enkiv2 11y ago
Isn't slack basically just IRC over port 80? (I realize that it has other features, like automatic logging. But, on the one hand, to suggest that people making meaningful and useful patches to open source projects would be incapable of figuring out IRC is absurd, and on the other hand, to suggest that putting a typical IRC client in a web browser with few other UI changes is some kind of major ease of use shift is equally absurd.)

ipozgaj 11y ago

IRC is constantly evolving as a protocol, and v3.3 is currently work in progress, so improvements are being made. See http://ircv3.net/ http://ircv3.net/

justin_vanw 11y ago
Except not really, and it hasn't changed in any significant way in over 20 years. Having a standard and a committee usually means that something has stagnated, not that it is alive and improving.
- hardwaresofton 11y ago
  While standards and committees might be slow to implement changes, their existence certainly does not mean some language/technology has stagnated. By your logic, the web has stagnated. Most experienced engineers are glad about the existence of a standard/committee. This is what lets people build stuff that can inter-operate. Without such specifications written somewhere, people are going to build random shit that doesn't work together because of small differences in implementation
  - tptacek 11y ago
    This is a pretty silly comparison, because the web is changing so fast that people regularly express concern that it's evolving too quickly. IRCv3, meanwhile, hardly changes IRC at all. There's no indication from the IRC standards work that IRC is heading in the direction that people who use Slack need it to go: it's not going to index channels, it's not going to allow long message lines, it's not going to deliver previous messages to users who join channels, &c &c.
  - justin_vanw 11y ago
    you're ignoring that period between standardization and the release of google chrome where there were effectively no changes and no browsers that were compliant. Suddenly competition led to a huge uptick in the speed of change of the web.
  - hardwaresofton 11y ago
    @tptacek: > This is a pretty silly comparison, because the web is changing so fast that people regularly express concern that it's evolving too quickly. This only serves to prove my point -- standards/committees do not imply stagnation. Also, I think you're conflating common complaints about web development (frameworks, libraries, paradigms) with core work done by W3C and friends. > IRCv3, meanwhile, hardly changes IRC at all. > There's no indication from the IRC standards work that IRC is heading in the direction that people who use Slack need it to go: it's not going to index channels, it's not going to allow long message lines, it's not going to deliver previous messages to users who join channels, &c &c. Just because something changes doesn't mean it's necessarily getting better. If you have looked into WHY they do not make those changes, then it should be clear to you whether they will nor will not make those changes in the future. My bet is that someone (or multiple people) on the standards committee do not think that is the purview of IRC, and those are not features it should be concerned with. If there is no good reason for them not making those changes (in your mind), then you can go off, and make your own protocol built on top of IRC that implements those desired features. This is how you build an ecosystem of composable concepts. This is how the networking stack is built. It works. @justin_vanw > you're ignoring that period between standardization and the release of google chrome where there were effectively no changes and no browsers that were compliant. > Suddenly competition led to a huge uptick in the speed of change of the web. What's your point? Competition is pretty much always around unless it's suppressed. Your complaint is not against standardization, your complaint is against the suppression of competition.

hardwaresofton 11y ago

So all of the things you've noted, IRC is perfectly capable of doing. It's just that no one has built the interfaces (or the bots) for doing so. It sounds like someone needs to make an IRC client that is approachable to encourage a new generation of people to be interested? Also, the article is trying to make you aware of a fundamental reason to NOT use slack for FOSS -- it's closed source.

tptacek 11y ago
"Just build a bot" is such a cop-out. With the right "bots", you could make Unix talk(1) competitive. The things that Slack does better than IRC are integrated into Slack. They just work, and the whole system is designed to make them work smoothly. "Don't use Slack for FOSS projects because it's not FOSS" is an intellectually coherent argument. But "don't use Slack for FOSS projects because IRC is just as good" is not.
publicfig 11y ago
That's true that many of the things I mentioned (not all) are possible through clients building in the functionality on their end, but that leads to another problem that slack can avoid, which is a unified interface for all users. While file transfers may be made easier on one IRC client that some users are using, it has to be completely compatible with the user who is connected through Irssi or another less capable client. This limits the possibilities of a client (which, mind you, is actually a big selling point for a lot of IRC users including myself). And I agreed on the fact that it's closed source and that can be an issue. But like I said above, that means that there is room for FOSS solutions, not that IRC is the answer.
hardwaresofton 11y ago
@tptacek: Slacks growing usefulness is predicated on the fact that people build bots for it. It's not that IRC can be as good as slack -- IRC is NOT the same kind of thing as slack, they are different. IRC is a protocol, slack is not, slack is a product. My point is that the right product needs to be build AROUND IRC to make it viable/interesting. From the previous comment, it seems like the features people are loving slack for are: - Well designed interface - File sharing - Inviting/sharing channels with people - Functionality provided by bots Is that incorrect? I'm sure that list is incomplete, is there anything very significant I left off?

DanitaBaires 11y ago

Isn't there any way to "mount" a custom protocol on top of the IRC protocol, like Microsoft Comic Chat did in the nineties? If I recall correctly they encoded custom commands in plain text the client could correctly interpret to draw the comic panels. That way the slack-only features could be offloaded to another open source service or protocol.

potatolicious 11y ago
Incredibly hacky and fragile - the MSN Messenger protocol of yesteryear was similar. It was originally a plaintext-only protocol that was simple to implement, but many features were grafted on top over the years while trying to maintain backwards compatibility. By the time that protocol mercifully died the thought of implementing a client would rightly give programmers nightmares. The argument I see in this thread (not yours necessarily) seems to suggest that in order to implement modern features demanded by users we ought to favor grafting plugins and protocol extensions on top of IRC rather than use something that actually supports said features out of the box.
ZenoArrow 11y ago
> "Isn't there any way to "mount" a custom protocol on top of the IRC protocol" Why not just use Matrix.org? https://matrix.org/ https://matrix.org/

davidw 11y ago

The only big thing that Slack has over IRC is being able to catch up on what was said earlier. However, to be honest, for open source projects, 'chat' of any kind should be for quick and unimportant discussions, or help. Important decisions should be hashed out on mailing lists so that people in other time zones can participate, so they get archived, and so people can take their time to write something that is well-reasoned.

yarrel 11y ago
A screen session, a bouncer, Quassel, or ircCloud can all allow you to catch up with irc. And don't suddenly bite you at 10,000 messages. ;-)
prg318 11y ago
To be fair to your first point, if you set up a bouncer or use a client inside of screen/tmux you can absolutely catch up on what was said earlier in IRC.
- bjt 11y ago
  And then you're back to the "easier to use" point. Maintaining an IRC bouncer is a chore that only an uber geek could love.
  - snuxoll 11y ago
    Really? I just leave irssi running on my linode, I don't even bother running a local client most of the time, I just SSH in and use it. The only exception is when I'm on mobile, and I have irssi-proxy running for that one special case.
    - hellofunk 11y ago
      Cool.. but I think you just underscored bjt's point.
    - davidw 11y ago
      I think part of this debate is that for some people, the above is a pretty normal and easy way of doing things, and for others, it's a large barrier to entry.

oddvar 11y ago

but there are alternatives! https://matrix.org https://matrix.org is an open standard defining a communication protocol. The goal is to have an open ecosystem where any app can talk to any other app. You can talk to Matrix either natively - or via a bridge. We already have written bridges to IRC, Slack, XMPP and libpurple - if you visit #matrix on freenode you are also talking in the #matrix:matrix.org (https://vector.im/beta/#/room/#matrix:matrix.org https://vector.im/beta/#/room/#matrix:matrix.org) room in Matrix (and vice versa). You can even connect to Matrix via your IRC client via http://pto.im/ http://pto.im/ Matrix is decentralised, you can run your own server (clone our server or write your own) and servers will create federated networks on a need-to-know per-room basis (see http://matrix.org/#about http://matrix.org/#about). Matrix is free software, all our code is Apache2 licensed, you can clone it (https://github.com/matrix-org https://github.com/matrix-org) and use as-it, modify it - or write your own client client and/or server (http://matrix.org/docs/spec/r0.0.1/ http://matrix.org/docs/spec/r0.0.1/)! disclaimer: I work for Matrix.org!

thenomad 11y ago
OK, I'm rather impressed. I was expecting this to be, shall we say, at usual FOSS levels of user-friendliness for non-technical users, but the new client (Vector) is very easy to get started with. I'd suggest making it clear that Vector is by far the most user-friendly way to use Matrix if you want to attract non-technical users to the service, but otherwise, well done.
- oddvar 11y ago
  Thanks! Vector (http://vector.im http://vector.im) has had a lot of UI/UX focus - but the nice thing with Matrix is that it enables you to pick the type of app/client that you like - and whether that's a web client like Vector, a terminal client like weechat (http://matrix.org/blog/project/weechat-plugin/ http://matrix.org/blog/project/weechat-plugin/), a mobile app, or even a different service like IRC - that's entirely up to you! Check out http://matrix.org/blog/try-matrix-now/ http://matrix.org/blog/try-matrix-now/ for a list of clients/apps that support Matrix!
deleted 11y ago
[deleted]

at-fates-hands 11y ago

There were several listed in the comment section including: Matrix (as someone with the project has already replied to your comment) Zulip Mattermost LetsChat RocketChat

akerro 11y ago
http://mattermost.org/ http://mattermost.org/ is good. We will use it in our company with 300 devs.
- at-fates-hands 11y ago
  Thanks for the heads up. I'm going to try this out. I have a small team of developers right now and Slack hasn't been working out as well as we had hoped. I also noticed a lot of the comments recommended Mattermost as well.
  - it33 11y ago
    Fantastic! Anyone interested, you can find Mattermost install guides here: http://www.mattermost.org/installation/ http://www.mattermost.org/installation/ Puppet, Docker, Cloud Foundry, Heroku, plus guides to install directly on Ubuntu, Debian and RHEL/CentOS/Oracle Linux, etc. Forums available for any help getting started beyond docs: https://forum.mattermost.org/ https://forum.mattermost.org/

exelius 11y ago

I love Slack, but I agree with the author. Slack's unsuitability is more around licensing terms and the ad-hoc nature of OSS. Slack borrows generously from IRC -- in fact, Slack is basically "Corporate IRC". It's a huge reason as to why Slack is so popular: IRC made sense in the 80s, and it still makes sense today. IRC is open (VERY open), easy to use, and less centralized than Slack. The only real benefit of Slack is easier file transfers; but even then you could probably just set up an IRC macro to send someone a link to the file on Dropbox. Now, the Slack client is much, much more slick than any IRC client I've seen. But if someone writes a great IRC client that looks like Slack (and has things like URL previews, etc), I doubt you'd have as many detractors.

tomschlick 11y ago
> The only real benefit of Slack is easier file transfers Also a good notification system, multiple session support, native mobile clients, easy third party integrations, baked in searchable history, team support, and easy enough for the non-techies to use.
- throwaway2048 11y ago
  you don't every single feature for something to be a useful alternative.
- exelius 11y ago
  The context of this discussion is open source projects. While I agree that these are all useful features, I'm not so sure they would be useful for open source projects whose membership tends to change relatively frequently. Also, many of these features are features of the client, not the protocol. > multiple session support There are web-based IRC clients that support this. In fact, I would not be surprised if under the hood Slack started out life as a web-based IRC client - it's a very similar (though much more polished) experience. > native mobile clients There are native mobile IRC clients; and Slack's mobile client is nothing to brag about - I've seen it take 10-15 minutes for messages to propagate to the mobile app. It also tends to hang frequently when using it. > easy third party integrations I don't know that it gets any easier than IRC - it's a plaintext protocol that's open and well-documented, and even easier to use than HTTP. As a kid over 25 years ago, I wrote an IRC bot in Perl - and the protocol hasn't changed a lot since then. There are mature IRC libraries for nearly every programming language / stack. > baked in searchable history Granted - this doesn't exist by default in the client - but an Open Source project could easily set up an IRC log bot (of which there are many, and they provide interface / search / etc). And then you can just search the history via private message with the log bot. > team support This is a management feature; you can also easily just create password-protected channels (yes, this is a feature of the IRC protocol and not any particular client). > easy enough for the non-techies to use IRC is a little more difficult than Slack, but then again I don't know that most open source projects have much reason to interact with people who are not technical enough to connect an IRC client (at least in the scope of the project).

3pt14159 11y ago

Why not Gitter? It's really easy and plugs right into your Github.

thenomad 11y ago
That's fine unless you're not a developer, don't have a Github account, don't know what it is and don't want one. For any wide-usage FOSS project, that'll describe quite a lot of their users.
- Touche 11y ago
  How is Slack better? At least with Gitter you just need a GitHub account, with Slack you have to create a new account for every Channel you might want to use.
hobofan 11y ago
Did you read the article? > Gitter is bad for many of the same reasons Slack is. Please don’t use it over IRC.

davexunit 11y ago

When you, as a free software project maintainer, rely on proprietary software for your infrastructure, you send a bad message of "I expect my free software to be good enough for you, but your free software is not good enough for me." A lot of the features you mention are better served by email, and I am completely opposed to editing messages after they are sent (chat is append only!) There are IRC bots for ticketing/build integration, and they were around long before anyone used Slack! But ultimately, even if Slack has more convenient features, we cannot rightly use it because it doesn't respect our freedom. Centralized network services are increasingly removing our control over how we communicate, and we must reject them for our free software projects. The ethical replacements (not alternatives, because Slack cannot be considered as an option) aren't going to get better if people aren't using them!

susi22 11y ago
Linus Torvalds uses Google+ extensively to communicate.
- ocdtrekkie 11y ago
  Linus has never been like... a Stallman-esque bastion of software freedom obsession.
  - ktRolster 11y ago
    Linus also spends a lot more time communicating via mailing list. Google+ is like a side thing for him.
    - petepete 11y ago
      Yes, and his G+ posts are seldom Linux-related.
- username223 11y ago
  And I haven't bothered to figure out which parts of my creep-blocking software I need to disable to read whatever he writes, so his "extensive communication" gets ignored.

woah 11y ago

I used to think that too, but irccloud.com solves almost all of the issues you mention.

deleted 11y ago

[deleted]

wcummings 11y ago

I chat with non-technical people on IRC everyday. If setting up an IRC client is "too much work", contributing to FOSS is "too much work." Don't force everyone onto a proprietary platform because its modestly more usable than IRC.

st3v3r 11y ago
And don't dismiss your non-technical users out of hand like that. It's elitist, and it sends precisely the wrong message.
- wcummings 11y ago
  I'm not dismissing non-technical users, I'm acknowledging that plenty of them seem to use IRC just fine, contrary to what people are saying itt. The barrier isn't skill or knowledge, it's investing a small amount of time in figuring out IRC. Anyone can do it, there's loads of resources about setting up IRC expressly written for a non-technical audience (which you can provide to new contributors).
  - st3v3r 11y ago
    "I'm not dismissing non-technical users" Yes, you are. You may think you're not, but you are

LinuxBender 11y ago

There is also Convos [1] a web front end client to IRC that addresses some of your concerns. It uses Redis to maintain state. [1] https://github.com/Nordaaker/convos https://github.com/Nordaaker/convos

enkiv2 11y ago

Isn't slack basically just IRC over port 80? (I realize that it has other features, like automatic logging. But, on the one hand, to suggest that people making meaningful and useful patches to open source projects would be incapable of figuring out IRC is absurd, and on the other hand, to suggest that putting a typical IRC client in a web browser with few other UI changes is some kind of major ease of use shift is equally absurd.)