Physical products: you are buying them for their software. That’s why you choose an iPhone over an Android phone. They’re all rectangles with screens.
When Sonos screwed up its app it was a crisis because: people pay for the software not the hardware.
Is this true about cars? EV design is converging. It will be. CarPlay controversy is a great example: people choose cars that support it.
Vanmoofs have a lot of hardware problems but the reason people bought them was software (like location tracking and e-Shifting).
So “well known when it comes to physical products,” that may be, but all products are software products.
“Software is eating the world” was all about like, replacing human labor or whatever, disruption. Marc Andreesen thinks he was saying something forward looking when it was all backward looking.
The story is differentiation and customer choices. Truly forward looking. But are Japanese firms incapable of that? Of course not.
Once there was a guy on here who said he had the brilliant idea of using a web browser to make an airplane UI. Listen brother, everybody knows how to write good software. It’s a business strategy not execution problem.
But once you get past toy examples, you start wanting to support operations like "edit", and there generally isn't a way to infer the user's intent there. Like, if my cookie recipe starts with 100g of sugar, and I modify it on my phone to use 200g of sugar, and I modify it on my desktop to use 150g of honey instead of 100g of sugar, there are a bunch of ways to reconcile that:
1. Stick with 200g of sugar, drop the 1.5x honey substitution.
2. Stick with 150g of honey, drop the 2x.
3. Merge them - 300g of honey.
4. Merge them - 150g of honey and 50g of sugar.
There's no way for any automated system to infer my intent there. So you've got to either:
1. Ask the user to resolve the conflict. This means you have to build out the whole "resolve this merge conflict for me" UI and the promise of "conflict-free" has not been fulfilled.
2. Arbitrarily choose an option and silently merge. This risks badly surprising the user and losing changes.
3. Arbitrarily choose an option, but expose the fact that you've auto-resolved a conflict and allow the user to manually re-resolve. This requires even more UI work than option 1.
4. Constrain your data model to only allow representing intents that can be deterministically resolved. In practice I think this is too severe of a constraint to allow building anything other than toy apps.
IMO #1 and #3 are the least-bad options, but I don't think they're consistent with the expectations you'd have for CRDTs after reading this article.
(FWIW, https://automerge.org/docs/reference/documents/conflicts/ is the relevant documentation for their Automerge library. It looks like they've chosen option 3.)
This is what every "cloud file sharing" provider like Dropbox is doing. If there is a conflict, the version on the server is "the right one", and your locally conflicted file is copied on the side with some annotation in the file name.