Live data from Hacker News

Please don't use Slack for FOSS projects

drewdevault.com

121–130 of 499 posts

Re: Please don't use Slack for FOSS projects

#121

This seems to be similar to the argument of "don't use Github or Bitbucket, use your own hosted Gitlab". Some of the complaints are a bit petty (really, an extra browser tab per project is a burden?) IRC is better for occasional participants that wish to remain anonymous and/or use less screen real estate, but Slack is generally a better experience for regulars and way less hassle than hosting your own server/bots. Y…

>really, an extra browser tab per project is a burden? It is, actually. I contribute to dozens of open source projects, and I am joined to hundreds of IRC channels.

Fair. My point is that you have a fairly unique set of requirements, such that there is a tradeoff in tooling to cater to part-time/open contributors vs. a core/extended team doing active engineering.

You bring up some reasonable points, even though I disagree with asking teams to not use Slack (as I vastly prefer it to IRC these days, but I am focused on open source collaboration with active engineering teams). I think a compromise would be for teams that want open contribution or a chat support channel to turn on Slack's IRC gateway.

Re: Please don't use Slack for FOSS projects

#122
post #45

It is reasonable to raise the point that building FOSS software while using a closed piece of software as a core tool bears consideration. However, I am 25 and largely missed the boat on irc. I decided to start using it ~1 year ago. It is hard to use, but we will look at that in a minute. Often, we assume people have as clear an idea of what we are talking about as we do. That is often not the case. Let's explore IRC…

It's worth mentioning that Zulip ( https://zulip.org/ ) is a new open source option that has basically all the features IRC/Slack does. So using open source tools for open source development doesn't have to mean dealing with IRC's limitations. (I'm one of the Zulip maintainers; happy to answer any questions about it).

I'm excited about Zulip as a Slack-style tool, especially for teams. (Separate from the discussion of whether FOSS project collaboration should be Slackish or IRCish.)

Are there any plans to support multiple teams / multiple servers from the native client? This is a particularly acute pain point on mobile; I'm reluctant to promote any tool that requires me to be logged in to only one project's instance of the tool at a time, because if it works well, it gets adopted for other projects, and then I'm having to juggle clients. I am unfortunately on two projects that use HipChat, and even there it's a huge pain that I can't be logged in to both simultaneously on my phone. (Some of their desktop apps finally support multiteam which is a huge help, but I still have to pick just one to participate in on mobile..)

Slack isn't perfect, but at least all the native clients will let me be logged in to 5 teams at the same time. (And no, opening multiple browser tabs is not an appropriate solution - it doesn't work at all on iOS, for example.) And obviously, this is something IRC does a great job of as well.

Re: Please don't use Slack for FOSS projects

#123

It's not as simple as "just use IRC". Even in cases where an IRC channel is both available and relatively well-promoted, some communities still seek out other tools. The first example that comes to mind is Reactiflux, a rather large React.js community that recently moved from Slack to Discord[1][2], another closed source app that will probably stay that way[3]. To me, the fact that a community of tech-savvy developer…

For context, we've always promoted IRC for real time communication on React. I encouraged people to setup other mediums for communication and many people attempted but only one took off: Reactiflux on Slack. The official way is still IRC on the website but most people are using Reactiflux which is pretty incredible.

Now, we got the bad news a month ago that we've been kicked off of Slack :( So, I started looking at all the options and frankly, all the alternatives I tried had a really bad user experience. Sure, they had all the features of Slack but the polish was not there.

Until I randomly stumbled upon Discord, a chat app for gamers. It turns out that it does everything that we used Slack for, has better perf than Slack... Before we even made the switch officially, people were already using it organically in favor of Slack which is a testament of its qualities.

I highly recommend using Discord for your open source project!

Re: Please don't use Slack for FOSS projects

#124
post #65
post #10

> Problems with IRC that Slack solves Main thing that Slack solves as far as I'm concerned is a great and uniform client on every platform. Don't get me wrong, I love irc. This is where I started learning everything I know about computer. I tried many times to get various team on it and it always failed. I think it's mainly because the learning curve is too big for non-technical/busy people, and that there's no good…

I think it's that it never gained a groundswell in the US. In Europe, and I can think of sweden and norway in particular, there were all sorts of completely technically illiterate people on IRC. Their friends just showed them how to download the client and connect.

I remember using IRC in the early 90s here in Norway, there was basically a channel for every municipal, school, social group etc. Even my mother used it.

That anyone find it hard to use is flabbergasting to me as it is a matter of opening a client, entering a nick and selecting server. With the web IRC clients it's even easier I guess.

I still hang out in several of the channels from my early days :)

Re: Please don't use Slack for FOSS projects

#125
post #65
post #10

> Problems with IRC that Slack solves Main thing that Slack solves as far as I'm concerned is a great and uniform client on every platform. Don't get me wrong, I love irc. This is where I started learning everything I know about computer. I tried many times to get various team on it and it always failed. I think it's mainly because the learning curve is too big for non-technical/busy people, and that there's no good…

I think it's that it never gained a groundswell in the US. In Europe, and I can think of sweden and norway in particular, there were all sorts of completely technically illiterate people on IRC. Their friends just showed them how to download the client and connect.

Yeah, nothing about IRC is intrinsically difficult. There's some things that are much easier on Slack, like archive search, but how many people actually use that?

If you tell people something is hard to use, they'll believe you. If you tell them how to use something, they'll use it...

Re: Please don't use Slack for FOSS projects

#126
I'm responsible for a medium to large FOSS project. I noticed that Wordpress had recently moved to Slack, and asked someone I knew over there how engagement had changed after the move.

He reported they saw about a 10x increase in users moving to Slack (100 -> 1,000). (https://twitter.com/HypertextRanch/status/627122747664113664)

I get the arguments about not using it, but my priority is providing the best tools to the community to enable them to work together productively, as well as providing the most effective forum to encourage more people to get involved. How can I ignore that sort of order of magnitude increase in the number of people who can engage in real-time with the project?

Re: Please don't use Slack for FOSS projects

#127
None of the problems listed seem like problems to me. All of the solutions that make IRC fill this role seem like they will require more work and time to set up than I am to put in just to get communication set up. Slack just works. So unless I am going to be working on something highly sensitive that I can't trust a third party reading about, I'm going to keep using it.

Wouldn't the best solution be to adapt one of the existing open source slack clients to use a local server? Then we have all of the feature set and none of the security and privacy concerns.

Re: Please don't use Slack for FOSS projects

#128

Wouldn't Slack be ideal for FOSS projects? My fear would be of losing sensitive data when using Slack, but with a FOSS project this isn't an issue. Slack is a tool, like a debugger or IDE, which aren't all open source. If you are working on a government project with secret clearance, then these issues make sense. Otherwise, the article feels like it has more of a "whippersnapper" message.

I disagree with some of the things in this article (mainly that IRC is necessarily better for your company) but Slack isn't ideal for FOSS projects. It's a very long way from ideal.

Main reason being: Slack is a company and as such they can change their policy at any time. There isn't any specific right granting FOSS projects any status. Slack can ban the users they want, can deny access to accounts they want, they can be sold to other companies and can be bankrupted, bring it all crashing down.

Slack isn't a tool, it's a service. It's not in any way whatsoever like a debugger or IDE, even if those may be closed source. A tool is something you have and can use. You might not own its manufacturing but you own its potential use. Like a hammer you didn't make but is yours to do anything with. You can use it a million times if you want.

Slack is someone else's hammer that you pay to use. That's a service. The fact that they allowed you to use it for free for some undefined period of time doesn't mean you own it or dictate any rule of its use. It's still their hammer. They can stop you from using it at any point in time.

FOSS projects are supposed to be inclusive, open, transparent and fully decided by an owner or a community. Giving away control to a third party with no contract whatsoever is a terrible idea and a good way to break many of those premises.

Slack is being used for FOSS because of the failings of IRC noted by others in this thread, but that doesn't mean it's a good idea. Certainly not when the audience for Open Source is already very accustomed to IRC.

Slack is great for the turnkey solution it is, it offloads that IRC configuration you'd have to do, and it's easier to introduce non-technical people to. It's good for paying customers that have a clear contract with the company and as such gain certain rights. It's not, in any way, ideal for other cases. It might fit them, but it's not a great idea.

Re: Please don't use Slack for FOSS projects

#129

IRC kind of sucks. The experience is worse. That's why people keep making these different tools - Campfire, HipChat, Slack. It's not just a technical thing. It's an experience thing. IRC is technically fine, just way too nerdy to be main line of business software these days.

Twitch.tv is using IRC in their main line of business (their chat). It seems to work fine for them and it is easy to write custom bots etc for it as it is based on an open protocol.

Re: Please don't use Slack for FOSS projects

#130
If IRC were good enough to handle the needs of small software company communication, people would use IRC. Sitting here pretending everyone just doesn't know about a 20+ year old technology is comical.

The "IRC Features" section bugs me, too. Unless you run a private IRC server IRC has a long, tortured history of design-based security difficulties. Gone are the days of netsplits permanently owning channels, but the so called "distributed" design of IRC makes it very brittle and easy to deny service.

Oh, and did you know that with modest, low volume channels (>200 Slack also offers a logging service that, for what it's worth, is configured correctly and secured by default. For organizations with 1-3 technical staff, maintaining and securing a reasonable approximation of Slack's feature is probably time better spent working on your product.

IRC is a classic example of the "it's broke but we don't fix it because it's familiar" mentality of old school services. While it may be a good choice for running low-volume (But if you're genuinely concerned about security, HipChat will sell you a whitelabel product you can host and monitor and its setup is quite good for what it is.

Post reply on HN