"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.
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.
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.
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.
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.
14 comments
[ 2.7 ms ] story [ 31.7 ms ] threadChat with the devs at https://chat.zulip.org !
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.
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".
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.
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.
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.
It's not slack--they don't host it for you.
I don't understand your second question.
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.
That would mean your concerns regarding /root would be solved automatically.