> - Closed Source. A dedicated team paid to work on the product full time, financially incentivized to expand the ecosystem is a major plus.

> - A walled garden. This sounds like the same as #1. Slack allows many integration points, including chatbots that can be programmed to do anything. I'm not sure it is that closed off.

Give it time. You'll come to realize that there are some good reasons - many of them quite grounded in practicality - why those of us who have been around for a while place some value on these things.

Then name them.

I realize this sounds caustic, but to say "Well, you're wrong" without giving adequate reasoning beyond "I've been around a while, so I know better" contributes nothing to the discussion.

Look them up. People have written books and articles on this stuff. Here are a few:

* http://www.dwheeler.com/oss_fs_why.html

* Internet Explorer in the 2000's.

* Look how Microsoft got everyone by the balls with Office software for many years.

* Look up the whole Bitkeeper fiasco with the Linux kernel.

* https://en.wikipedia.org/wiki/Vendor_lock-in

* Did you catch all those people freaking out because Parse is shutting down?

* Were you there when Twitter shut down a lot of people integrating with it?

* Unix is fairly open in terms of its interface, but plenty of people got stuck on proprietary ones over the years, only to see most all of them disappear in favor of Linux and the various BSDs.

I'm no RMS, and don't have problems with proprietary software, but am very wary of getting locked in to something, rather than simply buying a product that I use and can easily switch away from when there's something better that comes out. And chat protocols are very much about positive network externalities that leave you tied to something, like it or not.

The top post yesterday was literally about how Facebook was shutting down Parse and terminating support (in a year) to everyone who depends on it. You seriously don't see the relevance to this discussion?

Your argument itself aside, I think it's a bit uncharitable to fault someone for not seeing the relevance of an article they might not have read. Not everyone necessarily keeps up with every HN thread.

I'm not saying you're wrong, but maybe phrasing your comment a little less combatively would be nicer.

You've completely lost me. The argument ("Facebook killed Parse" -- see, I can even do it in three words) was given right there in the text. You certainly don't have to find it in HN archives.

The bit about the top post was just evidence to how visible to our community these kind of things are, in response to the great-grandparent's request for "name some examples", as if they were hard to come by. They're not hard to come by: you literally don't have to look farther than the most popular article of the last 24 hours on this very site.

Sorry if that seems combative, but them's the breaks. Argue from a sound position or else you'll get corrected.

The Parse situation is different because many there are companies betting their entire infrastructure on Parse. Moving from HipChat to Slack took a couple of days. Moving from Slack to whatever comes next won't take any longer.

Also, supporting your opinion with a coincidence (Facebook killing Parse) does not give you a "sound position".

Good grief things seem argumentative here.

Uh... It's not a "coincidence" that commercial products tend to die before their users want them to. It's basically the norm. Commercial software services tend to live, what, maybe a decade at best? I cited Parse as a particularly apt example, but let's try some others you might remember, trying to pick examples from a broader time range, all of which were very popular in their prime and had many teeth-gnashing users at their death:

  * Geocities
  * Google Reader
  * ICQ
  * Napster
  * Twitter's API Access
  * Deja News / Google Groups

That's just off the top of my head. You really want to continue this argument?

Open source projects die too, and it's not always because there are no users. Sometimes there is no one willing to maintain the project. My point is that "closed source software dies" isn't a valid argument for not using a product.

Indeed. My email client of choice (Thunderbird) "died" this way last year. Except of course I'm still using it, and it's still being maintained by community effort for high priority bugs. So I don't see your point, actually.

Commercial software tends to at least give a warning before dying.

Someone can certainly be forgiven for having not noticed a bit of news that may not be relevant to them, but they should definitely be cognizant of how this industry functions, both now and in the past.

"Technology changes, economic laws do not." -- Hal Varian, who is now the chief economist at Google.

Loss of message history for one.

Open Source projects can not afford to pay for archiving Slack messages. A lot of important discussions will vanish.

If writing a bot is a reasonable solution for IRCs shortcomings, then writing a Slack bot to do long term archiving of messages is also reasonable .

Slack's ToS specifically prevents doing that. Which, is reasonable, as if that's what they're selling, how would they make any money?

I'm no fan of Slack, but it has IRC and XMPP gateways. You can trivially set up an IRC bot that logs your channels & conversations, I connect to Slack via irssi & use its standard logging facility.

So you're no more likely to lose your logs via Slack than via IRC or XMPP if you set things up correctly.

So what you're saying is, Slack works great as long as you're willing to perform some 'uber geekery'? ;)

How do you think open source projects have preserved message history on the existing open source alternatives discussed in this thread (IRC & Jabber)? You set up & maintain your own logging bots.

I don't know if I'd consider that 'uber geekery'... it's just setting up an IRC client - they provide instructions on the slack website.

Either the user controls the program or the program controls the user. Those of us who don't want proprietary lock-in generally do it for one, some, or all of the four basic freedoms as defined by RMS:

1. Freedom the run the program, for any purpose. 2. Freedom to study and change the program (source code required) 3. Freedom to redistribute copies. 4. Free to redistribute your modifications. (source code required)

For the kind of people who frequent hacker news, I would expect you to be familiar with these very basic principles of software ideology. If you disagree with them, that's fine, but let's not pretend that proprietary is anywhere close to FOSS in the realm of freedom. Sometimes you must sacrifice functionality and usability to use FOSS, and that's a choice that only you can make, but what I don't want is you making that choice for me because you don't understand the basic ideas of software freedom.

On the subject of Slack, I can give you a quick example of this. Let's say you want a good chat app but it needs to be secure, and you don't want to trust another company (slack). So obviously you want to self-host internally right? Oh, sorry, no source code, no self hosted version, too bad, fuck off and wait until slack releases a self-hosted version. Oh, and if they do, and you want to implement your own internal feature X, too bad, fuck off, you get what you are given.

Very disappointed in the level of understanding of these things on hn lately.

You should also be aware, that not everybody buys into RMS's ideology, nor does it make sense for everyone. Also, the guy dos not have a monopoly on FOSS.

  > Very disappointed in the level of understanding of these
  > things on hn lately.

Well, maybe the understanding is lacking on your side…

I don't buy into it either, and spend my days working on proprietary stuff. But I use a ton of open source projects, and pretty much everything I do interacts with open source protocols, like HTTP.

" Let's say you want a good chat app but it needs to be secure, and you don't want to trust another company (slack)."

Counter-example: What if I don't care about that?

I don't understand questions like this at all. Is it not completely obvious that if you dont care about the that then go right ahead and do whatever you want? What are you even asking for? Seriously, what kind of reaponse do you imagine can even be given?

Qnd thats not even a counter example... Its just... Lazy.

If, tomorrow, Slack decided to close and there is no other app to read your conversation history; then you are locked out of this history.

That's just one point.

Could you enumerate a few? I'm open to being wrong.

One might be "what if a product shuts down?" This has happened before with chat (Campfire being spun out of 37Signals) and wasn't catastrophic.

In fact, this could be a long-term positive (but short-term pain in the ass) since it forces stagnating teams to update.

The value that you put into the walled garden will eventually be locked behind some sort of paywall. Lest that sound too cynical, it wouldn't be a walled garden in the first place if that wasn't the basic plan.

Probably one of the mental blocks here is that your exposure to a walled garden is bounded by the value you put in it, and it doesn't seem like "a few guys chatting in a Slack channel" is a lot of value. And yeah, it probably isn't for your median open source project, even accounting for the ease of underestimating the value of that chat. The median open source project is having a good day if two people are in its chat channel simultaneously. However, if you're a much bigger project, and you've got hundreds of lurkers and active ongoing conversation for hours a day that constitutes the "real" design of the project, etc., it is dangerous to let that be in a walled garden for "free". But, still, only dangerous relative to the value of what is in there.

"Site gets shut down" is just one possible exposure. More concerning is the "site becomes not free after all".

My synthesis of all this is that, yeah, there probably isn't a lot of concrete danger in using Slack for your communication, but that the signal it sends may not be what some people would expect. But even that depends; an open source Slack plugin may as well use Slack, whereas a GNU project wouldn't be caught dead there, and there's a whole continuum in between.

"More concerning is the "site becomes not free after all"."

Why is the team developing the thing you find valuable getting compensated for that concerning?

"Why is the team developing the thing you find valuable getting compensated for that concerning?"

It's about the value they'd have that would allow them to negotiate a deal you probably wouldn't have taken if it had been offered to you up front, i.e., "lock-in".

But I blame the project for letting themselves get locked in, not the company for trying to make the money.

Open source projects are usually unfunded and to a first approximation have a budget of $0. This makes them a strange case.

I thought about this a bit. I'm a huge opponent of closed source / walled garden-style approaches for many platforms and situations, and I'm curious why this seems different for me. The biggest difference between Slack and normal situations where you do not want a walled garden is that porting between chat programs is relatively easy. Unless you're highly invested in the user flows allowed by a particular chat application (bad idea, IMO) which particular client you use doesn't matter that much. The only thing I can see this being a problem for is chat history, which you can still access from the old platform if you need it.

Is there any reason you don't articulate the reasons here?

And I could say the exact same thing for the opposing viewpoint.

> If IRC filled people's needs, they would use it.

Can we please put this ridiculous circular argument to rest already? You can say that about ANYTHING, it's a vacuous fallacy.

People vote with their feet.

The real circular argument is "if only people used XXX they would love it!" That's not what I'm saying. People are choosing a new alternative to IRC because of the feature set.

Early on in the smartphone wars, the best argument from the Android side was "well just look at the adoption."

That isn't circular. Adoption is an important measure of "does this solve a problem people have?"

People rarely "vote with their feet", that's a myth used to justify a lot of crap that's happening in the world.

People follow the herd. In terms of collaboration tools, they use whatever tools everyone else uses, and often get stuck with bad solutions because of network effect. Just how many companies use Skype for group chats? In each case you could probably trace it back to the CEO / upper management needing it for actual video calls, who then force this tool on the employees and because it has some group chat capabilities, nobody bothers to switch to something better. I've seen similar things playing with other tools as well. It's not the good one that wins, it's the first good enough that does.

Whether you personally care about it or not, it's a little silly for an open source project to require closed source software to interact with the project.

Why?

Has GitHub been bad for open source software?

Has Google Groups?

Yes and yes.

Both of those platforms have fairly low barriers to exit.

Moving off of github is a simple clone. Google Groups is archived, and there are many other alternatives.

Unless you are paying for it, Slack message history vanishes.

And IRC history doesn't?

IRC doesn't even have the concept of message history. Any such thing is done by individual clients/bots.

Bringing up message history as a negative is just straight-up disingenuous with that in mind - the answer to both possibilities is the same: use a bot.

Whereas IRC history persists forever for free?

Oh, wait.

"Unless you are paying for it, Slack message history vanishes."

Same thing with IRC. With Slack, however, I can pay later, and still have access to the history. With IRC, once it's gone, it's gone.

  > Slack message history vanishes.

And?