Some people only go to church on holidays...
Why Slack is inappropriate for open source communications
251–260 of 536 posts
Re: Why Slack is inappropriate for open source communications
#252A 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…
> A great alternative to Slack, in the spirit of IRC, is matrix[1] Does it have Android and iOS clients? If not, it's not a great alternative to Slack. It's not even an alternative to Slack.
It does! Check out Riot.im
Re: Why Slack is inappropriate for open source communications
#253Earlier quoted context omitted.
I've seen it, but it's nothing like even Quasseldroid. And quasseldroid is already a horrible codebase (mostly because I took over maintenance when I knew nothing about code quality). Yet even Quasseldroid manages to be better. That said, there is truly a need for a really good, FLOSS irc client ob mobile.
You're saying they're nothing like each other but are providing no examples. Besides one being an app and one being a website, what are the differences? Neither quasseldroid or Lounge have push notifications or searchable messages yet, so they seem to be pretty identical feature-wise. EDIT: and we aren't talking about code-base, are we? If so, Lounge's is pretty solid (although it is in a pretty constant state of tra…
> 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 a lot better.
Re: Why Slack is inappropriate for open source communications
#254A 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…
> A great alternative to Slack, in the spirit of IRC, is matrix[1] Does it have Android and iOS clients? If not, it's not a great alternative to Slack. It's not even an alternative to Slack.
Yes, they have amazing (and multiple) clients for both Android and iOS. Especially Riot, which is not just a cheap web wrapper that a lot if the alternatives, it's native and in my experience, I have not had any problems, performance inckuded, using it for slack on my Android phone.
Re: Why Slack is inappropriate for open source communications
#255I'm not sure about others, but I very much dislike the idea of multiple channels (the way Slack, Discord, etc. do it) on one server/chat. It feels messy and half the time conversation doesn't fit neatly into any of the choices. Honestly, I can't think of something I'd rather use over Telegram here -- if I need multiple discussions it's just like IRC: I make a different chat for each one, rather than having to awkwardly subdivide my main chat. It also has the advantage (even more so than IRC) that all users exist on the same server, so you never have to deal with the awkward per-group account system (Slack) or server-only messaging (Discord) or having to switch rizon->freenode->mozilla IRC. WhatsApp would probably be just as good if not for publicly identifying users by phone number, what it really comes down to for me is just having a normal chat app. Maybe even plain old Skype would be nice if it wasn't proprietary. I don't need you to innovate the way my chat system works with fancy new methods of grouping users. I don't mind the bells and whistles (voice/video chat, bots, stickers/emoji, ...) as long as it doesn't get in the way of me having a conversation. But for fuck's sake don't try to cut off every group from everyone else like Discord/Slack.
Re: Why Slack is inappropriate for open source communications
#256Earlier quoted context omitted.
> 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... Which can also be done with IRC clients. This is a video of a search system I built for the Quassel IRC client: https://dl.kuschku.de/videos/2016-09-16_04-03-36.mp4 Quassel is a distributed system, so you have a bouncer…
Encapsulates this era as the battleground of silo'd "as a service" vs "can be done" For example I can have jenkins email build fails to slack in, oh, probably less than two minutes, I've done it before. From memory I make a custom email addrs in slack and tell slack which channel to feed it into, and then add that address to my jenkins that already sent buildSpam. In IRC I could do it... google implies there's a ZenI…
You can have Jenkins send IRC messages using a single invocation of netcat. This should take less than two minutes.
Re: Why Slack is inappropriate for open source communications
#257A 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…
"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.
I'm not sure it's fair to call it a massive blob of web technologies (although I'm biased, given I work on it). To compare sending a message on IRC versus sending one on Matrix:
$ telnet irc.freenode.net 6667
...
NICK Ara4n
USER Ara4n Ara4n irc.freenode.net :Matthew Hodgson
...
JOIN #matrix
PRIVMSG #matrix :test
curl "https://matrix.org/_matrix/client/r0/rooms/!cURbafjkfsMDVwdRDQ%3Amatrix.org/send/m.room.message/uuid?access_token=$access_token" -X PUT --data '{"msgtype":"m.text","body":"test"}'
Meanwhile definitely are some lightweight C matrix clients out there - e.g. https://github.com/matt-williams/matrix-esp8266/blob/master/... is a proof of concept client in C that runs on an ESP8266(!), or the libpurple plugin: https://github.com/matrix-org/purple-matrix.
In the end, if you don't like HTTP or web technologies, there is NOTHING stopping people from contributing alternative transports - COAP, MQTT, capnproto, QUIC, XMPP, WebSockets or whatever floats their boat. But it seems that the simple HTTP+JSON API works well enough that nobody has bothered yet (other than https://github.com/matrix-org/matrix-doc/blob/master/drafts/...).
Re: Why Slack is inappropriate for open source communications
#258I was expecting Stallman-style advocacy against closed-source as a principle; pleasantly surprised by the arguments. Synchronous communication, indeed, is bad for the main communication channel. However, as a secondary communication channel, it can serve important needs. When people are looking not to just get a single issue resolved, but to form a community, this community is often based on informal communication an…
> 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.
Re: Why Slack is inappropriate for open source communications
#259It'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.
[deleted]
Re: Why Slack is inappropriate for open source communications
#260We 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 application, or one person could, and you wouldn't have to do a thing. Variable costs for an OSS developer were $0. Fixed costs were just the cost of your computer and an internet connection.
But if you deploy an open source service to the cloud, it's going to cost you more than a few pennies, and if a million people try to use your service you have two headaches: financial and operational.
In theory something like Ethereum solves this problem, but it's not really ready for the scale yet, and it's hard to use.
In theory something like a Heroku Button[1] on Github solves the problem, but Heroku artificially introduces a 30 second delay for accessing free applications, and put lots of their infrastructure behind a paywall that the deploy-er has to manage and pay for.
This has been a difficult problem to solve, because unlike the x86 machine of the OSS explosion in the 90s, the "cloud computer" is still actively being invented. Ethereum didn't even exist a few years ago, and Heroku is a moving target. Linux Containers are also brand new, and then there's Docker and other VM standards, not to mention Google, Azure, etc... we are still grasping in the dark to try to answer the question, "What does a standard cloud machine look like?"
Until we answer that question, closed source services are going to have an immense advantage over open source ones. After we answer the question the power dynamic there will reverse and there will be a cambrian explosion of user-facing open source services.