> - 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.
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.
* 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".
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.
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.
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.
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.
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.
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.
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.
"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.
> - 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.