Live data from Hacker News

Please don't use Slack for FOSS projects

drewdevault.com

471–480 of 499 posts

Re: Please don't use Slack for FOSS projects

#471

Earlier quoted context omitted.

IRC is just a well-established and battle-tested server/client protocol. I'm eager for the day when a competing open source server/client protocol emerges and takes over. I imagine all it would take is a really good reference implementation server and client that everyone can just start using, right?

I certainly think having an open source reference implementation for a 21st century (and by that I mean having features like Slack or Yammer or other popular closed source packages) implementation of a successor to IRC would be the minimum starting point.

From what I've been able to gather, the open project that is most like Slack, but also offers self-host, decentralization is Matrix:

  http://www.matrix.org/
There's also Zulip, which as far as I can gather, is battle-tested, but does not have a strong story for federated servers, nor a good out-of-box experience for really small servers:

  https://github.com/zulip/zulip
Finnaly there's https://tox.chat -- which doesn't have a lot of the things IRC/Slack has (it's focused around p2p chat) -- but extensions are planned, for eg. persistent group chat. Perhaps most excitingly "new" of the three, which predictably is both a good and a bad thing:

  https://wiki.tox.chat/users/faq#what_is_tox
For those that "want Slack", but self-hosted, open/free software server -- I think Matrix is the most viable alternative -- if IRC is seen as not good enough.

I've not included any XMPP servers, although eg. Prosody should be simple to set up and use -- because, apparently like IRC, it has too many problems for people to actually embrace out-of-the box XMPP for team chat. The fact that most big public services that host XMPP tend to favour anonymity probably has something to do with the fact that getting reliable server-side message logging and off-line messaging is still not as easy as one would expect, for any(?) of the big free XMMP daemons (or indeed support client side).

[ed: Matrix also have some support through bots/plugins for IRC bridging: https://github.com/matrix-org/matrix-appservice-irc ]

Re: Please don't use Slack for FOSS projects

#472
I think you would be better off using a full fledged forum. Then use a chat (IRC or whatever) on top of that for real time communication. Where the important stuff goes to the forum, and general talk in the chat.

Re: Please don't use Slack for FOSS projects

#473
post #69

Some open source self-hosted alternatives to Slack: * Rocket.Chat ( https://rocket.chat/ ) * Zulip ( https://zulip.org/ ) * Mattermost ( http://www.mattermost.org/ ) * Let's Chat ( http://sdelements.github.io/lets-chat/ ) Oh, and by the way, you could have your own Rocket.Chat instance running in Sandstorm in about 30 seconds: https://sandstorm.io/apps Update. And I would love to see a modern federated chat protocol…

> Update. And I would love to see a modern federated chat protocol to take off. Something like http://matrix.org/ . XMPP?

On my last evaluation, I found the two most interesting to look at matrix and tox.chat. But in the context of a slack-alternative, matrix is definitely the one to look at. Also has an IRC bridge: https://github.com/matrix-org/matrix-appservice-irc

As for XMPP, I think it is still entirely viable as an alternative to using a brand new protocol and brand new clients and servers. But if you want solid off-line messaging, server-side logging and scalable group chat -- there aren't any out-of-the box combination of free/open servers and clients that will work, as far as I've been able to figure out. I assume one would want a solid command line client, solid gui clients for Windows, OSX, Linux/BSD, Android, iOS and Windows phone, along with a good web client.

I don't think you can pick-and-choose a XMPP server and clients that will provide all that, today. It is certainly possible to make that, standing on the shoulders of various open projects -- but the effort would be anything but trivial. I'd be happy to be proved wrong, though!

Re: Please don't use Slack for FOSS projects

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

> basically all the features IRC/Slack does.

First, let me say that I'm really happy zulip was opened up, and grateful for you and your team to support it.

But does Zulip support server federation? Obviously slack doesn't allow self-host, so if slack is the alternative, that doesn't really make much of a difference. But that is one feature that http://matrix.org/ does support.

Re: Please don't use Slack for FOSS projects

#475

Hacker News: is closed source is a walled garden requires a "Y Combinator" account to communicate Most people don't use software because of the driving philosophy behind it — they use it because it solves a problem of theirs. If a tool is the best one for the job, you should use it. And if Slack has a substantially better UI for communication, maybe developers of IRC clients should try to build a better UI rather tha…

In all fairness, while the currently running incarnation of HN isn't open, earlier versions of Arc and hn/news (along with forks) is open source, eg: https://github.com/arclanguage/anarki/

And there are clones, like lobste.rs:

https://github.com/jcs/lobsters

Then there's the API, that allows anyone to export data. So while I get your point, and agree with it to a certain extent, it's also not entirely fair.

Re: Please don't use Slack for FOSS projects

#476

To add to this, don't use Gitter for FOSS projects either. I've been seeing lots of projects abandon IRC for Gitter.

In addition, Gitter is open source, has many client apps and, it, or really need, a irc bridge

I'm sorry, the Gitter server part is open source? AFAIK it's a closed source service?

Re: Please don't use Slack for FOSS projects

#478
post #17

Main problem with IRC is that it's not "always on" and I really need this feature. Sure you can use IRCCloud or SSH/Screen into a server, but they both cost money while Slack is free.

You can use Quassel ( http://quassel-irc.org/ ). It's like ZNC without the setup

But then you loose messages when your quassel-core goes down (or loses its network access)?

Re: Please don't use Slack for FOSS projects

#479
post #197

Earlier quoted context omitted.

Are these limitations in the protocol, or just in the network, especially freenode? If someone were to run a paid, $5-a-month to run a channel with over 20 users IRC network, would they be able to address the difficulties of freenode and EFNet before it? Would SILC fix anything?

Why would this even be desirable?

Maybe because it's even cheaper than paying the monthly subscription of a single slack user?

Re: Please don't use Slack for FOSS projects

#480
post #359

Earlier quoted context omitted.

And you used to be able to get an RSS feed from twitter. Things in walled gardens tend to have a habit of disappearing when interoperability no longer seems to be in the proprietor's interest.

At which point I'll reevaluate the use of the application and potentially move elsewhere. FOSS developers pull these kinds of things all the time as well. Look at the cessation of interoperability after Lennart Poettering decided to "deprecate" consolekit in favor of the non-interoperable systemd. Or they'll stop development of software, like RedHat decided to cease development of the Insight Debugger they gained con…

And you were fully welcome to continue the development of ConsoleKit if you wanted. Slack, on the other hand, can hold all your important logs & metadata hostage.

Completely different situations. Neither of your examples could sanely be described as shady or underhanded - neither of them gave the producer a business advantage it wouldn't otherwise have. FOSS developers don't owe anything to you - they don't have to continue to develop your favourite feature for the rest of their lives. They do however give you the freedom to do that yourself.

Post reply on HN