Live data from Hacker News

Why Slack is inappropriate for open source communications

dave.cheney.net

281–290 of 536 posts

Re: Why Slack is inappropriate for open source communications

#281
post #213

A great alternative to Slack, in the spirit of IRC, is matrix[1]. It has lots of clients, and a great vision. You use an online client called riot[2] which uses the matrix protocol. There are other clients available[3] including desktop clients. There's E2E encryption coming to more of the clients which is inspired from signal protocol (double ratchet part of it specifically), without Forward secrecy so as to maintai…

Why is there not a web based IRC app?

There is. A bunch in fact.

http://mibbit.com/

https://kiwiirc.com/

or, site-specific:

https://webchat.freenode.net/

http://chat.efnet.org/

Re: Why Slack is inappropriate for open source communications

#282

Earlier quoted context omitted.

> Neither quasseldroid or Lounge have push notifications or searchable messages yet, so they seem to be pretty identical feature-wise. Quassel actually has both of those, but they’re still in separate projects atm: https://dl.kuschku.de/videos/2016-09-16_04-03-36.mp4 , and will only be integrated into the main codebase in the next version. That said, the performance of Quasseldroid, due to the nature of the thing, is…

Quassel has them, doesn't mean Quasseldroid does :P And I don't think you can say due to it's nature it's faster... I run Lounge in 20+ active channels on my iPhone SE and it runs perfectly. Native != more performant (and if the code base is as bad as you say I wouldn't expect it to be).

The bad part of the codebase is bugginess, and RAM usage. Especially because it always keeps all messages in RAM.

But what I consider a bug is already the best case scenario for the web client.

And 20+ active channels is nothing.

I'm in 460 active channels, with combined 40'000 users, and I get about a hundred to 200 messages a minute, while using the app on 64kbps connection.

(That's my test case for what should usable)

And quasseldroid already has code for those two, and a rewrite is almost done, I'm just waiting for the core changes to happen, and then release version 2.0

Re: Why Slack is inappropriate for open source communications

#283

Tangentially, I don't get how developers on the one hand strive for private offices and no (physical) interruptions, but on the other want to communicate through chat channels. Maybe these are different people altogether, and I'm just getting the wrong impression. But personally I prefer a little personal interaction over a long chat.

I don't have to drop (as much of) my mental state in order to communicate via chat. It's asynchronous, so I can finish typing out whatever I'm thinking about, or looking for whatever I'm trying to find, kick off a build, etc., and then turn my attention to the chat window and bang out whatever comes next in the conversation. Once written, I can switch right back to whatever I was doing - I type quickly, so it's usual…

> It's asynchronous

I find the same to be true on (small) Slack (or similar) channels. Which is funny given that Slack being synchronous is one of the two main points of the link.

Re: Why Slack is inappropriate for open source communications

#284
post #262

Earlier quoted context omitted.

> Well we are moving to a web first world, Too bad much of the web stinks, with terrible responsiveness and usability and impose those results through bloated protocols and spaghetti architecture on anything that tries to interface with them. Multiple times on caltrain I've had people ask me how I'm on the internet as I have meetings on IRC without even noticing the connectivity has gone poor -- while their webchat s…

Yeh in this vain, I'll add that I have very experienced colleagues who are so fed up with the current internet that they don't even fight net neutrality, and would rather another protocol rise in its place.

[deleted]

Re: Why Slack is inappropriate for open source communications

#285
post #222

Earlier quoted context omitted.

I don't think it's a generational thing either. I know how to use IRC and how to connect with it. The problem is the difference in the amount of energy demanded by the set-up process. Connecting to Slack is extremely simple and I don't have to fiddle with the settings in order to get a decent experience. Compared to IRC, I have to: - Figure out how to configure my client. - Figure out how to interact with the user ac…

> I know how to use IRC and how to connect with it. > [...] > - Figure out how to configure my client. > - Figure out how to interact with the user account and moderation bots I disagree with your initial claim. :P Those are irc basics, things you only have to learn once, and there is documentation online and on the web. It's worth it to spend the time to learn a tool that you can use throughout your profession, even…

That still ignores the existence of a huge usability problem. The investment of time may pay off in the long run, but IRC is large enough investment (and ongoing maintenance, ZNC doesn't just take care of its self forever) that people will take a route of less resistance when presented.

This all reminds of a few years ago when folks were banging on about how we needed to use Gitorious instead of GitHub for Open Source hosting. Gitorious is dead now and it wasn't until GitLab came along and recognized the usability problem that we got a viable Open Source alternative.

Re: Why Slack is inappropriate for open source communications

#286

Forums. I don't know why the internet got tired of them, even when they sometimes fit the bill so well. Slack is chat. Mailing lists are far too outdated. Forums are good, and some good people out there are still developing them.

They're generally fucking terrible in terms of UI. I much prefer Google Groups over older forums. Discourse is even better but there's no easy way to setup a forum for free. The last time I looked into it it would be roughly $10 a month for a DigitalOcean droplet to run a small forum, but that was more than I wanted to spend myself. And accepting money is a non-zero amount of work too.

Probably the main reason why Slack – and Gitter, and IRC too still – are widely used by open source projects is that they're free, financially, and mostly free in terms of maintenance.

Re: Why Slack is inappropriate for open source communications

#287
post #236
post #233

Earlier quoted context omitted.

"in the spirit of IRC" is a bit of a stretch. This is all a massive blob of web technologies which contrasts IRC's minimalism and it's lightweight clients written in C. It doesn't appear to require any specific service though so at least it has that.

Well we are moving to a web first world, and passing the terminal days of IRC. Trying to avoid web technologies isn't going to do anyone good. Best we can do is try to make them better are secure. Light weight clients can be written in C if you want. There's nothing that needs a web browser Here's the spec if you're interested[1]. There's also a weechat script if you want a command line client[2] [1]: https://matrix.…

This comment made me throw up in my mouth a little.

Re: Why Slack is inappropriate for open source communications

#288
post #272

We are, temporarily, in a kind of dark ages of end-user open source software. The reason is that we shifted from software-as-a-product to software-as-a-service. With the old upload-and-forget model of software distribution, you could put a tarball on a free FTP site for a few pennies, and then a million people could use it, or one person could, and you wouldn't have to lift a finger. A million people could fork your…

Blockchains don't really solve that problem. Scalability is a huge issue, and if you are trying to cram several apps onto the same blockchain they are all going to have scaling issues simultaneously​. It isn't a product maturity thing either. At a theoretical level, we don't know how to make blockchains scale. Every node needs to process every transaction, and we don't know how to get around that. Would be great to m…

The N^2 problem of Bitcoin and Ethereum is solvable through sharding. I agree that on-chain scaling is impossible (and the two projects differ in their taste for decentralization vs scalability at their core), but the build out of workable sharding solutions with reasonable trade-offs and a workable topology are underway by both camps. It's just going to take longer than I think a lot of people who bought in with the pay-per-service use case would prefer.

In the case of chat, I'm convinced that the ability to register data in a shared, immutable store like a blockchain with many stakeholders of disparate interests will be valuable to that end even before microtransactions start being sent with every packet on the internet.

Re: Why Slack is inappropriate for open source communications

#289
post #68
post #52

It's frustrating that the choice seems to be between modern closed tools like Slack and Hangouts and antiquated open tools like IRC and mailing lists.

Question for you: I hear this a lot, in terms of older tools being considered obsolete. Other than the natural human tendency towards novelty and the network effects, what, exactly, is obsolete about mailing lists or IRC? What features are missing in IRC that Slack has for synchronous discussion? (I'll start: animated dancing pigs out of the box and the need to write/plug in your own archiver.) What limitations do ma…

The primary benefit of 'Slack' over "older tools" is that the former are free – not just financially but in terms of how much time, effort, and energy is required to set them up and maintain them.

Sure, there's lots of freely available alternatives, but even tiny (but non-zero) costs in time and money are the difference between widespread usage and relative non-use.

I setup Gitter on a GitHub repo for a project by clicking a button and accepting a pull request that Gitter auto-generated for me to add a link to the repo's Gitter channel in my project's README. That's the competition that every older tool is failing miserably to meet, let alone exceed.

Re: Why Slack is inappropriate for open source communications

#290

We are, temporarily, in a kind of dark ages of end-user open source software. The reason is that we shifted from software-as-a-product to software-as-a-service. With the old upload-and-forget model of software distribution, you could put a tarball on a free FTP site for a few pennies, and then a million people could use it, or one person could, and you wouldn't have to lift a finger. A million people could fork your…

Along those lines, it sounds like Sandstorm may be a fit for what you're thinking of. It's generally more federated than a totally distributed system, but provides nice mechanics for packaging web apps, distributing them to others, moving from one server to another, sandboxing them, etc. It makes setting up and running web apps as easy and safe as downloading an app from an app store.
Post reply on HN