Please don't use Slack for FOSS projects

https://drewdevault.com/2015/11/01/Please-stop-using-slack.html

by ipozgaj • 10 years ago

612 384 10 years ago

drewdevault.com

jkot• 10 years ago

Also free service has limit, so older messages will be eventually lost.

st3v3r24• 10 years ago

IRC out of the box has an even lower limit (0).

tptacek3• 10 years ago

Previous thread: https://news.ycombinator.com/item?id=10486541

baldfat3• 10 years ago

Still worth repeating USE IRC :)

underwater• 10 years ago

IRC's time has passed. There's a reason that these alternatives are winning.

st3v3r24• 10 years ago

Why? What if I value those things that Slack brings to the table?

TheGRS• 10 years ago

I thought I just jumped in a time machine. This exact article and pretty much the same discussions popping up.

smt88• 10 years ago

Why not Mattermost?

http://www.mattermost.org/

j452• 10 years ago

Ideally, Slack can consider:

- doubling as an IRC client

- providing open source projects pro level services similar to github.

thebouv• 10 years ago

I doubt that's something they want to do:

“these communities are not something we have the capacity to support given the growth in our existing business.”

Though I do think they realize that getting these communities on there spreads the word about Slack and that is a good thing.

As a reverse on your first point, and something I didn't know, it looks like those folks who don't want to get rid of their IRC clients can connect to Slack:

https://get.slack.help/hc/en-us/articles/201727913-Connectin...

j452• 10 years ago

Having used irc for many years (haven't in a long time), my first impression of Slack was it was an updated irc client.

What kind? A well organized, approachable irc client with an updated feature set to help share the things we do today. Slack has made channel based chat relevant again to a new, much wider audience. But it's not all new.

There was a time, however, where IRC made chat available to a much wider audience when it was much harder to connect.

Slack has done a nice job of positioning themselves near creating beginners and deserve the success from doing so.

I'm not sure how much more overhead open source communities would be over the free plans that already exist. Interesting to see that you can use an irc client to connect to slack.. just not sure why I couldn't use slack to do even more of my communicating in one place to be an irc client.

ultramancool• 10 years ago

An additional option which is now available is to host your own Mattermost server. GitLab has integration for it even.

IRC is still my preference, but it takes a fairly technical person to appreciate it and host their own server. If you're catering to more general people, having 1 technical person spin up Mattermost in docker might be a good solution.

amyjess• 10 years ago

Does Mattermost solve the last problem with Slack listed in the article? This seems to be the single most important complaint. Anything that can be described "hey, it's just like Slack, except it's FOSS" is still going to have that problem.

Namely, is it still intended primarily for intra-team collaboration, or can it handle communication with the public as well?

drivers99• 10 years ago

GitLab has integration for it even.

It actually is included with the gitlab omnibus installation package now, and then it uses gitlab's LDAP for logins. I just had to set a few options in gitlab.rb because I wanted to use SSL and to set the external hostname.

publicfig2• 10 years ago

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.

ipozgaj2• 10 years 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/

justin_vanw2• 10 years 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.

hardwaresofton10• 10 years 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.

tptacek3• 10 years 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.

publicfig2• 10 years 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.

hardwaresofton10• 10 years 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?

hardwaresofton10• 10 years ago

@tptacek:

Slacks growing usefulness is predicated on the fact that you people build bots for it.

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• 10 years 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.

to3m2• 10 years 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? :)

kuschku9• 10 years 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.

DanitaBaires• 10 years 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• 10 years 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• 10 years 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/

davidw12• 10 years 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.

prg3182• 10 years 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.

jeena14• 10 years ago

I often have the situation that I asked someone something, then the next day, or next month I have the same problem again and want to search for that one link or answer without bothering everyone again. That is not possible with IRC (yet?)

snuxoll4• 10 years ago

Fedora uses IRC for all the various group meetings and it works out pretty well, IMO.

LaSombra2• 10 years ago

The only big thing that Slack has over IRC is being able to catch up on what was said earlier.

What happens when a topic of discussion is debated intensely on a different timezone and you wake up to more than 500 messages to read? Do you read them all?

I think this is a reason for people who really don't engage on IRC for anything other than "Hi, I have a problem, can anyone help me?".

If you do anything meaningful and engage on different channels you know there is no keep up with everything being said or discussed.

Sorry if I sound harsh but I keep hearing the same tiring argument and keep pointing people to the same thing over and over and over. If you want IRC and history, please use an IRC bouncer. With Docker and cheap hosting solutions it's almost a no brainer. Do one better, add SSL to your bouncer and connect to, at least on Freenode, using SSL as well. Win-win.

yarrel2• 10 years 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. ;-)

bluedino2• 10 years ago

> The only big thing that Slack has over IRC is being able to catch up on what was said earlier.

What about all the integrations with other services?

oddvar4• 10 years ago

but there are alternatives!

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) room in Matrix (and vice versa).

You can even connect to Matrix via your IRC client via 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).

Matrix is free software, all our code is Apache2 licensed, you can clone it (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/)!

disclaimer: I work for Matrix.org!

thenomad2• 10 years 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.

sandGorgon2• 10 years ago

this is very cool. has this ever been ProductHunt-ed?

EDIT: clicking on https://vector.im/beta/#/room/!cURbafjkfsMDVwdRDQ:matrix.org takes a long time to load. is this a consequence of the server ..or is the protocol slower ?

outworlder• 10 years ago

This looks incredible! Thanks for posting it.

Now, they mention that it can be used for decentralized machine communication too. I wonder if there any projects taking advantage of that.

st3v3r24• 10 years ago

But using those bridges, how can I be assured that someone on the other side has access to stuff like file transfers or code snippets, or any of the other features?

at-fates-hands2• 10 years 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• 10 years ago

http://mattermost.org/ is good. We will use it in our company with 300 devs.

exelius4• 10 years 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.

frik3• 10 years ago

The only real benefit of Slack is easier file transfers

IRC has rock solid file transfer. Depending on your IRC clients, it's easy to use as well.

tomschlick• 10 years 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.

pmarreck• 10 years ago

Have you tried out irccloud.com? It addresses most of what most people think Slack is better than IRC at.

3pt14159• 10 years ago

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

thenomad2• 10 years 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.

hobofan• 10 years ago

Did you read the article?

Gitter is bad for many of the same reasons Slack is. Please don’t use it over IRC.

davexunit11• 10 years 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• 10 years ago

Linus Torvalds uses Google+ extensively to communicate.

tobz5• 10 years ago

Who is the other side of the conversation you mention in your first paragraph?

It seems incredibly reductive to state that using proprietary software, in any way, somehow makes a FOSS project send an implicit message that it... I don't know what you meant, but, disrespects its users?

Did I disrespect the users of FOSS projects I worked on by using Windows / Visual Studio?

jules• 10 years ago

Not everyone is dogmatic about free software. Slack is better than the alternatives, and denying it out of dogma is not a virtue. Many people are pragmatic and just enjoy programming and getting things done in the most efficient way. Rather than complaining that people are "unethical" (?) for using closed source software, you'd help your cause more by developing an open source alternative that's actually better than Slack.

Someone1234• 10 years ago

Centralized network services are increasingly removing our control over how we communicate, and we must reject them for our free software projects.

So like IRC? Telling everyone to "use Freenode" is no better than Slack, both are centralised. You might have more client choice, but you're still logging into someone else's server.

outside1234• 10 years ago

I think what the previous poster is saying is just that - the free alternatives to Slack are not as good - and therefore they aren't using them.

There is no reason that an open source project shouldn't use proprietary software. This isn't a religion.

forrestthewoods2• 10 years ago

I expect my free software to be good enough for you, but your free software is not good enough for me.

Then maybe those other free software projects should get good.

mmanfrin2• 10 years ago

So this[1] isn't your github profile then? Because publishing FOSS via a proprietary service would be you saying that free software like Gitlab isn't good enough for you.

[1] https://github.com/davexunit

sergiotapia2• 10 years ago

But ultimately, even if Slack has more convenient features, we cannot rightly use it because it doesn't respect our freedom.

That's the crux of it. Some people just don't care and want to communicate. What is easiest to use is the only valid metric for the majority.

solipsism3• 10 years ago

That makes no sense at all. Firstly, most people working on free software don't make assertions like, "My free software is good enough for you." Most of us are much more realistic and assert something more like "My free software might be good enough for you, here's why you should consider it."

Secondly, even if one were making that assertion that one's free software is good enough for others, why would that mean they should believe all free software is good enough for everyone? It just doesn't follow.

I am completely opposed to editing messages after they are sent (chat is append only!)

This isn't relevant. Your personal communication preferences are not universal. Slack's popularity shows people don't care about this.

But ultimately, even if Slack has more convenient features, we cannot rightly use it because it doesn't respect our freedom

Most developers aren't as dogmatic as this. You're in an extreme minority. Which is totally fine, and you should try to convince others if you feel they should be convinced, as long as you recognize most of us aren't in your "we". It's not true that I must reject Slack.

lamontcg• 10 years ago

People use slack because they use it at work and don't want to have two different message clients and want to consolidate. Free software is not meeting the needs of corporate users and has failed them, so they are using Slack or HipChat instead. Your dogmatic stance on "I am completely opposed to editing messages after they are sent (chat is append only!)" is a good example of how open source is failing corporate user. I typo things all the time and want to be able to edit them, and don't care about your philosophical objections.

You can try to bludgeon and guilt people into using open source tools, but the problem is fundamentally that the tools that are Open Source are /failing/ a set of users. If you fixed the tools and ran HipChat and Slack out of business with Open Source competition, we wouldn't even be having this discussion. Lecturing people about Freedom(tm) and "Devsplaining" to users why they don't want the features they tell you they want isn't going to work.

If you want people to get off of Slack write an Open Source alternative that Slack users will freely choose to use instead. Compete in the market and win -- or else you're just pissing into the wind.

st3v3r24• 10 years 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.""

No you don't. You send the message that you're using what you believe are the best tools for your team.

karmajunkie• 10 years ago

Its really difficult to take you seriously if your only real argument is "But but FREEDOMMMMMM". Freedom is being able to say "fuggit, I'm using a better product because I effing well can." Its you exercising your freedom to not log in. Its not demanding everybody do things your way so you don't have to do it anyone else's way.

woah• 10 years ago

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

wcummings3• 10 years 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.

st3v3r24• 10 years ago

And don't dismiss your non-technical users out of hand like that. It's elitist, and it sends precisely the wrong message.

LinuxBender2• 10 years 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

enkiv2• 10 years 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.)

frik3• 10 years ago

All open source projects should offer an IRC channel, mailing lists and a forum!

And almost all do. Even newer ones like Elixir that started with Slack have now a mailing list and an IRC channel.

JoshTriplett• 10 years ago

mailing lists and a forum

Ideally those can be the same thing; see the current Mailman interface, or Discourse, both of which can provide a forum-like interface to a mailing list.

aggieben3• 10 years ago

+1 for discourse

frik3• 10 years ago

Discourse is a forum, with a modern UI.

Forums are more for new and normal users/fans of open source projects. Technical discussions happen over IRC. And even more longer insightful technical discussions (often over several days) happen on mailing lists.

aggieben3• 10 years ago

Mailing lists are the only thing worse than IRC. Seriously.

cballard• 10 years ago

This is true for large open-source projects but there are plenty of µframeworks and tiny Unix-philosophy-following tools that don't need more than a Git(hub|lab) repository with the issue tracker enabled.

ltbarcly3• 10 years ago

If you don't want to use Slack for FOSS projects then don't, but if you do, go for it. This is what OSS is all about, Freedom, use what you think is right. Diversity is good, maybe people leaving IRC will lead to innovations in IRC that address it's 20 year old deficiencies that have never been addressed.

ipozgaj2• 10 years ago

OSS (as the name suggests) is about *openness", and that's exactly the point where Slack is falling short and what the article is about.

JustSomeNobody• 10 years ago

And that openness extends to being able to use whatever software one wants be it open source, closed source or whatever.

mbrock3• 10 years ago

GitHub is also a proprietary walled garden, and it's pretty much the nexus of open source today, much like SourceForge was before. At any given time there seems to be a minority that really cares about open infrastructure while the majority just wants convenient stuff on a free tier.

mikegerwitz4• 10 years ago

"Open source" was created specifically to avoid talking about freedom. If you want to talk about freedom, please say "Free Software".

In that case, we are talking about the freedom of the user to use software as they wish, to study it and modify it to suit their needs, and to share it with others. We're not talking about the freedom to go about their lives as they wish---that's a separate fundamental freedom, although it can certainly be restricted by nonfree software. Ideally, that software would also be Free, but that's their own choice.

But we should never encourage the use of proprietary software.

If you're talking about the "open source" development methodology, though, then the argument ceases to exist, because freedom is not important enough to discuss, and so those who adopt that perspective won't understand why it's bad to recommend Slack to someone, or even require it.

Bahamut• 10 years ago

In my experience, I like IRC (been using it for ~10 years), but sometimes there is a lot of noise. For example, the Angular.js IRC channel devolved into a flood of bad questions with not enough information to help, and some entitled users. Many in the Angular community ran away to Slack in response. Code snippets aren't as nice either in IRC vs. Slack.

I'm not sure what the solution is, but IRC is lacking (and sometimes blocked at workplaces) & Slack seems to solve most of the issues, but it not wanting to support large open source communities is an issue as well. There is a hole in tools available.

theaccordance• 10 years ago

This comes off as a snobbish article IMO. I don't want to discredit the work the author has done, but it's all over a communication tool, one that many of us have adopted in other environments. Having open source projects on the same platform as our other groups is simply a matter of convenience for the project organizer.

elliotec• 10 years ago

Yeah this guy needs to move on. He is welcome to hold on to IRC forever, as is anyone, but Slack is obviously an extremely useful, popular, and effective communication tool for open source projects as well as just about any team function.

rasengan• 10 years ago

IRC is fine if you package it right. IRC is just a protocol anyway. Slack is way more convenient versus IRC + etc. However, we can change that.

aggieben3• 10 years ago

Uh, no. So much no.

So many things are better than IRC. Even Jabbr.net is better.

forrestthewoods2• 10 years ago

The positives listed in "Problems with IRC that Slack solves" are significantly stronger than the negatives listed in "Problems with Slack". By a lot. No wonder FOSS projects are choosing Slack!

I also like how the "IRC is better for your company" section doesn't actually give reasons as to why it's better. It instead lists multiple services you can employ to achieve the features Slack provides out the gate.

Kinnard• 10 years ago

There's a Free and Open Source Alternative to Slack called Mattermost: http://www.mattermost.org/

it332• 10 years ago

Thanks for the mention! Mattermost team here, just to add, there's an option to use Mattermost as an IRC server via: https://github.com/42wim/matterircd

So if part of your team wants to stay on IRC and part wants to use Mattermost with file sharing and messaging across PC and phone, and integrate with Mattermost apps (http://www.mattermost.org/community-applications/) all that is available.

tyre4• 10 years ago

Things I care about:

- User experience. In 2016, I'm not using the hacker's AIM to collaborate. I know many people love it, but there are seriously better options. Syntax highlighting inline and file attachments that Just Work are fantastic.

- Product development. I want products I use to be continually improving. Not yearly but weekly. If something breaks, I don't want to fix it because I'm not here to build a chat program or manage one.

Things I don't care about:

- Closed Source. A dedicated team paid to work on the product full time, financially incentivized to expand the ecosystem is a major plus.

- A walled garden. This sounds like the same as #1. Slack allows many integration points, including chatbots that can be programmed to do anything. I'm not sure it is that closed off.

There is a reason large teams collaborate over Slack as opposed to IRC. If IRC filled people's needs, they would use it. It doesn't.

davidw12• 10 years ago

- Closed Source. A dedicated team paid to work on the product full time, financially incentivized to expand the ecosystem is a major plus.
- A walled garden. This sounds like the same as #1. Slack allows many integration points, including chatbots that can be programmed to do anything. I'm not sure it is that closed off.

Give it time. You'll come to realize that there are some good reasons - many of them quite grounded in practicality - why those of us who have been around for a while place some value on these things.

vulpino• 10 years ago

Then name them.

I realize this sounds caustic, but to say "Well, you're wrong" without giving adequate reasoning beyond "I've been around a while, so I know better" contributes nothing to the discussion.

tyre4• 10 years ago

Could you enumerate a few? I'm open to being wrong.

One might be "what if a product shuts down?" This has happened before with chat (Campfire being spun out of 37Signals) and wasn't catastrophic.

In fact, this could be a long-term positive (but short-term pain in the ass) since it forces stagnating teams to update.

zepto2• 10 years ago

Is there any reason you don't articulate the reasons here?

natural219• 10 years ago

I thought about this a bit. I'm a huge opponent of closed source / walled garden-style approaches for many platforms and situations, and I'm curious why this seems different for me. The biggest difference between Slack and normal situations where you do not want a walled garden is that porting between chat programs is relatively easy. Unless you're highly invested in the user flows allowed by a particular chat application (bad idea, IMO) which particular client you use doesn't matter that much. The only thing I can see this being a problem for is chat history, which you can still access from the old platform if you need it.

st3v3r24• 10 years ago

And I could say the exact same thing for the opposing viewpoint.

jlarocco• 10 years ago

Whether you personally care about it or not, it's a little silly for an open source project to require closed source software to interact with the project.

tyre4• 10 years ago

Why?

Has GitHub been bad for open source software?

Has Google Groups?

mbillie1• 10 years ago

If IRC filled people's needs, they would use it.

Can we please put this ridiculous circular argument to rest already? You can say that about ANYTHING, it's a vacuous fallacy.

tyre4• 10 years ago

People vote with their feet.

The real circular argument is "if only people used XXX they would love it!" That's not what I'm saying. People are choosing a new alternative to IRC because of the feature set.

Early on in the smartphone wars, the best argument from the Android side was "well just look at the adoption."

That isn't circular. Adoption is an important measure of "does this solve a problem people have?"

jeena14• 10 years ago

Slack makes it so that you can see what you missed when you return. With IRC, you don’t have this. If you want it, you can set up an IRC bouncer like ZNC.

So perhaps I'm hoding it wrong, but I've been using ZNC for a couple of years and every time I forget to close Xchat at work and people keep talking, I can't see what they said on my phone or at home. Also I can't scroll up nor search for stuff which were said in the past.

For me that is the biggest drawback with IRC.

A sensible alternative, which I also was able to push at work, is Mattermost http://www.mattermost.org/

Although I would love to see us using http://matrix.org/ but I don't expect our customers to install their own instance so we could federate any time soon.

kuschku9• 10 years ago

For me that is the biggest drawback with IRC.

Ever heard of Quassel?

An IRC bouncer where the client integrates with the bouncer – just scroll up to load more backlog.

Disclaimer: Am working on Quassel.

jeena14• 10 years ago

Hm nope, never heard of it. Does it work on my Sailfish OS phone, my Linux laptop and on my iMac?

majuscule• 10 years ago

ZNC channel playback is configurable:

  KeepBuffer = true
  Buffer     = 5000

jeena14• 10 years ago

But this only works if no other client is logged in, isn't it?

fideloper• 10 years ago

Those bullet point against slack are really common around here, but I've yet to hear an explanation as to why they're a con.

Example: It's closed source.

Apparently that in itself is intrinsically "bad", and obviously so, because I've yet to see any explanation attached to that argument.

jeena14• 10 years ago

You can't know what happens with the content you put in there.

zepto2• 10 years ago

What does that even mean? Surely the same is true for IRC, since anyone can be running their own code for relays, bots, and clients.

yoo1I2• 10 years ago

Not sure that that really needs an explanation in an article about FOSS Software projects, but here goes:

Using a closed source messaging system you never know, if 5 years down the line the company who owns you, and who is in control of your communication, decides that they would like to monetize your "contributions" to their system to synergize shareholder smileability, by adding ads to your projects channel.

Or they might want to change their pricing structure so suddenly the barrier to entry to your project is suddenly higher.

Or they get bought by google for their engineering talent and the whole thing ceases to exist.

Or they exclude the bot that you write and depend on a little bit from their network with no explanation given.

Or any other further or not so far fetched scenario in which the owners of the software can do whatever they want without consulting with you, leaving you with little alternatives.

Using a free protocol with free software, if these things happen wrt to the entity writing the code that you rely on or the the hosting of services you rely on, you're still inconvenienced, but these things do not impact you as much, because you're free to continue to use the code without the new sucky modifications, fork if if your able (or rely on some other entity taking over the code) and run the damn service yourself.

Forking and self-hosting aren't always the best solutions, but the more invested you are in a service the better they start to look.

unexpand• 10 years ago

Finally someone said it. I have a tough time with one of the project I am working on during my personal time. By the time I go home and get time to work on it or ask a few questions, I don't see anyone in that slack room. When I am work, slack is blocked, so I have to wait till weekends to get someone answer my question.

eddieroger2• 10 years ago

One problem that they failed to address in the Slack over IRC section is a damn near non-existent barrier to entry. I've introduced people and small teams to IRC. I've also introduced people to Slack. IRC is just different enough, even when introduced to a team of technologists who grew on AIM and the like. Consider the onboarding experience - I emailed someone a link to a Slack channel, and before I heard back from them they'd signed up on my account and, unsolicitedly, downloaded the mobile client and were chatting with me. My setup time was nil, and there was no training. Sure, they could have downloaded Colloquy to their Mac and iPhone, and entered the settings, and hoped for the best, but I'm almost positive it wouldn't have gone so smoothly. That doesn't even include time to configure a bouncer for persistence. It's just anecdata, sure, but it counts for something, and helps to explain Slack's explosive growth.

kuschku9• 10 years ago

That’s why things like IRCCloud or Quassel exist.

They can sign up with IRCCloud (or any quassel-as-a-service provider), and instantly be online.

Webinterfaces, clients for all platforms, and bouncer is integrated.

Seriously, there are modern solutions for IRC, use them.

eddieroger2• 10 years ago

But why? Now I've got more than one set of accounts to manage, and sign up for, and troubleshoot when things go awry. Slack solves that problem for me, and they do it for free.

shmerl• 10 years ago

Why IRC and not XMPP?

drdaeman• 10 years ago

This.

Well, I must admit, XMPP isn't the nicest protocol out there, and it has some issues (esp. with older software that implements it). One can't talk it with telnet client, and this is a downside. We've discussed it the other day: https://news.ycombinator.com/item?id=10900859

But it has advantages over IRC. To name a few:

- Universal federation. Private systems (that don't have S2S enabled) aside, any public XMPP server can talk to any public XMPP server. You don't need to have a separate account here, there and everywhere. Not that IRC really needs accounts (one can surely use it without signing up with NickServ etc), but sometimes it does.

- History access. Well, it requires server to have MAM (XEP-0313) support, but if it does, then everything is there.

- File transfers. Unlike Slack, it may not work for absolutely everyone but I think Jingle had gone through a lot of work and is quite capable of piercing quite draconian NATs. I'm not sure IRC's DCC is anywhere near. Well, and there's also in-band file transfers (XEP-0047) that's awful and sucks but still works for tiny content (short code snippets). And XEP-0363, although not many servers support it. XMPP's messiness has both down- and upsides.

- Integrations. I think there are as many XMPP bots as there are IRC ones. Either way, there are ton of libraries for most languages so one can hack their own simple XMPP bot literally in just a few of hours.

- Extensibility. XMPP can attach virtually arbitrary metadata to messages, or send extra information like typing notifications or delivery receipts. Well, it all depends on client support, but you don't need a committee to think of your own standard and make a ejabberd/Pidgin/Gajim/etc plugin or patch. And, possibly, think of compatibility approach for non-supporting clients. That's it. I don't think IRC has anything like this.

- OMEMO (of Axolotl/TextSecure/Signal fame). It's not mature, but one can already have multi-point end-to-end encryption for personal conversations. Sadly, not for chatrooms yet (MUC doesn't support PubSub, MUC2 aka MIX isn't yet here), but I'm sure it will work in the future.

dawnbreez• 10 years ago

Is this gonna be one of those "every day until you like it" things?

ChuckMcM• 10 years ago

I appreciate the sentiment but the message is a bit weak. There are many things that are "closed source" that we have to use to collaborate on FOSS, I ride in closed source airplanes to get to conferences but I realize I could use a Prarie Schooner that I built out of freely obtainable materials to get there instead.

Ok perhaps that is a bit too harsh, but it is the essence of the argument. Its easy to get an open source tool that replaces IRC and works like Slack, you take $5M and you hire a half dozen engineers and a couple of designers and you build a set of tools and then you give it away for free and never see your $5M ever again. Welcome to the prisoner's dilemma, FOSS edition.

josep2• 10 years ago

People who are maintaining the FOSS projects should decide what they use, not you.

jakejake• 10 years ago

I've tried and failed many times to keep IRC in my workflow. I always wind up opening it for a few days/weeks then eventually just kinda fizzle out.

My company installed slack and it was just like wildfire - the whole team was on it instantly and never have looked back.

If there was a client + bot setup that would offer the same functionality out of the box over IRC I'm sure we would have picked it up just as quickly. And I would have liked to be on the irc channel for a few of my favorite OS projects as well. But as far as I know, without there is no such setup?

vortico• 10 years ago

Projects can use https://hack.chat, for which I am the main developer. I am also working on an overhauled version (temporarily named Libre Chat) supporting file transfers, mobile apps, channel subscriptions, and chat history. Both are GPL, can be installed on your own server, and have "official" hosted versions.

jscheel• 10 years ago

A lot of the popular FOSS irc channels have devolved into rooms with thousands of people there with nobody talking. Seriously, over the past few years, it seems like people are still on IRC, but they just don't engage on it. I wonder if that has to do with a lot of people becoming more used to other platforms doing a better job of assisting in communication.

andrewmcwatters2• 10 years ago

I like the present-day Slack vs. IRC argument. It's an ongoing manifestation of the blatant lack of appreciation of user experience and great design.

Developers need to get their heads out of their rear-ends. If IRC is so great, why doesn't everyone use it?

This endless argument has been fought in multiple other products and fields as well.

Sir_Cmpwn2• 10 years ago

Author here. There's not much to say here that wasn't said last time, but here are some retrospective thoughts on this post:

- Probably would have come across better if I didn't pitch IRC as better than Slack in general, but only that it's better for FOSS projects. This blog post wasn't meant to shame Slack in general, even if it kind of did in the end.

- Importantly, Slack has come out as saying that they don't want big public projects to host themselves on Slack. It's really just not a good use-case for Slack to put a FOSS project on it.

- In hindsight, a lot of the FOSS-friendly alternatives (Matrix, Gitter, etc) are quite good and I should have put more effort into researching them and discussing them in my article.

It's probably too late to steer the discussion, but please remember that my post addresses the use of Slack for FOSS projects, not in general.

stephenitis• 10 years ago

Slack has come out as saying that they don't want big public projects to host themselves on Slack. It's really just not a good use-case for Slack to put a FOSS project on it.

I'm curious and need help finding a link to this source.

solicode2• 10 years ago

There might be better sources, but here are two that I know of:

https://facebook.github.io/react/blog/2015/10/19/reactiflux-...

http://blog.freecodecamp.com/2015/06/so-yeah-we-tried-slack-...

Sir_Cmpwn2• 10 years ago

I mention this in the article, first heading. Includes source.

mberning• 10 years ago

IRC sucks from a usability standpoint. Huge opportunity to make it better, but also a huge risk due to the legacy of IRC.

kaiizen3• 10 years ago

I'm starting to see slack repeaters in IRC channels all around IRC and I am leaving those channel as it ruins my IRC settings and makes things confusing. My colored nicknames no longer work. It splits communities and makes people leave the channel.

Please don't repeat slack to IRC.

halis2• 10 years ago

I've heard this argument before. The only problem is that IMO slack is awesome and IRC is not anymore.

I'm on 3 slack teams, one with some former co-workers, one for a non-profit that teaches coding and one for a side project.

If any of them suggested IRC I probably wouldn't have bothered.

As it is, I have the desktop client on my Mac Mini, MacBook Pro and my Windows laptop and the app on my iPhone.

It's great. IRC is not. That's my opinion. You don't even give any good reasons why it doesn't work for open source projects.

kasbah• 10 years ago

I recently decided on gitter.im plus a channel on IRC and a bot [1] that syncs them.

[1] https://github.com/finnp/gitter-irc-bot

diegorbaquero• 10 years ago

My vote goes to Gitter

andrewmcwatters2• 10 years ago

Gitter is also a great example of excellent integration and general design that keeps developers from having to do busy work like setting up a GitHub <-> IRC bot. I use it for my own projects, too.

halis2• 10 years ago

IRC sucks.

pnathan• 10 years ago

The basic problem with Slack is that it's not libre. It's a fine product in many other ways. I won't defend the ethics of libre: I'll leave that up to rms, who has done a more-than-adequate job. But libre is a more ethical choice than proprietary.

uxcn2• 10 years ago

The nice thing with IRC is that it's scriptable. So for example if you want a klaxon to sound every time the secret word is mentioned, it's easy to do.

shylor• 10 years ago

Honestly, my group uses Discord (http://discordapp.com) now. We love it. It replaces IRC and Teamspeak for us. Plus, I can get a user on the service in 5 seconds just by sending a link to them.

It is mostly used for gaming, but coding with it is just as great. There are a lot of public servers also for all sorts of things. (http://discord.me/servers).

The voice is what we love it for, chat is awesome during the day when some of us are not able to talk over voice.

bsimpson• 10 years ago

React moved to Discord after being kicked off of Slack for having too large a channel. The Discord folks welcomed them in as a supported use case.

If your biggest concern with Slack is the invite-by-email hack, try Discord.

ValentineC• 10 years ago

I've been playing around with Discord, but it seems like it lacks search and a proper API. I'm looking forward to its potential though!

kaiizen3• 10 years ago

Weechat in tmux/screen with a bouncer is fantastic. Weechat has a ton of scripts like highlight monitoring, filtering of join/part/quit that you can customize for timeouts. Has a great support channel on freenode too.

If you're doing FOSS projects, you can probably get your way around a command line enough to install and run both of these in a $3 VPS or even an AWS instance.

ex3ndr• 10 years ago

Almost all brazil FOSS community is in our completely open app: https://actor.im

7185413413• 10 years ago

Kauan

superuser2• 10 years ago

Jabber rooms seem like a pretty good idea. Lots of open source servers to choose from. Is there a reason not to use them, other than relative obscurity?

johnchristopher• 10 years ago

It hasn't been mentioned yet but glowing bear (http://glowing-bear.org/) is a nice web client that plus into any instances of a weechat process (that you let run in a multiplex terminal on a raspberry you plug in the kitchen, on the fridge).

finnn• 10 years ago

irccloud: Is really cool and solves all of the problems. irccloud.com

Is IRCCloud not closed source also?

kuschku9• 10 years ago

Yes, it is. But it still uses an open protocol – so you can switch from IRCCloud to, say, Quassel[1] easily without having to recreate channels or permissions.

[1] Quassel is an IRC bouncer/client combination which handles things like backlog archiving and so on properly – you can connect with multiple clients at once, just scroll up to load more backlog, use web clients, windows/mac/linux/Android/iOS clients, etc.

(The backlog lives in an SQL database, so tools like Quassel-Suche can easily query it, and you can easily export it. I personally stopped using bookmarks, and just search for links through Quassel-Suche instead)

solicode2• 10 years ago

The fact that Slack has made it clear they don't intend to support large open source projects is the biggest thing in my opinion. Reactiflux was basically forced off Slack for getting too big. Other large communities like the Clojurians Slack community will likely be forced off soon in the near future too (some members of the community have begun discussing this and evaluating alternatives). The Elixir Slack community is also similar in size, and I see the same thing happening there eventually.

unimpressive2• 10 years ago

I plan to write a blog post on this at some point, but as a tentative short and rough draft:

IRC's biggest problem is what I would loosely term 'Grunginess'. Every single thing I've seen associated with IRC has this kind of Unix/Linux-y grunginess to it where nothing is easy and everybody rolls their own solution.

If you would like to experience this first hand, try setting up eir (https://freenode.net/eir.shtml) which is written in an unholy mixture of C++ and Perl. (The moment I see this combination I usually know I'm in for a ride.) Or try the python IRC library (https://pypi.python.org/pypi/irc) which has almost no documentation besides docstrings and needs to be puzzled out and examined and source-read before you can use it.

You want to be able to see messages in an IRC channel when you're not on? Don't worry, ZNC (http://wiki.znc.in/ZNC) is here to help, with powerful command line configuration action! Honestly IRC bouncers are kind of a red herring. Even if you can see what is typed in a room when you're not on using a bouncer, the real benefit of slack's message history is being able to see what's typed in a room before you joined, and being able to assume that this is a feature which is available to every slack user.

Slack's multithreading is beautiful. One of the biggest problems with running an IRC channel is that IRC is fundamentally broken. And when I say that I don't mean it in the shallow way most people do, I mean actually literally fundamentally broken. Here's why: The average human reads somewhere between 150-300wpm. A decent typist types at 60wpm. If we take 300wpm as an optimistic estimate of average reading speed, the moment you're having a lively discussion the channel is swamped at seven participants or so. Slack makes multithreading easy by associating multiple topic 'channels' together for a single group so that you can talk about one topic in this channel and another topic in that channel and it's not confusing or unwieldy, people who want to hear about certain topics can subscribe to a channel and people who don't can just not subscribe or leave. You don't have this 'stepping on each others toes' problem where three people want to talk about this and three people want to talk about that and they all use the same channel to do it.

Avatars, emoticons, that stuff is all a bit tacky but the core fundamentals of the design are a sound improvement over IRC, and IRC needs to respond to that.

kuschku9• 10 years ago

IRC has responded to that.

A huge part of users uses now IRCCloud, or their own ZNC or Quassel setup.

And creating multiple channels is never an issue to separate topics.

omginternets2• 10 years ago

If this post were titled "Please don't use OS X for FOSS projects" nobody would take it seriously. I'm struggling to see the difference ...

cyphar14• 10 years ago

Because projects don't force you to use OS X or Windows or whatever in order to contact the maintainers. Using Slack exclusively does force people to do that.

omginternets2• 10 years ago

So? If you need to contact the maintainers, you're using Slack already...

This is much ado about nothing.

sergiotapia2• 10 years ago

Makes total sense. Let's say I have an open source project, how do I create a FREE irc channel for my users and what server to I choose to host it on?

mwfunk• 10 years ago

Open source is a form of software licensing that lots of people develop and use for lots of different reasons. That's it.

Everything else is politics and philosophy. Some people really get into the very specific politics and the very specific philosophies of the FSF. What they don't seem to get is that the FSF merely has one out of infinitely many perspectives on why open source is important and what people should do about it.

It's fine if someone wants to run an ideologically pure (per FSF criteria) FOSS project, or not contribute to projects that don't meet their criteria for ideological purity. Where it gets counterproductive is asserting that one group's philosophy has some sort of primacy over the entirety of the FOSS world. It gets especially dicey when that group claims moral superiority over everyone else.

Instead of complaining about this or that FOSS project not being "true FOSS", the FSF should define a set of standards and practices that go beyond mere software licensing that DO meet their standards for ideological purity. Then a project that wants to comply with the FSF have an easy way to state up front that they are politically aligned with the FSF in every respect. Those who care about such things can use that information to set their expectations about how the project is run outside of the software licensing aspect. Maybe it draws them to the project, maybe it drives them away, but at least no one gets surprised and no mailing lists devolve into pointless political flamewars.

That way no one gets disappointed (for example) when a project wants to use Slack for communication, assuming that that project has not stated up front that FSF-compliant ideological purity is a goal. Alternatively, if a contributor to a self-declared FSF-compliant ideologically pure project wants to use Slack, the other contributors to that project have grounds for denying that on a purely philosophical basis. They can focus on maintaining their standards for ideological purity rather than continually arguing over whether or not FSF-compliant ideological purity itself is valid goal.

PuercoPop3• 10 years ago

Open source is a form of software licensing that lots of people develop and use for lots of different reasons. That's it.

Open is more than one form of software licensing, each license modified by the different idiosyncrasies and values of different people that develop software.

Everything else is politics and philosophy

Open source IS politics as well. The origin of the term itself is a way to subvert Free Software

cyphar14• 10 years ago

"Open source" is a term that was created to subvert another political and social movement (the free software movement). So, it's inherently political in nature. You might see it as "only a license" but I would argue that is a shallow way of looking at the problem. Only in the recent past has it become possible to run a computer with only free software. Before then, users HAD to use proprietary software. To claim that free software is nothing more than a license is to ignore the fact that 30 years ago you couldn't use a personal computer in freedom, that all users were slaves to IBM and the other companies. This is a social and political issue, just like all of your other freedoms are social and political issues.

But maybe you don't care about freedom. I'm not sure why, but you probably have some shallow justification why "it doesn't matter for you".

akmiller• 10 years ago

This whole article and discussion is silly. Use whatever you damn well please for your projects communication!

isaiahg• 10 years ago

I have only one complaint of Slack. It should be much easier to find and join open slack communities and switch between them.

I've used it for a small team before but we quickly finished what we were doing and now it's dissolved. So I've been hearing awesome things about it and how people are using it and I haven't really had a chance to try it out. I've applied to join a few communities but I've never received a reply.

That process should be so much easier.

For open source projects or communities I think Discord fits the bill much better. It allows you to take part in multiple communities in one interface and you can use it without an official account.

shriphani• 10 years ago

I don't mind FOSS projects adopting slack - whatever it takes to make devs/users happy. But slack's tab-completion is woefully pathetic when there's more than a few hundred members in a chat room.

This is a solved problem - get it together slack!

bovermyer2• 10 years ago

I'm not real keen on the Church of FOSS.

Don't get me wrong, I love a great many FOSS projects; but my entire life does not need to be constructed of such. Posts like this smack of dogma and fanaticism to me, and engender mistrust of whatever projects the person in question is a part of. After all, if they're that dogmatic about one thing, then what's to say they aren't dogmatic about other things?

habitue• 10 years ago

The reason the dogma of Free Software exists is because often in day to day decisions it's easy not to think about the long-term effects. Right now, you have a neat chat tool. Maybe in 10 years, you have a problem where Slack has a monopoly on all project chats, and abuses that power.

Today, you can look and see "Hey, Slack is a cool company. They get it. This isn't Microsoft of the 90's. They aren't going to abuse this power, they just want to make an amazing chat tool that improves all of our lives." (This is probably true) So it seems like it's ok to use Slack. The idea is that maybe this power corrupts eventually. Or maybe Slack as an entity may not always be run by people who get it. Maybe it's broken up into parts, or becomes a hollow shell as a holding company (cough Yahoo). Without an open platform and free source code, users are unable to move away.

The dogma is a rule that brings the potential long-term consequences to you when you're deciding what to do now. It gives you a twinge "Hmm, that feels dirty because it's proprietary. I'll keep looking". That way you don't have to imagine how Slack gets from Cool Company to Abusive Monopoly, you can just make an easy choice based on how you feel.

bovermyer2• 10 years ago

I generally make my choices based on a balance of time/monetary cost, feature set, user experience, service integrity (e.g., SLAs for proprietary software, or difficulty of maintenance for self-hosted/OSS), and ease of migration in the event of abandonment.

The choice I ultimately make is not always, or even often, open source. There is no blanket "always choose this" guiding rule for me.

cyphar14• 10 years ago

You may not care about your freedom. But that doesn't mean that people who care about their freedom and others' freedom are dogmatic.

st3v3r24• 10 years ago

He lists the stuff that Slack does better than IRC, but then ignores it. Kinda like he's just waving it off as not being important. So what's the solution for getting the benefits that Slack has, without using Slack?

smokedoutraider• 10 years ago

You were whining about this a couple of months ago already. Slack is simply much more user friendly and doesn't look as dated as 99% of IRC clients.

Sami_Lehtinen• 10 years ago

Slack client and web-app both are really heavy consuming ridiculous amounts of memory and cpu time.

e12e3• 10 years ago

On a related note, Debian annonced [1] a new unified communications in November:

https://wiki.debian.org/UnifiedCommunications/DebianDevelope...

I'm not a DD, so can't comment on how well it works - but I've had it on my todo-list s while to look at their real-world setup as inspiration.

[1] https://lists.debian.org/debian-devel-announce/2015/11/msg00...

Previously submitted to hn, but didn't gain any traction: https://news.ycombinator.com/item?id=10531061

Please don't use Slack for FOSS projects

Related Stories