New plans for self-hosted Zulip customers

edit: for Android at least, you could give your users a modified APK.

I don’t think anyone argues that charging for this thing is unfair, the act of offering it for free to acquire users then rug pulling to charge for it is the gross thing here. You can argue that people should have planned for this kind of thing and that it’s a risk you take with FOSS, but there were other, less rug-pull-ey approaches that could have been taken here. It just so happens that they might have affected growth numbers and subsequently made the company less money

You want a plan with push but without support, and I sympathize, but I also understand why they wouldn't. Once you start paying, you expect support.

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.

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.

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 agree the existing React Native mobile apps have been the biggest pain point for Zulip. Our mobile team's main focus for the last year been rewriting our mobile apps in Flutter, which will result in apps that are faster, dramatically more correct in terms of how faithfully they implement Zulip's API and business logic, and with a cleaner design. Here's the section of the Zulip 8.0 blog post about it:

https://blog.zulip.com/2023/12/15/zulip-8-0-released/#apps

Curious readers may enjoy the main chat.zulip.org conversation it links to, about our evaluation of Flutter. But in short, our experience has been that it has proven to be a much much better platform than React Native for a small but very capable team that wants to build a high quality mobile app.

I should mention that the upstream Flutter project is awesome: it's been an absolute pleasure that when we find significant problems with the platform for our use case, like the Android scroll physics not feeling native, we have been able to contribute a series of pull requests to fix the issue for everyone. As a result, we've contributed a few dozen PRs to upstream Flutter already.

Why aren’t cloud services priced closer to cost like every other commodity?

- It's more predictable for the business (you can model what you'll pay in advance), so the business can model their total expenses and make a budget. I don't see how a customer could accurately predict how many mobile notifications per month they're going to generate for a product they're not using yet -- it depends on the personal preferences of every employee what notification settings they choose. Any business with a procurement function is going to look very skeptically at unpredictable costs.

- It's more predictable for us -- metered per notification would have all sorts of weird seasonality.

- A per-notification fee would have perverse incentives for us, like "we made the product really spammy with push notifications and it doubled our revenue". We would try very hard to resist that, but incentive structures are powerful, and we want our financial incentive to be to maximize the number of people who are happily self-hosting Zulip, not some other weird metric.

- A per-notification fee would have perverse incentives for the business, like the manager asking people to toggle their settings to save money rather than to choose the settings that make them most productive.

Are you using Zulip exclusively for paid team members in a first-world country? It's hard to imagine this pricing being a significant expensive if you are.

If not, check the sponsorships and discounts section of https://zulip.com/plans/#self-hosted

(In any case, our sales team would be very happy to discuss your or anyone else's individual situation -- specific situations are very helpful for figuring out gaps in policies where it might make sense to introduce a new plan)

[0] https://unifiedpush.org/users/faq/#will-unifiedpush-ever-wor...

[1] https://zulip.readthedocs.io/en/8.0/production/mobile-push-n...

“Same deal” in that you can either pay a per-user fee, or host the push server yourself and ship patched mobile apps to receive them.

AFAICT the way push notifications (and SMS) work allows them to be received just by the baseband processor which listens to the radio transmissions at a very low power. So, until a notification comes, the whole app processor may safely sleep, saving a ton of power.

20 years ago, the only way to get proper push messaging on a phone (other than SMS) was Blackberry with a special phone plan where the provider ran the push notification server.

SMS still works fine. The situation for everything else has much improved.

A central notifications server is kind of an unfortunate necessity - if each app would open its own TCP connection, all the keepalives would significantly increase radio wakeups and thus battery usage vs. a single optimized connection. You can still use IMAP Push like you could 20 years ago, the reason few people do is because of the extra power usage.

(FWIW, 10k mobile push notifications a month sounds high, but it is not a very high limit; in practice, a lot of teams of fewer than 25 users exceed it.)

I will say that we put a lot of careful design and engineering effort into doing this transition in a way that cannot result in unpleasant surprises like upgrading to the latest release breaking a feature you're relying on.

Using a 100% open source product provides customers with a lot of protection against bad behavior by vendors. If you're using a proprietary product (including the paid/proprietary versions of open core products that market themselves as open source), the vendor has a huge amount of power to move a feature you need to their Enterprise plan that costs 5x as much, and if they do that, you're stuck either running an old version (which will accumulate serious known security vulnerabilities), upgrading and dealing with the changes, or migrating to an alternative, which in situations where the product has all your data in it, can easily cost far more in than the product itself.

I can't say I have all the answers for how commercial open source software should work. I can tell you that open core is a much easier business model.

The hope is that people do care about the very significant benefits that come with using well-engineered, no tricks, 100% open source software, and that businesses that are relying on open-source software are willing to pay for the services and support that they need to succeed with it. Time will tell.

I feel like the comment is a bit disingenuous, however; the complaint isn't "Zulip Business only includes push notifications" - rather, it's "the only thing I'd want out of paying for Zulip is push notifications." And indeed I would very happily pay for just notifications (which I assume costs a negligible fraction of the pricing) if it was a more reasonable price point (on the order of say, a dollar per user per month would still be a very healthy margin).

I suspect a lot of folks in a similar boat as me - sysadmins who pushed for Zulip as a Slack alternative at a small startup (with a nontrivial amount of convincing!) and are happy to deal with the hassles of self-hosting and don't ask for support. Having the price be exactly the same as a fully hosted solution, given the particular set of needs, then does feel like too much. I get that support is expensive, but having the option to not get support would be nice.

Of course, I totally get that you need to stay afloat, and it might be a short term way to get some money out of self-hosted customers. But it removes things that make Zulip appealing to someone who doesn't want support and would like to pay a more nominal fee for notifications (and certainly makes me less a lot likely to recommend it to someone setting up a new chat system, and I've done this a few times already).

I hope you’d rethink on this point. Nothing else matters in this context. Not Mattermost, not Rocket Chat, not the entire open source model.

The alternative would be that anyone could send notifications to an app, which seems destined for abuse. There could be a system where apps could have some mechanism for allowing authorized third parties to send push notifications, but that seems essentially the same as routing those through a central system.

Maintaining an open TCP/IP or even UDP/IP network socket to receive incoming notification messages requires sending a packet back and forth every so often to confirm the socket is live and keep it open, even while the socket is idle and there are no notifications.

You can technically open a socket without doing this, and this does work on parts of the internet. It often works between devices on your LAN. But many modern networks have unreliable connectivity, handovers between base stations (i.e. mobile or wifi), often one or more layers of NAT and/or firewalls, and more. The only generally reliable solution to get real-time inbound notifications to a device, is for the device to open an outbound socket and the protocol to send a packet occasioally in each direction. The packets confirm liveness to the receiving endpoint, as well as telling other parts of the network the socket is still live.

When your device hasn't received a confirmation after a configurable timeout, it's time to open a new socket from the device, because the original socket may have stopped working. The timeout lower bound depends on how much delay in notifications you can tolerate due to a non-working socket, and the upper bound is whatever keeps it working through all NATs and firewalls in the network, reduced by a margin to cover latency variance at an acceptable probability of disconnction. Often the packets are implemented as a "ping" request-reply pair in the protocol, but actually there are other, more efficient patterns, and pings are not required at all during periods of other active traffic.

Those pings wake the radio in the mobile device, which drains the battery more than you'd think.

If you have 50 apps each using their own separate socket and background process, they will wake the radio up to 50 times more often as one app, assuming they have independent timing.

If the 50 apps are synchronised to communicate at about the same time, they will wake the radio less often to send and receive packets for multiple applictions in a single radio wakeup. By itself this saves battery power, because the device's radio is able to send multiple packets with only a little more power consumption than a single packet, if they are within the same time slot. This also reduces radio overhead on the mobile network due to how time slots are negotiated among devices.

However, that requires all the apps to use very similar protocols and to synchronise somehow. Even more power is saved by having one shared app (or service), with only one socket open to a shared server. As long as that shared service handles notifications for the other 49 apps, and the 49 app notification channels are idle nearly always, the shared service reduces battery power consumption considerably, as well as reducing IP network traffic and mobile radio overheads.

That's three technical reasons to have a single, centrally managed notification service per device.

Additionally, the device maintains real-time contact with the mobile network. To do this, the mobile network protocol uses something like the above, sending a packet occasionally in each direction. This happens at a lower level than the IP protocol used by apps, but the principle is similar, waking the radio every so often to keep a live channel going.

The mobile protocol is diferent from the internet protocol normal apps use. The mobile protocl is robust enough to carry real-time notifications of calls and SMSes, among other things. It's not perfect, but when the mobile protocol is delayed or fails to deliver, an app using internet protocols (TCP or UDP) on top of the mobile protocol won't do any better.

If the mobile carrier/network supports it, the shared app notification service can wait for a special mobile protocol event. Think of it like a magic SMS. This notification event comes "for free", as it uses the radio activity already being done efficietly by the mobile protocol, instead of an internet socket with ping packets and its own, separate background radio activity. But this method requires a special arrangment with each mobile carrier, and functionality in the device OS. It's not as simple as the network-independent internet sockets which normal apps use.

That's a fourth technical reason to have a single, special notification service.

Running an actual service costs money. The proper thing here would be to allow people to self host the notification server also.

The pricing is terrible. The only feature we get from it is the push notifications. We've never used support other than raising issues, all of which turned out to be problems others were having.

But the source is actually open, you can compile it yourself, and you can even use their VM images and change the config. Google and Apple are the source of the intervening issues.

We may leave them over the pricing, but not the software or the license.