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

451–460 of 536 posts

Re: Why Slack is inappropriate for open source communications

#451

Post by ptman »

PaulHoule wrote: post #47

What drives me nuts is that there are so many of these things. I know groups that (for business or pleasure) use Slack, Discord, Skype, Google Hangouts, IRC, etc. All of these clients are a bit more obstrusive than they need to be in terms of pop-up notifications, software updates, cpu, memory, transfer, etc. They all screw up enough that there's always a little apprehension that something will go wrong when you get…

I think one of the strengths of matrix (in addition to federation) is first-class bridging. I already communicate to several IRC networks, gitter and slack via matrix. I only have to use one matrix client and it enables me to communicate with people on several different networks/services. No monstrous electron apps that load the web UIs of several services in different tabs. The server-side in matrix handles the bridging and I can use any matrix client I like.

Re: Why Slack is inappropriate for open source communications

#452

Post by Clownshoesms »

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…

I agree it seems like a dark ages, but it was inevitable software would move to a rent seeking position in this environment.

VC's want their income tap. These yachts don't run themselves!

Re: Why Slack is inappropriate for open source communications

#453

Post by milesrout »

ktta wrote: post #430
milesrout wrote: post #400

Earlier quoted context omitted.

>Unless you have a mobile keyboard you'll have to search for emojis yourself and paste them. Emoji's will always be an after thought unlike in Matrix[1] and riot[2]. What a load of crap. Emojis are simply sequences of Unicode code points . IRC supports UTF-8. A client with a button that brings up a big list of emoji is trivial to build. >You're right, it has nothing to do with the protocol. It was never about if it w…

> trivial to build The point was it isn't built, where as there's auto completion support for emojis which wouldn't even need that "trivial" software. That's in the matrix's sdk. If it's so trivial, please, build for the IRC community. I use hexchat on my desktop and weechat on the server. Would you mind building me one if it is trivial? > That's irrelevant. You claimed that the simplicity of the IRC protocol was som…

Slack is a widely used product, but its use is tiny compared to IRC. IRC isn't just tech people, it's very widely used by a really huge, diverse range of people.

Your original comment said 'the days of simplistic IRC protocols are gone' and then you gave a bunch of features with the implication that simple protocols can't handle those features.

I simply explained why those features are absolutely implementable over simple protocols, and also why IRC isn't actually a simple protocol - DCC is an example of something not at all simple in IRC.

I didn't say that IRC itself, in its current incarnation, solves those problems.

Ultimately you're basically saying 'I want a couple of features and because slack provides them, I'm going to justify my use of slack by comparing slack to the least featureful chat thing out there: IRC'. IRC's strengths aren't its features, it's its openness, familiarity, hackability, conceptual simplicity and community control. In fact, the things people that like IRC dislike most about it are the few parts that aren't open, hackable, simple or controlled by the community.

I don't particularly like IRC as a protocol. Maybe its time has come, maybe the replacement will be called 'IRCv3' or 'IRCv4' or called something else. Whether that replacement is called 'IRC' is not important. What is important is that it remains open (in spirit and in practice), hackable, simple and controlled by the community. Slack replaces a distributed, network-failure-proof system (IRC) with a centralised, corporate-controlled, paid, closed, proprietary solution. That's the worst possible collection of properties. Yeah you can search messages, yes it has a nice user interface, but that's about it.

>The point was it isn't built, where as there's auto completion support for emojis which wouldn't even need that "trivial" software. That's in the matrix's sdk. If it's so trivial, please, build for the IRC community. I use hexchat on my desktop and weechat on the server. Would you mind building me one if it is trivial?

I can't tell if this is a joke. This is literally:

1. map names to emojis 2. autocompleting input field on those names 3. append a couple of bytes to a string

This is 100% purely a user interface feature, it has nothing at all to do with the server or the protocol. You could implement this for literally any chat client that supported UTF-8 quite easily.

https://blog.irccloud.com/emoji/

Re: Why Slack is inappropriate for open source communications

#454

Post by milesrout »

joejev wrote: post #391
ravenstine wrote: post #355

Earlier quoted context omitted.

Ok, that's interesting. My impression from watching his talks is that he does not consider the two ideas as synonymous, in that a software can technically be closed-source but have licensing that is libre-free so that it can be used by whomever however. But perhaps I got it wrong.

It is the other way around: just because the source is available free of charge does not make the software free as in freedom. For example, there are licenses that prohibit you from running the software for commercial use even though you have access to the source. This would not fit the FSF's definition of free software because the user should have the right to use the software as they wish.

Those licenses also aren't open source. 'Open source' doesn't mean 'you can view the source', it means you can view, run, compile, modify and distribute the source, and distribute modified copies.

Re: Why Slack is inappropriate for open source communications

#455

Post by zAy0LfpBZLC8mAC »

Arathorn wrote: post #425
zAy0LfpBZLC8mAC wrote: post #387

Earlier quoted context omitted.

> Your justification of why "it's essentially impossible to reasonably port it to a sensible transport protocol" appears to be an explanation of how one could reasonably port it to a sensible transport protocol (JSON over some flavour of socket) ;) Except for the fact that it's necessarily redefining quite a bit of the protocol, also necessarily further complicating any possible universal implementations because this…

From my perspective, the defining bit of Matrix is the data model (eventually-consistent decentralised Merkle DAGs), the schema, and the semantics of the API - e.g. what arguments do you pass when you paginate? what data do you get when you sync? how do you tell it where to sync from? etc. I genuinely don't care whether you do RPC via an HTTP PUT, a COAP PUT, an MQTT Publish, or some funky custom RPC of your own devi…

> From my perspective, the defining bit of Matrix is the data model (eventually-consistent decentralised Merkle DAGs), the schema, and the semantics of the API

Great, and where is that actually specified?

> or whether you encode the data as JSON, CBOR, BSON, protobufs or whatever

Except that you still need at least a sort-of JSON generator for the signing stuff, thus only adding bloat by using a different format?

> It's just a transport!

Except that it isn't. HTTP is "just a transport" for JPEG files. You don't need to touch JPEG encoders and decoders to swap HTTP for SFTP, that is what "just a transport" means.

> We want people to propose alternative transports!

Which is just idiotic, both because you make it unnecessarily difficult if that really is what you want, and because a federated system that doesn't have a common transport protocol just doesn't work. And if you need to expose an HTTP engine for compatibility anyway, it would be just braindead to add further complexity on top of that.

> I guess you really don't like HTTP - I'm amazed you're willing to use it to communicate on HN!

I don't like unnecessary complexity because it makes it unnecessarily hard to build secure software. The HTTP engines in browsers are probably some of the best-audited ones out there, so it's somewhat acceptable to use them ... but even they have their history of vulnerabilities. The last thing we need is a new large distributed system that's creating even more botnet material than we already have.

> it's just a shame it doesn't seem to be particularly well-founded.

lol

Re: Why Slack is inappropriate for open source communications

#456

Post by mycloud »

newsat13 wrote: post #319
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…

A Cloud machine look like https://cloudron.io . It's distributed and they have the button you seek. Many github pages have this button already: https://github.com/RocketChat/Rocket.Chat#cloudronio , https://docs.nodebb.org/en/latest/installing/cloud/cloudron.... , https://kanboard.net/documentation/cloudron , https://github.com/wekan/wekan#supported-platforms to name a few.

Using Cloudron since a week now to host Rocket.chat for similar reasons mentioned in the article. Can totally recommend it!

Re: Why Slack is inappropriate for open source communications

#457

Post by frik »

zAy0LfpBZLC8mAC wrote: post #346
frik wrote: post #266

For open source projects: offer Github issues, IRC for chat and a proper forum like phpbb or a more modern forum like discourse (or one of the clones) and/or a mailing list.

> offer Github issues Why a proprietary issue tracker that requires that people make an account with them in order to communicate with you?

Replace Github with your favorite modern bug tracker. Some very old software Bugzilla/Trac/Confluence are not modern, have a bad UX and kind of off-putting.

Re: Why Slack is inappropriate for open source communications

#458

Post by arximboldi »

Taek wrote: post #272
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…

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…

I agree about blockchains, but when talking about P2P solutions in general, many scale way more naturally than centralized services.

When I read on HN the engineering posts from Netflix about the enormous engineering efforts required to make their video service scale, I can't help but think: that's a solved problem, Emule/BitTorrent have been providing good access to video for decades! Of course, there is the "monetization" issues... (but there is also on Netflix, good luck finding non-US or indie content there.) On other side of the spectrum, look at Syncthing vs Dropbox.

The thing about Slack is particularly crazy because even their client does not scale too: it was too slow to be usable daily in my 7-year old computer. A freaking chat app!

Admittedly, I hesitate about whether the best solution of the OSS community is to jump and try to replace all those things. At the same time, the kind of software I enjoy most both developing and using is desktop software. That is kind of software that is uses to empower our creativity. While the proprietary software world moves its engineering power to the cloud, we can still use it to build tools that help people expand their imagination. I am thinking on helping making Gimp and Inkscape and Blender and coding tools all those better, but also making new tools that we have not thought of. I think there is still a lot of potential for exploration, creating new interaction models, etc. in this area that we have not explored yet. Sadly for the libre software world, Apple still gets a lot of developer mindshare in that area too...

Re: Why Slack is inappropriate for open source communications

#459

Post by INTPenis »

jsat wrote: post #157

Mattermost is an excellent open-source Slack clone. It would be interesting if someone could add a feature to publicly host chat logs for indexing by public search engines.

I've been testing mattermost for a while but recently came across rocketchat and on the surface it seems much better. But I haven't tested it yet.

It remains to be seen if it has proper AD integration for example.

Re: Why Slack is inappropriate for open source communications

#460

Post by zAy0LfpBZLC8mAC »

frik wrote: post #457
zAy0LfpBZLC8mAC wrote: post #346

Earlier quoted context omitted.

> offer Github issues Why a proprietary issue tracker that requires that people make an account with them in order to communicate with you?

Replace Github with your favorite modern bug tracker. Some very old software Bugzilla/Trac/Confluence are not modern, have a bad UX and kind of off-putting.

No, really, replace github with nothing at all, they are all equally off-putting, because the concept of offering (only) a user interface and in particular accounts to external parties is stupid in the first place.

Offer an email address for bug submissions.

Of course, feel free to use a bug tracker internally if you like, and possibly even with a public user interface for people who want to use it, but a user reporting a bug to your project should normally not need more than a working email client.

I have an email client that's configured to fit my needs and that allows me to efficiently process lots of emails and to write and manage outgoing messages in a single unified interface, and that's all that's really needed for most bug reports, so don't try to waste my time by forcing me to learn your user interface of choice that's not going to have the features that I want to have anyway.

Post reply on HN