Hacker News new | past | comments | ask | show | jobs | submit login
Slack Is Going Public at a $16B Valuation (npr.org)
651 points by lgats 32 days ago | hide | past | web | favorite | 782 comments



Well deserved.

Their product-vision was clear, their execution focused on what mattered... and they didn't need to bend or break laws to succeed.

It's easily my favorite unicorn of the past decade.


Agree. About the breaking the law thing though: it's a B2B. Most "breaking the law" companies seem to be B2C.


Advertising companies like Facebook make their revenue by selling to advertisers, not individuals- they are emphatically a B2B company.


They're both. They're selling a service to consumers, which they buy with their personal data. They then use that data to sell to advertisers in the form of better targeted ads.

They didn't even run ads for the first three years of their existence.


Are you saying they are bartering and not paying sales tax for their services and their customers personal data ?


I would argue that this is not totaly true. Everyone can advertise on Facebook (I did it myself without a company).


Probably because there is money to be made from advertising/sharing user data and human customers don't have the money to see you like businesses.

geodel 32 days ago [flagged]

> and they didn't need to bend or break laws to succeed.

I agree. There is no law against half-assed, bloated Electron based desktop software that can bring even recent hardware to its knees.


A chat client that takes multiple hundreds of MBs of RAM and sucks battery life prodigiously should be, if not illegal, at the very least a violation of unwritten international norms.


It's actually not the first to do this. Adium (AIM) and Colloquy (IRC) switched to WebKit theming in the 2000s, when computers were /really/ too slow to run it.


Oh wow. Now that should be illegal.


I've never experienced this very common criticism of slack on here. When I occasionally check, Slack is using around 500mb or RAM. A lot for a chat app? Sure. But it has little to no affect on either my 16gb or 8gb machines.


I'm usually at 500mb... per workspace. And the loading times when switching workspaces / channels are just stupid.

Ended deleting the desktop client.


RAM alone isn’t the problem. The issue is that is so laggy and slow. Poor algorithms on 500mb of bad data structures can bring any modern machine to its knees.


It's 500MB RAM per tab/login/workspace (whatever it's called).

Office/company slack, project A slack, project B slack, ... and in no time slack starts to use more RAM than docker/VMs I am developing on.


Just reloaded the Slack tab in Firefox to clear down 1GB of RAM use.

As I do every day.

Every single day.

For the one single channel I join. with no PMs and no threads, no file transfers, no voice or video anything.

Maybe I wouldn't mind so much if it was astonishingly good. But it isn't. It isn't even basically competent, it's terrible. Terrible at scrolling back, terrible at editing previous lines, appalling at completing names properly, bad at search, and completely lacking at customizing when it displays 2MB animated gifs inline.

I would expect a 4Gb machine would mean I never have to check on a text chat client. Apparently not.


Slack is using 89mb here. I never notice it running, personally.


Why does anyone use the app instead of the site?


For me it’s a usability thing—I tend to lose track of SPA tabs, often by closing the window or not being able to differentiate them from content tabs. I do use web apps but I vastly prefer using my machine’s window manager and window buttons/lists.


I use a tool like applicationize (https://applicationize.me/) to make a chrome app for a site. It mimicks an app, but is running as a tab in chrome. Saves memory but gives the benefit of separate window and workspace management (I can tab to it, it can have icon etc).


I personally use a 3rd party client which uses actually native code rather than electron https://cancel.fm/ripcord/


The site also is a heavy resource hog but you're right that it's overall less.

There are plenty of lightweight clients that use the Slack API. I don't see why people complain so hard that the official client is heavy.

Weechat with Slack is a dream feels like the good-ole IRC days.


The site doesn’t use any resources when I close its tab.


The desktop app doesn't use any resources when you close it either. What's your point?


That’s only true if you configure it in a particular way. By default it stays running when closed so it can notify you and update its badge.


Using lots of browser tabs instead of applications appears to me to be a step backward in usability. Instead of relying on the window manager to organise your work, you add cognitive load instead.


Eh, you can just put Slack into it's own window if you're going to use multiple tabs for it. Personally, I just pin it next to my email and it works fine.

I'm not a fan of how much RAM or CPU it uses. I tried the desktop app hoping it would be better, but it seems like it's perhaps worse (I use Firefox, so


Not great for web developers. We have enough tabs open and if every window is a chrome icon it’s a pain to find stuff. I’ve got karma tests running, selenium tests, incognito windows testing security etc etc.


If the other poster has the tan pinned then it is probably very easy to find. Perhaps even command-2 if it’s pinned in the second tab from the left.


Not a great solution if your window manager groups application windows together (e.g. gnome shell and osx).


> Why does anyone use the app instead of the site?

Because on Android at least the website detects that you're on a mobile device and switches to read-only mode. Correct, you can't even post a reply without fudging user-agent or installing the app.


Isn't the Slack app on Android native?


Why would I hide my chatrooms in several browser tabs? Sounds maddening.


As a web developer I’m often using my browser as a guinea pig. Hell a selenium test shut the whole shit down and hijacked it today. I’m not going to run slack in the browser.


Slack is the only reason I used pinned tabs, FWIW.


Can't make calls through the site with Firefox


You are not wrong :-). In fact, your second line is completely correct. However, Slack has lowered the standards for desktop software by being a really terrible piece of software. Which means that the professional in me wants to see a decent client before I'm happy.

What's more worrying is that we are rapidly moving away from an Internet based on open standards and into walled gardens.


My personal take is that, as long as profit remains a guiding priority for a society, there will always be much greater incentive to create a new and successful walled garden than to share and contribute to open standards.

This is made evident by countless technology firms and other industries.


The internet’s previous models were doomed to fail. Service providers did not have a reliable monetization scheme. Client apps for open protocols have rarely had wide adoption and longevity, especially anything you had to pay for. I can think of plenty of examples of paid client apps from the late 90s/early 2000s... email clients, web, irc, etc. that just aren’t around because not enough people would pay for the client to sustain their development.

Slack and other tools are solving a problem customers have and they should be compensated for it, especially given much of their users are profit oriented enterprises.


And yet, the Internet exists because short sighted profit requirements were kept at bay, and eventually the Internet managed to create more value for society than any online service ever by a margin so large that logarithm of the difference is amazingly large.

I work for a telco. My assumption is that the profit margin for connectivity will first converge on zero and then it will drop below zero. There's so much value in the services above connectivity that connectivity won't need to be profitable.

Of course, nobody in my industry will want to talk about that, or even admit this is a real possibility, because it implies that connectivity will most likely be owned by those who make money on services on top.

If we think net neutrality is important today, we ain't seen nothing yet. And given how hard we have had to fight in the past to just about maintain some form of parity, I'm not extremely optimistic about the future.


> Slack and other tools are solving a problem customers have

...while creating others: fragmentation and lock-in


> as long as profit remains a guiding priority for a society

Found the bug.

> there will always be much greater incentive to create a new and successful walled garden than to share and contribute to open standards

It's really a shame that most customers never learn and they keep accepting closed source/protocols.

While the world economy is quickly moving into endless vertical monopolies, history has shown that governments can sometimes wake up and restore competition.

Perhaps in 50 years using open standards will be encouraged e.g. by providing a tax discount


> It's really a shame that most customers never learn and they keep accepting closed source/protocols.

I don’t care. I just want my tool to solve my problem so I can focus on creating business value at my job. I am sure we could all make our own hammers, but time spent making hammers is time lost from using them.


This isn't really what we're talking about. A better analogy are laptops, phones and tractors - which you are not allowed to repair and only work within a closed ecosystem that you either have to opt into our out of, and where opting out has an extraordinary cost.

I use a Mac. I'm part of the problem for having handed my money to an abusive, fraudulent company that is now squeezing all its users for more money for increasingly lower quality products. It used to be easy to buy into Apple's walled garden. But now choice of convenience over freedom is starting to cost me real money and that money buys less each year.


I’m interested in the lower quality part.

My Dad _just_ upgraded from an iPhone 5. Do you think his Xs won’t last as long?

I agree the laptop situation is a bit shitty. I hate the USB-C everything on my work laptop. Everything works fine on my personal computer but as soon as I plug my usb hub into a usb c adaptor everything stutters.

Love their privacy stance though. Best in the business for sure.

Also, what’s abusive? And what’s fraudulent?

Apparently their new monitors are very well priced. And building the same machine you’d get in a MacBookPro or different model ends up being more expensive or similarly priced.

I could be wrong, and I am, certainly, an Apple fan, but I will criticize when I think it’s appropriate and don’t hold views concretely.


I don't know much about the X since I stopped at the iPhone 7 and I am probably not going to buy any of their exorbitantly priced phones. That being said, in their pursuit of thin phones they ran into design issues with boards flexing so that BGA components will eventually fail. They became aware of the problem and then proceeded to make the same mistake again in later models rarther than fixing the problem. (The flexing problem isn't that they will break after one "bending event", but rather than they fail over time as your phone is subject to mechanical stresses of what is within the range of normal use. Typically because the tiny balls under BGAs will let go)

I'm mostly talking about their laptops and their iMacs. The USB C connectors are of course inconvenient, but I actually like them. Again, the problem is that in their pursuit of thinness they ended up designing keys that are very sensitive to dust (and not very nice to use). In subsequent models they kept at it, so the quality of keyboards doesn't seem to be a priority. Some laptops have a tendency to develop display problems due to bad design. For instance blowing hot air on parts that can't take hot air or laying out connectors so that they will fail more easily.

Now these are design flaws, which brings us to the "abusive and fraudulent" part. If you want to get these things fixed under warranty you _may_ be okay. Except the process appears to be entirely decided by chance. For instance they have put moisture indicators inside the macbooks that not only react to liquid damage, but which turn from white to red (indicating moisture) over time depending on the humidity in the air where you use it. (Most people don't know how these things work, so they'll accept it). So they'll accuse you of having spilled liquid in your laptop and refuse to fix it even when this is not the case. Accusing their customers of lying isn't a very good way to behave.

In many cases they will also claim that your laptop is in need to expensive component replacements. Either because they claim that the component cannot be repaired or when their service technicians fail to correctly diagnose the equipment. The repair costs quoted are supposed to make you buy a new computer rather than fix the one you have.

On top of that they have the gall to claim that independent repair shops are somehow less qualified than Apple. Which naturally rings true in the ears of most people; they designed it so they should be the best to fix it, right? However, this doesn't seem to be generally true. Especially since Apple and their authorized resellers appear to have very limited diagnostic and repair capability and the qualifications vary.

When you do send in an Apple device, you have to be aware of the fact that it isn't Apple that repairs your equipment - it is a subcontractor. And they are not always the best.

Wich brings us to the bullying. Apple do their best to kill the independent repair market any way they can. Often by filing lawsuits against repair shops and then putting them out of business. When confronted with this they us their go-to excuses. Like protecting the consumer from unqualified repair shops.

They do this by denying independent repair shops access to the supply line - meaning they work hard to make it difficult to obtain spare parts and components. Compare this to, for instance, Samsung, which sell parts online to make it easy for repair shops to get the needed parts. In order to get parts for Apple products there is an entire market for broken laptops that are bought and sold to repair shops in order to provide donor boards for components.

Of course, then there is the fact that they seem to deliberately make things harder to repair or upgrade. For instance batteries that are glued in unnecessarily, increasing the chance of destruction if you try to replace them. Or soldering in components that the user may want to upgrade later (like RAM and SSDs). For instance on my mac mini the SSD is soldered in, but fortunately the RAM is socketed.

I became aware of the systematic nature of this about a year ago when starting to watch videos to learn how to solder surface mount components (I do a bit of electronics). I stumbled over people who repaired Macs for a living. I didn't come there for the rants, but when starting to research the issue a bit and speaking to a couple of people who also do this for a living, it became obvious to me how terribly Apple are behaving.

Two things struck me 1) diagnosing and fixing macs isn't rocket science. People are able to even as Apple tries to starve them for information. 2) most people don't know how electronics are fixed so of course Apple will get away with claiming they are protecting their users by not allowing independent repair shops to repair their stuff. Diagnosing and replacing broken components and cleaning up fouled circuit boards is not all that hard. Sure, you need the equipment, ability to read schematics and some ability to diagnose electronics, but there are people who do that for a living.

And you really do want to be able to pick your computer repair people just like you pick repair shops for your car. I use a mechanic I know and trust for my car - a guy who walks me through everything he does with my car and even shows me what he has done, and what he thinks should be done. I never use the brand workshop simply because those guys only follow procedures (which aren't always correct), I have no idea who works on my car and I have no insight into what is actually done or if the car is actually fixed or serviced correctly. If anything, my computer is even more important to me so of course I don't want some semi-qualified, random clown subcontractor of Apple, far away, to work on my computers.

The upshot of all this is that I feel very uncomfortable as a Mac user. Whenever I buy a Mac I am taking a huge risk. If something breaks I may not be able to fix it and the only option available to me might be to buy an entirely new machine. Even when the fault is due to a cheap component that takes 10-15 minutes to replace. Simply because Apple actively work to withhold spare parts from the market.

This is even more true if you buy one of their expensive models. The new Mac Pro may look nice, both in terms of specs, price and looks, but if it breaks, you have no way of knowing if you are going to lose your investment. Your machine may become completely worthless as a result of a trivial, cheap component breaking.

If I trusted Apple as a hardware vendor I would probably have upgraded my laptop to a newer model and I would probably have bought an iMac Pro rather than a Mac mini. But since I can't trust them I'm looking at starting to move away from Apple. My next laptop probably isn't going to be an Apple and my next desktop computer is probably not going to be an Apple since I need more power with less risk.

I'm really not fond of the idea of running Linux and having to depend on vmware to run Windows for a lot of the desktop stuff, but this may be the only viable route if Apple doesn't get their act together.

Enough text. Here are some videos.

Some reporting on Apple's fraudulent practices: https://www.youtube.com/watch?v=o2_SZ4tfLns

Example of repair: https://www.youtube.com/watch?v=EDjwYf_GzK0


> However, Slack has lowered the standards for desktop software by being a really terrible piece of software.

You need to explain a claim like that.

On the face of it, the Slack UI works beautifully in Browser, Desktop and iOS clients. I'd quite like it to have code syntax highlighting. But really, what are you talking about?


>On the face of it, the Slack UI works beautifully in Browser, Desktop and iOS clients.

It's not accessible. This alone destroys "beautifully".

But even beyond that, it's just not a good citizen or experience wherever it is. It's deeply single-paned and hence single-tasked: you can't open a conversation in a tab or separate window. And switching between conversations/threads/groups on any platform is much harder than it needs to be. Their quick-switcher is a quasi CLI bandage over this that increases cognitive load on the user.

The enterprise multi-slack experience is even more horrible as it expands that problem across multiple quasi-discrete instances.

On iOS it does unnatural things with text so you can't select portions to copy and paste.

On desktop it is so much of a resource hog it's our generation's version of Eight Megabytes And Constantly Swapping.

And this isn't intrinsic: none of this stuff was an issue when you could use IRC clients to access it. But they turned those off.


I use Slack every day in the Desktop Electron app and the iOS app.

Firstly, lack of accessibility is lack of accessibility. Beauty is a distinct concept. Your comment reminds me of the sign on the Berkeley/Oakland border that reads "Animal rights are human rights". Both are highly desirable, but that does not make them synonymous or coextensive.

OK, It's never occurred to me that I wanted a conversation in a different window.

You use ⌘-k to switch channels. Partially drafted messages are retained. I think I prefer that to a mess of windows that I'd have to manage though of course I don't mean to impose my preference on you.

I have the desktop client open and it's using about 800MB memory between the main process and 3 helper processes. I agree it's a lot, but it seems 100% standard for modern applications. Everything seems to be built around the assumption that people have a $2000 laptop like rich westerners might. So I don't agree with it but I wouldn't single out Slack for criticism beyond any other modern consumer tech company.


Just my two cents, but I have to kill and restart the Slack app every morning because if left alone too long it starts eating 100+% of CPU and then becomes unresponsive (while still pegging the CPU). No other vanilla Electron app I've used does that.


And people still mock my editor choice for being eight megabytes and constantly swapping.


It wasn't claimed to be "beautiful", it was that it "works beautifully". And if it's not accessible, for a serious amount of people, it doesn't work. At all.


Maybe people are generally jaded to to the slowness of cross-platform Javascript apps, but if you take a step back you can really see how bad it is.

I had people at my last job who had to quit Slack because of how hot it was making their laptops, and how much memory it was using.

At my current job, Slack is definitely one of my most rate limiting applications for how quickly I can get things done. Scrolling in chat, searching, switching channels- these are all actions that are extremely slow, and sometimes seem like they don’t work at all.


Ye. It's silly how single page text search is now a hard problem to get done right with JS text edit fields.

It's the same thing with the Swarm review CI tool. If you diff a big enought file, but still quite small for a conputer, it get slow or crashes.

Also the same thing with MS Teams. The prior conversion are not loaded at startup and if you scroll it shows place holders instead of the text for some seconds.


The fact that the performance of the application is awful. You would think that a $16B company could move away from Electron and make native applications for their platforms.


It's never been awful for me. Even when running it on an iPhone 6S, it has always been nice and responsive.


It is native on iOS but not for desktop.


If you think Slack works beautifully you probably do not care about the things I find offensive about it. Like the slowness of switching contexts or the fact that it can only have one conversation on screen at any given time (which in turn makes the slow switching painful).

And this is before we get into the fact that it devours RAM and uses more CPU than is reasonable, making it somewhat pathetic if you think of programming as a craft.


Search doesn't work in slack! Have to use chrome incremental search!

Price/sales = 42, bubble stock ...


Check volt if you want a slack client: https://volt-app.com/

Other electron based apps like Discord perform better so I'm not sure why Slack is so crappy.


Have there been lots of updates? A few months ago it felt very alpha.


Whenever I read those "slack sucks", "jira sucks" rants I can't help but think "kids these days" are spoiled

Hate slack? Try mIRC. Oh wait what's a "netsplit"? What do you mean I can't paste pictures or code snippets without going to a 3rd party service?

Hate Jira? Try Bugzilla/Trac or a multitude of other bug trackers.

"Oh the design sucks" really? Have you tried writing a Win32 app and make it look nice? Ok, try it with Qt (old Qt). Cool huh?


IRC is better than you're suggesting:

* Netsplits would not be an issue, since most small to medium companies would use only one server. Even when they did happen to me in the past, the servers reconnected quite fast. I imagine a big corporation would be able to handle this rare failure case properly.

* DCC allows one to send files and since it's a direct connection, there is no 3rd party company in the US that's inserting itself in the conversation.

Jira is actually quite ok, I don't know why you're besmirching its name by comparing it to a bloated chat client.


> Jira is actually quite ok, I don't know why you're besmirching its name by comparing it to a bloated chat client.

It takes a lot of heat because it is very customisable and get locked down in large corporation.

I worked in company that ran an old shitty very version on underpowered server and disabled feature like rich text editing but force you through a 5 page wizard with in total tens of mandatory field to fill for any jira ticket. People at that company used an excel file on a shared drive to escape the jira hell.

Also there is the crowd of Agile purist that complain that Jira is too bloated for agile and ignoring the extra feature is not good enough because mostly "trust issues".

More recently there are stuff like plandek that create metric on your jira usage. In the wrong hands, this is modern day LOC metric.


Agree 100%. Almost every Jira complaint I see is a byproduct of the way our company centrally manages and locks it down. Things like custom fields and workflows require submitting a ticket and waiting a few weeks. That said, it can still be customized and made to work well for most internal teams.


> DCC allows one to send files and since it's a direct connection

since it's a direct connection it will never work in our modern nat'd/firewalled world, even between company branches (unless you have the whole company in the same VPN - but yeah don't do that)

Yes Jira is ok, it's just the target of (some) unfair hate like slack


I'll admit I haven't been on IRC in 20 years, but while I remember fiddling with active/passive FTP settings and port forwarding every week at the very least, I do not remember any times where I had similar issues on IRC (using mIRC and later various Linux IRC clients, mostly Xchat and BitchX) in the 1890's. I don't know how it would have worked though, thinking about it.

(and I think from the above description of my typical computer use at the time, it's quite obvious what I was doing, and how that would have given me plenty of opportunities to run into all sorts of (compatibility) issues)


When using DCC send in passive mode the sender listens on a local port (59 by default) and sends the receiver a CTCP message (an IRC protocol PRIVMSG message wrapped in \x01) containing their IP address in integer format and the port number. If the receiver accepts their client connects to the sender's open socket and the file is immediately dumped through the connection.

In theory there must be some scheme for forwarding the port through a firewall on the sender side, which might be setting the sending device as "DMZ". Or you can put the burden on the receiver by using active mode.

mIRC should really support UPnP by now but I don't think it does?


Are you sure? Wouldn't it be a direct connection, just between two NAT gateways? With each using the ports to track which connection belonged to the host behind the NAT?


If the connection is already established, sure. How did you establish it though? There are ways to hook clients up that are both NAT’d, (STUN, etc) but DCC doesn’t use any of them.


You did a handshake to the NAT server, which passed it on to the destination behind the firewall?

I'm more a Unix person that a network person so it's possible I'm missing something, but I'm not sure what it is. Thanks for replying.


Jira is too flexible so the right way to do things is never apparent.


I would literally and unironically prefer to run a company on mIRC/corporate IRC servers and Bugzilla than Slack and Jira.


Does anyone actually have data on which company is run with what.

Herding exists, but at some point I suspect the fact that more working business use the one rather than the other would have some meaning.

That being said, the good thing about mIRC / Bugzilla is that no-one prevents you from using them for your business, so go for it !


>no-one prevents you from using them for your business

People who complain about these products probably aren't in the position to use something else, or they probably would have switched already.


I agree.

I use IRC all the time, and IRCCloud makes it comparable to Slack.


+1


You could have a point with Slack but Jira is really terrible. I used it for a customer years ago and I'm so happy any other customer is using something simpler. Jira could be OK if operated by a specialized team paid to do project management and to shield developers from the complications of the tool. It's not only the design, it's the sheer amount of functionality. We don't need all of that.

I'd go with Github simplistic issues all the time instead of wresting with Jira. YouTrack from JetBrains is a reasonable compromise. Redmine is also ok.


Every single one of my clients uses Jira, and nobody I've ever met had a problem with it. It works, it's flexible, it's pretty easy to use. It's the industry standard, and for good reason, as far as I can tell.


Meet me.

I'm not sure what you're talking about. Confluence is OKish. But Jira is absurdly bad. I'm talking about the UI for creating Issues and Epics etc. The front-end devs that wrote it simply didn't have the ability. The parser for entering markup such as preformatted code blocks just doesn't work a lot of the time. The newer "Visual mode" just doesn't work a lot of the time. It simply needs to switch over to markdown and use a 3rd-party parser and renderer. The Visual Mode preview doesn't render using a fixed-width font. have you ever clicked on the little "Link" symbol in the top right of the text entry box? Obviously that should copy the current URL to the system clipboard. But they didn't know how to look that up on StackOverflow and instead made it a normal link to the current page (so you reload the page accidentally), with the link title saying

> title="Right click and copy link for a permanent link to this comment."

! You enter `bq.` to quote a line of text. This is all just some crap that someone with no design sense or standards came up with after 10 seconds thought.

I'm talking specifically about the quality of the UI. It is far, far, below the quality of UIs put out by respected modern products.


Not that it really matters much, but a lot of the design issues you're highlighting are due to the age of the software and Atlassian's seeming commitment to not breaking backward compatibility. In particular, Jira predates Markdown, so the software adopted the text formatter of the day, which was textile[0]. This is where the `bq.` syntax comes from. Jira didn't invent it from whole cloth -- it was adopted because that was the standard of the day. Likewise, it predates StackOverflow by a good 7 years. Some of the JavaScript used is old enough to be a college freshman.

As and end user, you may not (and probably should not) care about the historical context of its design decisions. But it's hardly the case that they hired a bunch of inept engineers. They've simply placed a large premium on backward compatibility and are still around today in large part because of that. Having said that, they really should find a way to support both Textile and Markdown if for no other reason than Bitbucket uses Markdown and it's confusing as hell having to switch between the two syntaxes if your company uses both products.

[0] -- https://textile-lang.com/


That's a helpful comment. Nevertheless

bq. commitment to not breaking backward compatibility

Backward compatibility with what? People's brains? We're talking about markup language and rendering right, which is not an API consumed by machines.

bq. it's hardly the case that they hired a bunch of inept engineers.

So why is the new "Visual Mode" WYSIWYG text entry mode so terrible? And why that absurd "link" icon in the top right of the text entry widget?


Backwards-compatible with people's brains is one aspect of it, sure. No one likes a constantly evolving UI that shuffles things around. But, also backwards-compatible with already entered issues. I wholeheartedly agree they should support Markdown, but I don't think they can just dump Textile in the process either, since it'd affect a load of already entered issues.

As for the link issue, I'm not entirely sure what you're referring to. I have an icon that looks like the Android "share" icon and that drops down a dialog with a link to the current page and a target user field. The link icon in the text entry field just adds a textile formatted link. I'm probably just overlooking something, but I'm not seeing what you described. And I never use the visual editor, so I can't speak to its quality.

I should note that I don't work for Atlassian and never have, so I don't have a horse in this race. But I have been using Jira since maybe 2004 due to its early adoption by the Apache Software Foundation. Jira is hardly perfect, but it's the least bad issue tracker I've used. At some level, I'm sure it's just a matter of preference. E.g., I know plenty of people that laud the GitHub issue tracker and I don't get it. It works well enough for small projects, but is too limiting for any project of non-trivial size, IMHO. I also find more than 2 or 3 labels in the issue list to just be a distracting sea of colors.

I hope you're able to find something that works well for you. I'll add that if you're using an on-premise version of Jira in your company, there's a high likelihood that you're running a dated release. I've found that some of the more aggravating issues people run into have actually been fixed, but not deployed in their environment. If you can find access to a running instance of the latest version, you might find it to be a more less frustrating experience.


I've never heard anyone call Jira the industry standard. There's way too much fragmentation in that market for anyone to be able to make that claim.

Jira can work well or it can work very poorly. It really depends on what you're trying to do with it and what resources you're willing to pour into it. That's why some people love it while others hate it.


It looks like the industry standard from where I'm sitting. Of all the companies I've worked for in the past 15 years, both as employee and as freelancer, I think only 2 didn't use Jira. 3 if I count my private projects (I used Pivotal).

In all that time, the only thing I've really heard people complain about, was when it was slow or down.


I'll see your anecdotal experience and raise you mine: in 9 years I've only worked with one company that did use Jira.


as a user (I do QA testing) I use JIRA every day and I really like it compared to other bug trackers I've used


Slack has resources!


I don't know about "well deserved". They did it by holding people's data hostage. It's one thing to make your messages unsearchable or otherwise available in the UI until your pay, but holding your data completely hostage until you pay up isn't exactly a noble way to go about things. Even Facebook isn't this obnoxious about getting you a copy of your message history.


Free is there to be a sales demo without deadlines with a casual shrug for people who aren't going to pay, I wouldn't ever use slack if it wasn't my intention to play and slack wouldn't miss me.

Choose your customers.


I never used Slack out of choice either. I've used it because I was forced to due to others' decisions. So now I've lost a bunch of my communications due to others' choices that I had little control over.


...OK, so you chose to communicate on it in order to communicate with "others", presumably due to an employer wanting you all to use Slack. In that situation, your communications are often legally not your own property (though it is arguable, at least in the US).

If you're using it personally, the limits on message counts are made quite clear. Exceeding them makes export difficult or impossible without paying. So don't exceed them.

A huge chunk of Slack's value prop (after decent UX) is exactly the fact that they have all of your communications. No chat admins, servers to manage and back up, or networking hell to orchestrate non-text content sharing in a multiparty way. Also makes corporate folks who pay for it happy as they have pretty good auditability/retention controls--not perfect, of course, but better than a truly p2p/federated solution, and again: no infrastructure management needed.

You don't have to be happy with it, but those are features, not bugs, and are valuable to many.

You also just, y'know, don't have to use Slack. Nobody is putting a gun to your head. If the hill you want to die on is "I won't work for any company/team that uses this chat platform", well, that's your choice (hell, there's not even an argument to be made about ubiquity making it a false choice; Slack has plenty of competitors, both paid/hosted and FOSS/federated, in active use by big companies). But don't pretend that a lack of local history or easy export is some sort of highway robbery or hostage situation.


No, I'm not referring to employment communications or personal communications. There are other categories where I've had no choice but to use the same communication channels others were using despite the content of my communications being emphatically mine.

Are you just trying to be infuriating?


> I'm not referring to employment communications or personal communications.

What are you talking about then? All of my communications are either personal or employment related, almost by definition.


I actually had the same question. Maybe community or neighborhood groups or volunteer activities? I'd probably just call all that personal but I could see a distinction.


Everything is personal or employer/business. Why are you assuming such malice from the person you responded to?


> So now I've lost a bunch of my communications due to others' choices that I had little control over.

I wrote a simple exporter using Slack api. It archives Slack from position of user, almost everything (like attachments).

But I'm not publishing it on GitHub because I don't want more people to use it, and don't want Slack to block mass api calls, and don't want slacks admins to know I written it and use it.


Your exporter goes beyond the 10k limit for DMs on a free plan?


I didn't try on free plan. But maybe just run it incrementally, at least once every 10k messages.


Well then you missed the entire point of my comment, which was specifically about the free plan, and specifically about when you haven't had a chance to run such a script incrementally.


The exporter doesn’t export DMs at all, does it? (On any plan).


Nah, this is a super slanted view of things. Their business succeeds because they've made a best in class amazing thing, not because everyone begrudgingly wants to see their history, lol


I'm not claiming they haven't made an otherwise great product, but if their business doesn't rely on this then why are they doing it?


Slack is still inferior to IRC overall. Don't know what you're talking about.


What? Slack is objectively better in every way except the open source part


Just double checked this and exported the history from my free plan -- in Slack I can only see messages back to November 2018, but the export includes all messages back to our beginning in 2016.

As others have said, this 'Standard Export' doesn't include direct messages and private channels, so there's still some amount of 'hostage taking'


And you're probably the workspace admin. I shouldn't need someone else's permission to export my own data either.


I miss this from Lotus Sametime: all of your conversations were stored in local XML files. It was very useful to "grep" through these to find some piece of information that someone told you years ago.


Huh. Wasn’t Facebook forced to add a export data button because of a law?


I don't know exactly what made them add that feature or when that happened (it was before 2011, I think), but AFAIK they never outright blocked you from even viewing older messages. And even then it was possible to scrape it I think, if my Googling right now is any indication.


This is not entirely true. You can export all data from Slack, including data that’s normally hidden because you’re on the free plan.


Really? How do I export the DMs I have beyond the 10k limit?


Is that still the case? That there is no way to export message history? I'm trying to find a way to publish messages from my Slack channel to my website in real-time so that I can give visitors a look at what they are signing up for. Similar to how Pieter Levels has nomadlist.com/chat/ set up (if anyone knows how he does that, please let me know).


You could probably write an integration to do this using the real-time messaging API.


It was as far as I was able to tell when I checked many months ago. I've seen no indications that anything has changed, but would love to hear otherwise...


"Corporate Export On the Plus plan, Workspace Owners can apply to access a self-service tool called Corporate Export. This type of export includes content from public and private channels and direct messages. If Corporate Export is enabled for your workspace, Standard Export will not be available." https://get.slack.help/hc/en-us/articles/201658943-Export-yo...


Yes, which means they hold your data hostage until you pay, exactly like I said.


I don't use or even like Slack, but what is the problem with that?

I mean they are already giving you the oppportunity to use a limited version for free, you can't expect them to give you one of the most useful features imho when you are just using their resources and infrastructure in exchange for nothing; it doesn't make any business sense.

If I'm a non-paying user of Slack (or whatever other SaaS with a free tier) I am not entitled to anything whatsoever, I'd be grateful for the fact that they allow me partial functionality at all.


How is it hostage if you voluntarily used the software for free? They’re spending money accommodating your free usage.


Slack has a completely different business model than Facebook. Facebook has no paid tier for its users, all the money comes from advertisers.


What does "well deserved" even mean? Does it just mean not evading your privacy to generate income via ads? Does it mean not being too aggressive / abusive of customers?

Personally, I would just call that normal / decent behaviour. Alone, it doesn't mean you deserve a ridiculous billion dollar evaluation


"Decent behavior" describes the process.

"Well deserved" describes the outcome.

So you might say the outcome is well deserved only if decent behavior comprised the process.


It's IRC with auto-linkification. Well deserved? Pro-capitalists are crazy.


I think the whole argument of "unicorns exploiting legal grey areas" falls victim to Hanlon's razor. I don't really believe these companies set out to bend or break any laws, it was more a case of the legal system not catching up fast enough. Uber started as a service to hire limousines, not a platform company.

If governments weren't so concerned with party politics, infighting and staving off populist surges, we'd probably have a proper definition for a "gig economy" worker by now. A definition that would allow them to keep the flexibility that they appreciate so much, whilst still having proper worker protections for sick pay, holidays and all the rest.


It's strange that you explicitly brought up Uber and still hold this opinion. Out of all the companies, they have most aggressively skirted labour laws in every country they are in, and have been selectively banned from some countries and cities due to their continual breaking of the law. Not to mention lobbying efforts to minimise the effects of labour laws.

They didn't start as a company for the sole purpose of exploiting legal grey areas, but they certainly have consistently done so since their inception.


Consumer ride-sharing (uber/lyft) is obviously exploiting "grey areas"


>>> More than 88,000 Paid Customers, including more than 65 companies in the Fortune 100; and

>>> We had 575 Paid Customers >$100,000 of ARR as of January 31, 2019, which accounted for approximately 40% of our revenue in fiscal year 2019.

If my math is right, 40% of their revenue is concentrated in <1% of their paid customers. Is this normal in the corporate SaaS market ? I can only think of this as a huge risk.

I also saw that this is a direct listing and not an IPO. Again, I can only see this as a risk, basically because no underwriter will push the stock to investors. Is this so ?


> 40% of their revenue is concentrated in <1% of their paid customers. Is this normal in the corporate SaaS market ?

Speaking from my experience of 6 months at a SaaS company this is about the norm.

Besides the usual 80/20 rule it gets more skewed at the top. And so even the product development was optimised to keep the top 1% happy. A ton of custom built features with hundreds of feature flags..


The 80/20 rule is basically the power law which is one of my favorite laws. https://en.wikipedia.org/wiki/Power_law


It is also one of the most abused rules, often used to justify extremely sloppy "big picture thinking".


Yeah, but 80% of the time, the sloppy thinking is right.


I would say this is only normal/healthy if you have a freemium business model--otherwise the revenues to me seem way to skewed (i.e. very/very far away from 80/20).


Most of the places I worked had 2 or 3 whales. 55 whales is actually pretty good.


Interesting... I guess you could see a lot of SaaS companies as outsourced software development teams for the whales.


yep, if you owe someone a little money they have control. If you owe someone a lot of money, you have control. The whales use SaaS companies to develop things they dont want in house and demand features because they know they're one of the biggest customers.


That is exactly how my current employer feels half the time.


I've noticed this too. I worked for companies that had one big customer; possibly branching out with two or three others. But if that one big customer ever went away, the company would probably collapse. They really should have just been bought and made a subsidiarity:

https://penguindreams.org/blog/tech-culture-shock-from-ameri...


Sometimes that is the strategy: create something cool and hope to get purchased. Having worked at a company that was likely one of Slack’s “whales”, it is a bonus to have feature requests weighted more heavily, but if a tool doesn’t keep everyone else using it happy - you run the risk of some other tool becoming the shiny new thing.


I've worked for a company with a whale client like that (maybe not total shutdown bad but pretty close). The argument for why they never bothered to just acquire the startup was their fear of ruining the agility of the startup. That seemed like a reasonable concern as they were a massive, heavily regulated company.


Well, it might still be the case.


> Again, I can only see this as a risk, basically because no underwriter will push the stock to investors.

They don't need the cash but want to make it easier for stockholders to sell. Now also seems to be the time for tech IPO.


Think about thousands very small customers you simply take the money from and have no effort but they are not the target of your sales team. The numbers sound good to me.


Regarding the direct listing, I wouldn't view that as a negative - sounds like they had no need to raise additional capital, but wanted to provide liquidity to their investors and employees.

They've raised a _lot_ privately, and some of those rounds IIRC were described as just "opportunistic" by the founder - i.e., raise money while it's cheap. Also given that they have a VC arm it sounds like they have more capital than they can actually deploy in their core business.


> I also saw that this is a direct listing and not an IPO.

A direct listing is an IPO. Underwriter's are not a requirement, as Spotify profitably demonstrated.


Thanks for clarifying. My understanding was that an IPO creates new shares, while a direct listing just sells the existing ones. In the same sense, I thought that underwriters were responsible for pushing the stock through the distributions channels (funds, investors, etc) so that they make sure that an IPO is successful in its opening.


After some more searching on "direct listing vs. IPO", there definitely seems to be a lot of "DPO is not an IPO" so I'm going to enjoy having my foot in my mouth.


Can someone please explain how a valuation of $16B is arrived at? I mean, from the math above, they have approximately 250K ARR?


They have 575 companies paying them more than 100k each


Thanks! That makes a lot more sense.


I predict that, one year from now, few people will be talking about Slack and, two years from now, Slack will be teetering on insolvency.


Those 50 largest customers are unlikely to move away within the next two years, and neither are most businesses. I can see someone worry about growth, but they're not going away in 2 years.


Two years ago, those 50 customers weren't using Slack at all. It will be just as easy for them to leave.


Especially when Microsoft just tosses Teams in for free in their next Office 365 renewal.


My company just switched to Teams (from Sametime). We had evaluated Slack, Teams, and Cisco/Webex Teams. To me Teams is a pretty crap chat tool, but it's integration with WIndows (and the macOS client isn't shabby either) is what made it a clear winner. We can chat, do voice, share files, collaboratively edit files, share desktops, all in one app. My only complaint is that the emoticons are typical Microsoft style and should be updated to something better. But this might be due to most Windows desktops not using a high DPI. On a Retina screen they look amateurish.


In large enterprises, it's hard to break into the enterprise but once your application is used you are in there for the long run until unless you have an outage while they have a major incident.

With Slack, if you have a few integrations setup or a bot or 2 configured, it's hard to move. Also the alternatives are terrible.


Why would they?


A free alternative?


You guys really think that enterprise-tier Fortune 500's are going to switch from Slack to a free alternative? Why would they? The money they spend on Slack isn't even a rounding error in their budgets, there's no way that they would want to cut that out and instead have their internal staff try to support some free service instead


Discord has essentially the same app but better voice/call support and other various features. But they seem focused on the gamer market.


When they realize they are tired of the distraction and didn't really need it in the first place.


Your sentiment is valid, but you need to quadruple the timescale.


Slack is great. The valuation makes sense and I wish them continued success.

All the integrations, and workflows that Slack has enabled for our company make us more productive.

I would hate to go back to what came before it.

IRC is complete trash and I don't know why anyone would use it in the same sentence as Slack. UX matters. It matters A LOT.


What's wrong with the UX of IRC? IRC is a protocol, not a specific client, and it supports a wide variety of server and client plugins. We had a really nice IRC going productively for a year or two, but we scrapped it because only our software developer used it and other people in the company preferred something else (they used a mix of email, Google chat/hangouts, and text).

The nice thing about IRC is that everyone can use whatever client they like and it will just work. I preferred command-line UX (irssi) because most of my job is based around the terminal, others prefer desktop clients, while others prefer web clients, and all were available for our IRC server.

Our problem was that management wanted everyone on the same thing, and neither side (IRC vs Google chat) wanted to switch (they liked integration with web Gmail, we liked extensibility, and had already built useful plugins, like "run a build"). In the end, they didn't like our "less professional" plugins (Chuck Norris facts, gifs, etc), and we ended up compromising on Slack (we rebuilt some of our custom integrations).

We went through a year or so of adjustment, and now we're reasonably productive with it. However, morale is a bit lower, and I think we're a bit less productive than before, but that's really hard to judge. Honestly, I just wish there was some nicer looking IRC client. I don't like trusting Slack and would prefer the tried and true protocol that we can tweak and just pay for a flashier client for those who like such things. However, it's better than the previous situation where teams just didn't communicate in text because they couldn't agree on a medium, which led to more interruptions than the annoying Slack notifications (non developers tend to always @ the tech lead instead of letting it be answered by whomever happens to be looking at the channel).

I think it's wrong to blame IRC here. The UX of IRC is fine, it just doesn't have a flashy client (pidgin is really easy to use and available everywhere, but it's kind of ugly).


  What's wrong with the UX of IRC?
* No user accounts, except via a baffling NickServ process involving things like 'ghosting'

* Poor abuse tools, e.g. accidentally IP-banning web IRC gateways.

* No searchable history

* No scrollback / visibility of messages that arrived while you were offline

* No support for uploading images or files.

* No sharing of a single identity / session across multiple clients (e.g. phone+pc+laptop)

As a veteran IRC user I know you can mitigate these problems by getting a shell account on an always-on unix server and running Irssi in Screen over SSH with logging, automated NickServ login, a bot to provide !seen and !tell, sharing images via Imgur, sharing files by uploading them to my personal website, and so on.

Slack has simply looked at the big collection of bodges I just described and made them native features. And you don't even need to know to use Ctrl+Alt+2 to change between channels like you do with ssh+screen+irssi.


> What's wrong with the UX of IRC?

One sentence later:

> ...we scrapped it because only our software developer used it and other people in the company preferred something else (they used a mix of email, Google chat/hangouts, and text).

Clearly something was wrong with the UX if only one person was willing to use it?

This place is a parody of itself sometimes.


I think they may have left off the "s" from developers, based on context it seems like there must have been multiple people who liked it enough to build plugins. Sounds more like a "developers vs. management" kind of thing rather than "our one IT guy tried to sell the whole company on IRC".


Typo aside, that does not materially affect the point. “Management” in this case appears to be every other team at the company...


The point you were making is that a single rabid IRC fan was trying to steer the rest of the company, so actually I'd say the typo certainly does affect the point.


Exactly.

And the only company out there that was able to stitch together more or less usable UX for a group messenger is Slack. IRC has no such killer app (sorry IRC fans!..)


Can you log on to IRC from your phone and then instantly search through all of your company's chat history through the last couple of years?


Sure, that's exactly what I'm doing all the time.

I can search my logs easily https://i.imgur.com/nTpoYs0.png (soon with even better integration, the prototype is a separate web app), and I can just open the web client or app on any device on this planet and instantly have all my logs and channels, and just chat: https://i.k8r.eu/54BPMQ.png

Of course, I use self-hosted quassel and quasseldroid.

Many other projects such as weechat and IRCCloud are also working on making IRC better than slack at everything it does — IRCCloud has a web client, mobile client, hosted team servers, a slack bridge, reactions, threads, emoji, attachments, and all you'd want from slack, natively.

Other projects such as IRC.com are also working on bringing the feq advantages Slack has back to IRC to make it more attractive.

The one single real advantage of Slack is marketing. They can call companies and spend a lot on money on getting more customers, due to the VC funding.


"The one single real advantage of Slack is marketing."

Respectfully, NO.

Providing a very useful turnkey set of features out of the box that are technically possible but fiddly and hard to use in IRC is in and of itself a huge advantage. This is why they're successful. This is why people use it. This is why people use it who barely know what a command line IS.


If you want that, you can just use IRCCloud, it has all that in a single solution. Just like Slack.

IRCCloud can even connect to Slack workspaces.

The only advantage Slack has over IRCCloud is marketing.

It's relatively ironic that I have to end up praising IRCCloud here, considering I'm contributing to a competing IRC client.


But when you use IRCCloud you don't use the IRC protocol anymore, you use the IRCCloud protocol. Which is the same as using the Slack protocol. Your features aren't available outside IRCCloud. Your account, your data, your history, everything is tied to IRCCloud. You haven't gained anything compared to Slack. You're advocating for the _exact_ same model and you don't realize that the only way to have the same features as Slack in an easy way is to basically do what Slack does. You're just agreeing with what the parent is saying.


IRCCloud can connect to normal IRC servers, and normal IRC clients can connect to IRCCloud servers — and you can export your logs and import them elsewhere.

That makes it much closer to the open ideal than Slack is.


I use both. IRCCloud isn’t close to slack in terms of features or feel.


> Of course, I use self-hosted quassel and quasseldroid.

That sounds exactly like the infamous first comments on the HN Dropbox post. I'd rather pay someone to use their app than go through the pain of self-hosting and administering yet another service.


Well, the post was "just use FTP with rsync".

Quassel on the other hand is to Slack what Seafile or NextCloud are to Dropbox — definitely not as comfortable, as you need some knowledge to self host it, but it's easily doable for everyone on this site, and once it's set up, it's just as comfortable.

Of course, if one wants to use a hosted service, there are solutions like that — IRCCloud is pretty much identical to Slack, except based on IRC, and in addition to paid team workspaces, you can also connect to any IRC network and use the same features there.

So, you see, while it has some hints of the same attitude as the original post — and definitely, neither of these products is as polished as Slack, after all we can't make 380k$ losses a day, while Slack can — they fulfil pretty much the same purpose with pretty much the same ease of use

And of course work on single-click deployments and hosted services for more such products has already started


> but it's easily doable for everyone on this site

And that's where you lost sight of the big picture. Slack is _not_ for people on this site it's specifically for people out there: people who don't know and don't need to know what a protocol is, who don't care about netsplits, who couldn't be bothered to install some random stupid stuff on their machine and spend an afternoon configuring it just to be able to talk to their co-worker. We're not the target here. And yet it has convinced some of us because it ticks so many boxes by default.


You can, if you log everything... and there are many websites that provide search engines for public channels... you could do the same for your private IRC server. If you don't mind having all of your data in the cloud, use slack.


"Complete trash"? Please.

I realize I'm feeling (objectively?) "defensive" as an everyday professional IRC user for the last 10-ish years. That said, having tried many of the recent obese chat tools (which do have some nice properties), I still maintain the stance that IRC's clutter-free nature brings a certain tranquility and clarity.

Sure, IRC absolutely has its problems. However, as noted elsewhere[1], despite its flaws, IRC's strengths still shine with great luminence, when it comes to plain text-based communication.

[1] https://news.ycombinator.com/item?id=20119407

    - - -
<digression>

It reminds of something I recently read in an essay called Coon Tree (written in 1956) by the inimitable E.B. White:

"Many of the commonest assumptions, it seems to me, are arbitrary ones: that the new is better than the old, the untried superior to the tried, the complex more advantageous than the simple, the fast quicker than the slow, the big greater than the small, and the world is remodeled by Man the Architect functionally sounder and more agreeable than the world as it was before he changed everything to suit his vogues and his conniptions."

I didn't quote the surrounding context (which itself is quite enjoyable) for brevity. But do read the full essay if you can.

</digression>


You have every right to think that Slack is amazing and that IRC is "complete trash" (although I completely disagree) - but please don't attribute it to UX.

UX isn't just graphical design, it's also feeling responsive, fast, and accessible. Something that Slack, in my opinion, gets horribly wrong.


Curious as to what specifically you think Slack gets wrong?

Honestly, I can't find fault with it. It's such a basic and uncomplicated piece of software, I'm not sure how they could get anything wrong.


I just think it doesn't actually fit any purpose. For quick chats irc is faster and more accessible, and for long thoughtful discussions Slack is lacking a lot of features so that you might as well use email.

A lot of discussion from this post from yesterday: https://news.ycombinator.com/item?id=20227115


How is IRC in any way faster or more accessible than Slack for quick chats? Does IRC fit a purpose? If so, what? And how does it do anything better than Slack?

Slack is certainly no email replacement, and nor will I ever use it for such but in my experience and for the purposes I use it for, it is far, far more featured than IRC, unless you're using some uber IRC client that I'm unaware of.

I'm genuinely trying to understand out how anyone would think IRC is better than Slack and I speak as someone who used IRC from the early 90s up until only a few years ago when the communities I'm part of upped sticks and moved over to Slack.


Personally, I cannot make a comparison between Slack and IRC because I have never tried the former. From the discussion, it is clear that Slack has many features and attractions that are not available or harder to obtain with IRC.

However, for me personally, a major attraction of IRC is that I can easily use it from within Emacs, and automatically have the same Emacs key bindings available that I also use for navigating and editing files.

With IRC, I can therefore quickly copy and paste text between chats and programs, search the history etc., all in the existing Emacs session, using the same key bindings, with direct access to built-in features such as autocompletion, dynamic abbreviation and spell checking, and — importantly! — without switching applications.


There is an emacs Slack client, though I don't know if you'll find it a seamless migration or as polished as what you're used to with IRC: https://www.emacswiki.org/emacs/Slack


I think that was something available to Slack in the past when it had it's IRC gateway. Sadly they closed that down.

We all have our own ways of doing things and I personally prefer to have applications run independently so I like my Slack client and my IDE and terminal etc. etc. separate.

I've always found if one tool can do it all, it's generally a worse experience than dedicated software applications and doing a Cmd-TAB (I'm on a Mac) is just as simple as switching to another window in a single application


To each their own. I’d hate chat and other things intermingled.


Just to follow up, I work for a distributed company where everyone works remotely. It's an essential tool for us to communicate quickly and easily, when talking over skype/video chat is not necessarily suitable or necessary every time one of us has a question. For our organisation, Slack fits the purpose perfectly.


> Curious as to what specifically you think Slack gets wrong?

Personally: responsiveness. Slack's native app on linux is slow. Switching channels has a noticeable delay, switching Workspaces takes seconds if you haven't used the workspace for a while. Starting the program takes ~8s on my machine (three workspaces, i7 with SSDs and 32G RAM).

For most IRC clients or Telegram, startup times are about as fast as Slack changes a channel, and there are no noticable delays when switching channels/IMs etc.


Haven't noticed any issue with responsiveness with the official Slack client but my boss was kind enough to set me up with a pretty beefy Macbook Pro with more RAM than I'd ever need to use.


It may be an issue with their linux client (pretty much all developers I work with are on linux), though I have heard complaints from windows users as well (but it's windows and the users are from the design team, so who knows what their computers do).


I'm on ubuntu. Have never had these issues.


UI is graphical design, UX design is research + a heaping dose of common sense.


Slack is one of the most bloated apps on my computer, and my smartphone.

On both, it takes seconds to boot, and that's just to load the local cache. Syncing with the main server takes a few more seconds.

It has some good UI patterns. But overall, it's heavy and slow. It takes longer to load than the previous chat clients I used.


On slower internet, slack takes ages. If I'm tethering, slack has taken over 30 seconds to load. Insane.


It is a large and complex piece of software that enables great productivity gains if used correctly. I think a few second startup time is a small price to pay for that.


I think the criticism is that it is hard to understand _why_ it is a large and complex piece of software. It seems like it should be small and relatively simple and load fast.


> IRC is complete trash

We'll talk about it 10 years from now when Slack is gonna be "old cruft" while IRC still gonna be there rocking.


10 years from now IRC will finally allow you to upload images and documents in the discussion while the Slack competitor will have figured the perfect blending between instant chat, asynchronous long-form communication and concurrent editing for documenting the decisions that were taken. It's easy to keep a protocol alive when the protocol does almost nothing.


Why are we comparing Slack to IRC, a product that came out in 1988?


Why shouldn't we compare them?

IRC has probably 95% of the features slack has, is completely free and has been around since 1988. Seems like a logical comparison to make.


IRC doesn't have the virtue of having millions of dollars spent on clients for it.

And we are comparing a service provider/client/protocol to something that is simply a protocol which is a bit apples to oranges.

Assuming the same kind of provider exists in your company (IRC+BNC+searchable logging) and you standardised on something like weechat, then perhaps a comparison could be made.

Slack Pros:

- Voice/Video chat

- slackbot "remind" notifications

- Number of highly polished integrations

- Rich integrations (button prompts etc)

- Webhooks for bot integrations instead of needing to subscribe to RTM

- User tags ("out of office" markers, "in meeting" markers)

IRC Pros:

- Your data doesn't have to leave your site

- You can force connections to be on your intra-net

- Simple, well understood protocol

- Which is open, and not going away

- More potential to integrate authentication with your normal authentication provider.

- Rich moderation story

- Flexibility of client, even if we take weechat as the standard it's still possible to run another.

Is this fair? Maybe we should weight how much they're worth.

But for sure if IRC had the investment slack had then it wouldn't be "trash", there's work to bring it into 2019 too[0]

[0]: https://ircv3.net


IRC is missing a LOT of the features that make Slack actually useable for its purpose. IRC just isn't a replacement for Slack in most situations, due to its lack of things people take absolutely for granted.

One massive one being keeping history. Another is not being limited to text only, something people absolutely expect in this day and age.


It's the pro-IRC crowd's own fault for bringing up IRC as an argument against Slack. They're obviously shooting themselves in the foot though.


> IRC is complete trash and I don't know why anyone would use it in the same sentence as Slack. UX matters. It matters A LOT.

To me, that sounds exactly like someone defending AppleTalk, AOL, ICQ, or Minitel. Focus on usability, not interoperability. That's what people want, right?

When it comes to communications, what matters even more than user experience, in the long run, is being compatible with everyone, even your competitors. There will always be customers who don't use your system, so lacking compatibility or federation will be a thorn in your side for as long as you exist. I've run out of fingers to count the incompatible proprietary chat systems I've seen die off.

Even Google has killed off a few of their own, and Hangouts is next. Just being a young smart agile tech company does not make you immune.

In 10 years, I bet people will be communicating over email, IRC, POTS/SMS, plus 4 or 5 new tech startups created by people who are in elementary school right now. Nobody's arguing that $(proprietary_system) doesn't make you more productive today (that's the point!), but they always have a sell-by date.


> That's what people want, right?

Yes. That's exactly what they want.


> Slack is great.

debatable. It is just a chat app after all. Don't get me wrong, it is alright, but I am not sure I would ever call a chatapp "great"

> The valuation makes sense

16billion? To me it doesn't. It is just a chat app. People and businesses can move off it when the next chat app comes along with a new UI


Happy for the people that built it, with the idea of improving what the chat was. Sad for the internet, because we were better in the 1980s with an open standard like IRC, and gradually the internet community lost the ability to adapt their old open protocols for the future.


The death of the protocol.

People no longer release protocols, they release products. The open net, the open web has truly died.

I wonder sometimes what we're missing because the conditions that let the web grow out of the internet have disappeared. What next leap are we missing?


There’s no money to be made in creating and building on open protocols. Without money to be made there’s no funding. Without funding there’s no way to create great experiences. Without great experiences nobody will use the thing.

Pretty straightforward, really


Great experiences are dependent on funding? Going back to IRC, many of us had great experiences on there. USENET was a fountain of great experiences. All text mode. Or do you mean "great experiences" as in the kind of thing depicted in Subaru commercials where they are selling the car as a gateway to beautiful mountaintop sunsets and beach picnics?

Great experiences come from true utility and functionality. Not putting lipstick on a pig and calling it The Next Best Thing That Will Make You Happy And Productive.


Try to get the average office worker to use IRC today and see how far that gets you. It really behooves Engineers to put themselves in the shoes of actual users once in a while


Nobody is saying IRC is the greatest thing in the world today. It was very effective in its time, and it existed (and continues to exist!) without a profit-driven motive.


It was effective for orders of magnitude less users than that of current chat apps.


Great experience for a tech nerd vs great experience for your average desk jockey. Nobody is stopping us from making new protocols, continuing to use IRC, etc. The reality is software is no longer a niche thing - its just another part of mainstream business. There are still "power user" versions of formerly-niche domains.


On the other hand, I don't think anyone accused slack, with multi-megabyte webpages and even worse mobile app, of being a great experience. I think I used it once, and said no more.


I've met only a few programmers IRL that complained about slack, and even then it was for ideological reasons, not user experience reasons. Everyone else, most programmers and all non-programmers I know like the user experience.

I haven't had any real issues with desktop or mobile apps either.


I use Slack for work, and while it was an order of magnitude better than the dumpster-fire of Hipchat (which it replaced for our team), I still think that the interface is kind of "meh".

Custom emojis are fun, inline markdown is useful, but it takes a lot of memory for something that, to me, seems like it should be lightweight. We've had IM since the 80's, after all. There's a part of me that has a visceral reaction to seeing an IM client taking more than 100mb of memory (though to be fair they seem to be getting improving that a lot.


The Electron-ness and memory usage of the app on desktop are certainly annoying, but the UX is still far better than any terminal-based or open source GUI for IRC. It was better than HipChat when my company moved to Slack 4 years ago.

Overall Slack is a net UX improvement over everything that came before.


Microsoft Teams is pretty good.


I'm not sure what about the experience you had a concern about. Slack is the de facto user experience standard right now, with everyone from discord to teams copying it.


Do these things matter to most users? The non engineers at my work have never complained about slack.


They do. Non-engineers just tend to blame the age/quality of their company issued hardware rather than the problematic software causing performance issues.


That is a very hot take. You're under the impression that nobody thinks slack is a great user experience? What?


And with all those problems it's still significantly better than the competition.


I wish I could upvote this comment 1000 times.


And yet, as a counterexample, HTML and HTTP persist. Maybe things aren't as straightforward as they seem.


With QUIC, even TCP is getting replaced because of the need to innovate despite protocol ossification. It's almost impossible to improve TCP at this point due to non-compliant endpoints and middleboxes.

It's a similar "lowest common denominator" issue with IRC, XMPP, mail and many others. Yes, XMPP can - in theory - do almost everything Slack does, but there's dozens of clients supporting a different subset of the protocol. Of course nobody wants to use it.


I don't get how your point is a counter example to the parent's argument? I think there is a lot of money to be made in building on HTML and HTTP. For one, a faster HTTP protocol directly means more cost efficiency in hosting and streaming content, better customer conversions, etc.


IMO, HTTP and HTML are counter-examples to the statement 'There’s no money to be made in creating and building on open protocols.' because they're open protocols that have attracted a great deal of money, and plenty of people creating and building on them.


By that reasoning (which I mostly agree with) making it cheaper to build great experiences is a good thing to do.


And yet open-source has exploded.


Except people still release protocols. Just look at https://matrix.org/

IRC is an early protocol and wasn't designed for extensibility purposes. A new chat protocol just needs to replace it.


IRC was created in 1988. There have been several chat protocols created since then [1]. A few notable protocols that tick a lot of "modern" boxes:

- Jami

- Matrix

- Signal Protocol

- XMPP

The better question: why aren't new and existing technology companies embracing these protocols and making them ubiquitous?

Personally I think it's because companies have a vested interest in creating walled gardens. The more users that are forced onto a platform, the more money they make. It's against their business interest to create a product that works with their competitors.

[1]: https://en.wikipedia.org/wiki/Comparison_of_instant_messagin...


>It's against their business interest to create a product that works with their competitors.

There's more to it than a simplistic "business interest" to explain it.

For example, the Signal protocol is free to use. No payments for patent royalties or software licenses required. Moxie Marlinspike's company Signal LLC (Open WhisperSystems) is a non-profit entity.

But notice that an organization that isn't pressured into making a profit and that's using an underlying free protocol -- does not want to federate with LibreSignal[0].

This an example of where the "openness of a protocol" runs into a hard reality of "closed wall of implementation". The protocols themselves can cost $0 but implementations (e.g. cpu+disk+bandwidth+staff) cost more than $0 which leads to complaints of it being "not really open".

If people do not examine the economic forces surrounding any protocol, they will always be perplexed why the internet is not as free & open as they think it should be. Even non-profit entities are not immune from economic forces.

[0] https://github.com/LibreSignal/LibreSignal/issues/37#issueco...


It might be because Slack has support, a great UI, lots of users, and 'just works'. A company I worked with tried to setup Riot and Matrix and they were having all sorts of problems. Even when they tried to use the Riot.im website there were bugs and features from Slack they needed that were missing. What Matrix and Riot.im is doing is still good though, I hope it takes off.


Matrix is improving all the time. 1.0 was just released


> why aren't new and existing technology companies embracing these protocols and making them ubiquitous?

Because they don't want to be at the behest of protocol maintainers to improve their product? Their goals and the goals of maintainers would never align.

Open source is great, but open source moves at slow pace compared to what a revenue-driven company can. There's a reason that most of the big open source projects have a company backing them.


Open source moves at a slow pace now, but look at HTML between 1994 and 1998, that was a fast-moving and exciting time.


Which was driven by Netscape, a revenue-driven company.

Complaints about corporations capturing HTML are not new; Google is merely the latest in the line. (That's not to diminish the fact that it's still bad every time. It's just this isn't the first time.)


It looks like 1-to-N protocols can grow organically without significant investment (HTTP, hypertext), but N-to-M (chat, social media) cannot.


Sad thing is that matrix is not working really well


how come?


>The death of the protocol. People no longer release protocols, they release products. The open net, the open web has truly died.

People ascribe too much credit to a protocol. The real issue is the funding model to support spending money on that protocol.

By focusing the lens on the funding, the web wasn't as "open" as people think. The so-called "open" web was a government project which wasn't fully open to the public until about ~1995. Before then, you had to work on government-funded projects (ARPANET & NSFNET). The "open" web was actually quite closed off to people that didn't belong to an institution to give them an ".edu" or ".mil" address.

>I wonder sometimes what we're missing because the conditions that let the web grow out of the internet have disappeared.

The "conditions" were government sponsorship to pay for protocols.

- Vint Cerf developed the TCPIP protocol -- but he was funded by DARPA (USA government). Mr Cerf didn't have to go to venture capital firms on Sand Hill Rd and get funding to pay the salaries of his team to build a proof-of-concept or "MVP". He didn't have to worry about not making payroll if his TCPIP protocol project failed.

- Tim Berners-Lee developed the http protocol and also HTML language -- but he was funded by CERN...which is one step removed from being funded by a consortium of governments[0]. Therefore, TBL didn't have to wear a "salesman" hat and pound the pavement begging enterprise customers to buy his "http protocol stack" so he could buy his expensive NeXT workstation[1] to help build and test the protocol.

Those are prominent examples but it doesn't mean people can't create new protocols on their without government help. The SSL protocol was developed by Netscape -- a commercial business. I believe the the git protocol was developed by Linus without a government grant. (Also note that http v1 was funded by CERN (government sponsored) but http/2 & http/3 appears to be mostly funded by Google (non-government sponsored).)

But notice what happens with "open protocols" like SSL and git: they eventually run into a wall where somebody has to spend money on it. The SSL protocol is free of royalties but the Certificate Authorities issuing certificates are not free of charge. The git protocol is free but enterprise accounts for Github are not. The ActivityPub protocol is also free but Mastodon servers are run by altruistic admins spending their own money or requesting Patreon donations. Somewhere, money has to be spent and that ultimately constrains what the "free web" will be. Releasing a "free to use protocol" is not enough.

Therefore, it doesn't matter if the old IRC protocol is free of charge. People still have to spend money on auxiliary features outside the scope of the protocol. Slack spent money on those extra features (e.g. searchable history, etc) that nobody spent on IRC.

[0] https://en.wikipedia.org/wiki/CERN#Member_states_and_budget

[1] https://en.wikipedia.org/wiki/Tim_Berners-Lee#/media/File:Fi...


I think this is a very good explanation of things.

Reminds me of the "free as in puppies" angle.


IMHO there need to be balance between open source and revenue, protocol and products. Just because everyone is going one way, doesn't mean it is correct. I have a friend from banking use to make fun of Richard Stallman 15 years ago. However, looking at it not what he said is quite prophetic. What I’m most concern about is cynicism.


ActivityPub shows a lot of promise.


Also look at dat:// take a look. Beaker browser.


ActivityPub (AP) has the advantage of running on top of HTTP. You don't have to convince people to install a new browser. All the tools that communicate over AP run on familiar technologies. The hardest part is convincing people to make an account, so most growth is from people following friends--the key incentive--to Mastodon instances. It's not a big problem in practice. Monoculture concerns aside.

AP doesn't have to run on HTTP, but any alternative has the same problem as anything else that needs its own client. Even browser support for FTP is on the way out, and it used to be standard.


I don't know about that. There's a flurry of open protocols being built on Blockchain and maybe there's a golden age ahead . . .

> "Historically many key protocols, such as TCP/IP and HTTP, have come from researchers. Subsequent iterations of these protocols were often handled by nonprofit organization that tried to wrangle with more or less success the various commercial interests that sprang up around this protocols (the companies that were making and selling software and hardware based on them). The more money was involved the harder this became.

> "Now, however, we have a new way of providing incentives for the creation of protocols and for governing their evolution. I am talking about cryptographic tokens . . .

> "I can’t emphasize enough how radical a change this is to the past. Historically the only way to make money from a protocol was to create software that implemented it and then try to sell this software (or more recently to host it). Since the creation of this software (e.g. web server/browser) is a separate act many of the researchers who have created some of the most successful protocols in use today have had little direct financial gain. With tokens, however, the creators of a protocol can “monetize” it directly and will in fact benefit more as others build businesses on top of that protocol. Given this new incentive I expect a lot of resources to be devoted to protocol innovation."

~ https://continuations.com/post/148098927445/crypto-tokens-an...


Not products, but platforms.


And in the past you could not be de-protocol-ed


Not by mobs of angry students, but protocol managing entities like Microsoft, Novell, IBM, and others sure could make your interpretation of the protocol invalid. Particularly if you had some competing software out in the wild...


You can code around a protocol change. You can't do that with a de-platforming.


We never got an instant messaging that works like email, for one.


matrix is exactly this, at least from an client/server interop standpoint. email is the first massively successful federated application. matrix just needs an easy to use client/webclient. Riot.im is close, but needs some UX love.


Agree. However the fact that E2E with perfect forwarding secrecy is not guaranteed is going to be an issue.


Can you explain? My understanding is that megolm (what Matrix uses) ratchets the session forward every hour or every 100 msgs, whichever first.


Man, it's crazy how much was riding on Slack staying private.


I'm a big fan of Pythonista. When I do a search for a topic Google often takes me to a post on the user forums. There's also a Slack channel, but Google can't see it so anything useful in there is much harder to access hence I don't use it. I don't want to encourage content migrating to a proprietary silo. That's why I don't mind Reddit, for all it's faults it's at least still an actual web site.


I think Discord is more a replacement of IRC than Slack could ever be.

Slack is enterprise and workflow-oriented, Discord is community oriented.


I'm truly hoping the Matrix protocol takes off.

(FWIW, /me has been using Matrix-based chat clients for group and individual chats at conferences. Quite happy with it.)


Is it not an inevitable result of federation and decentralization as governance? A camel is a horse designed by a committee, as the saying has it.


I dont think federation has anything to do with it. There were no incentives to bring it to consumers though (in contrast e.g. to email), and by itself it is not easy to use for vast majority of end users.


Federation prevents experimenting, iterating and developing the protocol forward.

Yes there are all sort of workarounds like protocol extensions and what have you not, but then you add massive new friction to the system ("No sorry my client doesn't do OpenVideoCall2.0 it only does LibreAVConference0.3"). That type of friction isn't that hard to deal with if you have a bunch of tech savvy people with time on their hands. But it is no longer appropriate for todays web that is used by everyone.

> Indeed, cannibalizing a federated application-layer protocol into a centralized service is almost a sure recipe for a successful consumer product today. It’s what Slack did with IRC, what Facebook did with email, and what WhatsApp has done with XMPP. In each case, the federated service is stuck in time, while the centralized service is able to iterate into the modern world and beyond.

https://signal.org/blog/the-ecosystem-is-moving/


There s nothing wrong with extensions unless they break the entire system, but seems there was no One IRC company that would essentially dictate extensions to everyone else. Google has changed HTTP and HTML a lot, and email too. Slack could have done the same with IRC (maybe someone else will do in the future? ). Yes, walled gardens are a recipe for success , but despite massive walled gardens we still have not switched wholly to those gardens, because they come and go.


> Federation prevents experimenting, iterating and developing the protocol forward.

How so? Nothing prevent versioning a protocol and having experimental servers.


I talk about that _literally_ in the sentence after the one you quoted.


But you still have to support the old stuff, which at internet scale, is never upgraded. So you have to support a really long tail of old versions.


The email protocols pre-date commercial access to the internet. So incentives were very different when it was created.


so does IRC. I believe even if it adopted IRC as a protocol, slack would still be successful, it's all about the UI being dumb-proof, friendly and capable and seemingly in-vogue. Discord, even more.


If Slack adopted the IRC protocol, it would be subject to the same issue Microsoft had with the early web -- either implementing proprietary extensions to the spec to enable features, kludging in new features by abusing existing functionality, or waiting for spec consensus before expanding.

And furthermore, it'd be reimplemented almost instantly by Facebook / Apple / Microsoft / Google.

So I can see why they decided to chart a different path.


> it'd be reimplemented almost instantly by Facebook

wait, how? It's not like there was/is a lot of ppl on IRC, just a handful, and it doesnt fit into their product (talking with strangers)


Clearly defined spec + order of magnitude funding difference + new market = ideal product cloning opportunity

As has been mentioned here, Facebook is running out of strangers to connect: future growth will depend on adding new types of users.


>it's all about the UI being dumb-proof

Make something idiot-proof and the world will make a better idiot. And it looks like I'm the bigger idiot here because I don't understand the interface at all.

I'm in two servers for two open source projects but my ID seems to be different for the two servers and not federated for some reason. Or is it? I don't really know. ¯\_(ツ)_/¯


Yeah because u re smart enough to understand the IRC so you naturally expect a single identity. Try to empathize with us mere mortals who still have not fully grasped the concept of the emoji.


MLP's "On Port 80" hits on much of the "why": Firewalls increase friction of new protocol development.

There's moe to it, but this is definitely a factor.

https://medium.com/@maradydd/on-port-80-d8d6d3443d9a


Seems like there are 16 billion reasons NOT to choose IRC. From Slack's perspective (and you could argue most of it's users) this was a good choice.

FWIW, I've been using IRC for over 20 years.


We still have IRC for those that choose to use it


IRC has terrible UX, and Slack beat it because the experience is better.


That's not an intrinsic problem with IRC-the-protocol. The only technical issue with it is the lack of server-side channel history scrollback which makes it inconvenient for users who aren't connected 100% of the time. This could have been entirely solved with a single extra server command - "/fetch-channel-history". But I suppose no one was convinced of the need.

If you wanted to make a modern, user-friendly chat application that relies on central servers, there's no reason not to base it on IRC.


By the time slack published the RFC and got a few people on board someone else would have launched and taken all its customers


Twitch.tv uses it


Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: