Why Slack is inappropriate for open source communications - <AUTHOR> https://dave.cheney.net/2017/04/11/why-slack-is-inappropriate-for-open-source-communications <comment><USER2> 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.

[1] [https://blog.heroku.com/heroku-button](https://blog.heroku.com/heroku- button)

<comment><USER3> 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.

<comment><USER4> 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...

</comment></comment></comment><comment><USER5> 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.

[1]:[https://matrix.org](https://matrix.org)

[2]:[https://riot.im](https://riot.im)

[3]:[https://matrix.org/docs/projects/try-matrix- now.html](https://matrix.org/docs/projects/try-matrix-now.html)

<comment><USER6> Why is there not a web based IRC app?

<comment><USER7> There is. A bunch in fact.

[http://mibbit.com/](http://mibbit.com/)

[https://kiwiirc.com/](https://kiwiirc.com/)

or, site-specific:

[https://webchat.freenode.net/](https://webchat.freenode.net/)

[http://chat.efnet.org/](http://chat.efnet.org/)

</comment></comment></comment><comment><USER8> 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.

<comment><USER9> >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.

<comment><USER10> As a freelancer, I have EXACTLY this problem, so I started hacking away on my own solution. Don't want to shamelessly promote myself here, but if you're interested, link is in my profile.

<comment><USER11> A few comments that I hope are constructive. Looking at your page, I'm not confident you're avoiding the issue by which these tools proliferate:

[https://xkcd.com/927/](https://xkcd.com/927/)

Your users and their clients are still going to be using Slack and email, but it seems like you're giving me one more thing to log into. You write:

> Schedule your time spent and group distracting reminders and notifications > in one place

If this "one place" is a separate silo from Slack, Outlook, Basecamp, Skype, SMS, Discord, Hipchat, IRC, and Github...it's not the one place I'll need to check. It's the n+1th place.

Now, if I can put my credentials into Calmbird (securely would be nice, but you can have the plaintext if you can make this insanity stop) and have it do the API connection to - or, if necessary, the nasty DOM-manipulation, Windows message hacking, and client-impersonating - to put all these services and their notifications in one place, _that_ would be a solution to the proliferation problem.

Also:

> schedule automatic emails to your clients with updates

My clients don't want automatic emails, especially from templates/digests. They want me to hand-craft them as if it was the most important thing in my life. And while they can understand a curt update message or a missed daily status notification, the real point of these updates are to confirm that I'm still on the project. If a message accidentally went out with a placeholder like "I'm still working on {todo-insert-task-here}", and I didn't know about it, that would be...bad.

<comment><USER12> Aka Trillian from the last Great Messenger Client War.

<comment><USER10> Well, perhaps but I am more trying to develop a service to avoid the Slacks and Basecamps of the world, while still being aware of what's going on, rather than just being a multi-network client.

</comment></comment></comment></comment></comment></comment><comment><USER13> 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?

<comment><USER14> I was at a dev meetup for Python: I really thought he was joking when he said, what is IRC? And then I realized that we have a whole generation of devs that have no idea what IRC is or how to use it. Amazing the amount of knowledge and experience lost between a single generation.

<comment> jay-anderson I've tried to give IRC a chance a few times, but it always felt like there were a few too many odd little things to learn before I could be productive and comfortable. I didn't get used to it and dropped it. It never felt inviting.

I use slack at work and love it. I fully agree that it isn't that different from IRC and I hate that it's another walled garden (of sorts), but it fixes a lot of the little annoyance in dealing with IRC.

<comment><USER15> I've been IRCing for 24 years. I know about bouncers, different clients, etc., and I still prefer Slack to IRC.

I like knowing that it's going to handle unicode properly, in all cases, for everyone on the Slack channel. I like that it handles right-to-left text for everyone reading.

I like not having to ever think about, is my bouncer down? I also like not having to think about, where am I going to run my bouncer? It's nice not having to think about that stuff at all. I've got a lot on my plate, keeping a bouncer up and running somewhere (just so I don't lose history!) doesn't need to be another thing I do.

I like the plugins, the integrations with various other services. I like the convenience and polish. No IRC client compares to Slack for integrations and polish. It takes friction out of my daily chat experience.

I've even moved some private irc channel chats to Slack channels, because it's just a more pleasant experience in 2017. No regrets about any of that.

<comment><USER16> I used IRC a lot as a teen back in the late 80s early-to-mid 90s. This was back when to make a private channel you would have to join a channel that was a negative number and hope nobody else wandered in on a guess (which was unlikely to happen since the number of users was literally under 200 at peak times). Pre-Eris, Pre-EFNet, etc.

Despite the nostalgic kick of it, I never used it as a serious work tool at any of my jobs, haven't used IRC at all in probably a decade, and totally agree that options like Slack are just plain better work communication tools.

<comment><USER17> I used IRC a bit in the mid 90s when I first encountered this whole internet thingy. Even though I was young and dumb, it struck me as a bit lame: nerd bullshit with fiddly setup. The async aspects of usenet and email struck me as more scalable, and the web had, you know... graphics.

I had to use IRC again in 2015, and pretty much nothing had changed, except now I was 20 years older.

Most of the criticisms of Slack seem to boil down to: this (whatever it is) is something IRC could do. But it (whatever it is) is virtually always something IRC doesn't do, something it does in some half-arsed fashion (that requires a huge amount of fiddly setup), or something that's supported by only a few clients. How is this not obvious? I'm perpetually mystified that anybody would admit in public to not understanding why Slack is taking a massive dump on IRC.

(Criticisms of Slack's closed nature are valid. It's also worth asking why it has to take up 2GBytes of RAM just to show a tree view, an HTML view and a text box! But don't tell me that you can't understand why Slack is winning anyway.)

</comment></comment></comment></comment></comment></comment><comment><USER18> 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.

<comment><USER19> I don't understand why people seem to thing that chats will solve all the problems. Chatting is having to write the same thing a million times.

<comment><USER20> > Chatting is having to write the same thing a million times.

If you find yourself repeating the same thing a lot in chat, it would be a good idea to document it somewhere and just paste a link. With a link to the relevant documentation, a lot of people will just do the rest of the legwork on their own, and will now be able to quickly reference it going forward, and hopefully bug you less in chat (you can always be explicit and refuse to answer people, asking them to read the docs instead).

If you find you're pasting too many links too frequently, then it's time to make an FAQ with those links, and start linking to that.

<comment><USER21> The problem is though, that some people like to be the local expert on IRC/Slack with all the answers. They don't _want_ to document it elsewhere.

<comment><USER22> Fix your group's culture. Document things. If people refuse to document things, then do it for them and shove your docs in their face. Do it until they write the documentation themselves.

<comment><USER23> > Fix your group's culture.

Culture-change is about the hardest thing to achieve.

<comment><USER24> It's also the most important thing. If your culture is bad, changing what tool you use isn't going to fix everything. You're just going to have a new tool everyone uses poorly.

</comment></comment></comment></comment></comment></comment></comment><comment><USER25> 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.

<comment><USER26> Well, some of the open communities are using [http://slackarchive.io/](http://slackarchive.io/)

<comment><USER27> Thanks for the pointer! Hadn't seen this before.

</comment></comment></comment><comment><USER28> 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.

<comment><USER29> > Mailing lists are far too outdated. Forums are good, and some good people > out there are still developing them.

WTF?

How is it even remotely sane to provide a user interface instead of an API/protocol?

I don't care to learn your forum's user interface, and I don't care to poll your forum for new content. I have a mail user agent that's configured to fit my needs and that I know well how to operate, and that's where all the mailing lists that I am subscribed to push their new content into this one unified interface for me to interact with them. Web forums for the most part are just a pile of broken usability.

<comment><USER30> Why not both? Something like DFeed[1] which is used as the D programming language's forum[2].

[1] [https://github.com/CyberShadow/DFeed](https://github.com/CyberShadow/DFeed)

[2] [https://forum.dlang.org/](https://forum.dlang.org/)

<comment><USER29> Yeah, sure, provide as many user interfaces as you like, just not _instead_ of an API/protocol. The whole point is that everyone can choose the UI they prefer, or build their own if they like.

</comment></comment></comment></comment><comment><USER31> 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.

<comment><USER32> > 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 decentralization in order to support another entities profit motives?

<comment><USER31> 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.

<comment><USER32> > 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.

</comment></comment></comment></comment><comment><USER33> 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).

<comment><USER34> The threading model in Zulip is genius. It's the perfect marriage between instant messaging and email.

Other things I like about it:

\- e-mail addresses in addition to nicknames

\- working full text search over everything

\- plenty of well thought out keyboard shortcuts

\- high quality production tooling (they even have Nagios checks, out of the box!)

</comment></comment><comment><USER35> 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.

<comment><USER36> Are there any open source projects that coordinate development or provide support primarily through in-person discussions at conferences?

<comment><USER37> I don't know about "primarily", but it's certainly an important aspect overall for many projects.

</comment></comment></comment><comment><USER38> 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.

</comment><comment><USER39> 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.

<comment><USER25> But if your entire infrastructure is centrally managed and can disappear at a company's whim, you're setting your community up for problems.

<comment><USER40> This applies to Freenode as much as it applies to Slack. If freenode disappears, people using its channels for foss will have similar issues and inconvenience as if Slack/Discord disappear and in both cases, it's recoverable.

<comment><USER41> If freenode disappears, it's less than a day to pick a new network and connect.

Nobody changes clients, tooling, etc. That's the difference between a closed walled garden like slack and an open protocol.

<comment><USER40> Nobody changes clients if Slack disappears and is replaced by another webapp. It's all in browser.

The UI might change, but the UI also changes when you go from a Mac IRC client to a Windows one, which doesn't happen with web apps.

I say this as someone who's used IRC a crapton and is a strong advocate for open protocols (and for more than just ideological reasons): _Realistically_ , if Freenode disappears, IRC will most likely die as a protocol as all major projects switch to non-IRC solutions, which is happening today anyway. A protocol needs users.

The only thing IRC has got going for it is federation and openness. It's not easily extensible, it's not secure, it can't benefit from most of the advances we've made in comms and protocols since the 90s, and there isn't even a common format for your messaging history - most clients just use text logs!

If you want to advance the state of comms and ensure humans are using open protocols to communicate rather than walled gardens, you first have to acknowledge these flaws and needs. Propping up IRC as something it's not doesn't do anyone any favours.

<comment><USER42> If Freenode disappears, people will join Debian over on OFTC. I'm not sure if Mozilla and GNU/FSF use Freenode or run their own infrastructure but if the former, then they may set up their own network(s).

Other IRC networks than Freenode and OFTC exist too.

As far as security goes, SSL is an option for client<->server connections. I _hope_ that at this point it is default for server<->server connections. What else are you expecting for security?

<comment><USER40> SSL is not required and it's certainly not default in most clients.

IRC won't survive the loss of Freenode. With Quakenet dying off (its userbase went from ~65k in 2013 to 23k today), Freenode is the last central bastion that keeps the protocol in people's minds.

FOSS projects _today_ are migrating off IRC, onto Slack and Discord instead. This is why you have an article here talking about it and it's not the first one. If Freenode disappeared, this would accelerate massively. The projects won't bother going to another network because the topic of "Where do we go now?" is going to be asked and in most cases is going to be answered with "Well, we wanted to move to Slack/Discord anyway...".

There will be a few projects left on OFTC, certainly. But they'll give up and go elsewhere eventually as well when they'll see their userbase shrinking 5-10x due to other projects migrating elsewhere and taking their users with them. They'll probably end up on Matrix.

</comment></comment></comment></comment></comment></comment></comment><comment><USER43> 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

<comment><USER44> Everyone should be using Matrix. Not just open source developers.

It's near feature parity with Slack and it's also one of the best IRC clients around. I used to run ERC in a tmux session just so I could stay connected and not lose messages. No more.

<comment><USER43> The ease of bridging is great. We've got a minecraft server bridge of all things; being liberated to actually have universal chat is the future for sure.

</comment></comment></comment><comment><USER45> 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.

<comment><USER46> I don't have to drop (as much of) my mental state in order to communicate via chat. It's asynchronous, so I can finish typing out whatever I'm thinking about, or looking for whatever I'm trying to find, kick off a build, etc., and _then_ turn my attention to the chat window and bang out whatever comes next in the conversation. Once written, I can switch right back to whatever I was doing - I type quickly, so it's usually only a few seconds of interruption. I can easily carry on a couple of extended chat conversations while simultaneously continuing to get my actual work done.

If someone wants to talk in person or via voice instead, my heart always sinks a little, because it means I have to drop whatever I was doing and give the conversation my full attention instead. Once we're done, I have to try to remember what I was thinking about before the distraction happened, get myself back up to speed...

This doesn't come up so frequently anymore, but it was very noticeable when I used to work remote. Some coworkers were happy with chat, and it was easy to communicate with them; with others, it'd be like twenty seconds of productive conversation, then "can we please just have a call about this" and, oh god, that's it for getting anything done for the next 40 minutes.

<comment><USER47> > It's asynchronous

I find the same to be true on (small) Slack (or similar) channels. Which is funny given that Slack being synchronous is one of the two main points of the link.

</comment></comment></comment><comment><USER48> 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.

<comment><USER49> 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.

</comment></comment><comment><USER50> 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.

Obligatory link to 37 signals post on this topic: [https://m.signalvnoise.com/is-group-chat-making-you- sweat-74...](https://m.signalvnoise.com/is-group-chat-making-you- sweat-744659addf7d)

</comment><comment> nv-vn 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.

</comment><comment><USER51> Mattermost is an open source alternative to Slack btw.

And Discourse is pretty great, though much more like a forum.

<comment><USER52> We have been using [http://rocket.chat](http://rocket.chat) at work and it works beautifully. Slack was never an option for it was not self-hostable

<comment><USER51> Also a good choice.

</comment></comment></comment><comment><USER21> Forums work better.

Using IRC/Slack in place of forums is like using a wiki in place of real documentation.

<comment><USER53> It's much worse. A wiki still consists of pages of documents, even if they're kind of improvisational and perhaps incomplete. A chat log is just a log of people chatting, with all the free-wheeling and meandering conversational style that entails.

</comment></comment><comment><USER54> It'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.

<comment><USER55> Question for you:

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?

<comment><USER56> To have all the features you get for free out of slack, you have to do a lot of work and maintenance to get out of IRC and mailing lists.

Mailing lists by themselves are terrible, because there's no history. You can't scroll up to find context for the conversation. You can get public archives, but then where you actually use the mailing list and where you go to look at history are completely separate, which is a terrible UX. Google groups mostly fixes this because they're really just a forum that supports emails.

IRC is terrible because everyone has their own client, so you never actually know what someone will see when you post something. Post a link, - will it get auto-expanded? How will it look? Will it get auto-linked? If you @ someone, will they get notified? if so, how visibly?

IRC also has the multi-login problem - it gets confused if I log in from my phone and my laptop. To get a persistent history of IRC requires running an external service which is way beyond most users.

Slack has mindshare, which leads to having a ton of integrations with other platforms, which just multiplies its effectiveness.

I 100% agree that I wish they offered a publicly visible option, so anyone can view without logging in. I also wish they natively supported self- registration.

I have to echo another commenter on here. If you want the best of all worlds, a forum is what you're looking for. Publicly visible, easily linkable, long form, asychronous communication. Whether that's google groups or something else is up to you.

<comment><USER57> Slack gets a lot worse once you want to start dealing with two teams using it. With most IRC clients, I can have connections to multiple servers running, and able to see at a glance everywhere that there's activity. With Slack/Discord/etc, that involves a frenzy of clicking as you look through each group of chats individually. I can lay things out how I want, move things around, etc. Slack, fortunately, has bridges built in for IRC and XMPP clients, so I can use my already working clients instead of having to keep another web page open to another javascript-laden nightmare.

<comment><USER58> > Slack, fortunately, has bridges built in for IRC and XMPP clients, so I can > use my already working clients

Unfortunately, the Slack gateway implementation is subpar. In my experience, it will send me the last message I sent before I disconnected when I reconnect, but it won't send any of the other messages that were sent in the meantime. The other problem is that group chat only works over the IRC gateway, not the XMPP one (at least I could join it from my XMPP client, but I couldn't send any messages to it).

In contrast, the old XMPP server we used would just replay messages in group chat when you reconnected, so at least you wouldn't miss anything when you weren't connected.

Edit: s/Slack implementation/the Slack gateway implementation/

</comment></comment></comment></comment></comment><comment><USER59> I personally prefer Gitter & other tools over Slack for open source communications. The Slack signup process can be a road block as it takes to many steps. To often I run into open source communities that require you to join their Slack channel for posting any questions (that may or may not be bugs in their software).

I really like Slack for a lot of things, but it's often a tool used incorrectly due to its popularity.

</comment><comment><USER60> > Slack, et al, are based on synchronous communication, which discriminate > against those who do not or can not take part of the conversation in real > time. For example, real time chat discriminates against those who aren't in > the same time zone–you can't participate fully in an open source project if > all the discussion happens while you're asleep. Even if you are in the same > time zone, real time chat assumes a privilege that you have the spare > time–or an employer who doesn't mind you being constantly distracted–to be > virtually present in a chat room. Online chat clients are resource hogs, and > presume the availability of a fast computer and ample, always on, internet > connection, again raising the bar for participation.

It's quite amusing that the author takes his (valid) argument about the problems of closed, synchronous communication straight to the language of privilege, discrimination, and oppression.

<comment><USER61> There's no talk of 'oppression' anywhere in the article.

You understand that 'discriminate' and 'privilege' are regular words with regular definitions that were used by regular people for hundreds of years before you came along with your chip on your shoulder, right?

</comment></comment><comment><USER62> I can't believe that in 2017 we're still discussing what's wrong with our chat software. I have to wonder when we will finally see chat as a solved problem.

<comment><USER63> The OP isn't actually discussing chat as an unsolved problem. OP is arguing that chat is the wrong choice of solution to the problem of open source software project communication, because it's synchronous.

Or to abuse a metaphor, OP is arguing we need to use boats instead of cars to ship heavy things overseas, not that cars are an unsolved problem.

<comment><USER57> OP is arguing we should use boats for everything, including sending something across town. Realtime chat works a lot better for certain things, like troubleshooting, where having to wait around for a forum/email response may not be the best way of doing things.

</comment></comment></comment><comment><USER64> Discourse offers free hosting for big Open Source projects, and you can self- host it on a $5 VPS too.

Full Disclosure: I work at Discourse.

<comment><USER65> I doubt Discourse will run on a $5 VPS. The last time I checked its crashes on 512MB RAM, needs at least 1GB just to start. Have the minimum requirements changed? 1GB minimum and 2GB is recommended by Discourse itself.

Discourse is also not easy to setup, its quite involved and complex and you need some Ruby and systems expertise. Infact I think Discourse only supports Docker installs. So you need to know Docker too.

Given the complexity you should be pretty comfortable with Ruby to run it with any amount of confidence. The hosted option seems much better than trying to run it yourself.

<comment><USER64> I believe Linode and Vultr already have $5 1GB VPS offers.

Also the Official Install Guide[1] doesn't require any Docker-fu.

Also, we give hosted Discourse for free for open source projects with a big enough community to have a forum[2].

1: [https://github.com/discourse/discourse/blob/master/docs/INST...](https://github.com/discourse/discourse/blob/master/docs/INSTALL- cloud.md)

2: [https://blog.discourse.org/2016/03/free-discourse-forum- host...](https://blog.discourse.org/2016/03/free-discourse-forum-hosting-for- community-friendly-github-projects/)

</comment></comment></comment><comment><USER66> As I posted on twitter[1], Slack is linkable. Not public, but if you can chat you see them. Gitter: public AND linkable. Async is a good argument; linkability is not.

Slack's UI is good. Not perfect, but it's quite usable compared to _all_ the alternatives[2]. People always underestimate the value of good UI.

[1] [https://twitter.com/zellyn/status/851818007248678912](https://twitter.com/zellyn/status/851818007248678912) [2] I've been on IRC on and off since 1993. It's _much_ worse.

<comment> grey-area Slack doesn't have _public_ links and an archive of posts, it's a stream behind a login, which might go away at any time on an active project. It's a terrible idea for anything other than ephemeral communications which don't need to be logged or kept. Re the UI, for a chat app it's fine, most conversations around an open-source project should not be held in a chat format however, but in a format that respects participants not being in the same time zone or having the same time pressures (that means an async format, not a linear chat).

If you want to have an open process (for discussions around proposals, bugs etc), you need an open, linkable, archivable format, ideally hosted somewhere you control. That means mailing lists or a public html server, not a private chat service which may or may not be around, which may delete data or change policies at any time. For this reason Github isn't great either, but at least it has public links and you could scrape the data if required.

</comment></comment><comment><USER67> Here's combined forum + chat + question & answers software that you might want to use instead of Slack:

[https://www.effectivediscussions.org/](https://www.effectivediscussions.org/) (ED)

It's open source. It seems to solve the problems mentioned in the article (I mean, openly accessible — can link to a discussion & (soon) to a post in a chat channel. Both sync & async communication (both chat and traditional forum topics).

I'm actually just about to a-little-bit start promoting it. ... Ok so let me try to make you more interested in ED:

\- Often, organizations setup a chat (e.g. Slack), a forum (e.g. Discourse) + use e.g. StackOverflow — but then they've split their community into three. However with EffectiveDiscussions (ED) you can gather everyone at one place.

\- ED is looking to improve the quality of the discussions. For example, there's a novel voting system that solves (I hope) problems related to people downvoting-because-they-disagree, + a novel algorithm for finding the "best" comments (in threaded HN style topics). Plus some other improvements over HN & Reddit, see [https://www.effectivediscussions.org/-32/how-hacker-news- can...](https://www.effectivediscussions.org/-32/how-hacker-news-can-be- improved-3-things)

(As you might have guessed, I'm the one developing ED.)

</comment><comment><USER68> A different take on solving the problem of asynchronous communication: JayPad is a simple web app which works like a tiny mix of Slack/Group Chat and Post- Its. Offering synchronous discussion via chat and the possibility to store results of these discussions into a container of Notes for asynchronous consumption.

In its early stages, but working beautifully.

[1] [https://jaypad.de](https://jaypad.de)

[2] [https://hackernoon.com/how-jaypads-help-us-build- jaypads-c66...](https://hackernoon.com/how-jaypads-help-us-build- jaypads-c66c07c6c3ae)

[3] [https://hackernoon.com/how-planning-a-weekend-trip-with- our-...](https://hackernoon.com/how-planning-a-weekend-trip-with-our-buddies- changed-our-perception-of-slack-and-whatsapp-1d53058f51d0)

[4] [https://www.youtube.com/watch?v=0g2Hecd- Ujo&](https://www.youtube.com/watch?v=0g2Hecd-Ujo&)

</comment><comment><USER69> The argument about why slack doesn't work well is a bit of a stretch. I understand all the points on closed system etc. But the author states that slack doesn't work because it's synchronous and it excludes others from participating in the conversation. Then mentions that even with history recorded, the person in a different time zone can't participate. Then the argument is to use email threads instead. email suffers the same problem of slack, where those who didn't check their email while a discussion was happening now feel missed out on. However, they can reply 8-20 hours later or even days later. Well, you could do the same thing with slack. The problem with slack is the lack of relevant threads. Everything is one giant thread. But that is how most email mailing groups become anyways.

Now, I am not a proponent of slack, I think it has its own problems, but I don't think email is any better.

</comment><comment><USER70> I think there are good points there about offline participation and archival. I would expect that 99.9% of those on HN have at one time or another found an answer via a direct forum/message list archive or off a google search result returning the same. That will not happen as discussions move to Slack like systems and even if it were, threading would not likely exist.

Addressing another point, and though I do use a Slack imitator for a small non-work/non-programming group - an advantage of IRC is that it can be part of many chat clients which handle multiple protocols. Thus I have IRC open with multiple Jabber chats and mucs. Slack et al, at least on the desktop, are space hogs (from those I have seen) and when I am working, space is a premium commodity even with two large displays. The last I checked, IRC integration into Slack is cumbersome and lacking, is this still so?

</comment><comment><USER71> Sounds like a great new splash screen for them.

"Slack is inappropriate for open source communications" \- Your friends at Slack.

</comment><comment><USER72> My HN feed right now:

4\. TypeScript at Slack (slack.engineering) 183 points .. 5 hours ago | flag | hide | 86 comments

5\. Why Slack is inappropriate for open source communications (cheney.net) 615 points .. 12 hours ago | flag | hide | 395 comments

Quite random, but I couldn't help but notice.

</comment><comment><USER73> Can we just go back to aim? I really hate having one damn view for channels, so if I'm talking to two people I have to constantly switch back and forth. I still don't get how these kinds of tools get such a big following.

<comment><USER57> I think that's the biggest flaw with a lot of web-based chats. There's no flexibility in layout. With a chat app like pidgin, I can choose how things are laid out, set up notifications a lot easier, etc. Webapps tend to be a lot more limited in such areas -- not able to choose notification sounds, set various things to notify in different ways, etc.

<comment><USER73> Yeah but no one seems to be making anything but web apps. I guess I come from a time just before this but I honestly can't understand how people think these things are better than their native counterparts.

</comment></comment></comment><comment><USER74> I think many opensource communities do not want to dogfood on other opensource projects anymore. They want the best product out there for other things and more often than not these products are closed source SaaS products.

</comment><comment><USER75> Just yesterday I was looking for a way to present all the messages in a given Slack channel as an RSS feed, and I was surprised to come up empty. (I found lots of ways to go the other way though, from RSS into Slack.) The best I found was this, but it looks like you need a Heroku Dyno and must be the account owner---oh and it only exports links, not full messages:

[https://gozman.github.io/slack-rss/](https://gozman.github.io/slack-rss/)

So that is one drawback to a closed system.

</comment><comment><USER76> Mailing lists really are preferable for a number of reasons but unfortunately Google Groups or worse, mailman is the interface, and they're both pretty bad.

<comment><USER77> "Mailing lists really are preferable for a number of reasons but unfortunately Google Groups or worse, mailman is the interface, and they're both pretty bad."

How in the world would you improve mailman ?

Not enough js for you ? Not enough on-hover events ? Too much plain text and obvious links ?

Please, please - to everyone reading this today and into the future - _do not fix mailman_. Go "fix" something else.

<comment><USER76> Well, not emailing me a password in the clear once a month would be a start. Needing yet another username and password for a site they already has its own some sort user login system is another wart that is easy enough to solve, but for some reason or another, hasn't been fixed on any sites in recent memory.

My email address was already validated with main site sign up, I shouldn't need to repeat that for every mailing list I want to subscribe to on top of that.

If you're reading this from the future, please let me know if any open federated systems managed to come into being, or if spammers finally managed to kill off email so important business is conducted via Snapchat.

</comment></comment></comment><comment><USER78> I have had good experience communication with the Aurelia.js community using Gitter. I strongly recommend it.

</comment><comment><USER79> Does Slack's terms of use forbidden creating an off platform archive?

If not, given that searchable archives are one of the ways Slack makes money, makes me wonder why there's not an open source way to pull the chats and archive them in a way that's cheaper and independent of Slack.

<comment><USER53> Yes, but chat logs are logs of ... chat. By nature, it's disorganised, free- wheeling, contains lots of casual meandering (as any conversation would). Not very useful to a third party.

How often do you find solutions in public archived mailing list posts when Googling problems? I imagine often. While some e-mails are more terse than others, fundamentally e-mail list posts demand a certain structure. Can you imagine having to pour through a 25-page chat log instead?

And with that, the entire idea of "search the archives before asking a question" would go to pot.

<comment><USER80> I did find some gems on irc logs, but I agree, they should be treated as snooping on conversations

</comment></comment></comment><comment><USER81> what do people think about zulip.org?

</comment><comment><USER82> I know most people hate meetings, but chats are worse. Maybe you want a Bulletin board system ?

</comment><comment><USER83> I was [breifly] part of a project that used slack as the primary communication medium. I can second all the points in the article. IRC is a terrible format for open source collaboration. Flame wars can get out of control really quickly via text.

</comment><comment><USER84> Feel like this argument happened 5 months ago and 5 months before that too

<comment><USER85> and it needs to continue to happen until OSS communities ditch Slack.

<comment><USER24> You're never going to move large groups of people by just yelling "xxx is terrible!" You have to make something better that people want to use to get them to switch. Unfortunately, Slack is better than IRC in many ways that matter to a lot of people. Ignoring all of those things doesn't make IRC better, and it's not going to make people want to use IRC over Slack.

</comment></comment></comment><comment><USER86> I don't quite understand what everyone has against email. Just get a good client and server with imap IDLE support and you should be good to go.

</comment><comment><USER87> I must've missed the memo which says any conversation around the globe is waiting for my input before it proceeds.

<comment><USER88> Well put.

But you may have missed the memo because you're in the wrong time zone, and with Slack, your possibly-relevant input is ignored because you can't participate in real time.

This is my beef with chat. As the OP says, it biases all conversation to those in the same time zone. Fine for some things (like baked goods arriving in some far-off kitchen), but not for others (like a design decision that should have input from stakeholders around the globe).

But it's often used for the reverse.

<comment><USER89> If a group has the choice between realtime and asynchronous channels there needs to be a guideline for this.

If my org takes pride in consensus for everybody, everybody needs to have the time to submit input. It's not uncommon that some active users in a chat go for an ad-hoc decision just because they are more than one and want to work _now_. In the long term this damages the culture, splits the participants and is difficult for newcomers.

<comment><USER88> I completely agree. Unfortunately, what I've seen more than once is that mgmt (or even someone from the rank-and-file) sees / experiences a new tool like Slack (or Campfire, or Hangouts, or...) and says "hey, great new tool we should use!" and that's the 'decision'. No thought given to how async comms biases development when developers are spread world-wide.

I gripe because I am a US left-coaster who works with a team that is increasingly based in Western Europe. By simply deciding to rely on Slack, they have essentially cut me from development conversations other than the weekly live session.

<comment><USER89> I feel ya, it's frustrating. Although I did not yet have a problem with time zones, I experienced being left out simply by joining the chat later in the evening.

</comment></comment></comment></comment></comment><comment><USER90> I like IRCCloud, it lets me use an open platform, but pay for archival of the channels I care about.

</comment><comment><USER91> Honestly wondering what benefit for business chat that Slack has over IRC for software devs?

</comment><comment><USER92> Free and unlimited 'Slack' is Bitrix24. Smart people switched years ago.

</comment><comment><USER93> Switched from Slack to Telegram. The desktop client is so much faster.

</comment><comment><USER94> Just discovered Gitter this week. That may be a suitable alternative.

</comment><comment><USER95> IRC (and Slack) are _not_ real-time. Why do people think this?

</comment><comment><USER96> I don't know why didn't just evolve irc. Feature wise slack doesn't really bring much new. It just has a good interface. If someone made an irc client as easy to use as slack then we'd have our answer.

<comment><USER97> > It just has a good interface

But this is such a big deal. You make it sound like a good interface is trivial. It isn't, and it makes a huge difference.

<comment><USER98> irssi is a significantly better interface than any slack application.

<comment><USER99> The technically illiterate people I know would have a much harder time using irssi than slack

</comment></comment></comment></comment><comment><USER40> I massively disagree with #2. Unless your project has very little activity, synchronous or pseudosynchronous communication is a lot more efficient than async through email/discourse. It's also a lot more friendly to your contributors, it makes things less formal and more human.

Async shines when you have a lot of users, but only if it's very accessible (searchable). Otherwise it's just people repeating themselves constantly.

Also, longer rant on the IRC thing. For the past decade I've been using IRC as my central mode of group communication for all open source work. Last year and as part of my (open source) company, I've completed the switch to Discord.

I'm an open source die-hard and it bugs me that Discord isn't open source yet, but I believe this has a fairly high chance of changing (MUCH higher than Slack has at any rate). I would heartily recommend Discord for open-minded open source communities.

I'm now using Discord for everything. It has given me a unified interface for all my personal _and_ group communications, easily searchable, with voice chat too (and video chat very soon, I cannot wait to never open Hangouts again). Needless to say, I'm a huge, huge fan.

Slack has none of that. The #1 thing that bugs me with Slack is the forced separate accounts for every single Slack instance. And you can't delete any of those accounts, you can only "deactivate" them.

Our open source community uses it. It works really well for us because we're a gamer-oriented open source community, so Discord is already pretty well known in that circle. On an ideological level, its API gives enough control over everything that goes in in it that I'm satisfied I could move to another service, should I need to. If anything, it's _harder_ to move off IRC because there's no public logs, easy point of contact for the regular users, etc.

Also, I'm using Matterbridge to mirror our public channel to IRC: [https://github.com/42wim/matterbridge/](https://github.com/42wim/matterbridge/) (highly recommend everybody here checks it out; it supports a lot of protocols)

IRC has really disappointed me the past few years. I had a lot of hope that irccloud.com would offer a solution to IRC becoming irrelevant in the face of Slack and Discord, but it just hasn't happened. They're understaffed and don't have enough money coming in.

There's also a lot of ideological purity in recommending against SaaS "centralization" for comms but the truth is, it's not better. Last year my HDD crashed and I lost the logs for my organization's original channel going back to its creation... I'm very, very sad about that. Had I been using IRCCloud (or Discord) at the time, I wouldn't have lost all that. Granted, those companies could have, but the chances are lower than me fucking up.

This is the same reasoning why email is usually better off handled by companies whose livelihood depends on offering you the service, than by yourself.

Also like I said elsewhere in this thread, for a project using a Freenode channel and another using a Discord/Slack server, there is no difference between Freenode disappearing and Discord/Slack disappearing. Your host disappears, you have to find a new one, update tons of references and contact lots of users to let them know. On IRC, that's even harder. You _can_ run your own IRC server, but very few do that, and those that do get less mindshare because connecting to yet another server is very annoying on IRC. It also costs you more, both in money and maintenance.

<comment><USER57> The biggest problem I have with discord is that the client is complete and absolute balls if you want to be in more than one group at once and keep up with notifications and the like. With IRC, my one client shows the activity of all of the networks I'm in, with discord, the only notification I get is that there's "something" going on in another group, without telling the channel, etc. It's much more interrupting and frustrating.

</comment></comment><comment><USER100> Some people only go to church on holidays...

</comment><comment><USER101> I've been making this exact case since it came to popularity.

There's tons of FOSS alternatives! No excuses!

</comment><comment><USER102> The article, at the end (spoilers) states that async communication should be preferred for open source work. And I agree that async is important. But there are times where you do need that synchronous, let's talk now communication. And for that, Slack is great.

</comment><comment><USER103> > _This means that the content inside those systems is closed. I cannot link > to a discussion in a Slack channel in a tweet._

Such a shame that you can't make a link in one closed system to another closed system.

> _The tools that fit this requirement best are; mailing list, issue trackers, > and forums._

Mailing lists _suck_. They're hard to read, hard to follow, and create an endless supply of unresolved issues that everyone forgets about. Big projects using mailing lists seem to do so out of inertia rather than choice.

<comment><USER58> > Mailing lists suck. They're hard to read, hard to follow,

I find them quite easy to read using a mail/news reader and connecting via a NNTP gateway like gmane.

</comment></comment><comment><USER104> Please, stop advertising slack. Any time when i read hackernews, i see 2-3 'news' about this chat program. It was big mistake to use slack in our company.

<comment><USER105> Curious why: as a specific tool, or, would IRC / Skype / whatever have been equally as bad (e.g. because they suck productivity and encourage factionalism or...)?

(My org uses it having replaced Skype for team chat, and so far it's been an improvement for us.)

</comment></comment><comment><USER106> 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.

<comment><USER29> > offer Github issues

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

<comment><USER106> 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.

<comment><USER29> 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.

</comment></comment></comment></comment><comment><USER107> It seems kind of funny that an open source project can't find an open source form of communication.

<comment><USER108> IRC and mailing lists have worked for 20? 30? years and continue to work today.

<comment><USER54> Well, then we can all turn off our computers and go home, because something that "works" is obviously good enough and the entire software industry doesn't need to exist anymore. Most things we have today "work" but we're still improving on them because "good enough" isn't good enough.

<comment><USER108> The question you're not asking is whether your replacement is better than the existing solutions. Slack isn't. It's closed source, proprietary, and tied to a third party's servers. I'm not going to tie my projects or company to that kind of anchor.

<comment><USER54> Absolutely. I completely agree that Slack brings too many problems to the table to be a replacement for IRC+Mailing lists.

I'm just saying that IRC+Mailing lists aren't good enough.

</comment></comment></comment></comment></comment><comment><USER109> Was hoping for something original but nope:

> these services are not open</comment>


Your company's Slack is probably sexist - <AUTHOR> https://work.qz.com/1128150/your-companys-slack-is-probably-sexist/ <comment><USER2> The article makes an observation that online communication favors a typically male communication style. That does not make you, your coworkers, or your company bad or inconsiderate people. There is no reason to respond defensively to an article like this, because it is not an attack. It is an observation on how modern work environments may favor one style of communication over another, and what role that gender socialization has in all of this.

What's important to gather from reading an article like this is that people are different. They communicate differently. Keep that in mind when you are communicating with them, because you may unintentionally be limiting their potential to contribute.

<comment><USER3> > male communication style.

I'm sorry but WTF does this even mean? Every individual person has it's own communication style AFAIK.

<comment><USER2> The keyword that you seem to strategically be removing is "typically". Yes, everyone has their own style of communication. From the article:

> Gender socialization helps explain these findings. "From age two or three, > kids show patterns where little boys are more assertive and girls more > indirect," says Herring.

If we are going to discuss an article based on studies supporting the idea that men and women are raised to communicate differently, we have to accept that there is room for some generalizations with how people communicate.

</comment></comment></comment><comment><USER4> The idea of being always available on Slack is bad for all programmers regardless of gender. Flow requires long periods of uninterrupted work. Sometimes intense thought outside of sitting at a computer. Slack sets up the expectation of instant communication from non-devs who don't follow the same schedule.

</comment><comment><USER5> It's interesting how the author reads the male behavior as indicating authority/confidence/etc. I usually just read it as poor social skills and general lack of awareness.

</comment><comment><USER6> > ... the ones who posted blunt statements, or dropped in links with no > context. They responded to others' statements with sharp critiques, "no," or > radio silence

I haven't seen many (any?) people fitting this description on my company's Slack, which makes me think this is more a reflection of culture in the author's workplace than of Slack as a medium.

</comment><comment><USER7> I've just logged into our Slack.

Seems we only share links to interesting GitHub repo's, issues on stuff we use and interesting blog posts about code/software architecture and devops related stuff.

Zero sexist messages.

But here's the thing: All male team. All white aswell. Are we an exception?</comment>


Database of private SSL keys for embedded devices - <AUTHOR> http://code.google.com/p/littleblackbox/ <comment><USER2>
      select * from firmare
      [...]
      [4:08pm:~] RIDGELAND:tqbf [0:6]% pbpaste | egrep '[0-9]+\|[0-9]+\|[0-9]+'
      | cut -d\| -f4-5 | cut -d\  -f1 | sort | uniq

Cisco|v188.8.131.52 - Cisco|v188.8.131.52 - Cisco|v220.127.116.11 - D-Link|v1.20b39 - D-Link|v1.20b44 - D-Link|v2.02NA - D-Link|v2.03NA - DD-WRT|Accton - DD- WRT|Aceex - DD-WRT|Actiontec - DD-WRT|AirLive/Ovislink - DD-WRT|Airlink - DD- WRT|Alfa - DD-WRT|Asus - DD-WRT|Avila - DD-WRT|Bountiful - DD-WRT|Broadcom - DD-WRT|Buffalo - DD-WRT|Compex - DD-WRT|D-Link - DD-WRT|DD-WRT - DD- WRT|DIR-300 - DD-WRT|DIR-400 - DD-WRT|DIR-600 - DD-WRT|Doodlelabs - DD- WRT|EAP-3660 - DD-WRT|ECB-3500 - DD-WRT|ECB-9750 - DD-WRT|EOC-1650 - DD- WRT|EOC-2610 - DD-WRT|EOC-5610 - DD-WRT|ESR-9752: - DD-WRT|Edimax - DD-WRT|GW- MF54G2 - DD-WRT|Gateworks - DD-WRT|JJPlus - DD-WRT|LaFonera - DD-WRT|Linksys - DD-WRT|Mega - DD-WRT|Meraki - DD-WRT|Micro_OLSRD - DD-WRT|NEWD - DD- WRT|NOP-8670 - DD-WRT|NS5 - DD-WRT|Netgear - DD-WRT|NoKaid - DD-WRT|OpenRB - DD-WRT|Pronghorn - DD-WRT|Special - DD-WRT|Standard - DD-WRT|Standard_USB_FTP - DD-WRT|TP-Link - DD-WRT|TRENDnet - DD-WRT|Tonze - DD-WRT|US - DD- WRT|Ubiquiti - DD-WRT|Ubiquity - DD-WRT|VINTAGE - DD-WRT|VPN - DD-WRT|VoIP - DD-WRT|Voip - DD-WRT|WHA-5500CPE - DD-WRT|WHR-HP-AG108 - DD-WRT|WLA-5000ap - DD-WRT|WLA-9000ap - DD-WRT|WP188 - DD-WRT|WRT610N - DD-WRT|WTR54GS - DD- WRT|WiliGear - DD-WRT|Wistron - DD-WRT|Xbox - DD-WRT|ZCOM - DD-WRT|dd-wrt.v24 - DD-WRT|dd-wrt.v24,Atheros - DD-WRT|v24 - DD-WRT|v24-preSP2, - DD-WRT|v24-sp1 - DD-WRT|v24-sp1,Consumer - DD-WRT|v24-sp1,Professional - Linksys|3.0.03 - Netgear|v1.0.0_09.25NA - Netgear|v1.4.20

Wireless access points.

<comment><USER3> I don't get why this post keeps getting up voted: it's mostly just a list of DD-WRT firmware, small percentage of the market most likely. And wouldn't that be the most likely candidate for the appropriate fix, i.e. uniquely generated Keys on each device, not preprogrammed, and a way to import your own?

<comment><USER2> Probably because it takes the 1.7 minutes required to download the stupid database, dump it, and sum it up for everyone else?

</comment></comment></comment><comment><USER4> This is why I have my own CA. Too bad the router manufacturers don't do the same; let the router generate a key-signing request, paste it into the manufacturer's site (with a "real" SSL cert), download file suitable for providing to the router, enjoy secure VPN.

Oh yeah, but that would add like fifty cents to the cost of every $150 VPN router, and we can't have that!

<comment><USER5> Fifty cents and another ten dollars or more to deal with the extra tech support.

<comment><USER4> When you unpack and plug-in a router, it automatically gets the current time without any tech support. Why not get an SSL cert too?

<comment><USER6> That works, but unless the router manufacturer has a sub-CA of a CA present in all browsers, the above "extra tech support" is very true. And those sub-CAs are _expensive_.

<comment><USER4> Cisco can probably afford it.

But remember, we're only talking about SSL-based VPN boxes here. Joe Average does not buy these, and the people that do are willing to pay; handling more than one connection does require some not-tiny hardware. (I have a Soekris router, and Gigabit Ethernet makes pf max-out the CPU at around 300Mbps. OpenVPN... sooner. And this thing was $300. :)

</comment></comment></comment></comment></comment><comment><USER7> This would only allow you to sniff/MITM SSL connections made by/to the router itself, right? Not connections made by users of the router to servers on the Internet. What do these routers use SSL for, anyway? Update checks? Admin control panels?

<comment><USER8> I use SSL for my admin control panel. I don't know if it's really useful but I feel better :-)

</comment></comment><comment><USER3> Great article. So what's the fix? What should the right approach have been? Let's see a solution!

And yes, I read the blog post associated with it and didn't see a solution: [http://www.devttys0.com/2010/12/breaking-ssl-on-embedded- dev...](http://www.devttys0.com/2010/12/breaking-ssl-on-embedded-devices/)

<comment><USER9> The devices should've generated their keys (and provided a legit key import and cert generation function) once initialised at home instead of pre- generating them.

Of course, I'm waiting for the inevitable mashup with this and firesheep.

<comment><USER10> That would protect against passive attacks with known keys, but it would do little to stop MitM attacks, since your freshly-generated certs haven't been signed by a CA.

Is there a way to add a unit-specific salt to a cert?

<comment><USER9> The easy way (and I'm not saying it's the right way, because it's not, but it's probably the easiest way of getting it more right than it is now without getting it right if that makes sense) is to generate a self-signed cert on initialisation. Make everything needed available for import and alert on changes. A unit specific salt isn't necessarily the right way forward. What you want is to import the private key (generated and confirmed on setup) to import a certificate.

</comment></comment></comment></comment><comment><USER11> Good to see Hacker News living up to its name.

</comment><comment><USER12> Mostly used for home vpns and router admin https it looks like. Also dd-wrt is fairly niche.</comment>


The Economy of Lebanon Is Collapsing - <AUTHOR> https://marginalrevolution.com/marginalrevolution/2020/07/the-economy-of-lebanon-is-collapsing.html <comment><USER2> Of course Lebanese economy was in trouble before Covid, but the pandemic made the situation worse. This might be a foreshadowing of what is in store for other countries, at least in part, if this covid induced shutdown of the economy continues.</comment>


How Can You Be in Favor of ISPs Collecting and Selling Your Data? - <AUTHOR> https://medium.com/@davepell/seriously-how-can-you-be-for-this-b9fa50a11d50 <comment><USER2> Easy. Politicians love campaign contribution bribes and ISPs see that bribe cost as minimal compared to the amount of money they stand to make.

No citizens required, needed, or wanted to make this easy, easy decision.

</comment><comment><USER3> > I know, I know. When Obama is for something, you have to be against it > because you have this thing with Obama.

Don't forget these protections were created in _1934_ , not 2016. They were removed in 2016, and reimplemented in 2016, but the new implementation will never come into fruition now.

This isn't just blind hatred of the Obama administration. These rules were put into place by FDR _before the internet existed_. This is blind hatred of regulation. This is blind partisanship against anything done by a democrat.

</comment><comment><USER4> I suppose if you are a major shareholder of an ISP you might see the upside.</comment>


The Personal MBA Recommended Reading List - <AUTHOR> http://personalmba.com/recommended-business-books/

<comment><USER2> This list has changed significantly over the last couple years. I'd be wary of entrusting your education to someone who is optimizing his reading list based on what's generating the most Amazon referral fees. At the very least go and find the original version.

</comment><comment><USER3> " If you're serious about learning advanced business principles, "

don't read, start a business yourself.

<comment><USER4> or do both

</comment></comment><comment><AUTHOR> A pretty comprehensive list of business books. What books do you think should be added to the list?

It would be great to see reading lists like this for other subjects. What books would a "Personal Computer Science Degree" contain?

<comment><USER5> The great thing about computer stuff is that it's so _easy_ to try it. Reading isn't enough, you need to do, but with many fields, doing isn't so easy. Talking about what you've read also helps some, which was one of the ideas behind Squeezed Books, which, unfortunately is not getting much traction.</comment></comment>


Show HN: Gadabout, a Ruby library and job DSL for Nomad - <AUTHOR> https://github.com/joshpmcghee/gadabout <comment><USER2> 1\. Can you explain what it is for? I really don't get it.

2\. Why do you put it on CI if you have no build steps/tests? [https://github.com/joshpmcghee/gadabout/tree/master/test](https://github.com/joshpmcghee/gadabout/tree/master/test)</comment>


Ask HN: Review my landing page, cowriter.co - <AUTHOR> I was hoping someone, preferably a marketer/growth hacker, would be willing to view my landing page and give some feedback.
Link: www.cowriter.co
Some background:
Me and my team launched CoWriter during a 24 Hour Startup Challenge. Within 3 days we had over $5000 in sales, from there we kept growing mostly from word of mouth. At this point we are at approximately $20,000 in pre-orders but have completely stalled out.
We ran some facebook ads and while they did bring traffic in we got no addition pre-orders from this.
Currently when users visit the site, over 90% of them don't even scroll down the page. They just read the top part and leave pretty quickly. At this time I am considering putting the video explainer at the very top.
I am a developer, not a marketer. I am open to any and all advice. I know there is demand for this product I just am not sure how to reach our audience.
PS: The video on the page is being replaced by a more professional one with a voice over. We are hoping this will help. <comment><USER2> This would make a good "Show HN:". Consider posting a direct link with that in the title. Add additional information as a comment after posting.

On my laptop, the call to action fills the screen from top to bottom. The Facebook, Twitter, etc. links signal a footer. The first time I visited, I didn't realize there was more if I scrolled down.

"Join the WriterVerse" may be a better call to action than "Say Goodbye to Writer's Block". The times I pathologize my non-writing as writer's block are pretty rare. The times I look to connect with other people are common.

Are there really thousands of authors? I don't see evidence. Is that really a selling point? One or two people who care seems like a better value proposition. That's something that could be done in a non-scaling way by founders.

This looks like a chicken and egg problem. Charging for a pre-launch is tough. Once I am paying, why should I review other people's work.

It seems like publishing is beyond a minimum viable product. What's the evidence for expertise?

My advice: Limit the scope. Make a few users happy. Build a community. Skip the growth hacking.

Good luck.

<comment><AUTHOR> Thanks for the advice! I am new here so I wasn't sure if this was good for a Show HN or not.

Fixed the call to action so it now shows you are supposed to scroll down.

Changed the call to action as well. Thanks for that. It does sound a lot better. :)

We do have thousands of authors, but I am not sure how to show evidence of that. I will remove it and just keep the testimonials of the 3 authors/publishers on the page.

I know charging for pre-launch is tough, but the grid succeeded so we were trying to do the same to see if we could manage it. We would rather not need a investment.

The publishing functionality is already built in. We take the stories that are written on our website and convert them to ePub, PDF, HTML, and Mobi automatically. This gets hosted on a special page and allows for the author to sell the book right there. No hassle. I suppose we could hold off the feature, but it feels like that's why most people would buy in. We do have an author & publisher on board as consultants.

Thanks for the advice. I will definitely start working on building the community we can always add our features in as we get users instead of launching with them all in.

</comment></comment><comment><USER3> Any site about writing has to be pretty immaculate with respect to grammar, usage, and punctuation to be taken seriously. This one could use some proofreading.

e.g. on front page:

Writers -> Writers'

comma between writers and and

Features page

With CoWriter you can -> comma before "you"

under Collaborate - comma between chat and or

etc. etc

I'm sort of hyperobservant of typos, so the average user may be fine with it.

<comment><AUTHOR> Thanks! I am a developer, not a writer so I am the greatest at this. I should have had our writers do the copy. :)</comment></comment>


The Specialized Field of Fetal Surgery - <AUTHOR> https://www.dmagazine.com/publications/d-magazine/2018/october/timothy-crombleholme-works-on-babies-before-theyre-born/?src=longreads <comment> trey-jones In 2009, when my wife was 20 weeks pregnant, we were told that our little girl in the womb had spina bifida. We had never heard of it. The next day we traveled to Atlanta to see a specialist and get some more information and a second opinion.

One of our options was to move to Philadelphia for probably 6-8 months to be a part of a trial one of the in-utero surgeries referenced here. We declined for several reasons:

* All the daunting decisions that might come with relocation

* Possibility of her being in the control group

* Additional risk to her from in-utero surgery

* Unknown benefit compared to post-natal surgery

Maybe some others. For us, relocation would have been a huge disruption of our life and goals at the time. If not for that we might have been more interested.

I sometimes wonder if I should regret that decision, now that studies are showing outcomes to be better overall, but I don't. We are happy. Our child is not without issues, but she's OK, and we obviously have no insight on how making the opposite decision would have changed her life or ours.

My wife was also able to have VBAC for both of our other children. I'm not sure this would have been possible, had we gone through with this. A small thing, but not insignificant to us.

<comment><USER2> Humans are bad at assessing risks. 1 out 1000, sounds really low but to the one person it happens, it is everything.

</comment></comment><comment><USER3> FYI, due to the complications involved with dosing anesthesia at small weights, surgery was for the most part done on babies without anesthesia prior to 1986.

Obviously I think it should be done, but it brings up a fascinating philosophical debate and shows how different surgeries on babies and those and the womb can be. Many of those who've had surgery as a baby no longer recall the pain. Does this make what happened okay? Some ppl argue circumcising causes a great deal of pain, but there is no society-wide memory of searing pain from that procedure.</comment>


Ask HN: Do purely ad-based web sites still make sense? - <AUTHOR> It looks like even with 1M monthly page views, it would be tough to generate $10k. It seems like it'd be pretty tough to market a website to that level.
I have a service I was building just for myself to fix some problems with online movie, tv, book, etc reviews -- sort of like FakeSpot -- but after doing the math, I'm wondering how much energy I should put into marketing it. The upside seems pretty low, and the costs can be quite high...
Does anyone have any success stories with an ad-based website? <comment><USER2> Affiliate links are probably a better way to go than pure ads. e.g. Amazon

You can have a gander over at old.reddit.com/r/juststart - there are lots of case study type posts that give you a sense of how these things scale (or don't).

<comment><USER3> Second that. Or something similar. Link people to products they actually like and came to site for.

</comment></comment><comment><USER4> You can still make really good money with ads, you just can't rely on Google AdWords. If your site has a very specific bit of content that isn't drivel (like pop culture gossip) then you can work with brands or ad networks to find good advertisers that will pay more because of the audience you bring. I agree that affiliate is a great way to monetize but that doesn't mean ads are bad; you can do both.</comment>


You Can't See It, But You'll Be A Different Person In 10 Years - <AUTHOR> http://www.npr.org/blogs/health/2013/01/03/168567019/you-cant-see-it-but-youll-be-a-different-person-in-10-years

<comment><USER2> Biologically, you'll be a different person in much less time :-)</comment>


The Story Behind Susan Kare's Iconic Design Work for Apple - <AUTHOR> https://milanote.com/the-work/the-story-behind-susan-kares-iconic-design-work-for-apple <comment><USER2> What is the source of these quotes? If it's an original interview, you should say so. If from somewhere else, you should say where and link to it.

<comment><USER3> To my recollection having just watched it a few months ago, the quotes and figures are all pulled directly (and uncredited), from the talk she gave at the Layers Design Conference, 2015. [1] Of course she's maybe given this same talk on other occasions but the OP is a shoddy piece of work. The video's worth your time if the topic interests you, she had some other interesting anecdotes about the Apple days and her work after also. Just don't waste your time with John Gruber's Q&A at the end, he wasn't on the same page as her at all.

1\. [https://vimeo.com/151277875](https://vimeo.com/151277875)

<comment><USER4> Aww! Seems like she lost that fun New York accent she had.

[https://youtu.be/AY1-UYnaBm8](https://youtu.be/AY1-UYnaBm8)

</comment></comment></comment><comment><USER5> These basic designs pretty much stayed the course all the way through OS 9, and some even in OS X. It's gotta be surreal to think something she designed is on millions of devices. Reminds me of someone I met who wrote video drivers for Intel. It's something small you don't think about, a tiny piece that is essential in bringing the whole thing together.

Too often we think about the captains of the ships, the Gates and Bezos and Musks of this world. People attribute so much to them, when all they really did is convince other people with actual skill to make the things they wanted. I doubt Elon could design the engine of a rocket. There are no Tony Starks outside of the movies. There are 60 ~ 150 engineers who carefully design and check each others work.

It's like when we see Columbus discovering the new world, even though so many other civilizations had discovered it before him, ignoring all the ships and crews that got him there, and the fact that the new world was named after Amerigo Vespucci, the cartographer who actually mapped it out.

There are hundreds or thousands of engineers and designers like this one, who are the people who really make these products real.

<comment><USER6> Gates was quite heavily involved in making Microsoft's early products, long before they had '60 to 150 engineers'. In the case of Jobs, the really enduring mystery to me is that despite some seemingly disqualifying personality flaws, he managed to both surround himself with very talented people and get them to do outstanding work together. Once, you could chalk it up to luck but somehow he did it repeatedly.

<comment><USER7> I found the anecdotes from John Carmack about working with Jobs really interesting in this regard. Apart from being probably very smart Jobs did care a lot about the things they were building, and willing to throw everything overboard if you could convince him that an existing approach was not the right thing to do. It is something many managers or leaders lack IMHO, not willing to do the "right thing" because of politics, market studies or something else.

<comment><USER6> I didn't get that impression from the Carmack stories at all. If you haven't had a chance before, dig into the early Mac development history at folkore.org. A number of the stories involve the team engaged in some (in hindsight) hilarious and ridiculous effort to humor, misdirect or otherwise manage Jobs in situations that arose primarily from him being profoundly, stubbornly, catastrophically wrong. The eventual resolution never involves Jobs saying 'ok, ok, you lot were right, let's do it your way'.

<comment><USER8> >The eventual resolution never involves Jobs saying 'ok, ok, you lot were right, let's do it your way'.

That would be un-becoming of a narcissist and a leader. What he would do, is to do a 180 and claim that it was his idea all along. From a dispassionate point of view this is actually good since all sides of a contentious issue can be fully explored, but it sure feels shitty when someone steals your idea and claims it as his own.

<comment><USER9> _> but it sure feels shitty when someone steals your idea and claims it as his own._

Such is the life of the salaried employee.

There are advantages though, in that you don't have to run with the idea. You can just go home in the evening and be with your kids.

Also, if it turns out to actually be a bad idea it's not your problem either!

</comment></comment></comment></comment></comment></comment><comment><USER10> Articles tend to pigeonhole her as an Apple designer, but that sells her influence short; Kare also designed the icons for Windows 3.x and the cards for Solitaire.

</comment><comment><USER11> For those who wonder, the uncredited cartoon strip

"When you look at a photo or see a realistic face, you see it as the face of another; but when you enter the world of cartoon, you see yourself"

is from Scott McCloud's excellent "The Invisible Art" [1].

Cannot recommend it strongly enough; it contains a rich and enlightening analysis of cartoons, and through that of the way we human perceive and communicate using graphics.

[1] [https://www.amazon.com/Understanding-Comics-Invisible- Scott-...](https://www.amazon.com/Understanding-Comics-Invisible-Scott- McCloud/dp/006097625X)

</comment><comment><USER12> For the lazy: the symbol (⌘) has apparently been used at Swedish campgrounds and parks for decades. It's used to denote interesting features, both natural and man-made. It was inspired by the way Swedish castles look from above (a central building with a turret at each corner).

<comment><USER13> Apparently it started being used to denote a place of interest in Finland in the 1950's. Funny enough I have always thought that sign was universal, understood by all culture to mean you can park your car here and see something interesting.

[https://en.wikipedia.org/wiki/Looped_square](https://en.wikipedia.org/wiki/Looped_square)

<comment><USER14> There's just few things that are truly universal. One example from somewhat nearby: nodding means "no" in Bulgarian.

<comment><USER9> I've also met some Indian guys who bob their head when they're in agreement which is very similar to how I'd be used to people I know shaking their heads in disagreement.

<comment><USER15> I see that as a kind of figure-of-8 movement... when my friend and I visited India we decided that it was a cross between a nod and a shake ie. ambiguous yes/no, non-committal

</comment></comment></comment></comment></comment><comment><USER16> My mother keeps calling the feature symbol "zolbia" for its resemblance to the middle eastern pastry, so whenever I have to help her over the phone I have to tell her to press zolbia-so-and-so instead of command-so-and-so.

</comment><comment><USER17> > Kare also developed the icons, such as the trash can for discarding files, > that helped define graphical interfaces. She and Jobs hit it off because > they shared an instinct for simplicity along with a desire to make the Mac > whimsical. "He usually came in at the end of every day," she said. "He'd > always want to know what was new, and he's always had good taste and a good > sense for visual details." Sometimes he came in on Sunday morning, so Kare > made it a point to be there working. Every now and then, she would run into > a problem. He rejected one of her renderings of a rabbit, an icon for > speeding up the mouse-click rate, saying that the furry creature looked "too > gay."

</comment><comment><USER18> We couldn't afford a Mac when I was a kid, but Susan's icons were one of the primary things that made it stand out as "special". From the trash can to the fact that it booted up with a smiling Mac icon, instead of the typical stream of bios logs on every other machine of the day.

</comment><comment><USER19> I hope she got disgustingly rich from her time at Apple. Her designs were an integral part of making the Mac what it was and is today.

</comment><comment><USER20> I wonder if graphical user interfaces will become less relevant as natural language, both voice and text, become more capable via A.I. No need then to learn icons.

<comment><USER21> That will happen as soon as natural language isn't incredibly painful to use with computers (or other humans, for that matter).

<comment><USER22> I think it's a pretty safe bet that computer experts (developers, admins, etc.) will be both the first ones and last ones to use GUIs (just like for TUIs).

</comment></comment></comment><comment><USER23> Thanks for introducing me to Milanote

</comment><comment> cup-of-tea It's seen on Swedish road signs because it was copied from Swedish road signs. Did anyone really think it might be the other way round?

<comment><USER24> I don't think anyone is confused that the origin is swedish road signs. to quote from the article:

"I was just not sure what a 'feature' looked like … so I was thumbing through a symbol dictionary and I came across this symbol (⌘). In the back of the book, it said it was for an 'interesting feature' at Swedish campgrounds. I thought it was maybe a little abstract, but it worked."

<comment> cup-of-tea The original title of this submission was something like "Why is the Apple symbol seen on Swedish road signs?" It was clearly renamed and now my comment makes no sense.

<comment><USER25> It was: What is the Apple ⌘ symbol doing on hundreds of road signs in Sweden?</comment></comment></comment></comment>