This strikes me as ironic, because Zulip started as a SaaS project. Much of the current cruftiness perceived in the install process is likely because earlier generations of the Zulip codebase were written with the presumption of developers in the same team being the ones deploying it.

SaaS itself is the cancer killing usable software installations, not the other way around, IMO.

When there are so many options for one-click repeatable deployments of complex stacks that strikes me as an overreaction.

I recently had to test a complex Django-based Document Management System: https://www.mayan-edms.com/

The install was a breeze. Even with very little experience with Docker it took me a matter of minutes to fire up a Digital Ocean droplet, paste in a few commands and have a fully working install.

Every open source web app should have some equivalent that is as simple as this.

The install was a breeze because you practically installed a self contained black box. What if you wanted to use Apache instead of nginx or a custom compiled Python interpreter or PyPy?

How often do the majority of people need to make these changes? With a well designed "self-contained black box" it should be possible to make the changes you suggested (web server and Python interpreter) pluggable, to some degree. There is always going to be a trade-off which has an impact on those with more specialized requirements.

> The install was a breeze because you practically installed a self contained black box.

Yes. Exactly what I wanted.

> What if you wanted to use Apache instead of nginx or a custom compiled Python interpreter or PyPy?

Then I would have read through the Docker config and figured out how to change it.

Then you go to documentation for a more manual installation and adjust it to your tastes.

Problem is there doesn't seem to be much documentation at a quick glance. At least for Zulip.

There seems to be a lot more information within the section of docs focused on developers like https://zulip.readthedocs.io/en/latest/development/setup-adv....

Companies and investors prefer SaaS because it solves their requirements, including: cheap support with no legacy installations, and the ability to move the product in new directions very quickly. This often doesn't overlap with what all customers of a piece of software want.

SaaS software often hits a sweet spot for one set of customers and then it is updated to match the needs of a new set of customers. Conflict can arise and the first set of customers abandon the product or are unhappy. When customers can deploy the software themselves they can decide to stay on the old version.

Of course this is often a terrible decision because customers get stuck on the really old version, experience security issues etc., but when it is managed appropriately (i.e. just strategic software for a business) it can work out. Managing lots of individual packages is a cottage industry for IT teams in big companies so they often undermine efforts to do this right.