Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Slack is inappropriate for open source communications

dave.cheney.net

Post reply on HN
Print view View original

481–490 of 536 posts

Re: Why Slack is inappropriate for open source communications

#481

Post by wtbob »

panic wrote: post #356
erikpukinskis wrote: post #260

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…

What if we had an easy-to-use home server you could just plug in and start running "apps" on? Being able to download and run services on hardware you control would avoid some of these problems.

In the long run, I think that's the right location for things like IoT devices: there's no reason for my thermostat to dial back to the cloud when it can just connect to my central computing unit in the closet, exactly like it connects to the central heating and air conditioning units in the closet. Normal people don't mess with HVAC, but they can if they want to (and it's remarkably simple!); likewise I don't imagine normal people would mess with their home system, but they'd be able to if they wished.

Re: Why Slack is inappropriate for open source communications

#482

Post by ryanbrunner »

rco8786 wrote: post #89
alpha_squared wrote: post #83

Earlier quoted context omitted.

I completely agree with this. I'm part of a group that's trying to help people in the local community learn programming and we're using Slack to chat outside of any scheduled sessions. We're at over 1000 members in Slack now and are seeing messages disappear before the two-week mark. We don't collect any money from our members and Slack's pricing model makes it unfeasible for us. At this point, Slack's search feature…

With respect - Slack is a business that runs on a freemium model. You can't expect them to handle your (large) user base for free just because.

That still doesn't make Slack an appropriate choice for open source. Even if the project didn't mind paying, Slack's business model is wholly incompatible with the traffic that an open source project would expect (lots and lots of not very active users)

Re: Why Slack is inappropriate for open source communications

#483

Post by unlmtd »

EvanAnderson wrote: post #402
ryanbrunner wrote: post #337

Earlier quoted context omitted.

You're arguing semantics. What most people are looking for is a "service bureau", and they use the word software to describe that. People don't want to manage their own infrastructure, and right now will happily pay for someone to take care of that for them. Open source isn't wholly incompatible with this model, for sure - you can still have open source code that can be hosted by the developer for a fee. But the spec…

I'm arguing semantics because I believe the semantics matter. I feel very strongly that decentralized computation and software freedom are powerful forces for good. Conflating hosting and software plays to an agenda of curtailing individuals' and businesses' ability to self-host and to have freedom. I think this agenda is driven by hosting providers' profit motive primarly, but it plays into agendas of unrelated part…

Well said. Ideas are not scarce, only the physical realm is. Its not hard to envision the coder being paid to code; when no more code is being written, there are no more checks coming in. Nobody is owed anything based on past accomplishments. In the information age, reputation is _everything_.

Re: Why Slack is inappropriate for open source communications

#484

Post by aeorgnoieang »

zAy0LfpBZLC8mAC wrote: post #342
aeorgnoieang wrote: post #289

Earlier quoted context omitted.

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 cl…

> 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. You are ignoring the costs that come from lock-in (inflated prices, lack of innovation) and migration in case the proprietary solution shuts down. That's the psychological tendency of humans that these companies exploit.

Lock-in is a cost of any solution tho. Whatever solution one picks, it's going to cost time and energy and, probably at least indirectly, money to migrate to another.

Non-proprietary solutions 'shut down' too, e.g. because the unpaid developers burn out and quit.

A lot of people reasonably believe that 'free' solutions are inherently riskier, all else being equal, because (generally) no one is being compensated to maintain and support it.

It's tradeoffs all the way down!

Re: Why Slack is inappropriate for open source communications

#485

Post by compuguy »

ktta wrote: 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…

Rocket Chat is a great (open source) slack alternative: https://rocket.chat/

Re: Why Slack is inappropriate for open source communications

#486

Post by compuguy »

VLM wrote: post #50
cortesoft wrote: post #37

Earlier quoted context omitted.

A better IRC client isn't going to provide chat history.

Just run your IRC client in screen/tmux like we've done for a quarter century. The real advantage of slack isn't even client its stuff like massive logging for e-discovery and single sign on integration. Admittedly not terribly appealing for FOSS but once you use it at work... Also integrations in general are smoother in slack than in IRC. Someone has already written the bot and its a click away to install and it gen…

Or you can use a web based interface like the lounge.

Re: Why Slack is inappropriate for open source communications

#487

Post by unlmtd »

srssays wrote: post #380
zAy0LfpBZLC8mAC wrote: post #350

Earlier quoted context omitted.

> They aren't unnecessarily complicated They are, for what matrix intends to do.

Programming sucked before HTTP+JSON became the lingua franca of machine communication. Being able to use any programming language with modern HTTP-based protocols is a real luxury. Before, you could only use a programming language if had a production-ready implementation of the protocol you wanted to speak. Otherwise you would spend the next weeks or months tediously writing one. This was so crippling that XML actual…

You're both right. Yes http sucks. And x86 sucks even more. But it's all we got right now. So http is a bridge so we can finally all _communicate_ ! Then, when we're all on matrix, we can work together on designing a better ipfs system, with a nice riscv SoC.

Re: Why Slack is inappropriate for open source communications

#488

Post by Arathorn »

kuschku wrote: post #472
Arathorn wrote: post #389

Earlier quoted context omitted.

So, this was a design flaw in how matrix-js-sdk was originally implemented - it simply didn't cache any state whatsoever locally, so every new launch meant re-syncing the whole world to the client. This can obviously be improved by lazyloading, but for now we've fixed it by caching full offline state in indexeddb - https://github.com/matrix-org/matrix-js-sdk/pull/363 & friends. This speeds up launch time to a few sec…

So, how can I launch a matrix client that has never been used before and chat, with only a dialup connection, in less than 4 seconds? I can do that with IRC. I can do that with all IRC bouncers. And it’s a daily use case for me, and many other users (mobile networks provide free 64kbps network in many places) I’m not saying Matrix is bad, Matrix has some awesome properties (especially regarding encryption). And maybe…

So, worst case this is 4 hits; one to /login (if you don't already have an access token), one to /directory to resolve the room alias to a room ID (if you don't already know the mapping), one to /send to send a message, and one to /sync (filtered to the room you care about, if you're mimicking IRC). In practice, this looks like:

  $ time (
      (curl -s --limit-rate 8K 'https://matrix.org/_matrix/client/r0/login' \
            --data '{"type":"m.login.password","identifier":{"type":"m.id.user","user":"matthew2"},"password":"secret"}' -A '' --compressed &
       curl -s --limit-rate 8K 'https://matrix.org/_matrix/client/r0/directory/room/%23riotdemo%3amatrix.org' -A '' --compressed) &&
       curl -s --limit-rate 8K "https://matrix.org/_matrix/client/r0/rooms/%2eNNtfYnugaAKouPTJdp:matrix.org/send/m.room.message/uuid?access_token=$access_token" \
            -X PUT --data '{"msgtype":"m.text","body":"test"}' -A '' --compressed &&
       curl -s --limit-rate 8K -Gg 'https://matrix.org/_matrix/client/r0/sync' \
            --data-urlencode 'filter={"room": {"rooms": ["!NNtfYnugaAKouPTJdp:matrix.org"], "timeline": {"limit": 20}, "include_leave": false}}'
            --data-urlencode "access_token=$access_token" -A '' --compressed
    ) > /dev/null
  real    0m3.258s
  user    0m0.057s
  sys 0m0.025s
...which signs you in, locates #riotdemo:matrix.org (which has 23 users), syncs 20 messages of scrollback from it, and sends a message, simulating a 64kbps link via curl's --limit-rate, and under your target of 4 seconds.

Now in practice, most Matrix clients (e.g. Riot) currently don't bother to lazyload the initial /sync response with filters, which is why it can be slow the very first time you ever log in on a device. But this is just a matter of optimisation work on the clients - https://github.com/vector-im/riot-web/issues/1846 and https://github.com/vector-im/riot-web/issues/2914 etc. Meanwhile, any app built on matrix-{js,ios,android}-sdk caches sync results locally these days, so the slow initial sync is only ever a problem on the very first login.

So, to be clear: HTTP is inefficient, but in practice it really isn't that bad. Can't wait to spend the time to switch to a proper binary transport system down the line, though, but to do so now would be premature optimisation.

Re: Why Slack is inappropriate for open source communications

#489

Post by Arzh »

aiiane wrote: post #360
Arzh wrote: post #333

Earlier quoted context omitted.

Why do you want a chat client to integrate with gitlab or jenkins?

Oftentimes the 'sync' conversations are either triggered or resolved by commit/build events.

Do you mind expanding on this and showing a full flow? That sounds a little wonky to me but I could be missing something.

Re: Why Slack is inappropriate for open source communications

#490

Post by zAy0LfpBZLC8mAC »

aeorgnoieang wrote: post #484
zAy0LfpBZLC8mAC wrote: post #342

Earlier quoted context omitted.

> 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. You are ignoring the costs that come from lock-in (inflated prices, lack of innovation) and migration in case the proprietary solution shuts down. That's the psychological tendency of humans that these companies exploit.

Lock-in is a cost of any solution tho. Whatever solution one picks, it's going to cost time and energy and, probably at least indirectly, money to migrate to another. Non-proprietary solutions 'shut down' too, e.g. because the unpaid developers burn out and quit. A lot of people reasonably believe that 'free' solutions are inherently riskier, all else being equal, because (generally) no one is being compensated to ma…

> Lock-in is a cost of any solution tho. Whatever solution one picks, it's going to cost time and energy and, probably at least indirectly, money to migrate to another.

That's not lock-in. Lock-in is when you are dependent on a (quasi-)monopoly, not just any potential migration cost.

> Non-proprietary solutions 'shut down' too, e.g. because the unpaid developers burn out and quit.

No, actually, they don't. The point, as above, is that it's not the sole decision of another party when a 'shut down' happens, that is, again, there is no monopoly. First of all, if you have free software running on your own machine, there is noone but you who can decide to just shut it down today, but also, in the long run, you can just take over maintenance of the software yourself, or you can buy/hire a software developer to do it for you, or you can get together with other users of the software to hire a developer.

Also, more generally, with regards to open interfaces/protocols rather than necessarily free software: No, email cannot be "shut down" because "the unpaid developers burn out". And changing my email client or server or hosting service does not necessitate everyone else I want to communicate with to do the same.

None of that guarantees that you can keep using things indefinitely at an arbitrarily low price, but that's besides the point: The price is determined by a market, and not by a (quasi-)monopoly.

> A lot of people reasonably believe that 'free' solutions are inherently riskier, all else being equal, because (generally) no one is being compensated to maintain and support it.

Well, yeah, those people are just clueless, if only because they confuse freedom with not paying for something. If you want to have something maintained, how about you pay for it? How does it make any sense to say that you prefer being forced to pay for something because you otherwise fear that it's not being maintained if you don't pay for it?

Also, none of this has anything to do with open protocols (which was the primary topic of this thread, kindof): Microsoft is being paid very well for maintaining Outlook and Exchange, which is both proprietary software. They still speak SMTP with the rest of the world, instead of forcing everyone to buy Outlook and Exchange to be able to communicate with their users.

Post reply on HN