What we talk about when we talk about sideloading

> The most likely vector was that her phone was out of date and not receiving security patches anymore.

I believe these individuals are suggesting that locked-down ecosystems can be beneficial in certain situations. They help prevent regular users from compromising their device security... assuming they keep them updated...

> Solve the platform tax, solve the side loading issue.

I think maybe for a large part of legitimate app owners there would be no incentive, but there are other reasons/incetives for legitimate app owners to go outside the official app store even in the case of no tax, a few that pop to mind are:

- open source devs might have the preference to publish their app on a community-led store.

- users trying to keep an old phone functioning using an unofficial custom android, with no support for the store.

- developers creating apps for themselves and their friends not needing to publish the app publicly.

- companies creating apps just for work phones wanting to keep them private outside of any store.

- A company providing "build-your-app-with-AI" service preferring to just provide a final apk file.

I think it's important to remember that there are loads of other reasons outside the financial one to keep the ability to install what you want on your phone. If google dropped any tax they put on their store now, the problem with these new changes would still be there

(edits: formatting issues)

  > But I think there has been a real shift in mindset over time.

I'd even go so far as to say that the selling of hype creates an environment where we almost certainly will have worse products. The business people are most interested in the sale, not maintaining the customer. The incentives to fix things or bring them out of alpha or beta release disappears. Even if this is harmful to the longevity of the company. But that doesn't matter either if you're only thinking one quarter at a time...

The point was never that it is easier to patch now and back then it wasn't possible. The point of this conversation was that we can't begin to solve the actual problems if we can't recognize why they happened in the first place. To base our premise on products being finished in the past will only lead to us cycling back to where we are. Someone just has to come up with the /brilliant idea/ of "what if instead of mailing patches, we send them over the internet!" It is good intentioned and will result in more users getting patches. We should not throw out the baby with the bathwater!

But the abuse of the environment is an entirely different problem. You're right that the ease of shipping patches lubricates this abuse of shipping to prod to early. But it isn't a causal variable. The causality here is the business people being uncaring about the quality of the product. The causality here is engineers not taking enough pride in their work to push back against the business people. The causality is that we've structured our work environment to reinforce this behavior and promote those who fall in line instead of those who do quality work. (quantity over quality) The causality here is that customers cannot differentiate a well designed product from a half baked idea and a promise. The causality here is that we call product vision a product demo (demonstrating what we want the product to be, not what the product is).

There's more causal variables, but these are clearly part of the chain of problems. The problem is that the situation is complex! But we can't fix complex problems by oversimplification and denial of their complexity. We have to break them down into simpler parts and address those smaller and more manageable problems. I mean we use this same procedure every day to write code and do numerous complex tasks!

But we can't solve complex problems if we deny the existence of their complexity.

I was not throwing punches. One can be 25 years old now and never have lived in a world without smartphones or social media.

> But pretending that software was ever finished

I'm not saying it was perfect (or bug-free). I'm saying that when you shipped, in many situations there was no way to patch the bugs. And even when there was a way, it was painful. So when you shipped, it was finished, as in "fully functional". Doesn't mean there wasn't any bad software or that good software did not have bug. But the teams shipping a product had to finish it before.

Nowadays, the norm is to ship unfinished software, with the expectation that there will be plenty of bugs, and those that are deemed worth fixing will be fixed.

And I do believe that it became like that precisely because it's easy to send patches. It's now economically viable to ship bad software, because people are used to having to wait for bugfixes. I'm guessing that back then, people would not have bought twice from the same company if the first time had ended up with unusable software.

> if we're going to stop it.

There is no stopping it. The quality of software is going down because it's economically viable, and I don't see that changing anytime soon (especially with LLMs).