
Open Sourcers Race to Build Better Versions of Slack - butterfinger
http://www.wired.com/2016/03/open-source-devs-racing-build-better-versions-slack/
======
scrollaway
A hundred different chat systems mentioned here. _None_ of them compatible
with one another. Well, I guess a couple of them have IRC gateways, but you
have to actually set those up.

Gee, wouldn't it be nice if you could pick and choose your UI? Pick and choose
your "integrations", your "plugins", your client, etc without having to lose
your entire userbase, history, contacts?

Some sort of _open_ protocol.

Urgh, I've been working on this lately and the entire field is depressing.
Between one side that doesn't understand the legitimate need for open
protocols, and another side that doesn't understand why IRC isn't the end-all-
be-all of group chat (and why UX matters), it's just people talking past each
other.

Every new attempt at making "the slack killer" makes this problem worse,
because it comes with its own protocol. Its own users. Etc.

PS: If somebody has free time to work on an open source multi-protocol group
chat gateway, email me, I have something started.

~~~
rekoros
Here's a timeline we put together of about 60 incompatible chat services:
[https://cdn.sameroom.io/chat-timeline.pdf](https://cdn.sameroom.io/chat-
timeline.pdf)

Our service Sameroom ([https://sameroom.io](https://sameroom.io)) is a
commercial solution to the chat incompatibility disaster, not too different
from an AC adapter thingy with a bunch of different plugs, one or two per
continent.

After implementing the protocols of quite a number of these systems (~20),
we're seeing a scary acceleration toward further incompatibility. It's good
for our business, but really pretty bad for the world.

~~~
takeda
This is so disappointing.

Especially Jabber/XMPP was created to fix that issue by standardizing the
protocol. The idea is that IM would be like email - no central server.

Others (GTalk, Facebook, WhatsApp, HipChat to name few) started implementing
it but did not enable server to server communication (ok GTalk did, but as
soon as they became popular they intentionally broke it with Hangouts).

So now we have bunch of services that use same protocol but still can't
communicate with each other, the XMPP seems like it is dying.

A while ago there were plenty of server-side transports to help migrate to
XMPP, but it doesn't seem like they are no longer being developed.

I don't understand why no one cares anymore about decentralizing and
standardizing IM.

~~~
zamalek
The problem is that the IM protocol space seems very opinionated. "XMPP? XML
sucks!" "Web sockets? Web sockets suck!" "JSON? JSON sucks!" "Binary? That
prevents telnet, binary sucks!"

People do care, it just seems as though they care about their pet peeves more.

~~~
iheartmemcache
That "XML" sucks thing is why we don't have single-sign on (YuBiKey is doing a
great job getting half way there though). We keep on reinventing the wheel re:
authorization & authentication despite the fact that there are well-defined,
cryptographicly secure[0]. SAML2[1] has been standardized, implemented,
operates in a similar fashion to SMTP/Kerberos (i.e., your identity is
established (i.e. authentication) purely through a trusted-source), after
which you can proceed.

    
    
      * This eliminates the whole issue for users (I don't want to have to remember 40 million passwords, and I don't want to rely on Google as my SSO). 
      * It helps the developer because all he has to do is implement one protocol (rather than make 8 different accounts to register passport.js with).
      * It helps the tin-foil hatters like me, because I can revoke access from any source at any time & if my account gets compromised I call my buddy Bill hosting the IDP and invalidate my credentials.
    

It's SMTP mail back in the late 90s when your buddy ran his own server as your
primary MX, and his buddy as a secondary MX (i.e., you host an IdP similarly
to hosting a mail server).

I've been working on this problem on and off for about 10 months, the last 4
of which have been fairly rigorous. I've got a solution for the "buddy"
willing to host the IdP. [https://github.com/bergie/passport-
saml](https://github.com/bergie/passport-saml) is a low friction add-on to
your node app for the developers. The last piece of the puzzle is dev adoption
(i.e., getting traction on par with LetsEncrypt) to _actually_ spend 5 minutes
for that passport-saml stuff.

The other issue is developing an easy solution (easier than SSO with Google)
done by mobile App authentication. User-flow is basically: you click "Login
with <name>", the IdP forwards the message to your mobile via APN, and you
swipe left or right to auth. That's the last technical barrier (user adoption
is 80% of the problem). I need to take ~3 mo off and pony up high-five, low-
sixes in fees re: getting a great UX guy (I'm abysmal [[if you're great at UX,
contact me]]), lawyers, liability insurance, a security firm to audit, etc
(there's already a monetization model for this venture, though the whole thing
will be GNU AGPL[3] / free for universities / research institutions, etc.)

[0] Like, in the formal mathematically proven sense, both in concept, and
implementation (though which one slips my mind).

[1] [http://wso2.com/library/articles/2010/07/saml2-web-
browser-b...](http://wso2.com/library/articles/2010/07/saml2-web-browser-
based-sso-wso2-identity-server/)

[2] Encryption is basically a subset of privacy, which I think we have a
constitutional right to, though other people object.

[3] The whole point is to do this first as a human good, but profiteer off
expensive licenses a la Exchange modules, et al. I don't really want to shop
around Sandy Hill but if any of you successful Angels (who are historically
privacy advocates, I'd give Karsten Nohl or DJB (or hell, PG if you're reading
this message haha, 30% and 2 seats in a second, but Larry Ellison could offer
3MM for .1% and that meeting would conclude rapidly) are interested, e-mail me
me -- we'd be able to go to market a lot quicker with 2 or 3 FTE's. I'm going
to complete this anyways, but we're fighting cryptowars again so there might
be a rush.

~~~
zamalek
We integrate pretty deeply with SAML and, yes, it's awesome tech. It makes
complete sense that XML was used because real namespaces are important for
claim extensibility. Sadly, _" XML sucks!"_

------
navait
For talking about a race, Wired seems to have neglected a crucial technology:
ircv3[1].

I'm not very fond of IRCv2, and have moved away from it where I previously
used IRC. But IRC is popular, has a lot of clients, and v3 has a lot of
promise. Why didn't the author bother to mention it?

[1]: [http://ircv3.net/](http://ircv3.net/)

~~~
Kalium
IRCv3 lacks a logo, a startup, and VC funding. So people who write tech news
seem to often be unaware that it even exists.

~~~
scrollaway
It's also lacking adoption (which is understandable since it's not "officially
released" yet).

~~~
zilean
I believe twitch uses ircv3.

~~~
scrollaway
Wow, you're correct. I did not know that. Fun!

~~~
coroutines
Twitch is fairly-conforming to IRCv3... they don't prefix their non-standard
capabilities with their domain in CAP LS. :>

I'm sad because I applied to Twitch directly stating what I'd want to work on
with the IRC portal and never got a response. My entire work history is IRC.
XD

------
matthewmacleod
It's good to see a bit of a variety – we all know that monoculture ends up
being a bad thing, and there are obvious downsides to applications hosted by
third parties (though of course in some cases it's not a problem!). Of course,
there's no real network effect with applications like this either (beyond
integrations support) so there's a relatively low bar to switching when
compared to something like Facebook.

I do hope to see some work on better user interfaces. Our team recently
switched to Slack from Hipchat - many features are better, but the desktop UI
is really unpleasantly sluggish. It seems unreasonable for a chat application
to stutter and freeze on even small amounts of data. The trend for wrapping
web UIs in desktop apps is not a good one, in my experience. Hopefully open
equivalents will encourage the development of native clients.

~~~
wlesieutre
Mattermost claims to have "Native Applications".
([http://www.mattermost.org/community-
applications/#native](http://www.mattermost.org/community-
applications/#native))

Turns out they mean "electron is a native application, and our app is a
webpage inside of electron, so our webpage is a native application."

Bummer. I use both Slack and Hipchat for different groups, and I'm not happy
with the wrapped webapp for either of them.

~~~
benologist
What's wrong with that? VSCode is also such a thing, high performance and
beautiful apps are obviously possible.

~~~
kitsunesoba
Apps built with front end web tech are nearly always heavier than their fully
native counterparts, for one. It's nothing for an electron-based app to gobble
up 150MB, 250MB, and higher amounts of memory while doing (in terms of
resources actually required for the given task) nothing. A great comparison is
Sublime Text, which takes up ~35MB of memory at cold start, even with a few
plugins enabled. Compare this to VS Code or Atom, which take around 200MB
right out of the box. That's downright comical, and I can't accept the "but
resources are cheap" excuse. That mentality has been robbing users of the
lightning-fast, ultra-silky experiences that are possible even on decade-old
hardware for years now and it needs to stop.

Aside from that, non-native applications inevitably introduce accessibility
issues and UX incongruencies with the rest of the system that are difficult if
not impossible to resolve entirely. There's a huge trade off made when using
web tech for desktop applications and developers would do well to deeply
consider their choice of technologies before acting.

~~~
msbarnett
It's not just RAM, either. If you measure "energy usage" however your OS
allows you to (powertop or OS X's Activity Monitor, etc), Electron-based apps
are absolute _battery killers_.

You'll lose literally hours of battery life simply by running Atom instead of
Sublime. It's absurd how little regard Electron devs are showing for end-user
resources.

------
andrey_utkin
What about reusing and polishing XMPP and existing decent software for it?
About donating money to people who develop it all these years? No, we'll
spread FUD upon XMPP or just ignore it but will proceed to use and abuse its
legacy behind the closed doors.

[http://risovach.ru/upload/2016/03/mem/novyy--
shablon_1085837...](http://risovach.ru/upload/2016/03/mem/novyy--
shablon_108583764_orig_.jpg)

~~~
imglorp
For one thing, XMPP is complicated and difficult to implement.

~~~
Zash
It may look intimidating at first, but it's really very easy once you get the
basics.

HTTP and IRC on the other hand look easy at first, then you get past that and
there's just more and more complications and edge cases and horror. Like all
the various cache headers and behaviors in HTTP, or how all IRC networks have
their own dialect that's subtly different.

I once tried to work on an IRC server interface, I read all the RFCs, wrote
code, then tested with a client. Nothing worked, so I had to resort to replay
what the client sent to a different network and reproduce whatever they did.

If you go read the XMPP RFCs, you should be able to write a client or a server
that gets along pretty well with the rest of the XMPP world.

------
parfe
In my org we started using slack and the people who talk the most say the
least.

Important conversations already took place on our internal jabber server.
People with nothing to say never connected, but now with animated gifs and
embedded youtube they use slack for entertainment.

Never thought I'd see Eternal September in a professional environment.

~~~
thearn4
In our team, we created a "random" channel for animated gifs, unrelated links,
etc. to keep from cluttering the work-related ones. So far, it seems to have
worked well.

------
whitegrape
It's been built: [http://matrix.org/](http://matrix.org/)

~~~
soupbowl
I've been using matrix for a few months replaced our XMPP setup with it. XMPP
feels like the stone ages compared to matrix.

------
abecedarius
No mention of Zulip? It's the first to come to mind for me if you ask for an
open source Slack competitor.

------
wslh
I think the Achilles heel of almost every open source projects is [end-]user
experience. The first time I used Slack I was sure it was trivial to replicate
the software (not the business) by a small team of developers but a short time
after I realized a lot of UX details that a normal open source team will not
prioritize ever (e.g. conversationally educating the user about new features).

Probably the weakest point of Slack is their price. A similar open source SaaS
offering will not be free so Slack has margin to compete.

------
giancarlostoro
One thing that nobody's mentioned yet is encryption. A Slack alternative
that's end-to-end encrypted (at least for private messaging between users) and
has encryption for chatrooms would be worth my time.

~~~
llimllib
Is a slack alternative that can never support search truly a slack
alternative?

~~~
icebraining
"Practical techniques for searches on encrypted data" (2000)

[http://www.cs.berkeley.edu/~dawnsong/papers/se.pdf](http://www.cs.berkeley.edu/~dawnsong/papers/se.pdf)

Highly-Scalable Searchable Symmetric Encryption with Support for Boolean
Queries (2013)

[http://eprint.iacr.org/2013/169](http://eprint.iacr.org/2013/169)

~~~
TorKlingberg
Homomorphic encryption would be great, is it likely to become practically
usable soon? That is, is it safe enough against attackers, while allowing
useful search?

~~~
icebraining
Homomorphic encryption is about doing computation on encrypted data, but you
don't need it just to search. All you need is some way to get the server to
send you the encrypted blocks which contain the messages you want (and which
you can decrypt); you don't need the server doing computation on the encrypted
data itself.

A simple solution: divide the data into N blocks. Create an index that maps
words to blocks (e.g. word "hello" is on blocks 36, 43, 84). Then encrypt the
blocks and the index and upload them to the server. When you want to search,
you just download the index, decrypt it, then use it to identify the blocks
you need to download from the server.

The first paper I linked has some more advanced techniques of the same sort.

------
tambourine_man
We need open protocols.

Then let a thousand clients with different paradigms bloom

~~~
vannevar
For reasons that have never been entirely clear to me, chat has been
reinvented more times than perhaps any other common Internet utility, and
every time it is, there are no shortage of investors lined up for it. I think
the cycle is largely driven by fashion, as youth get online and demand chat
apps that are distinct (if not different in any meaningful functional way)
from the existing ones.

~~~
abraae
Perhaps because "chat" is the oldest human activity there is, so the idea that
chat will ever be "done" is a chimera.

~~~
vannevar
If the medium is the message, then yes. A chat on ICQ is different from a chat
on WhatsApp, because the app itself is part of the tribal identity. Like slang
for existing words. So even if the functionality stays identical (and I would
argue that it has, there's only so much you can do with a chat app), the
cultural context of the app is different.

------
maaaats
I work in consultancy, and the client I currently work for has us working on-
premise using air-gapped computers. No internet, only intranet, meant finding
new ways to communicate. So far Mattermost works well. We have it integrated
with Jenkins, Stash etc. and do the typical "chat-ops" things.

------
fweespee_ch
Hopefully Mattermost and Rocket.Chat both build mature, robust HA systems
since their features [honestly] are on par with Slack. Then move into SaaS
hosting of their service in VM clusters across ~3 regions. :)

Really, the only thing that stops me from wanting to use these services at
$DayJob is the fact I have enough stuff I have to maintain. I'd really rather
just pay $99/month for a 10-20 person team.

~~~
__david__
I set up rocket chat on my home server as a test and it's been great. I use it
to chat with my family. So far the maintenance has been _very_ minimal.

~~~
fweespee_ch
I deal with production stuff at my $DAYJOB and it needs to run for 6+ months
without a single on-call event for me to consider it minimal.

~~~
__david__
I've had zero problems with the server (like memory leaks or random crashing),
but the iOS app started complaining when the server was roughly 3 months out
of date. To stop the errors there I had to upgrade the server code (which was
itself pretty simple). That doesn't meet your criteria, but I've find it
pretty minimal by my standards.

------
mikerichards
Regarding IRC... I started using Gitter a few months ago and have used various
IRC clients for over 20 years.

I was blown away on how much better the UX was in Gitter compared to IRC. The
history, the notifications, the markup, the UI...you name it.

And Gitter is a pretty crappy client. If there was a nicely implemented
client, it would be even more impressive.

~~~
shakeel_mohamed
I've been using Gitter for a few months now, I think it's just polished enough
to use consistently. If it were even slightly unstable I'd have to stop using
it.

~~~
mikerichards
Until recently, Gitter had some weird bug where it the process would be in the
background after you closed it, and you thinking that it was gone, would try
to fire up another one it would just go to a background process or something.

But Gitter has other issues - mostly of the UX kind. One of them is that you
can search for other rooms, but you can't really save that search. You have to
start over everytime. Also, the default of sending you an email for every
freaking message when you star a room is absolutely atrocious.

------
altitudinous
This reads like that old XKCD where someone tries to build a standard that
unifies all the existing 14 incompatible standards but it just becomes the
15th incompatible standard itself -
[https://xkcd.com/927/](https://xkcd.com/927/)

Getting a critical mass of people to use a chat system is the defining factor
of success, not the technical genius or features of the system.

Slack is successful because it IS one of those standards that a critical mass
of people use and is modern.

There are plenty of systems that are far superior. However they are failures
because they didn't achieve the critical mass of users.

------
ex3ndr
If someone want performance, simplicity and encryption, take a look at our
project: [https://actor.im](https://actor.im)

~~~
Qwertious
The download page lists "Mac OSX, Linux x86", Linux x64, Windows x86, Windows
x64". The average user does not know what x86 or x64 means, and if they assume
that the larger number is the latest (because duh) then they'll be causing
problems down the line by installing the 32bit version on their (probably
64bit) machines.

Traditionally, this is solved by autodetecting their OS and giving them a big
link in giant UX-ey button form as "recommended", and only mentioning the
other platform links in smaller letters below that.

So, I don't think it's quite ready for grandmas yet.

------
alex_duf
I know what we need: an open protocol so that people can chat easily,
whichever company you work for, wherever you are... We should call it IRC or
XMPP

:)

Seriously I know XMPP is pretty un-popular, but deep inside I kind of wish it
was the default protocol everybody used to communicate...

------
cookiecaper
This is one of those applications that is always being rewritten somewhere.
JWZ's law may even be relevant here: "Every program expands until it reads
mail". It seems there is always a large group people out there working on
messengers.

The question really is what made Slack special. Why is it the Slack revolution
and not the HipChat revolution? What about the veneer has allowed it to become
a pervasive trend, expanding into non-tech companies and being hailed as a
permanent replacement for most emails? This is the only interesting question
around Slack, since, as numerous other commenters have pointed out, it doesn't
really bring anything to the table that the messaging space hasn't seen a good
number of times before.

~~~
auntyJemima
Revolution? Drinking the kool aid much? My team has it. We've had it for a
month or two now. There has only been a handful of posts and most of them are
"TGIF" posts.

~~~
cookiecaper
>Drinking the kool aid much?

As you can tell from my post which states that Slack doesn't offer anything
unique or special, uh, no, I'm not drinking the kool-aid.

~~~
auntyJemima
I realize you're skeptical too, but I'm saying I wouldn't even go as far as to
call it a revolution. Call it a trend if you'd like, that's giving it too much
credit.

------
supergeek133
Oh man this entire field is madness... especially when you realize this when
trying to get ahold of someone:

I'll try Slack... let me check Skype... no maybe they're on HipChat... SMS...
oh hell I'll just call them!

~~~
moonshinefe
Yes it is fairly ridiculous. Which is why an open protocol / non-closed
environment would help solve this.

Yeah, IRC is from the 80s and is lacking some modern features, but at least it
was a fairly unifying chat system in its day. No one company owned it, most
people could use it trivially, and there were many different clients out there
to suite one's taste.

There's still a market for wrapping a protocol in a nice web app UI and hiding
the complexities from the user, which is why this closed chat systems trend is
getting frustrating.

Can't different chat services communicate with each other easily, without the
need for a bridge?

~~~
ZenoArrow
> "Can't different chat services communicate with each other easily, without
> the need for a bridge?"

If more chat services supported Matrix.org we could get there.

[http://matrix.org](http://matrix.org)

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

Someone's suggested it in the Mattermost suggestions site:

[https://mattermost.uservoice.com/forums/306457-general/sugge...](https://mattermost.uservoice.com/forums/306457-general/suggestions/10208583-integration-
with-matrix-org)

------
trengrj
If we are going to go with the name Open Sourcers why not make it Open
Sourcerers.

------
kin
I dunno, I love being able to easily switch between different teams. Plus,
they've just introduced audio, and video is next.

Everyone is talking about open protocols but when you're client agnostic you
have to store/manage data somehow so surely Slack with its integration
friendly mentality could go in that direction?

------
cybette
What about Telegram? It's partially open source (clients only for now) and
provides end-to-end encryption.

~~~
whitegrape
[http://unhandledexpression.com/2013/12/17/telegram-stand-
bac...](http://unhandledexpression.com/2013/12/17/telegram-stand-back-we-know-
maths/)

~~~
cybette
Thanks for the link. However it is quite old, and Telegram was responding to
the discussions and comments, demonstrating at least some respect for the
feedback and perhaps doing something about it. Is there a more recent audit? I
came across this - [https://www.eff.org/secure-messaging-
scorecard](https://www.eff.org/secure-messaging-scorecard) \- a while back but
it doesn't seem very thorough.

Then there's also Ricochet: [https://ricochet.im/](https://ricochet.im/)

------
benevol
Has anyone compared Rocket.Chat VS Mattermost?

What are the significant differences (advantages/disadvantages)?

------
shmerl
So, is any of those projects proposing something better than XMPP as IETF
standard, or may be someone is proposing to improve XMPP further? Without
interopearibilty it will be just +1 to the sea of incompatible solutions.

------
jessegreathouse
I wish we could just hurry up and come to the ultimate conclusion that we
always had everything we needed with IRC. I can't understand why we're still
in the jungle of high level applications replicating a low level protocol.

I get that IRC never had a particular client that galvanized the protocol as
much as the many iterations of proprietary real time chat that has came and
went over the past 10 years, but honestly the problem isn't the protocol, the
problem is that no one was making clients meant for the mainstream.

------
hammerandtongs
matrix.org with the vector.im and android client have been pretty great so
far.

Matrix has solved the right engineering problem first which is the persistence
of the chats across all of your clients.

------
tribaal
If only there was a well supported, standard, open and interoperable text
messaging protocol (with multiple implementations) that companies could host
themselves...

Oh wait, IRC.

~~~
matthewmacleod
This comes up every time, and as usual you have _totally missed the point_.

IRC is difficult to configure, difficult to host, difficult to use, and does
not offer the same feature set as Slack. There is an obvious use case for
something like Slack (obviously, because otherwise it would not have millions
of users!) and covering one's ears while yelling _" IRC! IRC! IRC!"_ is sort
of wilfully ignoring that if it were a suitable solution, Slack would never
have taken off.

~~~
tribaal
Maybe slack gets enough momentum to overtake IRC. Right now it looks a lot
like Google Wave to me.

~~~
Klathmon
You are seriously out of touch if you really believe that.

~~~
whitegrape
Yeah, comparing it to Google Wave probably is a bit too much. In my neck of
the tech woods HipChat is still pretty hip. I suspect that by the time we
discover Slack, something else will have taken Slack's place as the new wave.
Meanwhile I'll just keep visiting the same IRC channels outside of work that I
have been frequenting for a decade. Will Slack be around in 10 years? Maybe.
Will it be the poster-boy of internal chat? Unlikely.

------
ursus_bonum
I don't know why people think Slack is any good to begin with. It's fine at
first but the more people use it the more unwieldy it gets.

Email's pretty crappy but at least with email I get small, contained threads
of conversation that can be searched and organized easily. Slack is like
having a few giant never-ending email threads. It's horrible.

And there's still no voice.

------
amelius
What I conclude from this is that open-source developers are all hungry for
good specs (for a killer application).

Therefore, wouldn't it be nice if there was a website where product designers
(not software developers) could post their product designs, so that the
developers have something to work from?

------
55acdda48ab5
Between phone conferencing, email, and shared desktop video conferencing, I
don't get what more is needed in professional contexts.

I don't even get IRC or IM. "Chat" is noise and distraction. Write proper
emails or arrange phone calls.

What exactly are people using slack for? I don't get it.

~~~
adrianpike
They're all different when it comes to communication bandwidth and
effectiveness.

We need to discuss something visual as a five-person team? A phone conference
is the wrong medium.

We need to collaborate on a significant technical document? Slack is the wrong
medium.

We need to have a searchable back-and-forth discussion, interleaved with other
things that are vying for our attention? We should probably use a chat tool.

~~~
55acdda48ab5
> We need to have a searchable back-and-forth discussion, interleaved with
> other things that are vying for our attention?

This is email.

> We need to discuss something visual as a five-person team? A phone
> conference is the wrong medium.

Shared desktop conference, such as gotomeeting.

~~~
adrianpike
If those work for you and your team, that's great!

However, the growing number and popularity of alternatives should be a strong
signal that they do not work for every team.

------
it33
Connect IRC with Mattermost:
[https://github.com/42wim/matterbridge](https://github.com/42wim/matterbridge)

You can also talk to Mattermost team on #matterbridge on Freenode.

------
pcocko
We started to use Slack in our company but it wasn't adopted by most of the
people. Desktop version requires too much resources and it was unacceptable.
We backed to Skype again. Has anyone ever had same experience?

------
ShaneBonich
It's already here - Bitrix24. Light years ahead of Slack. Free for unlimited
users without silly restrictions on search and other crap. And GASP it comes
with actual work tools beyond IM.

~~~
taurath
It looks like it has 500 features on the screen and it tries to do everything
for you. Its not even in the same ballpark as slack.

------
ausjke
Could not read this from wired.com due to my router has adblock enabled. Wired
says if you don't let us do ads you can't read on. How did they detect that?

------
beyti
adblock blocker on wired, so upset

~~~
SwellJoe
I don't mind them, normally, but in the case of Wired their detection is
broken for uBlock. It continues to detect the blocker as on, even once
disabled. So, reading Wired is now impossible for me, even if I accept their
ads (which, I tend to be fine with for companies I trust not to be too
invasive, and not to have ads that make noise or start video without warning).

~~~
ar0
Ghostery counts 27 trackers for me on this single Wired article, 19 of which
are classified as "Advertising". I would not call this "not to be too
invasive".

~~~
SwellJoe
I didn't look too deeply, but yeah, that's ridiculous. I don't need any Wired
article that much.

~~~
alexschleber
Exactly. The whole piece is < 900 words, mentions about 4 meaningful pieces of
info (current Slack stats, names of 3 OSS competitors and a line or three
about their rationales, history, 1-2 added features). Hardly "must-read"
territory.

For those ~15 lines of unwrapped text, the whole page is 1900 lines in total.

------
_pmf_
Too bad Google insisted on dead-birthing Wave by throttling access via beta
invitations.

It generated incredible hype, but a lot of people (including me) could not use
it due to this bullshit; maybe they can acquire Slack and reengineer it using
the much more mature Wave foundation.

------
DeepYogurt
IRC comes to mind.

------
luckydude
This is why I sort of hate open source. Slack is doing a great job, their
prices are right. So why is it OK to destroy that? With what is going to be
not as good stuff?

I'll get down voted to hell but come on. It's cheap, it's good, so why not let
the guy make a living? And for the record I don't even know who the guy is (or
woman is).

I just hate the "it's cool, lets rip it off attitude". Because the ripoff is
rarely better than the original.

~~~
mmel
Do you really hate open source? or is that just an exaggeration? I find it
hard to believe anyone could actually hate open source.

~~~
luckydude
Nah, I use open source every day, I've contributed to it.

I just don't like that as soon as something becomes popular then it's a
target. It's always bothered me that open source seems to copy more than
innovate. I'm sure there are open source projects that invented something new
but it's hard to think of them (for me at least). But I can think of zillions
of copies of closed source things (linux, gcc, etc).

In the case of slack, it seems sort of mean spirited to try and clone it. They
give it away for free for most people and charge for some sort of extra
functionality and it's cheap, $7 or $8/month/person. I can understand
something like Postgres, Oracle is expensive and cumbersome. But slack?
Really?

For the record I have no connection to the slack people, don't know them other
than what I've read in the press.

