I think the intuition would be that if a determined "core" feature set of something is so easily and trivially reproduced, then it's not the core/source of its value.
Which makes me wonder: Just how much of UI development had software engineering had consumed and automated since 1980s, or is it still in the realm of pure human art?
This is correct. The core value-add of e.g. Slack is not actually "transmit messages between authenticated users." There were dozens of other applications, both commercial and open source, that already did exactly that when Slack came out and killed them all off.
The core value proposition of Slack is next-level beyond that: it adds a visually appealing, highly intuitive UI/UX that almost anyone can sit down and immediately use, without any studying or setup or manuals or training. No technical skills are required. You don't need to understand anything beyond "type username and password"; the rest is self-explanatory.
> it adds a visually appealing, highly intuitive UI/UX that almost anyone can sit down and immediately use
And yet, there were dozens of other applications doing exactly that (Slack is a list of channels on the left, and the text of the channel in the center).
This is a very astute way to look at it. I'd say then that the value of Slack is to be user friendly, which suc definitely is not for muggles.
But then more difficult questions arise:
- Is the price of slack worth it, when the alternative is having more educated users that can do very basic command line calls ?
- Same question, but taking into account that Slack captures your data and won't give it back to you ? How expensive is it to leave Slack ?
Sure, suc sucks, but we probably could converge on something less bloated and proprietary than Slack ?
> But then more difficult questions arise: - Is the price of slack worth it, when the alternative is having more educated users that can do very basic command line calls ?
I'm not sure that it would be difficult to wrap that up in a web interface running on a single server that does nothing but execute those command-line calls - auth, data and everything but session would be managed by the web server.
You could perhaps even make a local GUI application that spawns ssh once and reads+writes to it, and have your 90% slack functionality done in a weekend.
I'm not sure where to post this reply but I have a hot take cooking up for about a week now: Is it too crazy to just leave a clustered SQL DB open to the Internet, static asset on S3, and call it THE backend of a social-* (-networking, -game) app? It's mostly SQL anyway. Maybe a message signing system like IPsec auth header can be set up with a client cert, and TLS packet encryption can be dropped, if it's going to be public data or data is to be advertised as "e2e encrypted". Isn't that going to cut a lot of backend cost?
Is suc scaleable? I didn’t see any discussion of managing conversations across a cluster of ssh-capable hosts and you’re not going to support more than a few thousand with a single ssh server.
This is something I would like to explore. If I had to guess now, I would think that the management of many open handles on a single file by the kernel is going to be more limiting than ssh.
But I'd also wager we can go quite far with a single cheap VPS. A few thousands user does not seem impossible at all.
Which makes me wonder: Just how much of UI development had software engineering had consumed and automated since 1980s, or is it still in the realm of pure human art?