> You’ll need an Ubuntu system that satisfies the installation requirements.
So if I'm using RHEL, Fedora, Arch or any other Linux distribution, tough luck. If they're supporting only Ubuntu, they could have at least created some deb packages.
There is an install script, but no details about what's going on under the hood or explanations of how to do it manually; what other software is required, e.g. for the database, how Zulip uses it, what libraries or other kind of dependencies it has, etc.
(and get a lot more detail if you browse around the rest of our 120K words of developer documentation).
I have a great deal of Debian packaging experience (I used to maintain over 100 Debian packages for MIT's Debathena project, mostly powered by the config-package-dev project that I'm a co-author of; and then later 20+ in Debian itself as part of getting Sagemath into Debian; and I maintain the handful of Zulip dependencies that we ship versions of in our Ubuntu PPA), and so I have a pretty good sense of what does and doesn't work well with the Debian (and RHEL) style packaging models.
I'd love to support native packages for every platform, but it's a huge amount of work (especially on the maintenance side, since one needs to do QA for each platform's upgrade process) that comes out of the time we can spend on making Zulip a better product. And the result is likely to be less good error-handling; I'd rather have an installation/upgrade process that just works (and if it can't because of some problem beyond our control, like the server not having enough RAM or disk, gives a clear error message that explains the problem to the user) but is limited to one platform (which anyone can easily get; virtualization is 20 years old at this point!), than support lots of platforms but be constantly fixing little issues with the other ones.
Which isn't to say that we won't support e.g. RHEL in the future (we probably will), just that it's costly to do so, and the "Use an Ubuntu VM or container" solution works pretty well for most folks.
That said, we're open source (and an open community!) and anyone who's worked with Zulip knows that I'm very happy to provide detailed technical advice and do code review to help things like this happen.
That and this page [1] mentioned by zerkten, are what I wanted. Too bad I didn't find them in the first place. Maybe they should be mentioned in the page I've complained about.
I'm familiar with RPM packaging, so I feel you pain.
I understand that you don't have native support for every platform, after all you probably don't support Windows :-) What puzzled me was the lack of instructions, so that others could at least try making Zulip work on their system.
Those instructions are for the development environment which is simpler in a few key ways (e.g. one doesn't need to deal with SSL certificates). But yes, that'd be the starting point for a production installer for other platforms.
I see Docker / your container tech of choice as a solution to this. Your server can still run whatever distro, and a specific app can run a different one.
This can be annoying from the sysadmin perspective, since there are now multiple operating systems to take care of, but at the same time, the developer may not be able to produce builds for all distros their users would like.
Ubuntu is a fine choice IMHO, given the above. But yeah, some debs / ppa would be nice.
One day libfoo announces a must-fix RCE bug, which started in 1.74 and is fixed in 2.11.
Quick, which containers have libfoo in them? What version? Do you have a complete build process for them, or did you download the container from somebody else? Is it a clean libfoo, or did somebody clone it into their own tree and has later made modifications to it?
And that's really quite "annoying" from the sysadmin perspective, which makes it annoying from the devops perspective, which should make it annoying from your whole IT infrastructure perspective.
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.
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.
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.
I think that people who want software as a service, are probably happy with running the install script on Ubuntu and just treating everything as a black box.
> You’ll need an Ubuntu system that satisfies the installation requirements.
So if I'm using RHEL, Fedora, Arch or any other Linux distribution, tough luck. If they're supporting only Ubuntu, they could have at least created some deb packages.
There is an install script, but no details about what's going on under the hood or explanations of how to do it manually; what other software is required, e.g. for the database, how Zulip uses it, what libraries or other kind of dependencies it has, etc.
[1]: http://zulip.readthedocs.io/en/latest/production/install.htm...