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 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.
The costs for an Free / open source developer haven't changed in this "new" world. Distribution of software is the same as it ever was.
I'm having a bit of cognitive dissonance trying to understand what an "open source service" is. If it's "open source", in terms of the OSI definition, your "million people" could just download and self-host it. To my mind, at least, if it can't be self-hosted it's not "open source".
If you're talking about selling access to servers running an instance of the application then you're talking about running a service bureau, not distributing software. The economics are completely different.
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 move to a model where the end user can pay for the server time. sandstorm.io was (is) exciting for more than a few reasons. But overall it's still an unsolved problem.
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.
The pendulum is definitely ready to swing back the other way. A related problem with SaaS is the risk associated with whether or not the company will endure (and open-source-on-company-failure is not confidence building imo).
https://machinebox.io/#pricing is one example that I like of a product that goes back to software-as-a-product. I've not dug into the operational aspects of this product, but if done well should be able to scale from a dev's laptop to k8s or other PaaS.
> With the old upload-and-forget model of software distribution, you could put a tarball on a free FTP site for a few pennies
You can still create a Digital Ocean droplet, Docker container, or VM Image - and do the same thing (upload & forget). Then it's up to the user to pay $5/mo to host it, a process which doesn't need to take more than a few mouse clicks.
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 maintain session history on new devices.
I think it has a bright future and you should consider it too.
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 a number of people together for a meeting.
It is one thing to deal with one of these things, but when you have to install ten to get your work done you have a problem. I have a high performance computer and I want to keep it that way.
>It is one thing to deal with one of these things, but when you have to install ten to get
The modern office large office is pretty bad in this respect. Really not uncommon to see things like
• Need to have Slack open
• Need to keep an eye on Basecamp/pm software
• Need to have Outlook open / check in on for email and calendar invites
• Need Skype open because not everyone uses Slack
• GitLab is open in another tab
I've started counting the minutes that I use in a day just logging in to things with our SSO, because it has started to actually add up, haha. It has gotten silly.
In the good old days of ICQ and Jabber you could install a client that would integrate several protocols into a single lightweight UI (e.g. Miranda IM). Unfortunately the new wave of messengers is much more successful at guarding their protocols against such integrations.
That said, I wonder what's Discord's official stance on such things. Their bread and butter is voice chat, and they seem to be fairly open minded. Maybe they will eventually provide a public API for basic text messages.
If I can't use my own client (pidgin/finch), then I'm just not going to use the chat-service. I don't mind being logged into $chat_client_of_the_week, I mind logging into all of the $chat_clients_of_last_week though.
I feel the same way. Standardization is a feature, but it also comes with its costs (difficulty of extending features). In many places lack of standardization is okay, but I feel like for most chat purposes (especially about programming), plain text over IRC works just fine.
I don't mind Gitter though, because it has a useful feature (code snippets) and it is available through a web app as opposed to a separate install.
What if software engineering as a skillset hit its peak within the last 5 years and now it is just going downhill in general? The quality of "companies" isn't going down - companies are made of people, and some of those people are in charge of creating and testing its technology...
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.
Is that really happening that open source communities use Slack as their primary communications channel? I haven't seen that happening in the communities I participate in (Python/Django/...). What I do see is that more and more communities switch from IRC to Slack as the primary "sync" channel (while still maintaining mailing lists, bug trackers and the like).
And as much as I hate it, the success can't be denied. Especially when looking at some conferences I've been to over the years. If they even had an IRC channel, it was mostly dead, but the Slack channels were buzzing with activity during the conference. I'm not sure why that is. Ease-of-use? The fact that many attendees are familiar with Slack from work, but not with IRC?
Issue #2, that slack is based on synchronous communication, is something that is always ignored. Sometimes I log in to slack and see a conversation that I want to add something to, but it is 4 hours old with 50+ new messages on varying topics. Even with Slack's new threaded messages it is hard to evolve the conversation after all the synchronous folks have moved on to other topics.
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.
I never used Slack, but in IRC I'd quote what the user said (a format like "<user> message", optionally with a time) if it's really relevant; and in Telegram it's a simple matter to rightclick and reply (which allows people to click/tap it to jump back to context) which I feel much less bad about.
If I really wanted to bring up a topic that had passed, I would break out to a separate channel and invite the relevant people and drop a note in the main channel with a "bringing things back up about $conversation in #newchannel". This works better than writing to threads in my experience.
Chats (of whatever type) have never been a good solution for this, that's why mailing lists exist. Improvements there would be nice, sure, but are unlikely to come from a chat service. They just solve different problems.
This is more of a usage problem that anything else. If your organization makes decisions based on synchronous communications, without stopping to notice who wasn't included and get their input before final decisions are made, that is a cultural problem, not a tooling problem.
Good points but the bigger problem for me is the lack of an archive.
You only have the last 10k (?) messages and that includes public and private messages. If you have a mildly active project, messages may only be available for a month and you lose the history of the project. That makes it an awful support option too.
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.
I 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 and emotions. Seeing the same people in the member list every day, exchanging little inside jokes, getting to know individual members of the community on a personal basis — this is something completely irrelevant for the user of the open-source product, but can be an important emotional component that motivates people to stay in the community and continue to put in effort into the project.
And, of course, a synchronous channel, where you can get more lax on moderation, is a much more suitable tool for this purpose.
I am the lead developer of Zulip (zulip.org), an open source Slack alternative built around a better threading model.
I strongly agree with both criticisms of using Slack for open source, and I am impressed that Dave wrote this post, given that some of those criticisms apply to his own product.
However, I think the proposed solution of relying on mailing lists, issue trackers, and forums is the wrong solution.
Support for synchronous communication is not the problem with using Slack/IRC/etc. for having discussions in open source organizations. After all, even with "asynchronous" media like email, bug trackers, or forums, often people reply basically immediately (within minutes or maybe hours), just like you can in chat, and it might be hours or days before everyone has a chance to see the conversation and respond.
The problem is that the messages have no organizational structure beyond the channel. In Slack and friends, there's no easy way to see what _actual conversations_ happened while you were away, and it's really hard for a channel to discuss multiple things, so conversations either die or become hard to read when someone starts talking about something else. Combined, this means you have to (1) read _everything_ in order to know what happened and (2) be continuously online in order to participate effectively. This may not matter if your community is super low-traffic, but if you have hundreds or thousands of messages being sent daily, this effectively excludes everyone who doesn't have a LOT of time to spend on the chat community.
It doesn't have to be this way. Nothing prevents creating group chat software that handles both synchronous and asynchronous communication well. In particular, Zulip is built around a simple threading model that solves both of these problems. In our own chat.zulip.org community, people constantly contribute valuable commentary or feedback to a thread that started a few days and hundreds of messages ago. And I can come back from a week's vacation, and skim the 5000 messages that might have happened while I was gone, and easily reply to all the threads where I have something to add.
(As a sidenote, it's easy to post permanent links to conversations in Zulip, which we use regularly in the Zulip issue tracker to point to the original discussion that led to a given proposal. But the important problem isn’t the link part, it’s separating the conversations from each other: without something like Zulip's threading, reading chat logs can be a slog).
It might be more useful to speak in general terms than call out Slack in particular. The concerns expressed here aren't limited to Slack (despite the link-baity title), but any form of communication that:
(a) Can't be referenced or linked from the Web, and
(b) Is a form of synchronous communication
The same factors, BTW, apply equally to in-person discussions held at open source conferences. I wonder what the author thinks of the value of those insofar as "open source communications" are concerned.
Slack is technically inept as well. Earlier today I was modifying a robot design in Fusion 360. Huge beast of a model with too many parts to bother counting. Fusion was consuming nearly 900MB of memory (and I am rounding up here). Which is unsurprising for a CAD package editing a large model.
Meanwhile my mostly idle Slack with perhaps a couple hundred users across four teams was consuming 1.3GB of memory.
Not to put too fine a point on it: it is a piece of shit software.
It seems to me that Slack could position itself to provide free and open access to certain types of communities like open source projects, charities, etc. Enable the "pro" features so long as the community follows the rules.
The value of synchronous communication is very real and it should not be precluded, but the points are totally valid. Slack is a closed-garden and it does not contribute to the global conversation if the access and historical record is controlled from within.
I feel like more and more people are coming around to seeing the relevancy of distributed federated chat and breaking out of the walled gardens. My person money is on Matrix[0] taking off but I think the general theme of people pulling away from interesting their communication to corporations is a positive.
[0] matrix.org
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.
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.
Many of these complaints are just as valid for any business or organization trying to function as a modern software-based org in this day and age.
You have remote workers, flexible schedules, people traveling everywhere, all doing knowledge work that depends upon sustained focus and reaching a flow state. All of which Slack and synchronous chat detract from.
Slack just happens to be easy and convenient, so orgs end up using it by default.
I'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.
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 mailing lists impose on open source development that are not present in other tools?
What really needs to die is the view that old tools are bad tools. In my experience, the most useful tools I use (standard unix utilities, vim, emacs, lisp, etc) are the oldest ones while the newer ones are the ones I could most easily replace.
[+] [-] erikpukinskis|9 years ago|reply
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.
[1] https://blog.heroku.com/heroku-button
[+] [-] EvanAnderson|9 years ago|reply
I'm having a bit of cognitive dissonance trying to understand what an "open source service" is. If it's "open source", in terms of the OSI definition, your "million people" could just download and self-host it. To my mind, at least, if it can't be self-hosted it's not "open source".
If you're talking about selling access to servers running an instance of the application then you're talking about running a service bureau, not distributing software. The economics are completely different.
[+] [-] Taek|9 years ago|reply
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 move to a model where the end user can pay for the server time. sandstorm.io was (is) exciting for more than a few reasons. But overall it's still an unsolved problem.
[+] [-] mnutt|9 years ago|reply
[+] [-] transitorykris|9 years ago|reply
https://machinebox.io/#pricing is one example that I like of a product that goes back to software-as-a-product. I've not dug into the operational aspects of this product, but if done well should be able to scale from a dev's laptop to k8s or other PaaS.
[+] [-] 31h|9 years ago|reply
You can still create a Digital Ocean droplet, Docker container, or VM Image - and do the same thing (upload & forget). Then it's up to the user to pay $5/mo to host it, a process which doesn't need to take more than a few mouse clicks.
[+] [-] ktta|9 years ago|reply
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 maintain session history on new devices.
I think it has a bright future and you should consider it too.
[1]:https://matrix.org
[2]:https://riot.im
[3]:https://matrix.org/docs/projects/try-matrix-now.html
[+] [-] PaulHoule|9 years ago|reply
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 a number of people together for a meeting.
It is one thing to deal with one of these things, but when you have to install ten to get your work done you have a problem. I have a high performance computer and I want to keep it that way.
[+] [-] 27182818284|9 years ago|reply
The modern office large office is pretty bad in this respect. Really not uncommon to see things like
• Need to have Slack open
• Need to keep an eye on Basecamp/pm software
• Need to have Outlook open / check in on for email and calendar invites
• Need Skype open because not everyone uses Slack
• GitLab is open in another tab
I've started counting the minutes that I use in a day just logging in to things with our SSO, because it has started to actually add up, haha. It has gotten silly.
[+] [-] romaniv|9 years ago|reply
That said, I wonder what's Discord's official stance on such things. Their bread and butter is voice chat, and they seem to be fairly open minded. Maybe they will eventually provide a public API for basic text messages.
[+] [-] CaptSpify|9 years ago|reply
[+] [-] ReverseCold|9 years ago|reply
[+] [-] saosebastiao|9 years ago|reply
I don't mind Gitter though, because it has a useful feature (code snippets) and it is available through a web app as opposed to a separate install.
[+] [-] pokemongoaway|9 years ago|reply
[+] [-] giancarlostoro|9 years ago|reply
http://meetfranz.com/
[+] [-] ptman|9 years ago|reply
[+] [-] beamatronic|9 years ago|reply
[+] [-] piquadrat|9 years ago|reply
And as much as I hate it, the success can't be denied. Especially when looking at some conferences I've been to over the years. If they even had an IRC channel, it was mostly dead, but the Slack channels were buzzing with activity during the conference. I'm not sure why that is. Ease-of-use? The fact that many attendees are familiar with Slack from work, but not with IRC?
[+] [-] johnomarkid|9 years ago|reply
[+] [-] fiatjaf|9 years ago|reply
[+] [-] freehunter|9 years ago|reply
[+] [-] lucb1e|9 years ago|reply
[+] [-] delias_|9 years ago|reply
[+] [-] maxxxxx|9 years ago|reply
[+] [-] ska|9 years ago|reply
[+] [-] codingdave|9 years ago|reply
[+] [-] flukus|9 years ago|reply
[+] [-] caseysoftware|9 years ago|reply
You only have the last 10k (?) messages and that includes public and private messages. If you have a mildly active project, messages may only be available for a month and you lose the history of the project. That makes it an awful support option too.
[+] [-] joaodlf|9 years ago|reply
[+] [-] golergka|9 years ago|reply
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 and emotions. Seeing the same people in the member list every day, exchanging little inside jokes, getting to know individual members of the community on a personal basis — this is something completely irrelevant for the user of the open-source product, but can be an important emotional component that motivates people to stay in the community and continue to put in effort into the project.
And, of course, a synchronous channel, where you can get more lax on moderation, is a much more suitable tool for this purpose.
[+] [-] tabbott|9 years ago|reply
I strongly agree with both criticisms of using Slack for open source, and I am impressed that Dave wrote this post, given that some of those criticisms apply to his own product.
However, I think the proposed solution of relying on mailing lists, issue trackers, and forums is the wrong solution.
Support for synchronous communication is not the problem with using Slack/IRC/etc. for having discussions in open source organizations. After all, even with "asynchronous" media like email, bug trackers, or forums, often people reply basically immediately (within minutes or maybe hours), just like you can in chat, and it might be hours or days before everyone has a chance to see the conversation and respond.
The problem is that the messages have no organizational structure beyond the channel. In Slack and friends, there's no easy way to see what _actual conversations_ happened while you were away, and it's really hard for a channel to discuss multiple things, so conversations either die or become hard to read when someone starts talking about something else. Combined, this means you have to (1) read _everything_ in order to know what happened and (2) be continuously online in order to participate effectively. This may not matter if your community is super low-traffic, but if you have hundreds or thousands of messages being sent daily, this effectively excludes everyone who doesn't have a LOT of time to spend on the chat community.
It doesn't have to be this way. Nothing prevents creating group chat software that handles both synchronous and asynchronous communication well. In particular, Zulip is built around a simple threading model that solves both of these problems. In our own chat.zulip.org community, people constantly contribute valuable commentary or feedback to a thread that started a few days and hundreds of messages ago. And I can come back from a week's vacation, and skim the 5000 messages that might have happened while I was gone, and easily reply to all the threads where I have something to add.
(As a sidenote, it's easy to post permanent links to conversations in Zulip, which we use regularly in the Zulip issue tracker to point to the original discussion that led to a given proposal. But the important problem isn’t the link part, it’s separating the conversations from each other: without something like Zulip's threading, reading chat logs can be a slog).
[+] [-] otterley|9 years ago|reply
(a) Can't be referenced or linked from the Web, and
(b) Is a form of synchronous communication
The same factors, BTW, apply equally to in-person discussions held at open source conferences. I wonder what the author thinks of the value of those insofar as "open source communications" are concerned.
[+] [-] bborud|9 years ago|reply
Meanwhile my mostly idle Slack with perhaps a couple hundred users across four teams was consuming 1.3GB of memory.
Not to put too fine a point on it: it is a piece of shit software.
[+] [-] ntaylor|9 years ago|reply
The value of synchronous communication is very real and it should not be precluded, but the points are totally valid. Slack is a closed-garden and it does not contribute to the global conversation if the access and historical record is controlled from within.
[+] [-] lordCarbonFiber|9 years ago|reply
[+] [-] Underqualified|9 years ago|reply
[+] [-] jsat|9 years ago|reply
[+] [-] INTPenis|9 years ago|reply
It remains to be seen if it has proper AD integration for example.
[+] [-] rsanheim|9 years ago|reply
You have remote workers, flexible schedules, people traveling everywhere, all doing knowledge work that depends upon sustained focus and reaching a flow state. All of which Slack and synchronous chat detract from.
Slack just happens to be easy and convenient, so orgs end up using it by default.
Obligatory link to 37 signals post on this topic: https://m.signalvnoise.com/is-group-chat-making-you-sweat-74...
[+] [-] tmail21|9 years ago|reply
[deleted]
[+] [-] nv-vn|9 years ago|reply
[+] [-] patrickg_zill|9 years ago|reply
And Discourse is pretty great, though much more like a forum.
[+] [-] branchly2|9 years ago|reply
Using IRC/Slack in place of forums is like using a wiki in place of real documentation.
[+] [-] Pxtl|9 years ago|reply
[+] [-] _jal|9 years ago|reply
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 mailing lists impose on open source development that are not present in other tools?
[+] [-] vertex-four|9 years ago|reply
[+] [-] fiddlerwoaroof|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] grx|9 years ago|reply
[+] [-] lucb1e|9 years ago|reply
and Telegram and Wire and Riot and Semaphor and Tox and... Plenty of non-closed tools.