See, I love it. I work for a mostly-remote company and before Slack we had an IM product but it was a 1:1 chat. Having an always-on chat room for the entire team, knowing other teams use the same product and I can pop into their chat room, spinning up channels for project teams, etc. It's been a huge boost to our company.

And since so many companies have settled on the same solution, when I'm working with a client I can join their Slack workspace too. That cuts down on the numerous quick phone calls and long email threads that we used to have.

Slack vs Teams vs IRC vs anything else, I don't care. It's not about the product. But my company (and most of our clients) didn't have this capability before Slack even though IRC existed for decades, so I'm going to give Slack some credit.

It seems that you could take any old-school internet tech, add some flashy GUI, slap "for enterprise" label and you get a great and popular solution that solves the problem noone ever could solve. Maybe it's time for gopher for enterprise

That's really what it comes down to. Email existed forever, but no one really liked it until Gmail made it flashy. Smartphones existed forever but no one really liked them until Apple/Google made them flashy. Search existed forever but no one really liked it until Google made it flashy.

Hackers like to pretend that presentation doesn't matter, but in the end presentation is the only thing that matters.

Sorry, you are wrong. This is pure revisionism.

Blackberry was absolutely massive before the iPhone, email has always been the largest use of the internet (until media became possible), and Google search became successful because it actually worked, unlike everything available at the time.

I do agree with your sentiment, though. To the user, the UI is the product.

I owned several Windows Mobile phones, one Blackberry, and one Palm device before iPhone and Android came out. I know the history. They were not popular devices. Even just looking at Blackberry sales by themselves, sales of these devices pre-iPhone were absolutely insignificant [1].

Same thing with email. Hotmail/Yahoo/AOL pre-dated Gmail by quite a long time, but Gmail now owns something like 80% of all webmail traffic.

I think your confusion might be where I said "these things existed but no one really liked them" maybe you read "these things didn't exist before"?

[1] https://www.statista.com/statistics/266240/global-revenue-of...

Lots of old technology is really good but has a bad user interface. There is something to be said for packaging up something in a nice, good looking, easy to use way. I mean, look at how many companies use Sumologic and hosted ElasticSearch for log ingestion. Theoretically speaking, with grep, regex and python you could make all the graphs and charts yourself, there is no real reason to purchase these (pretty expensive) services if you are willing to put in the work. The problem is the amount of work required to do what you say successfully is massive.

Agreed. Easy to use UX is what sells tech and gets it used en masse.

Pretty tangential, but I observed that exact phenomenon recently after looking at the recent VR headsets: Oculus Rift and HTC Vive existed for at least a few years. Tried them, was pretty fun, but tangling with wires, having to have a powerful PC on hand, that 1-2min set up every time before you want to use it, it was all killing the usability for me.

Then Oculus Quest comes out earlier this year. Pretty much similar tech (a few differences, no need for PC, but can be used with one through easy sideloading), but no wires and no need for a PC connection. Every time I want to use it, I don't need to fiddle with my PC. I put the headset on, it wakes up in a few seconds at the exact spot I left it last time. I put it down, it goes to sleep in 15 seconds.

I ended up spending an hour or two almost every day for the past two months playing with it, as opposed to the previous headsets (most of which were left on the shelf a few weeks after the initial purchase). The only major advantage that Quest has over previous gen is easy and frictionless UX.

It got to the point where every single friend of mine who tried it at my place ended up purchasing their own headset the day after. And those people were some of the biggest VR skeptics, after their experiences with original Vive and Rift.

So, what you're saying is there's tons of technologies lying around that are a solid UI and some extra features away from being valuable to normal people. But somehow doing those things and making lots of money is bad?

No, of course not. Neither adding some minor extra features (that make a huge difference for the end-user) nor profiting from it is bad. My concern was that there is so much good tech that is not being utilized just because it lacks enterprisey look and marketing attention.

Take slack as an example: ircd with logging enabled + elastic search/sphinx/lucene + web frontend (use any existing web irc client and integrate that with elastic search results). MVP really seems as a one guy one weekend project. And that was lying underutilized for decades. While my original comment was just a snarky remark, I really think that there are other areas where such a (relatively) simple MVP could allow huge productivity boost to many businesses and allow them to use an existing tool that right now is just too hard/too complicated to use by a wide audience.

And of course the market will reward those that will find the right solution and come up with a great UX improvement to that tech. The hard part is creating the GUI that is both efficient and easy-enough , and the hardest part is of course finding the right tool and the right problem to solve. (edit: formatting)

> ircd with logging enabled + elastic search/sphinx/lucene + web frontend

Slack is way more than that, though.

My recollection is that even the initial version of Slack was more than that.

At this point, it's enough that "let's extend ircd" isn't exactly a practical answer. Either they maintain their own incompatible fork of ircd or they try to force their business desires into the irc protocol.

There's plenty of things that are "just X plus some paint" if you don't look at them deeply. That usually does an extreme disservice to the difficulty of the "plus some paint" part, and often represents a failure to understand the features involved.

While you are obviously right, I still believe that the MVP one weekend project I described in parent post would still cover a large fraction of use-cases. You could then improve on that and add some "minor" (minor in the sense of dev-time) improvements like syntax highlighting using some free (as in beer) libs for that. I am not trying to imply that I could "clone" Slack over the weekend by putting together ircd+elastic and then adding some JS cruft on top of that. But I do imply that just that would be enough as an MVP and as something that would make usage of self-hosted IRC possible for a wider, non-technical audience. I also believe that this itself would cover the functionality actually used by many slack users (at least my personal anecdata from 8 smallish companies supports that) And I also can't stress this enough: I am not trying to say that Slack was created over the weekend or devalue a really impressive and massive effort they've put to get the scale, the functionality and the UX.

I don't use Slack, but I'm curious about which features make up the "more than that" part.

Based on me augmenting my memory with searches of release notes at the time:

- Phone apps from the jump - Easy ability to upload files - Search includes the content of those files - Editing

I also work fully-remote and the dependency on Slack (prioritized over email) makes it near impossible to communicate with my coworkers during outages because I can't just go over and talk to them.

My deploy on our staging environment fails because the bot can't post the deployment status update on Slack, so yeah, there's that.

...sounds like you need to revisit your CI pipeline. Your build shouldn't fail when your chat tool is down.

Yep, made a ticket about it :)

Sure that didn't fail too because its creation could not be announced on Slack? ;-)

That's funny because we used to have a Zendesk Slack bot to open tickets but it's broken nowadays.

This is the first Slack outage where it's really affected me. My team has gone all-in on Slack as our communication mechanism. Though now I get to walk around and talk to people in person, so it's not all bad.

You can apply the same logic to email and the internet in general.

Comparing one proprietary service to federated and open services? I'm not following you

While email as a whole is indeed federated, email service for a single company is usually not, that is you have a single provider and when that provider happens to have technical issues your email might be down. While obviously you could use other provider (or even free email) almost immediately to send emails, you will not be able to receive/access emails that are sent to your primary address/domain until the provider resolves their issues.

>you will not be able to receive/access emails that are sent to your primary address/domain until the provider resolves their issues.

You won't be able to receive new e-mails, but if you use a local client like thunderbird, you can still access your old e-mails.

With slack down, I can only access the messages that I (luckily) have cached locally.

Except that email has built in retries and feedback. Also it's expected to be async, so if a server is down for an hour, most people don't even notice.

> email has built in retries and feedback

Yes it has and it is a great thing - hopefully no messages would be lost assuming that downtime is relatively short. This still does pose a (possibly minor) problem when some mails are urgent.

It doesn't really matter how open and federated email is if all mail in/out of your mailbox has to go through one provider. If my company's Exchange server went down, email would stop.

Likewise for Internet service... if my local AT&T connection went down, it doesn't matter how open and resilient the Internet is, I'm not getting online until it's fixed.

I used to work for a relatively small dev-shop (9 persons) and we had two independent internet connections from two providers to avoid such problems. This was because done that way because there was only one fiber provider that wasn't really reliable (3+ hours downtimes every 1-2 months) and mobile tethering wasn't really an option as well because of nearby powerlines that made the reception quite a problem - to the point where our sales guy had to go outside the building during some calls. Luckily there was a second ISP - not really fast (10mbps was the best they could do) and quite expensive (we've paid more than twice more for that 10mbps than for a gigabit fiber), but still cheaper than having 9 people not able to work while waiting for the "main" ISP to solve their problems.

When this happens I just switch to tethering from my cell phone. Redundant enough.

So when Slack is down, just text your coworkers. Problem solved.

> f my local AT&T connection went down, it doesn't matter how open and resilient the Internet is, I'm not getting online until it's fixed.

Except that you could work from home, check your e-mail using mobile.

Mailservers are also down very often.

When a company switches from their own e-mail server to hosted Google Mail, their uptime improves.

No, Slack is more like sunlight, which also exhibits a single point of failure for most orgs. While the sun does go down, it somehow seems more reliable.

> Slack is more like sunlight

Yep. It's pleasant at first and a genuinely useful tool when used correctly, but if you're not judicious with your usage, you could get burned.