| Last year I was looking for a tool where one team could provide chat support to customers - of course the customers should have their own space, in tulip this would be organizations. Zulip comes with some good UI ideas for a chat system, the multi-organization experience was not so great. Unfortunately it was not possible to have users take part in several organizations - so each support team member would need to have one account in each organization - that gets messy really quick. I do not think that this is a very edgy use case, but it is an indicator of some underlying design limitation. Having users limited to 'org' does not seem to make sense - instead it is obvious that one wants to have users and groups and some sane way to fine-tune rw permissions and visibility between groups and objects that groups create. I was wondering if such an obvious limitation in the basic design was somehow induced by the use of Django. A programmer with some DB design experience would have spotted that quirk in a very early stage. I understand that Django traps new users into these kind of constructs with its obscure db layer - this is the microsoft principle - 'hiding complexity' in the end leads to hiding knowledge and makes people produce problematic results. It is a good example of how the use of a framework can destroy a good software idea. Hopefully some people with good db knowledge can fork the frontend and build a better backend for Zulip - obviously Elixir would be a good fit with its soft-realtime channels for this kind of communication software. Zulip is still good enough for more simplistic use cases, but you could use any php chat system out there without the incredible installation and maintenance overhead that python brings in - absurd over-complication seems to be another symptom of the framework disease, people just do not seem to know that they are in the 'absurd zone' because they have never seen how it can be done in a much easier way. The tools you use make up your view of the world, so you can not understand what people with other tools are even talking about as long as you do not try them. A good lesson for every developer to stay open-minded and not let productivity pressure eat your learning and research time. |
Although there's the superficial similarity that they both involve "chat", customer support is actually a very different problem to solve than what Zulip (and Slack and all its other alternatives we're talking about today) is focused on. It's no surprise that Zulip wouldn't have the features you need, and it's definitely not somehow an overarching indictment of the Python ecosystem.