I really disagree. On-Premise software is frequently bought by large customers with significant resources - including a competent ops team. Yes, there may be some initial handholding, but once things are up and running, there is little support necessary.
Basically, if you want to build an on-premise offering, look at the way Nginx, Postgres, Redis and similar projects are packaged and do the same.
> Basically, if you want to build an on-premise offering, look at the way Nginx, Postgres, Redis and similar projects are packaged and do the same.
Nope. You should look at how an app that uses all of those is published. That’s what on-premise software truly is. A combination of dependencies and your companies secret sauce.
This highly depends on the industry… I worked on projects for large F500 companies who had neither ops nor where willing to spend resources… as I mentioned in another thread, on prem can be a world of pain… but it can also be a lot of fun if you have customers like you mentioned
> On-Premise software is frequently bought by large customers with significant resources - including a competent ops team.
These are orthogonal. Resourcing is no guarantee of ops competency, or a culture where ops is enabled to deliver, hence the concept of shadow IT. On-prem software is bought by orgs with low risk appetite or other compliance objectives that skew procurement towards running on prem. I have seen exceptional ops teams on a shoestring ramen budget, and I have seen dumpster fire ops teams in companies with thousands of workers and billions of dollars a year in revenue who could not get you a single virtual machine in less than 90 days even if preventing the end of the world depended on it.
Basically, if you want to build an on-premise offering, look at the way Nginx, Postgres, Redis and similar projects are packaged and do the same.