>Okay, I'll take the bait. I'm about as good a representative sample of the people you're talking about as anyone else.
This starts off strong, but then ...
>I'm 39. I've been in technology in a professional capacity for 22 years, longer now than perhaps a few folks on HN have been alive. I wrote my first computer programs over 30 years ago, started online with local BBSs and then eWorld and then the internet.
If I were typing this in slack, this is where the first :facepalm: emoji would appear.
This is the mentality that caused the now-semi-famous HN post in the early days of dropbox, arguing that it was useless because with a combination of [ simple CLI tools that nontechnical people have never even heard of ], you could create the "same" functionality.
Say it with me: Being so simple that utterly nontechnical people can use (edit: not just 'use', but 'deploy and administer') IS important functionality. That's what made Dropbox, and it's what's made Slack. You don't have to be an IT pro to deploy it successfully. You don't have to be a programmer. You just click half a dozen buttons, all of which are helpfully color coded so that your unwillingness to read any text on the screen won't be an obstacle.
Yes, there are things you lose when you "build infrastructure out of walled gardens" -- but the reason some people prefer cathedrals vs bazaars is that they often have much lower barriers to entry, and for many people that is a worthwhile tradeoff.
What mentality are you talking about? That so-called falepalm-worthy quote is just them describing their experience. You're reading way too much into this.
> the reason some people prefer cathedrals vs bazaars is that they often have much lower barriers to entry
There's nothing inherit about these "cathedrals" that require them to be walled gardens. Slack could have been an open protocol, but they decided not to be.
Yes, I do think so. But I also think fundamental functionality like team chat should be a solved problem by now, and shouldn't be so concentrated to a single company.
By no means am I calling the product perfect. Resource hogging is an issue that is particularly important to most HN users.
But would you say that they're _not_ investing in the product? They're improving on search, their API, adding new integrations with Github, etc. Those might not be the things that matter the most to you or other HN users, but they are investments in the product.
Yep, use it every day. Agree that it takes a lot of resources. But lack of investments in one aspect of the product doesn't mean that they haven't / aren't investing in other aspects.
> This is the mentality that caused the now-semi-famous HN post in the early days of dropbox, arguing that it was useless because with a combination of [ simple CLI tools that nontechnical people have never even heard of ], you could create the "same" functionality.
That's a strawman - no one said dropbox was useless to everyone: this is not about how simple it is to replicate the functionality, but who controls the data. The point gp was raising is that surrendering control your data to a 3rd party company has costs most people do not consider until it's too late - and this happens time and again ("oh no, this shit again"). How many stories have you read about downtime, account bans/freezes, and companies winding down or sold with little or no notice and no way to retrieve your data? Is it a worthy tradeoff for a shiny UI?
Exactly, thank you. I wasn't FWIW one of the folks on HN who responded to Dropbox with "but rsync...". (And I was on HN when it debuted!) I did express concern about the privacy and security implications of storing sensitive information with them, and if I remember right, they did have a partial breach early on.
But, they handled it well and they've never screwed over their users and they have partially resolved the long-standing file transfer problem (https://xkcd.com/949/).
So I still have those concerns, but overall it's a great service and I've recommended it to a few folks over the years.
It helps also that there are some open alternatives on the scene now, so if you make Dropbox some critical part of your infrastructure, it's feasible to switch to something else if Dropbox suddenly decides they want to focus only on the smartphone market.
Slack had the ease-of-use and feature advantages -- which I acknowledged -- but it was too young and there were no open alternatives that matched it feature-for-feature. That made it dangerous to rely on too much. i.e., I'd still use it, but I wouldn't make it the de facto communication system for a company.
This starts off strong, but then ...
>I'm 39. I've been in technology in a professional capacity for 22 years, longer now than perhaps a few folks on HN have been alive. I wrote my first computer programs over 30 years ago, started online with local BBSs and then eWorld and then the internet.
If I were typing this in slack, this is where the first :facepalm: emoji would appear.
This is the mentality that caused the now-semi-famous HN post in the early days of dropbox, arguing that it was useless because with a combination of [ simple CLI tools that nontechnical people have never even heard of ], you could create the "same" functionality.
Say it with me: Being so simple that utterly nontechnical people can use (edit: not just 'use', but 'deploy and administer') IS important functionality. That's what made Dropbox, and it's what's made Slack. You don't have to be an IT pro to deploy it successfully. You don't have to be a programmer. You just click half a dozen buttons, all of which are helpfully color coded so that your unwillingness to read any text on the screen won't be an obstacle.
Yes, there are things you lose when you "build infrastructure out of walled gardens" -- but the reason some people prefer cathedrals vs bazaars is that they often have much lower barriers to entry, and for many people that is a worthwhile tradeoff.