Having it available as self hosted doesn't exclude the possibility that the author or another company will offer it as a service. The reverse is often not true.
If I were developing a product like this, I'd build it for self hosting and charge a nominal cost plus yearly a maintenance/support subscription. Then you could deploy the same product yourself and offer it "as a service" for a monthly subscription. Atlassian does this for many of their products.
The problem I see with paid self hosted PHP apps, in this case, is that they are often using ioncube obfuscation and then if I can't read the source how do I know my data is more secure than a cloud provider?
My market research suggests that the market for hosted products is much larger but the market for self-hosted products these days is underserved.
There are people who for various reasons refuse to use any hosted product (legal issue, boss said no, etc.) and depending on the competitive landscape they may not have any other options than buying your product. This produces a captive audience.
We also find that the what the cloud team finds as a sufficient level of quality or service often does not match what we require or expect. And fixing that is a major PITA because it comes down to culture, and suddenly you are not dealing with your company's culture but a 'cloud' culture.
And on top of all that there is the issue of who controls your data. Is it secure? is it safe? What's your uptime, downtime, maintenance? Often we get promised good things (sales people are good at what they do), but it rarely works out as such.
The answer to this is find another cloud provider, but I dont want to spend months RFI, RFP, migration, integration, etc....again because the first cloud people were terrible. It's often just better in the long term to do it yourself.
It's a pay me now or pay me later scenario and I'll live by the words if you want something done right, do it yourself, especially for enterprise.
SaaS apps seem to be about lock in wherever possible with just the barest lip service given to standards and true interoperability.
You make this sound somehow irrational.
For a large number of companies, business data is the key to the running of the business. Why would you ever let someone else control this data, much less someone who themselves doesn't have full control?
Do you not remember what happened with Codespaces?
How many times are there posts to HN: "AWS is down in <FOO>" with dozens of comments "yep, XYZ doesn't work right now"
How many service based companies have been bought out by a bigger fish only for the service to be shut down or changed in some dramatic way?
For the majority of businesses I very much doubt that theft is the primary concern with using SaaS. Control, visibility, access to your own data regardless of the app/system author's current situation, etc.
Even if theft is your primary concern - and I will grant you that for most small companies where it's targeted theft, the finger more likely points to an insider - using SaaS, especially if it's one builds on a third party provider's stack, means you are increasing the potential for breaches, and you don't even know what that increased potential is, and potentially you may not even know if a breach occurred.
Imagine a company that runs a service on Heroku (who in turn have built on AWS). So by using this service, you suddenly have great potential for individuals at three other corporations to heavily influence your ability to do business and remain profitable, either through data loss, downtime, or the aforementioned security breach.
I haven't even mentioned the issue of data privacy here - it seems quite common for modern SaaS startups to rely on VC funding to offset the costs of providing their service, with the vague notion of "if you build it, they will come... and then we can somehow turn them/the information we hold on them into a profit"
This is the ideal compromise to me. I can own my data and the application, but I don't necessarily have to deal with all the annoying details of managing my own servers.