35 ms·

Why Slack is inappropriate for open source communications

• johnomarkid 10y ago
  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.
  • fiatjaf 10y ago
    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.
    • artursapek 10y ago
      It's easier to ask for help NOW and get customized answers NOW than to dig through a wiki/documentation for the answer.
      • rdiddly 10y ago
        Proving the point that someone then has to repeat the content of the docs.
        • artursapek 10y ago
          Of course - I'm just saying it's easier for the customer/consumer.
      • maccard 10y ago
        It's easier for you. As the person who answers your question, it's easier for me to point you at the documentation
    • tetrep 10y ago
      > 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.
      • branchly2 10y ago
        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.
        • BuuQu9hu 10y ago
          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.
          • mverwijs 10y ago
            > Fix your group's culture. Culture-change is about the hardest thing to achieve.
            • npizzolato 10y ago
              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.
        • joshuamorton 10y ago
          Then that person is doing all the legwork, but someone else can come along and create a KB themselves with those answers.
  • maxxxxx 10y ago
    I have recently started using slack and I see the same. Once a conversation has moved on it gets awkward to move back to the previous topic.
    • ntaylor 10y ago
      This may be a shortcoming of the UI, more than anything else. There's definitely room for improvement here as I often miss updates to threaded conversations even as I'm looking for them.
      • hehheh 10y ago
        I think they could make threads work with some simple changes: * Optionally show thread replies in-line with chat, as they come in, just like regular chat but with some special annotation to indicate they're part of a thread. * Allow the user to collapse a thread so they no longer see it in-line. * Auto-close threads after they're idle for more than 1 hour (or some site-policy-configurable timespan). * Allow the user to navigate between threads using only their keyboard. As they are now, I think threads are bad for business. They hide useful information away and slow conversation (responses dragged out because they're no longer in your face).
  • delias_ 10y ago
    If I really wanted to bring up a topic that had passed, I would break out to a separate channel and invite the relevant people and drop a note in the main channel with a "bringing things back up about $conversation in #newchannel". This works better than writing to threads in my experience.
  • ska 10y ago
    Chats (of whatever type) have never been a good solution for this, that's why mailing lists exist. Improvements there would be nice, sure, but are unlikely to come from a chat service. They just solve different problems.
  • freehunter 10y ago
    What you're looking for is email. Multi-user chat simulates a real life conversation, and in real conversations it's also awkward to say "hey so going back to what we were talking about 15 minutes ago..." after the conversation has moved on.
    • NateDad 10y ago
      No, email is terrible. There's no history. You can't "scroll up" to see what people were talking about. You can't link to another specific email to reference it (yes, there's archive services, but then you have to go dig through an archive to try to find a horridly formatted email to link to, which is completely separate from the normal consumption platform).
      • freehunter 10y ago
        I actually argued here recently that email was hard to switch away from because of the history. You can keep your emails forever. I have emails from 2007 sitting in my inbox. And if I want to keep them, I can download them with IMAP or POP. If I send an email to five people and they remember to hit "reply all", well that's a conversation, isn't it? And if I need to show someone an email they weren't party to originally, I can forward it to them.
        • NateDad 10y ago
          That puts the onus on every single person to maintain the history of the project. Lots of people delete mail (not me, but lots of people). Also, you can't retain history of what was sent before you joined. Also, emailing individual documents means people can't research by themselves.
          • freehunter 10y ago
            I mean, email isn't meant to be a document repository. Slack (or other chat) is great for immediate conversations with many people. Email is great for slower conversations with a more limited number of people. A wiki is great for a very slow conversation. An actual document repository is great to be able to link to when using any of the other conversation methods. Just because Slack isn't good at slow conversations doesn't mean it's bad. Just because email is bad at including people who joined after the fact doesn't mean it's bad. Those aren't their strengths, and that's fine. They still serve their own purpose just fine.
  • lucb1e 10y ago
    I never used Slack, but in IRC I'd quote what the user said (a format like "<user> message", optionally with a time) if it's really relevant; and in Telegram it's a simple matter to rightclick and reply (which allows people to click/tap it to jump back to context) which I feel much less bad about.
  • codingdave 10y ago
    This is more of a usage problem that anything else. If your organization makes decisions based on synchronous communications, without stopping to notice who wasn't included and get their input before final decisions are made, that is a cultural problem, not a tooling problem.
  • flukus 10y ago
    The biggest problem I had is that if you wanted to scroll back through those 50+ new messages you need 32GB of RAM.
• caseysoftware 10y ago
  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.
  • cristaloleg 10y ago
    Well, some of the open communities are using http://slackarchive.io/ http://slackarchive.io/
    • deleted 10y ago
      [deleted]
    • michaelmior 10y ago
      Thanks for the pointer! Hadn't seen this before.
    • smhx 10y ago
      thanks for the pointer. I started using this today for pytorch
  • drey08 10y ago
    Just a note: if you go from free to paid, you can recover those lost messages. They're never actually deleted, you just can't view messages after the 10k limit in the free version.
    • uiri 10y ago
      Wow, that is kind of evil. I could understand if Slack kept, say, the last 20k or 50k and only showed the most recent 10k. For them to store all the messages indefinitely for all free servers means that they are incurring the same storage costs whether the server is free or paid. Are the bandwidth costs really that high to justify hiding all those messages (likely on the order of 100k or 1M for many servers) ?
• Proven 10y ago
  Slack is okay if used appropriately. Sometimes there's just general trash talk or real time chat and Slack is perfect for that. We who use it don't want to have low value info pollute google search results. And we also have a public forum for info that should be searchable and requires asyn comms. Of course like with anything if you're a fool and use it wrongly, you want get good results with it.
• ntaylor 10y ago
  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.
  • rckrd 10y ago
    I believe the Cloud Native Computing Foundation qualified for discounted pricing for the Kubernetes slack channel under this program https://get.slack.help/hc/en-us/articles/204368833 https://get.slack.help/hc/en-us/articles/204368833
    • caniszczyk 10y ago
      This is true: https://www.cncf.io/blog/2017/03/01/slack-gives-back-k8s-cncf-community/ https://www.cncf.io/blog/2017/03/01/slack-gives-back-k8s-cnc... Slack extended their not profit pricing to 501(c)(6) not profit organizations which covers CNCF projects like Kubernetes.
  • caseysoftware 10y ago
    But if your entire infrastructure is centrally managed and can disappear at a company's whim, you're setting your community up for problems.
    • joelberger 10y ago
      This is the point that I can't get anyone to see. So what if they provide history? They can take it away at any point too. So what have you accomplished?!
    • scrollaway 10y ago
      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.
• lordCarbonFiber 10y ago
  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
  • lindner 10y ago
    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.
    • lordCarbonFiber 10y ago
      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.
    • qznc 10y ago
      Yes, Matrix has great momentum. It is somewhat sad that XMPP is falling behind. There is no technical reason, why Matrix should be superior, but they are winning.
  • danyork 10y ago
    Similarly, the huge buzz over the past few weeks about Mastodon as a distributed/decentralized micro-blogging service has been positive. People starting to learn more about federation and decentralization. Good to see.
• mfukar 10y ago
  I must've missed the memo which says any conversation around the globe is waiting for my input before it proceeds.
  • creeble 10y ago
    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.
    • grx 10y ago
      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.
      • creeble 10y ago
        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.
        • grx 10y ago
• hxnjxn 10y ago
  Feel like this argument happened 5 months ago and 5 months before that too
  • aarpmcgee 10y ago
    and it needs to continue to happen until OSS communities ditch Slack.
    • npizzolato 10y ago
      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.
  • Stranger43 10y ago
    It's been going one since the first companies tried to monopolize Internet chat by centralizing it on their infrastructure in the 90ies. The argument for AOL/MSN etc back when the Internet was new openness for the unwashed masses just a dream is exactly the same being made by slack i.e. that by making it locked and taking away the complexity introduced by the existence of cross vendor compatibility new users face less confusion.
  • s73ver 10y ago
    Well, this one was supposed to be a little different, as instead of open vs closed, it was sync vs async. But when the topic of OS projects and closed tools comes up...
  • richardwhiuk 10y ago
    Because the things that are driving people to use Slack are the same as existed five months ago, and arguments like this do nothing to prevent people moving.
• spectistcles 10y ago
  It seems kind of funny that an open source project can't find an open source form of communication.
  • zuron7 10y ago
    I might be wrong in saying this, but I suppose that most open source projects use IRC, and the larger, important ones use mailing lists.
  • coldpie 10y ago
    IRC and mailing lists have worked for 20? 30? years and continue to work today.
    • Pxtl 10y ago
      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.
      • kuschku 10y ago
        Exactly, that’s why we evolve them (see ircv3.net), or try to reinvent them (see matrix.org), and don’t try to make a proprietary clone and sell it.
      • coldpie 10y ago
        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.
        • Pxtl 10y ago
          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.
• isaiahg 10y ago
  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.
  • chrisseaton 10y ago
    > 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.
    • apocalyptic0n3 10y ago
      It really is. Slack's interface is good enough and easy enough to understand that even the least technical people can pick it up in a few minutes after you show it to them and explain the difference between public and private channels. A week or two of use is enough to master everyday Slack use. Slack may not bring much to the table in terms of new functionality, but it does make it insanely easy for the average person to easily use the system and be involved, which really cannot be overstated when working at a company with a varying level of technical abilities.
    • thraway2016 10y ago
      irssi is a significantly better interface than any slack application.
      • Karunamon 10y ago
        Slack's users would disagree.
      • Eldt 10y ago
        The technically illiterate people I know would have a much harder time using irssi than slack
  • StavrosK 10y ago
    Because adding a feature to a standard means you have to get everyone on board. Slack as an IRC client would basically be Slack as it is now, and the server protocol would be an implementation detail.
• piquadrat 10y ago
  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?
  • pmarreck 10y ago
    Slack chat provides a number of nice features that IRC (at least out of the box... I know there have been attempts) does not. IRCCloud at least lets you see chat history, which IRC doesn't have out of the box but Slack does.
    • exelius 10y ago
      So get a better IRC client? Really not hard to do things like syntax formatting and auto link follow (GUI versions of IRCII had plugins for this in the late 90s, so it's not like it's even a novel idea).
      • cortesoft 10y ago
        A better IRC client isn't going to provide chat history.
        • jstanley 10y ago
          An IRC bouncer (e.g. znc) can do this, but it's far from seamless.
        • VLM 10y ago
          Just run your IRC client in screen/tmux like we've done for a quarter century. The real advantage of slack isn't even client its stuff like massive logging for e-discovery and single sign on integration. Admittedly not terribly appealing for FOSS but once you use it at work... Also integrations in general are smoother in slack than in IRC. Someone has already written the bot and its a click away to install and it generally works.
• otterley 10y ago
  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.
  • pseudalopex 10y ago
    Are there any open source projects that coordinate development or provide support primarily through in-person discussions at conferences?
    • steveklabnik 10y ago
      I don't know about "primarily", but it's certainly an important aspect overall for many projects.
  • michaelmior 10y ago
    Except with both Slack and Gitter (not sure about others) you can link to specific messages. Sure you still need membership to view the content (a serious downside), but saying you can't link at all is disingenuous.
    • otterley 10y ago
      With Slack, at least, channel history is truncated for free accounts; so it's quite possible that a specific conversation could become practically inaccessible after a while.
      • RyJones 10y ago
        You are able to export your entire public history, regardless of the status of your account. I was able to do this to rescue the chat history for Hyperledger[0][1] before we moved to Rocket.Chat. [0] https://github.com/hyperledger/slack-archive https://github.com/hyperledger/slack-archive [1] http://slack-archive.hyperledger.org/html/index.html http://slack-archive.hyperledger.org/html/index.html
• wonderous 10y ago
  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.
  • pavement 10y ago
    forbid creating an off platform archive I'm not sure that's a substantively enforceable idea. Just try and stop me?
    • Filligree 10y ago
      Break the terms of service, and you'll be booted off. Be a large enough problem, as they see it, and you'll get the entire project booted off. Probably they don't care enough to enforce, but surely you see it's part of the problem that they could?
      • pavement 10y ago
        Right, but they do still permit the capacity to read accessible history, which is open to scraping and archiving. They can't completely kill the concept of doing that, realistically. They can't stop someone from creating an archive that's inaccessible to them, if they don't know of its existense. Anyone can create an archive of something they can read and hide it, and selectively share it. Such an agreement on curtails specific forms of automated crawling and public-facing archives.
  • cortesoft 10y ago
    Like http://slackarchive.io/ http://slackarchive.io/?
    • wonderous 10y ago
      Is an example of a third-party archiving chat, though doesn't appear to be open source; possible it is though, but if it I'm unable to find the code.
• alistproducer2 10y ago
  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.
• golergka 10y ago
  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.
  • cat199 10y ago
    > 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?
    • golergka 10y ago
      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.
      • cat199 10y ago
        > 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.
• zellyn 10y ago
  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.
  • grey-area 10y ago
    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.
  • kuschku 10y ago
    > [2] I've been on IRC on and off since 1993. It's much worse. So? There are services offering that, too. Linkability is easy to add to IRC as soon as you are using logging systems and modern bouncers such as IRCCloud or Quassel.
  • aeorgnoieang 10y ago
    'Async' isn't even that good of an argument. Have you never replied to an old forum post and been accused of 'necromancy'? Have you never been late to reply to an email chain or a thread on a mailing list or forum? There's no clear line dividing asynchronous versus synchronous communication. Even phone calls can be (partially) asynchronous – "hold on, let me check" let alone "let me call you back in <some amount of time>". And similarly, if a group of people are responding to each other quick enough, even using an 'asynchronous' medium, then they're basically communicating 'synchronously'.
• xfalcox 10y ago
  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.
  • throw2016 10y ago
    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.
    • aeorgnoieang 10y ago
      I did just run across a cloud provider with $5 VMs with 1 GB of RAM (somewhere), but the last time I checked it's at least $10 per month to host Discourse on DigitalOcean or similar.
    • xfalcox 10y ago
      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/INSTALL-cloud.md https://github.com/discourse/discourse/blob/master/docs/INST... 2: https://blog.discourse.org/2016/03/free-discourse-forum-hosting-for-community-friendly-github-projects/ https://blog.discourse.org/2016/03/free-discourse-forum-host...
    • spectistcles 10y ago
      To be fair, you don't actually need to know Docker beyond being able to follow a tutorial.
• PaulHoule 10y ago
  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.
  • 27182818284 10y ago
    >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.
    • treve 10y ago
      > 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. If you need to log in more than once, can you really call it SSO? =)
      • falcolas 10y ago
        If it's anything like my experience, the trip from clicking on the button to open the app and wait for the myriad of redirects, before clicking through to the page you actually want to monitor is non-trivial (and sometimes doesn't occur if the tab isn't in the foreground). I don't have that many open, and it still takes me around 5 minutes every day to open them back up.
• Pxtl 10y ago
  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.
  • vertex-four 10y ago
    Orrr there's "modern" open tools like Matrix+Riot, too, which would fit most open-source communities wonderfully.
  • grx 10y ago
    Hmm.. Matrix? XMPP?
  • _jal 10y ago
    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?
    • abalashov 10y ago
      > What limitations do mailing lists impose on open source development that are not present in other tools? None, in my opinion. On the contrary, they are the only tool that demand a structure — just by the nature of e-mail messages — that is coherent enough to be highly useful when searching archives later.
      • u801e 10y ago
        > On the contrary, they are the only tool that demand a structure — just by the nature of e-mail messages Newsgroups also have this structure and they have the advantage of easily doing an archive search (by being able to download part of or the entire message archive of a given group and using the search features of your mail/news client).
• patrickg_zill 10y ago
  Mattermost is an open source alternative to Slack btw. And Discourse is pretty great, though much more like a forum.
  • simopaa 10y ago
    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
    • patrickg_zill 10y ago
      Also a good choice.
• Raphmedia 10y ago
  I have had good experience communication with the Aurelia.js community using Gitter. I strongly recommend it.
• branchly2 10y ago
  Forums work better. Using IRC/Slack in place of forums is like using a wiki in place of real documentation.
  • abalashov 10y ago
    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.
  • Sanddancer 10y ago
    Forums fall apart when you're trying to do things like realtime debugging. With a chat client, I can leave a window open in a corner and keep an eye on it while doing other things. With a forum, that becomes a game of hitting refresh every thirty seconds waiting for new messages.
• scrollaway 10y ago
  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.
• s73ver 10y ago
  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.
• deleted 10y ago
  [deleted]
• joaodlf 10y ago
  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.
  • mmanfrin 10y ago
    Reddit and Facebook ate forums. Reddit in particular fills that interest-niche conversation role to a degree that it strangles forums.
    • monkpit 10y ago
      Reddit IS a forum platform. Anyone who wants to create a subreddit can do exactly that. Reddit did not replace forums, just the software that they run on.
      • projektir 10y ago
        Reddit is distinctly different from a typical forum due to how heavily it weighs time and popularity. A normal forum can have multiple threads of thought active at the same time without interference, and sometimes a thread can live for a long, long time. There's no need for a thread to be super popular to survive, a thread can literally live off of two users. On reddit, if the time is not right, the discussion will not be had and ends up in oblivion.
      • flukus 10y ago
        BUMP! Doesn't work with reddit.
  • lucb1e 10y ago
    The forums I visited all died, but none replaced them (and I kinda miss forums). There are still some active forums that I know of, like Factorio's (a modern game, not one from 2001 when forums were still hot). They have a subreddit which is active as well (though less), but the forum format still works fine for them. New services replaced many things that forums were used for, but not all.
• Underqualified 10y ago
  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.
  • misterbwong 10y ago
    I'm with you on the personal interaction but I think people like slack/email/IM because it allows them to be in control of their communication. If someone drops by your office/cube, it snaps you out of your flow and you have to work to pick it up again. With the online forms of communication, you can turn them off and be guaranteed some distraction free coding time.
  • grub5000 10y ago
    Easier to compose an eloquent and effective reply in chat than in person. Time to think over the messages etc before responding. Can pick my nose while talking to you etc.
  • IanCal 10y ago
    As someone who works remotely, I really appreciate things happening more on chat channels, because then I'm included in part of them. > But personally I prefer a little personal interaction over a long chat. Although it's hard to schedule an 80 second meeting between five people, but a quick set of questions and answers might only take that long.
  • joombaga 10y ago
    For me it's probably selfishness. I'm an infinite inboxer, who prefers synchronous communication (if any). If I need something, I'm going to walk up or call, and yet my door stays closed. So the two preferences aren't mutually exclusive, but in my experience these generally ARE different people altogether.
  • lucb1e 10y ago
    > 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. Chats are much less interrupting. When someone walks in, you have to look at them (it's rude to keep typing and look at your screen), your brain starts to assess who it is and their mood and pulls into an appropriate facial expression, and you have to start listening because your audio buffer is much more volatile than your chat client's message log. Even if you're just finishing the "hope to hear from you soon" of an email, you typically have to acknowledge someone's presence and already detect who it is (someone two levels above your paygrade, you'd not want to keep waiting, while you would let a peer wait for that email to get sent out). I don't know how much of that subconscious activity really interrupts flow, but I notice it's annoying. For chat, group messages don't trigger notifications and they just get looked at when I have a second. If someone needs me specifically, they'll mention me or send a private message. In those cases, I will notice the notification but will (depending on how concentrated I am) either not process it beyond "there's something" or not beyond judging whether it's urgent (based on the first five words, or whatever makes it into the notification). I catch myself thinking "wait, someone sent me something, I totally forgot" and it turns out there are no unread chats. What must have happened is that I alt-tabbed back and forth to make the unread-message counter go away (and give them the double tickmark to indicate I saw it) because what they sent did not need further processing (something like a final "okay"). That did not interrupt flow. --- On top of that, what others have said: external people (at clients', at home, whatever) can follow chats along; you can do stuff in between messages; you can pick your nose during conversations; and you can have an 80 second meeting between five people. I think an uninterrupted private office and "instant" messaging are not mutually exclusive things.
• newsat13 10y ago
  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.
• jsat 10y ago
  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.
  • INTPenis 10y ago
    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.
• Arzh 10y ago
  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.
  • lucb1e 10y ago
    How did AIM do that? I've never used it. (In my geographical region MSN was the thing.)
    • mi100hael 10y ago
      For a long time it opened a new window for each conversation so you could have a few going at once and see them all side-by-side. At some point tabbed windows became standard, but I'm pretty sure most clients like Pidgin will still give you the option of separate windows.
  • Sanddancer 10y ago
    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.
    • Arzh 10y ago
      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.
• fragmede 10y ago
  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.
  • daenney 10y ago
    > Mailing lists really are preferable for a number of reasons What reasons?
    • fragmede 10y ago
      The biggest reason is that it's asynchronous. Not everything needs an answer right now this instant, and in order for there to be an instant reply, someone has to be on the other end of the keyboard and continual interruption is a way to get nothing done real fast.
  • rsync 10y ago
    "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.
    • fragmede 10y ago
      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.
• rsanheim 10y ago
  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-744659addf7d https://m.signalvnoise.com/is-group-chat-making-you-sweat-74...
  • tmail21 10y ago
    Hope this does not come across as self-serving, but I think it is relevant to the discussion. We have built a product around what we call "Deep Collaboration". Deep Collaboration is fundamentally asynchronous in nature. The term is derived from Cal Newport's book on Deep Work. Deep Collaboration allows teams to collaborate asynchronously thus enabling Deep Work (which group chat basically kills). If you read his book (highly recommended btw) you will see how individuals (and organizations) can produce transformative results via Deep Work. Unfortunately, his solutions to actually obtaining the uninterrupted time required for Deep Work is unrealistic in today's collaborative environments. That's where Deep Collaboration comes in. https://tmail21.com https://tmail21.com. Would love any feedback from the HN community.
• amelius 10y ago
  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.
  • thehardsphere 10y ago
    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.
    • amelius 10y ago
      Well this was not directed at the article as much as the other comments in this thread, some of which I wholeheartedly agree with.
    • Sanddancer 10y ago
      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.
• rodionos 10y ago
  Switched from Slack to Telegram. The desktop client is so much faster.
• ktta 10y ago
  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
  • swiley 10y ago
    "in the spirit of IRC" is a bit of a stretch. This is all a massive blob of web technologies which contrasts IRC's minimalism and it's lightweight clients written in C. It doesn't appear to require any specific service though so at least it has that.
    • ktta 10y ago
      Well we are moving to a web first world, and passing the terminal days of IRC. Trying to avoid web technologies isn't going to do anyone good. Best we can do is try to make them better are secure. Light weight clients can be written in C if you want. There's nothing that needs a web browser Here's the spec if you're interested[1]. There's also a weechat script if you want a command line client[2] [1]: https://matrix.org/docs/spec/ https://matrix.org/docs/spec/ [2]: https://matrix.org/docs/projects/client/weechat.html https://matrix.org/docs/projects/client/weechat.html
      • COMPUTERLOSER 10y ago
        This comment made me throw up in my mouth a little.
      • nullc 10y ago
        > Well we are moving to a web first world, Too bad much of the web stinks, with terrible responsiveness and usability and impose those results through bloated protocols and spaghetti architecture on anything that tries to interface with them. Multiple times on caltrain I've had people ask me how I'm on the internet as I have meetings on IRC without even noticing the connectivity has gone poor -- while their webchat stuff with multiple megabytes of ajaxy whatever won't even load.
• swiley 10y ago
  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.
• mattferderer 10y ago
  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.
• hota_mazi 10y ago
  Was hoping for something original but nope: > these services are not open
• plandis 10y ago
  Honestly wondering what benefit for business chat that Slack has over IRC for software devs?
• probinso 10y ago
  Some people only go to church on holidays...
• maehwasu 10y ago
  > 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.
  • okdana 10y ago
    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?
• nv-vn 10y ago
  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.
• erikpukinskis 10y ago
  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
  • Taek 10y ago
    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.
• frik 10y ago
  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.
  • zAy0LfpBZLC8mAC 10y ago
    > offer Github issues Why a proprietary issue tracker that requires that people make an account with them in order to communicate with you?
    • frik 10y ago
      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.
      • zAy0LfpBZLC8mAC 10y ago
        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.
• killin_dan 10y ago
  I've been making this exact case since it came to popularity. There's tons of FOSS alternatives! No excuses!
• pjungwir 10y ago
  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.
• softwarelimits 10y ago
  what do people think about zulip.org?
• reiichiroh 10y ago
  Just discovered Gitter this week. That may be a suitable alternative.
• lacampbell 10y ago
  Sounds like a great new splash screen for them. "Slack is inappropriate for open source communications" - Your friends at Slack.
• grandalf 10y ago
  I like IRCCloud, it lets me use an open platform, but pay for archival of the channels I care about.
• z3t4 10y ago
  I know most people hate meetings, but chats are worse. Maybe you want a Bulletin board system ?
• tabbott 10y ago
  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).
  • lima 10y ago
    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!)
• diminoten 10y ago
  IRC (and Slack) are not real-time. Why do people think this?
• beezle 10y ago
  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?
• sundvor 10y ago
  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.
• bborud 10y ago
  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.
• nhumrich 10y ago
  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.
• vacri 10y ago
  > 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.
  • u801e 10y ago
    > 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.
• JackPoach 10y ago
  Free and unlimited 'Slack' is Bitrix24. Smart people switched years ago.
• imazurenko 10y ago
  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.
  • aaroninsf 10y ago
    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.)
• deleted 10y ago
  [deleted]
• KajMagnus 10y ago
  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-be-improved-3-things https://www.effectivediscussions.org/-32/how-hacker-news-can... (As you might have guessed, I'm the one developing ED.)
• hankewi 10y ago
  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-c66c07c6c3ae https://hackernoon.com/how-jaypads-help-us-build-jaypads-c66... [3] https://hackernoon.com/how-planning-a-weekend-trip-with-our-buddies-changed-our-perception-of-slack-and-whatsapp-1d53058f51d0 https://hackernoon.com/how-planning-a-weekend-trip-with-our-... [4] https://www.youtube.com/watch?v=0g2Hecd-Ujo& https://www.youtube.com/watch?v=0g2Hecd-Ujo&