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.
They didn't even run ads for the first three years of their existence.
I agree. There is no law against half-assed, bloated Electron based desktop software that can bring even recent hardware to its knees.
Ended deleting the desktop client.
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.
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.
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.
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
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.
What's more worrying is that we are rapidly moving away from an Internet based on open standards and into walled gardens.
This is made evident by countless technology firms and other industries.
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.
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.
...while creating others: fragmentation and lock-in
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
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.
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.
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'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:
Example of repair:
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?
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.
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.
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.
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.
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.
Price/sales = 42, bubble stock ...
Other electron based apps like Discord perform better so I'm not sure why Slack is so crappy.
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?
* 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.
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.
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
(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)
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?
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.
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 !
People who complain about these products probably aren't in the position to use something else, or they probably would have switched already.
I use IRC all the time, and IRCCloud makes it comparable to Slack.
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.
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.
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.
 -- https://textile-lang.com/
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?
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.
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.
In all that time, the only thing I've really heard people complain about, was when it was slow or down.
Choose your customers.
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.
Are you just trying to be infuriating?
What are you talking about then? All of my communications are either personal or employment related, almost by definition.
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.
As others have said, this 'Standard Export' doesn't include direct messages and private channels, so there's still some amount of 'hostage taking'
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.
Personally, I would just call that normal / decent behaviour. Alone, it doesn't mean you deserve a ridiculous billion dollar evaluation
"Well deserved" describes the outcome.
So you might say the outcome is well deserved only if decent behavior comprised the process.
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.
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.
>>> 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 ?
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..
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.
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.
A direct listing is an IPO. Underwriter's are not a requirement, as Spotify profitably demonstrated.
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.
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.
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?
* 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.
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.
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!..)
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.
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.
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.
That makes it much closer to the open ideal than Slack is.
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.
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
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.
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, despite its flaws, IRC's strengths still shine with great luminence, when it comes to plain text-based communication.
- - -
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.
UX isn't just graphical design, it's also feeling responsive, fast, and accessible. Something that Slack, in my opinion, gets horribly 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.
A lot of discussion from this post from yesterday: https://news.ycombinator.com/item?id=20227115
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.
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.
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
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.
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.
We'll talk about it 10 years from now when Slack is gonna be "old cruft" while IRC still gonna be there rocking.
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.
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.
- 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)
- 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
One massive one being keeping history. Another is not being limited to text only, something people absolutely expect in this day and age.
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.
Yes. That's exactly what they want.
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
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?
Pretty straightforward, really
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.
I haven't had any real issues with desktop or mobile apps either.
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.
Overall Slack is a net UX improvement over everything that came before.
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.
IRC is an early protocol and wasn't designed for extensibility purposes. A new chat protocol just needs to replace it.
- Signal Protocol
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.
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.
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.
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.
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.)
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. 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 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.
Reminds me of the "free as in puppies" angle.
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.
> "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."
Slack is enterprise and workflow-oriented, Discord is community oriented.
(FWIW, /me has been using Matrix-based chat clients for group and individual chats at conferences. Quite happy with it.)
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.
How so? Nothing prevent versioning a protocol and having experimental servers.
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.
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)
As has been mentioned here, Facebook is running out of strangers to connect: future growth will depend on adding new types of users.
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. ¯\_(ツ)_/¯
There's moe to it, but this is definitely a factor.
FWIW, I've been using IRC for over 20 years.
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.