I know the answer but I don't like my own answer. When a company hosts it's own code, they are in control of how it and the infrastructure their code is running on are managed. They can keep everyone on the same version and ensure all the servers are managed following a specific process. If there is a critical bug they can patch it right away, sometimes without getting into details.
When people host a companies code, the vendor ends up with a lot more support cases due to externalities that the vendor does not control and the customers of the product will tweak and modify it in ways the vendor did not expect and does not support. The customer can see under the hood and find embarrassing mistakes. The customer may have network configurations and use cases that the vendor never expected their application to reside and function in.
There are pros and cons to each method and both the vendor and customer stand to benefit from one method over the other but ultimately the vendor has to decide if they are willing to take on the extra support load and extra time to work with the customer to ensure best practices are followed for the app, the servers, for backups, for disaster recovery procedures, etc... In most cases the vendor does not have the ability to debug a customer hosted instance directly and depend on working with intermediaries sometimes over video chat screen sharing sessions.
Vendors are not suppressing self hosting due to technical overhead. In fact, you shrink both your operational expenses and technical overhead by delegating to your customers entirely running, securing, and operating your software.
Vendors are suppressing self hosting because it's not a revenue generation stream, and to peddle back FOSS commitments. Customers are required to pay for a cloud-hosted version, while self hosted is free. And while they're at it, why continue to support open source once you cripple the self hosted version and only support the opaque cloud version?
This same playbook has been executed time and time again. Elastic comes to mind as a prominent example.
That's why I said I don't like my own answer. I know its conditionally half true and I have always preferred to host things myself. I can put the right security controls in place and I can coordinate patch management to not conflict with customer code patch management. I am also a bit jaded after dealing with three-letter-agency funded hardware that must have a cloud connection to perform big data analysis on logs and totally not to have that back door connection into the datacenter and psychologically condition the network team into expected to see hundreds of GB of data flow to a cloud provider. But I tried as best I could to keep that out of my answer.
the kind of experienced user like you is not the one causing to many support issues. the difficulty is knowing which users are, and being able to charge them appropriately
As a developer I never want to work on anything that isn't "cloud" (meaning hosted by us on our infra) ever again. It is sooooo much better in every way.
As a customer I hate cloud stuff. I wanna host it myself and have full control.
I understand and agree with every point you have made.
There are two business reasons I see that providing a self-hosted solution would actually be beneficial. First, it would expand the market potential to include companies that for whatever reason do not want to use the cloud system. Second, it would give another revenue outlet by charging hefty fees for support. How many companies like Apple sell a warranty that the purchaser might not ever use? I could see that happening here too.
When people host a companies code, the vendor ends up with a lot more support cases due to externalities that the vendor does not control and the customers of the product will tweak and modify it in ways the vendor did not expect and does not support. The customer can see under the hood and find embarrassing mistakes. The customer may have network configurations and use cases that the vendor never expected their application to reside and function in.
There are pros and cons to each method and both the vendor and customer stand to benefit from one method over the other but ultimately the vendor has to decide if they are willing to take on the extra support load and extra time to work with the customer to ensure best practices are followed for the app, the servers, for backups, for disaster recovery procedures, etc... In most cases the vendor does not have the ability to debug a customer hosted instance directly and depend on working with intermediaries sometimes over video chat screen sharing sessions.