Live data from Hacker News

Why Slack is inappropriate for open source communications

dave.cheney.net

511–520 of 536 posts

Re: Why Slack is inappropriate for open source communications

#511

Earlier quoted context omitted.

I've just finished my first project using websockets. Coming from the embedded world and bare UARTs plus a little bit of C sockets, I found it hilarious that we've got so many layers to essentially do the same thing that I could do on an 8-bit microcontroller. The critical difference? Speed of development. Websockets was so blindingly quick to get working. Haven't hit the edge cases yet though. If I were doing it wit…

> The critical difference? Speed of development. Websockets was so blindingly quick to get working. Now, is that websockets or is that "not C"? I mean, speed of development certainly is valuable, but I would think that same speed of development only needs little more than an 8 bit µC (or, for that matter, is even possible on an 8 bit µC if the memory size is at the upper end of the range). > Sort of. They're peers, b…

> Now, is that websockets or is that "not C"? > Though I guess NAT also is part of the problem here, which is another of those idiocies of the "modern internet".

The second point answers the first. It is websockets rather than C, because the client is a random user on a mobile web browser.

Now if I could control the other endpoint and were it not for those modern idiocies, P2P could easily be done in C. The problem then becomes discoverability (if you're after true distributed P2P) rather than the actual communications.

(I did port the lightweight lwIP TCP/IP stack to a 16-bit microcontroller and custom RTOS many years ago...)

Re: Why Slack is inappropriate for open source communications

#512

Earlier quoted context omitted.

I've just finished my first project using websockets. Coming from the embedded world and bare UARTs plus a little bit of C sockets, I found it hilarious that we've got so many layers to essentially do the same thing that I could do on an 8-bit microcontroller. The critical difference? Speed of development. Websockets was so blindingly quick to get working. Haven't hit the edge cases yet though. If I were doing it wit…

It's not exactly super hard and complicated to get things working on a microcontroller though. In fact, the first time I did it, I felt it was so much simpler than all this complicated web stuff.

It absolutely is! I love micro-controller development. It's you and the bare metal, not dozens of layers of abstraction that often feel like they're fighting you at every turn.

On the other hand, it's hard to impress with blinkenlights and basic motor driving.

I'm currently going through a phase of thinking on how I could apply functional programming theory and techniques to the next iteration of this embedded system...

Re: Why Slack is inappropriate for open source communications

#513

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 actually think that it's a social and business problem, more than a technical one.

Some SaaS providers already choose to run an OSS product which they develop for their needs but also share (like GitLab, Discourse and Sentry). Others choose not to publish their code, and lock the software to their infrastructure. These are business strategies as well as ethical decisions. Different technologies might change the cost/benefit ratio, but people that really want to be OSS already are.

Re: Why Slack is inappropriate for open source communications

#514
post #437

Earlier quoted context omitted.

IRC as a protocol is very outdated. If I log in at home and forgot out log out at work, I need another username. IRCv3 has a lot of enhancements that should move IRC out of the 1990s as far as a communication protocol, but there's not a whole lot of movement on it. I think FreeNode has some v3 support. We don't have a lot of developers dedicating time to this. I'd love to myself, because it's something the OSS commun…

"If I log in at home and forgot out log out at work, I need another username." You don't log into irc from your work or your home or your anything. You run screen in your shell account and log into irc once and never log in again. Christ - do we need a refresher course here in how to use the Internet for the incoming freshman class of 1994 ?

Kids these days use tmux.

Re: Why Slack is inappropriate for open source communications

#516

Earlier quoted context omitted.

What you're looking for is email. Multi-user chat simulates a real life conversation, and in real conversations it's also awkward to say "hey so going back to what we were talking about 15 minutes ago..." after the conversation has moved on.

No, email is terrible. There's no history. You can't "scroll up" to see what people were talking about. You can't link to another specific email to reference it (yes, there's archive services, but then you have to go dig through an archive to try to find a horridly formatted email to link to, which is completely separate from the normal consumption platform).

This is just wrong.

Re: Why Slack is inappropriate for open source communications

#517
post #422
post #324

Earlier quoted context omitted.

Because in the skillset of developers, IRC is such a difficult one to acquire?

Grep isn't a difficult skill to acquire but I wouldn't hire someone that didn't know it. Some skills can be good proxies for a range of other skills an experience and a lot of developers are in that "don't know what they don't know" range.

Sure, I just have to disagree on IRC being a good indicator for that.

Also, fwiw, most of my colleagues use IDE "search project for string" in places where I use grep. Also, if I'm being honest, you should hire nearly all of them before you hire me.

I think you've picked two false flags.

Re: Why Slack is inappropriate for open source communications

#518

Earlier quoted context omitted.

>Are you serious? I think lots of people do. I think it's one of the draws of Slack. No it isn't. What it implies is what people want: persistent logs, signing in from their phone logging them into the same session as signing in from their desktop, etc. >Is that what Slack does? Whatever they do, I think it's what people want. Indeed it is not an experience offered by IRC, perhaps because "most IRC servers don't want…

> What it implies is what people want: persistent logs, signing in from their phone logging them into the same session as signing in from their desktop, etc. Okay, to me that is the same thing as 'persistent sessions', but without belaboring the point... can IRC do those things? Right, it depends on the server and client. What servers and clients can? I think it's pretty rare, if it exists. If your answer is "well, I…

You're missing the point. This subthread is not about what IRC does do, it's about whether a chat protocol with support for persistent sessions, search, etc. can still be simple.

Maybe actually read the thread next time? So don't "so what?" me. This isn't about whether IRC can do those things.

Re: Why Slack is inappropriate for open source communications

#519
post #497

Earlier quoted context omitted.

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

> it's very widely used by a really huge, diverse range of people. Well you must be around cooler people than I am. Today, if someone wants to start a group chat with persistence (I'm surprised you seem to think this is useless), without having to bother with setting up their own server, IRC will not be on that list. But there is a large group that wants this, and its increasing, because people don't want to bother w…

>Well you must be around cooler people than I am. Today, if someone wants to start a group chat with persistence (I'm surprised you seem to think this is useless), without having to bother with setting up their own server, IRC will not be on that list. But there is a large group that wants this, and its increasing, because people don't want to bother with a bouncer.

I don't care what you use personally. The reality is that many hundreds of thousands of people use IRC frequently. Communities all over the world use IRC. Most of them are non-technical. Most have never heard of Matrix, or Riot, and certainly have no interest in using Slack.

>This is a bit similar to FORTRAN's situation. FORTRAN can still do the things C++ can still do, but you don't see people using FORTRAN. IRC is a simple protocol and is simple, until it has it be used for increasingly complex features and also being adopted for the web requires all sorts of proxies and workarounds.

No, it's nothing at all like Fortran. That's a silly comparison.

>What are you saying then? You said people can use IRC now for all the features I talked about, but then now you changed your stance.

No I didn't. I never said that IRC could do all those things today. Are you even reading my comments?

>Then what solves those problems? I think Matrix solves those problems, so what do you think is a better alternative? Does it have a community comparable to matrix? Say so and I will switch right now. The guys working being matrix know what they're doing. HTTP transport isn't the fastest, but it is simple to implement for a web developer. And with more and more people preferring in-browser clients, I saw HTTP as a good choice.

Again, you're missing my point by a country mile. If you had said "IRC doesn't currently support this" I would agree with you. But you didn't. You said that simple protocols could never support these features. You said that the days of simple chat protocols are over. And quite frankly, that's rubbish. That's all I am saying, all I have ever said. Stop pretending that I'm saying IRC has all the features you are asking for. I am saying that you can implement those features in a simple way on top of a simple protocol. That is all.

>Holy cow. I've been linking to matrix and Riot links, how did you still think I'm talking about slack? I was talking about how slack is getting the mindshare of OSS communities and that's not good.

No you've just asked me repeatedly and for no good reason to show you how IRC does all the things that I've repeatedly said it does not do. I don't know why you're incapable of understanding the difference between "IRC has features X, Y and Z" and "it is possible to implement features X, Y and Z on top of simple protocols, so no the days of simple protocols are not over". But you do seem to be incapable of understanding that, as it's about the fifth time I've said it.

>No I assure you it's not. You linked to a single web client. That's not the same support for emoji's as matrix's.Those are emocodes, and on the big list of supporting clients here[1], I see only IRCCloud (which is the same web client you linked me to) implementing it. No other IRC clients does this.

You can use shorthand emocodes (with autocomplete!) to send them and they’ll be converted to unicode so anyone using another IRC client that supports emoji can enjoy your graphical exuberances.

You could at least read the link. You type them as emocodes, which are mapped to the actual Unicode emoji. All that is sent over the wire is normal Unicode emoji. That is why I'm saying that this is a purely UI issue.

This is what emoji are. They are Unicode grapheme clusters formed from a group of Unicode code points. That's the implementation, and the interface is, on both Slack and IRCcloud and everywhere else I've seen them, either a giant grid of emoji to pick from, or emocodes :simple_smile:, usually both.

>That's why I listed the clients I use - Hexchat and weechat. Please share the easy code that can add those features to them. While you're at it, licensing it with a FSF approved license would be much appreciated.

Why on God's earth would I do that?

Re: Why Slack is inappropriate for open source communications

#520
post #193

Earlier quoted context omitted.

> I was expecting Stallman-style advocacy against closed-source as a principle; pleasantly surprised by the arguments. Is this a problem? Ostensibly one should hope to be able to communicate online in the same manner that one does offline: without paying an intermediary Further, if the 'natural trend' of economics is towards commoditization of products, why then are we abandoning those things which facillitated decen…

If you're communicating with someone from a dicferent continent offline, get ready for a bill from your landline. We're gravitating towards better products. Sorry, but having used IRC a lot, Slack is just better.

> Further, if the 'natural trend' of economics is towards commoditization of products, why then are we abandoning those things which facillitated decentralization in order to support another entities profit motives?

your point fails to address this point; similarly 'better' has varying metrics.

Post reply on HN