4 ms·

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

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?
- md224 11y ago
  Please reply to posts directly for the sake of keeping the thread tidy. If you don't see a reply link for a post, click the timestamp (e.g. "17 minutes ago") to go to the permalink view for a given comment, where a reply box will be available.
  - ufo 11y ago
    Is there a reason why the replay button doesn't appear sometimes? I always wondered about that.
    - jat850 11y ago
      To you and the others curious about why the reply button doesn't show up, there is a buffer period after a reply appears before you can reply to it, to mitigate flame wars and such. It's usually a few minutes.
      - hardwaresofton 11y ago
        Uhhh does that mean we just found a bug?
        deleted 11y ago
        [deleted]
        edanm 11y ago
        If you mean the fact that you can circumvent this, then I'm not sure. It's possibly intentionally left in so that more experienced users have a way around that limitation.
  - hardwaresofton 11y ago
    Thanks -- reply button didn't show up, wasn't sure why, didn't know about this trick to leave comments.
    - 11y ago
hardwaresofton 11y ago
@tptacek: Slacks growing usefulness is predicated on the fact that you 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? @publicfig: Not all? Which aren't possible? And yes, it is true that slack avoids this problem -- the same way apple avoids having to deal with disparate use models for their hardware and software. You are arguing for a walled garden right now. That is the antithesis of what FOSS should be built on. So this is the place where standards come into play -- by finding reasonable ways to implement these features ON TOP of a protocol, people can implement them (or NOT implement them) consistently across clients. As long as the feature standards were written to degrade gracefully (as in they would still work reasonably well if your client didn't support any advanced features), there would be little problem with clients that didn't implement certain features. If you're using a client that doesn't support certain features, the beauty of FOSS is that you can actually change that client. You can make your tool better. That, or switch to a better tool?
nilkn 11y ago
> Also, the article is trying to make you aware of a fundamental reason to NOT use slack for FOSS -- it's closed source. Surely this suggestion can only seriously be made for projects that are also not hosted on GitHub.
- hardwaresofton 11y ago
  This is a good point, and the case can certainly be made that source code hosting should be done on sites that are powered completely by FOSS. Neither Github nor Bitbucket (I use bitbucket more than github) are open source. The shining hope is the darkness is Gitlab (https://about.gitlab.com/ https://about.gitlab.com/) though, which is a wonderful tool. That, and someone with deep enough pockets to start a publicly hosted gitlab that everyone in FOSS can use.
- scbrg 11y ago
  Not that I know much about Slack, but by using GitHub you don't give up control over your repository, or its history. Every single project member has a fully working copy that can be used if GitHub for some reason decides to go rogue, and it's accessible through open source software. How about your communication in Slack? Can it be withheld or otherwise become inaccessible, or is it completely accessible through open source tools and possible to export continuously to a useful format? If not, then there's quite a difference.
to3m 11y ago
So IRC can do all this stuff, but nobody has done the work to do it. That is another way of saying IRC doesn't do this stuff. That might be why people like Slack rather than IRC. ``It sounds like someone needs to make an IRC client that is approachable to encourage a new generation of people to be interested?'' Yes. It sounds... very much like this? :)
- hardwaresofton 11y ago
  Again, IRC != slack, they're not the same type of thing. IRC is a protocol, slack is a product built upon a (proprietary?) protocol that slack built to do pretty much the same thing IRC does (with arguably more features built in). Also, no one is arguing whether people like slack more than IRC -- the point I'm trying to get across is that IRC is capable, but only lacks the development of a client, and forging of standards that would allow features that slack has. All the bot stuff is copyable pretty much 1:1, the great design, and built in features of slack require a much better IRC client to be built. But that's the only thing standing in the way. Taking the walled garden over developing an open source solution is widely accepted in the world at large, but it should not be the defacto solution for the FOSS community.
- LinuxBender 11y ago
  Actually, people have. They just haven't packaged it all up into a happy-clicky single click deployment. There is a little bit of configuration involved, but I have confidence that a majority of folks here could do it in two cups of coffee or less. For me, it is Convos (web front end that uses redis for state tracking) + UnrealIRCD (IRC daemon) + Anope Services (channels, users, permissions, etc). It isn't as pretty as the Slack UI, but it could be.
  - to3m 11y ago
    I suppose I'm just perplexed at this persistent view that one can just handwave away the fact that IRC doesn't do everything Slack does simply by saying that it could.
kuschku 11y ago
That no one has built the interfaces for doing so? There are interfaces and solutions for everything suggested. Use quassel or irccloud as frontend and bouncer (on Windows, Linux, Mac, Android, iOS and the web), use the standard bots, etc.

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?

md224 11y ago
Please reply to posts directly for the sake of keeping the thread tidy. If you don't see a reply link for a post, click the timestamp (e.g. "17 minutes ago") to go to the permalink view for a given comment, where a reply box will be available.
- ufo 11y ago
  Is there a reason why the replay button doesn't appear sometimes? I always wondered about that.
  - jat850 11y ago
    To you and the others curious about why the reply button doesn't show up, there is a buffer period after a reply appears before you can reply to it, to mitigate flame wars and such. It's usually a few minutes.
    - hardwaresofton 11y ago
      Uhhh does that mean we just found a bug?
      - deleted 11y ago
        [deleted]
      - edanm 11y ago
        If you mean the fact that you can circumvent this, then I'm not sure. It's possibly intentionally left in so that more experienced users have a way around that limitation.
- hardwaresofton 11y ago
  Thanks -- reply button didn't show up, wasn't sure why, didn't know about this trick to leave comments.
  - 11y ago

hardwaresofton 11y ago

@tptacek: Slacks growing usefulness is predicated on the fact that you 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? @publicfig: Not all? Which aren't possible? And yes, it is true that slack avoids this problem -- the same way apple avoids having to deal with disparate use models for their hardware and software. You are arguing for a walled garden right now. That is the antithesis of what FOSS should be built on. So this is the place where standards come into play -- by finding reasonable ways to implement these features ON TOP of a protocol, people can implement them (or NOT implement them) consistently across clients. As long as the feature standards were written to degrade gracefully (as in they would still work reasonably well if your client didn't support any advanced features), there would be little problem with clients that didn't implement certain features. If you're using a client that doesn't support certain features, the beauty of FOSS is that you can actually change that client. You can make your tool better. That, or switch to a better tool?

nilkn 11y ago

> Also, the article is trying to make you aware of a fundamental reason to NOT use slack for FOSS -- it's closed source. Surely this suggestion can only seriously be made for projects that are also not hosted on GitHub.

hardwaresofton 11y ago
This is a good point, and the case can certainly be made that source code hosting should be done on sites that are powered completely by FOSS. Neither Github nor Bitbucket (I use bitbucket more than github) are open source. The shining hope is the darkness is Gitlab (https://about.gitlab.com/ https://about.gitlab.com/) though, which is a wonderful tool. That, and someone with deep enough pockets to start a publicly hosted gitlab that everyone in FOSS can use.
scbrg 11y ago
Not that I know much about Slack, but by using GitHub you don't give up control over your repository, or its history. Every single project member has a fully working copy that can be used if GitHub for some reason decides to go rogue, and it's accessible through open source software. How about your communication in Slack? Can it be withheld or otherwise become inaccessible, or is it completely accessible through open source tools and possible to export continuously to a useful format? If not, then there's quite a difference.

to3m 11y ago

So IRC can do all this stuff, but nobody has done the work to do it. That is another way of saying IRC doesn't do this stuff. That might be why people like Slack rather than IRC. ``It sounds like someone needs to make an IRC client that is approachable to encourage a new generation of people to be interested?'' Yes. It sounds... very much like this? :)

hardwaresofton 11y ago
Again, IRC != slack, they're not the same type of thing. IRC is a protocol, slack is a product built upon a (proprietary?) protocol that slack built to do pretty much the same thing IRC does (with arguably more features built in). Also, no one is arguing whether people like slack more than IRC -- the point I'm trying to get across is that IRC is capable, but only lacks the development of a client, and forging of standards that would allow features that slack has. All the bot stuff is copyable pretty much 1:1, the great design, and built in features of slack require a much better IRC client to be built. But that's the only thing standing in the way. Taking the walled garden over developing an open source solution is widely accepted in the world at large, but it should not be the defacto solution for the FOSS community.
LinuxBender 11y ago
Actually, people have. They just haven't packaged it all up into a happy-clicky single click deployment. There is a little bit of configuration involved, but I have confidence that a majority of folks here could do it in two cups of coffee or less. For me, it is Convos (web front end that uses redis for state tracking) + UnrealIRCD (IRC daemon) + Anope Services (channels, users, permissions, etc). It isn't as pretty as the Slack UI, but it could be.
- to3m 11y ago
  I suppose I'm just perplexed at this persistent view that one can just handwave away the fact that IRC doesn't do everything Slack does simply by saying that it could.

kuschku 11y ago

That no one has built the interfaces for doing so? There are interfaces and solutions for everything suggested. Use quassel or irccloud as frontend and bouncer (on Windows, Linux, Mac, Android, iOS and the web), use the standard bots, etc.