"More than 150 people (!!!) contributed commits to this release, bringing the Zulip server to 307 distinct code contributors. In 2017, Zulip has had, by a wide margin, the most active open-source development community of any group chat software."

Zulip is an amazing open source community to work with. The community puts in a lot of effort and thought to welcoming new contributors and keeping it easy, fun, and productive to contribute.

Repository: https://github.com/zulip/zulip

Chat with the devs at https://chat.zulip.org !

Zulip is easily the best open source group chat solution, especially for companies.

It's very well designed from the ground up and gets all the little details right (real name + mail address handling, not mangling pasted content, full text search, hell, they even ship with Nagios checks for their backend services...).

The threading model is second to none - once you've become used to it, using any room-based chat software feels cumbersome and "wrong".

Does not match my personal experience over several months of daily use. Zulip is designed by and for software engineers—which is not a compliment. The whole experience feels like opening vi for the first time. Nothing is obvious… not even writing a message.

The threading model is probably how all other chat apps should work, but I don't think that the ui/ux that actually exists in Zulip is good.

Clicking on a message is how you open compose to reply.

Also, there are giant buttons at the bottom of the screen to compose a new one.

Yes, you do need to learn a bit about how to use the tool, but that's true for any new tool.

Big congrats to all the contributors, this is a huge release!

Is it just me or do the instructions (https://zulip.readthedocs.io/en/latest/prod-install.html) for running the server "in production" make people's skin crawl??

I suspect that this is common with corporate tools and services since business priorities usually dictate that resources are focused on revenue generating systems / services. Comes with it's own risks...

FTR: will see if I have some cycles to contribute improved release process documentation in the coming months.

For opensource standards the instructions look pretty okay? Looks similar to instructions for projects like Mattermost, OTRS, etc.

concerns stemmed from the various mentions of everything being in /root which just seems like plain bad security practice.

however a cursory review of the codebase indicates that most of the services run as the zulip user and authentication uses certificates rather than passwords.

It might not have been obvious, but for installation, you should use a dedicated machine or virtual machine.

That would mean your concerns regarding /root would be solved automatically.

What business priorities? Dropbox owned the IP and opensourced it. No one is selling it now. If you know Django, the instructions are pretty simple.

If you intend to deploy this for your organisation, who is going to deploy and maintain the service for you? Does your company / organisation emphasise the same level of support for internal tools as you do for external services for (paying) customers?

It's not a supported, paid, commercial product...if you want to use it, you can set it up yourself. If you want to have someone set it up and support it, you can hire someone, or use your own staff. It's no different than 99% of open source software out there.

It's not slack--they don't host it for you.

I don't understand your second question.

Anybody have a Kubernetes Helm chart for Zulip so I can just do 'helm install zulip' to try it out?