This is quite disappointing - having the same pricing as a fully managed Zulip Cloud for simply getting push notifications (at $8/user/mo!) is really steep and feels like a clear way to push people to Zulip Cloud and discourage self-hosting.
In particular, "We are not turning Zulip into a proprietary product with an “open core” demo version" doesn't ring too true, given that a key component that must also be pretty inexpensive to run is walled off (self-hosting the notification server is explicitly discouraged by the Zulip documentation and would require re-compiling both iOS and Android apps).
I've been evangelizing Zulip for a long time but this feels like it's being slowly turned into Slack, and the open source/self-hosting proposition lost a lot of value.
Is there no way they could have framed it that would make it clear that you get support for the thing that you are paying for? Maybe it's because I'm a software developer, but it seems pretty easy to understand that if you're paying for the push notifications API, then you're paying for the push notifications API. Support for the rest of the self-hosted app doesn't come along with.
If you're a software developer, yes. If you want to have this in an org where there are non-technical people, explaining it to them may be a tad more problematic.
I work for a company that offers both a cloud and support for self hosted version and if anything offering support is more expensive than the cloud version
"self-hosting the notification server is explicitly discouraged by the Zulip documentation and would require re-compiling both iOS and Android apps"
Given the app store rules, this seems like the Zulip team has no choice in this matter.
If I'm wrong, and it is possible to have an app whose notification server is configurable at run time, then only one person needs to do the work to modify and publish that binary. Everyone else who wants to self-host a Zulip notification server can use that same binary.
The issue is that to setup push notifications for an app you link your apps bundle id/package name with the Apple/Google developer account that you publish with. For the Zulip app that will be the developer account owned by Zulip. Your app is then signed with credentials linked to that account as well.
When you want to send a push notification to the app you use an API key from that developer account. This lets Apple/Google know which app to send it to and confirms you have the permission to do it.
If Zulip wanted to allow a self-hosted notifications server to send notifications directly to Apple/Google and into the app they publish on the app stores then they would need to give out the API key from their developer account to everyone.
You wouldn't be able to do much without the matching device push token (a unique token per device which lets Apple/Google know which device you want to send a message to) but anyone could use that API token to attempt to spam messages which is a quick way to get your developer account banned, or at the very least have your access to the push API severly limited.
I'm sorry, why would they do that? Instead of building their own API key infrastructure and proxy the requests to the respective notification services? For an example, please see Mattermost's on-prem notification implementation.
> "We are not turning Zulip into a proprietary product with an “open core” demo version" doesn't ring too true, given that a key component that must also be pretty inexpensive to run is walled off
No, it's pretty clear it doesn't change anything about uts open source status. No definition ever required that authors run the services for you.
> I've been evangelizing Zulip for a long time but this feels like it's being slowly turned into Slack, and the open source/self-hosting proposition lost a lot of value.
Why? From my POV, push notifications are sort of an edge case, useful only for a handful of people who need synchronous communication in their mobile device. I disable notifications for most apps I use anyway, they do nothing but annoy me.
What I'm saying is, this very much depends on the use-case and work style. If my most used productivity app lost notifications, I wouldn't even notice.
In particular, "We are not turning Zulip into a proprietary product with an “open core” demo version" doesn't ring too true, given that a key component that must also be pretty inexpensive to run is walled off (self-hosting the notification server is explicitly discouraged by the Zulip documentation and would require re-compiling both iOS and Android apps).
I've been evangelizing Zulip for a long time but this feels like it's being slowly turned into Slack, and the open source/self-hosting proposition lost a lot of value.