It's always annoying to have something that was free taken away from you, but this seems pretty fair. There's no way to handle push notifications without a centralized server.
You can complain that $8/user/month is too expensive for hosting a service that probably does not require much in the way of infrastructure. Well, you can host your own, it's just a pain. And all of the code is open source, so if someone else thinks they can offer Zulip hosting for cheaper, they are free to do so.
This post feels a bit overly sympathetic to what amounts to a rug pull on the part of the business.
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
It is a pain, you would have to submit your own versions of the android and iOS app, bundling your FCM info. I'm not even sure they would be accepted since the app is already on these stores. It might be impossible to do this.
edit: for Android at least, you could give your users a modified APK.
Maybe somebody could build free versions of Zulip apps that use UnifiedPush instead and ask the server to send pushes to their preferred push notification provider. (Of course, this would mean you have to keep both apps and the server soft-forks updated with upstream changes, but it doesn't seem too hard of a project.)
From the FAQ: "iOS doesn’t support running services in the background, so running a UnifiedPush distributor won’t be possible without jailbreaking or Apple’s approval for the foreseeable future."
I think a better strategy that would require less ongoing maintenance would be for someone to build the mobile app and a routing server similar to what is in place now rather than reengineer the core server and mobile apps to use a different tech stack for notifications than it currently does.
I kinda feel that while doing something like would serve a segment of the user base this would also be a bit disingenuous to the folks at Zulip who have done an amazing job at balancing commercial monetization needs with their dedication open source principals and giving away their labor of love to world in general.
It has been a while since I looked into it, but don’t both app stores have provisions for offering private apps available only to people within an organization? Still seems like kind of a pain to maintain release parity, but not out of the realm of reason for an org that cares a lot about keeping their communications fully in-house.
1. Apparently, only one MDM is allowed per iOS device. This is a no-go for BYOD Consultants (like me).
2. Apple Business Manager does support Ad-Hoc distribution of links to private custom apps, but is limited to only one country. I have at least one client that has consultants across countries (typical when hiring in EU). The client doesn't even have a business registration in each country, so they can't even sign up for Apple Business Manager per-country they have users in. And even if they could, that would cost 300 USD per country.
Android doesn't even need the app to be distributed via Google, or even that an app uses Google's Push servers.
Publicly available apps for orgs that require an account in order to do much of anything exist. You could download the app and end up in no-account purgatory
Push notifications can be cobbled together for self-hosted Zulip using self-hosted Gotify and letting users install the Gotify app. No requirement for an app store approved app. However, Gotify is blocked on iOS via lack of viable background connections.
There is a way to handle push notifications without a centralized server for web/PWAs. Each instance can generate a VAPID and deliver direct to clients.
While this might be a special case, in my experience anything which sends customizable notifications or messages of any type will end up being attacked with attempts to use it for spamming, and that ends up being a constant battle.
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.
I'm a really, really big fan of Zulip - I forced it on my company and people are also not mutinying (though it's closer to mutinity than I'd like).
I understand the need to monetise and I'm a paying customer despite not really needing (or being able to use in some cases) the extended features of the standard plan.
But for the love of god, please fix the mobile app.
It's the #1 thing people are complaining to me about, and by a very wide margin.
Adding more costs for self-hosting and using mobile is not a smart play when the mobile story right now is already terrible.
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:
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.
I’ve seen engineers lead the charge to force Zulip on a company. I get it, it’s an engineering friendly tool. Otherwise it’s a fundamentally terrible application that is not appropriate for a whole company to use. I hope your mutiny happens!
Most companies don't actually do anything useful, and their internal chat is just for socialization. Slack is terrible for having actual productive conversation and great at unstructured socialization, whereas Zulip is the reverse.
“because its not slack” was the consensus when I conducted an internal survey.
Sadly people were not clearer than this. I suspect some UI prettiness things, some ease of use things (onboarding) and a fair few misgivings (such as voice chat and how images work) that makes it feel user-unfriendly.
In the last decade, decentralized web-crawlable forums (the likes of vBulletin, phpBB, etc) have been decimated by the proliferation of monolithic walled gardens like Discord and Slack. Then Zulip comes along with features that feel like a throwback to the forum era (web frontend, public access option, threaded topic system, email notifications) but with modern sensibilities in mind (mobile clients, proper API, bots, push notifications). Zulip seems like the kind of project that has the potential to turn the tide and make discourse more decentralized again.
I fear that the introduction of any pricing for self-hosted installations like this will steer Zulip away from its potential as a ubiquitously deployed platform and toward a niche subscription model, as open as it may be, relegated to the odd enterprise with refined taste in communication platforms. Very unfortunate news.
I'm disappointed with the new pricing for self-hosted Zulip customers. While I understand the need to monetize, charging a flat rate of $8/month/user for push notifications seems excessive, especially when notifications are the only feature that can't work without purchasing a plan. It would be more transparent and fair to charge based on the number of notifications sent instead of a per-seat basis. The current pricing model could discourage small organizations from using Zulip, as adding a new member becomes a significant financial decision.
Because it's not a commodity, you can't plug another notification service in any app and then pay that notification service provider just for notifications
Is there any reason besides tradition to charge per seat? If notifications cost money, wouldn’t it be more transparent to charge per idk 1k notifications / mo?
With new pricing, if you have a small org, say, 11 ppl, you suddenly have to pay an extra $1000 - on top of paying for the hosting of the self-hosted solution.
It goes from “sure we can add this one guy to the org for a month without thinking much of it” to “do we really need this person in our Zulip” which isn’t a great strategy for comms.
Pricing per seat is a better model for all parties.
- 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.
(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)
> 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.
The problem is not that it’s expensive, it’s that it was sold as free, and that was a major component in getting the go ahead to use it. As soon as money becomes part of the equation the process of me ‘just using tulip’ becomes 100x more involved, and the balance swings heavily towards ‘just dealing with Teams’.
Of course that doesn’t really mean anything from a business perspective since we weren’t –and won’t be– paying either way. Just wanted to make it clear.
While I imagine it's no priority, nor a solution for everyone, I wish more apps would support UnifiedPush[1]. The notification limitation is purely an Apple/Google one, and there's no "hub" setup you can easily configure with either.
This would solve the notification problem for many self-hosted applications, also allow for non-Apple/non-Google deployments if you want to avoid sending PII or other sensitive data through those servers (though Android apps could use UnifiedPush/fcm-distributor to combine the advantages of FCM with the advantages of UP).
I get that there's not a lot of business interest in this solution but when it comes to open source stuff, I really wish this would pick up more steam.
Conversations (the XMPP client) has also figured out a way to receive notifications without using centralized servers by keeping an TCP open thus avoiding any centralized servers for push notifications. Modern XMPP servers can be instructed to only use the TCP connection when a notifying message arrives to avoid radio and battery consumption. Conversations also can act as a UnifiedPush distributor for other apps which don't want to maintain their own TCP connection.
How does this handle frequent network/tower changes (think high-speed train) and such?
There are also the privacy implications, if you have separate connections to a server for every single app, every single app knows exactly when you get home and go to work (by monitoring when you're connected to WiFi and connecting from a broadband operator and when you're on mobile.)
The goal or Unified Push is that you have one push provider you install (Conversations, NextCloud, ntfy) that ofher apps integrate you. Apps register a callback URL through the provider on your phone, report that to their own servers, and when it becomes time to notify the user, the server submits a POST request to the app server.
If set up right, there will be two persistent connections at most: one to Google/Apple, one to the provider you have registered. The app will inform the other applications on the phone of the notification, so there is no need for any other individual connections back home.
This is an alternative for what happens now when apps can't make contact with platform notification services (either because of network failures or because of the push service being disabled): suddenly, every app falls back to their own custom notification socket, or notifications stop showing at all.
The mobile platforms really need to provide an API like "the radio is now on, please do your thing", so all apps can coordinate when they're active, and save battery.
QUIC makes changing IPs cheap & trivial, send one packet to server to poll for new messages, server responds with one or more packets to get pending messages delivered, and will push messages to that IP from there on.
I'm not quite sure how it handles network changes, but Conversations has worked well for me even on trains and cars in the last 2 years. Maybe this? https://xmpp.org/extensions/xep-0198.html
Yes, XEP-0198 is how reconnects (network changes, train tunnels, etc.) are handled. When the client reconnects to the server they exchange where each received up to before the disconnect and each side resends anything that was dropped.
This blog post covers some more recent improvements at https://blog.prosody.im/fast-auth/ - it makes XMPP (and therefore Unified Push) even smoother on lossy and high latency networks.
Android, Windows, macOS, Linux, any platform but iOS, really. There's little stopping you from taking the Java library and stuffing it into a desktop application for a single everything-but-iOS notification service.
I'm not sure where the restriction lies, but with AltStore being easily accessible and Apple being rumoured to allow users to install their own apps like normal, it's quite possible that we will have an iOS version soon. Of course nobody will work on it until Apple fixes their restrictions, but I wouldn't be so pessimistic as the authors of the website.
"Fix" is a strong word. I was of the opinion that both Google and Apple have limited background services heaps of the years for the purpose of saving user battery life. Why should this one be an exception?
Perhaps the companies which self-host are the ones with the most stringent security needs, and are the exact customers who would be willing to pay more.
Perhaps the optimal price is higher for this new plan, than for the cloud plan?!?
That's kind of stingy IMO. The push notification service can't be too expensive to run. Plus, notifications are a big part of messaging services.
Yes, the client is open source, but the user would need to submit their own version of the client apps to Google/iOS, while embedding their FCM API info into the app, in order to access push notifications again.
Wasn't Zulip grandstanding about remaining free when Mattermost removed their free plan [0]?
I guess no "free forever" promise was made about push notifications, and the free cloud plan remains, but billing the self-hosters feels bizarre to me. It would make more sense to provide them with a way to self-host the push infra and assume the cost themselves.
Wait why does selfhosting Matrix and using the Element app give me notifications for free but Zulip tells me I can pay them or recompile my app? Does that seem right to you?
That is totally wild to me. Of course we are entitled to free notifications if we run the infrastructure. Who is subsidizing my XMPP client notifications? Why has this never been a problem for any other chat client until Zulip? If literally every other chat client to a FOSS chat server can make it work without crumpling under costs, Zulip is in the wrong and should not do this.
The push notifications are a centralized service that communicates with the Apple and Google push notification service. All those Element/XMPP/Zulip/etc apps run their own infrastructure that receives the notifications from your self-hosted server and passes it along to Google/Apple.
If you run an XMPP server and an iOS client for example you'll see in your logs that your server is connecting to, e.g. push.tigase.im or whatever if you're using Siskin. Another server for Monal. Another one for ChatSecure. and so on.
And they break. Monal for example rate-limits connections which leads to no push notifications for a while.
It's not unthinkable that they will either fold and follow the current trend or stop offering the service altogether, if it really does cost.
That's just plainly wrong.
A push notification will wake up the app for 30 seconds and in this timeframe enables it to receive all new messages directly from the xmpp server. When Monal receives an additional push message within these 30 seconds, the background time is increased by apple for another 30 seconds, resulting in a higher power consumption without any benefit.
That's why our pushservers ratelimits (lets better call it: deduplicates) pushes to 2 per 30 seconds.
Ceasing to operate our pushservers would be the same as ceasing to develop the app itself. And that would be bad even if no pushservers were needed.
So no, it is indeed unthinkable to stop offering these pushservers.
If you want development and the operation of the push servers to continue, you can always donate some money. Currently our funding especially for the push servers could be better…
Are you running the infrastructure? If push notifications go from your Matrix server to some server run by Element to Apple to your phone then Element is subsidizing you.
Yeah, but everything else being equal (using Element), I have my account on their server too, and use push messages there. Or I only use their push messages and host my own server. As far as I understand both are free.
So you have nothing to worry about, then. If you were running your own Matrix server, and wanted to use their push infrastructure.. Well you're still fine for now but who knows in the future.
It seems like Mattermost is basically the same deal unless you use their “Test Push Notifications Service”, which they discourage using in production, no?
“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.
There's no Zulip Test Notifications Service. And after a few years of running on the Mattermost Test PNS it is generally pretty stable, you just don't get any support if things do go wrong.
Not a criticism of Zulip, but it'd be nice if "push notification" services in general went away.
Mobile devices used to work well enough, without needing an extra server over the Internet involved in notifying the user of something they cared about. And battery and processor technology has advanced a lot since then.
On my current handheld, I like the Internet bandwidth and latency, and I like the OpenStreetMaps-based app, but otherwise... the important features I actually want generally worked better 20 years ago than they do today (and didn't feel like everything was designed to shovel garbage at me, and spy on me).
If these platforms had been designed for privacy and security, and to serve the user rather than exploit them, I think they would be very different by now, including not needing "push notifications".
> the important features I actually want generally worked better 20 years ago than they do today
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.
I appreciate very much the push notifications for emails and IMs. For one, they rid the email and IM apps from having to periodically wake up and poll their servers.
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.
New self-hosted customers will no longer get unlimited free access to Zulip’s Mobile Push. Fortunately, this doesn't mean they are making anything closed source!
In short, you have to change some config in the self-hosted Zulip server, and publish modified versions of the application to the app stores you want to support. This is not a limitation of Zulip, it's the app stores forcing all apps to have their notification sources restricted to a common, known ahead of time, server.
As I wrote under another comment, this doesn't seem like a good reason or I must be missing something because I can selfhost Matrix or an XMPP server and get notifications for free with any client.
Whatever Zulip is offering here is not good and if these other offerings can make it free, Zulip should be able to too without charge or requiring I recompile their app.
The Element client will register your client with their push notification system (even if self hosted). It will attach data to your session on your homeserver of where the homeserver should send notifications of new messages for APNS, FireBase, or UnifiedPush. The respective notification pipeline will wake up your device, and inform Element of the new messages, and display them accordingly on your device.
Android + Apple OS only listen to their respective ecosystem's push notification system, in order to minimize battery drain + needed background services on their phones.
Element has a push server to send to Apple + Google's offerings:
You can configure Element to use ntfy, or some other unifiedpush implementation, but (a) this is hopeless on stock iOS devices since apple severely limits what background services can do (b) this is frustrating on Android because there is inconsistent handling of background services.
Since I use android, I've taken option (b), and it's worked mostly okay, because I've figured out the specific magic spell for my OnePlus phone to leave the background ntfy service alone, and I'm willing to eat the extra battery to have one more service running in the background.
> As I wrote under another comment, this doesn't seem like a good reason or I must be missing something because I can selfhost Matrix or an XMPP server and get notifications for free with any client.
I don't know about Matrix, but for XMPP, push notifications work like this:
XMPP Client tells the XMPP server where to send push notifications to (a server controlled by the client author); the XMPP server sends notifications there; the server connects with an API key to Google or Apple for the push notification to appear on your phone.
Presumably the cost of running a server is low enough that free Matrix and XMPP apps exist. It's definitely not free.
Zulip is charging to nudge businesses into using their paid version. It's their server that they are running, so they are free to do so. Your Matrix and/or XMPP client is choosing to not charge, which they are also free to do so.
Zulip provides instructions on how to use a different notification server; if you want to avoid giving them money that much, then you can do so.
Zulip has always had this weird behaviour. I remember using it a few years ago until they wouldn't let me back up the whole site because it would compromise the security of my users' messages. Sure, that was true, and I could read the messages of the whole office if I did that. But someone has to be the one who can do it and doesn't. I have been that person in my office for years, and I have never read an email that was not addressed to me, and I have no intention of doing so in the future. Anyway, those are my principles, and if you don't like them, I've got others. In any case, people in the office would be a lot safer depending on my behaviour than on the behaviour of who knows who. To this day, there are colleagues who ask me to check that they haven't received a message with (for example) the following error: hharris@ to harris@. Migadu has a catch-all function, but I don't use it. Life is hard enough dealing with my weaknesses, I just hope other people know how to deal with theirs and that's it. Nota bene: I used to host Zulip myself. I can't remember why they wanted me to join the server. Otherwise Zulip was great, but truth is a good policy. Truth is a necessary policy. You will not go wrong by telling the truth: "This service will be paid for at some point, we are testing it on you. Use it at your own risk, when the free part is over we will send you a teddy bear with a Z embroidered on it".
Why would you pay $8 month per user for this when you can just get Google Workspace for the same price with Google Chat, GB of storage, Google Calendar, GMail, Google Drive, Google Meet etc.?
Pretty much all companies that care about making a profit and remaining viable offer loss leaders to build a customer base. I'm not saying that is what this is but it might be. I doubt the product would have been so widely adopted without the no cost notifications. It would be interesting to see how this affects the continued use by organizations as well as the adoption rate by new users.
That said I can't say enough about how solid and adaptable the core server product is. IMHO they have no competitors in this space. Sure there are other options that say they are open source but in reality they are all feature crippled open core distributions.
So yeah this is probably a bit of a setback for a segment of users and those affected will need to make some decisions going forward. Maybe at some point they will offer a reasonably priced a la carte version of just the notification service.
It's funny because recently there was some drama around Rocket Chat with release 6.5.0. They introduced a new "free" tier in addition to the "community" version where the latter introduced a user limit of 25. During the upgrade to 6.5.0 existing Rocket installations also were switched to the new "free" tier and thus got the new user limit. It was possible to uncheck some boxes to get back to "community" but it caused a lot of confusion among Rocket users/admins.
As of yet notifications ("up to 10,000 free monthly push notifications") are still free on the community version, though, as far as I know. Not that I necessarily want to promote Rocket.
We of course carefully looked at following Rocket.Chat's previous business model of metering notifications. A lot of incentive and predictability problems with a per-notification pricing plan that I mentioned in https://news.ycombinator.com/item?id=38660799 apply, though to a lesser extent, because a lot of potential customers will be far from the threshold.
(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.
Since there's a lot of discussion of it feeling expensive for "just push notifications", I think it's probably worth my addressing that directly as a top-level comment.
Zulip Business costs $6.67/user/month. While the only Zulip feature that can't work without purchasing a plan (or doing a huge amount of work to publish your own mobile apps) is mobile push notifications for businesses with 10+ users, https://zulip.com/plans/#self-hosted details dozens of features for which Zulip Business includes expert support.
Zulip is 100% open source. In open core products, those specific features just don't exist at all in the open source version. For example, Mattermost requires the proprietary Mattermost Professional [1] at $10/user/month if you want to use SSO, LDAP sync, user groups, read receipts, etc.
(Note also that $10/user/month is the minimum price at which Mattermost offers push notifications "for use in production environments" [2].)
If you compare Zulip's pricing options to Mattermost's, our offering is substantially more generous.
It would be even if we went open core and moved a few dozen features of Zulip to a proprietary version. But we're not going to do that: we really do care about being an 100% open source project.
If you instead compare Zulip Business to using Zulip for your business's mission-critical communications between paid team members without paying for something, I think that's the wrong question. Skilled humans' time is incredibly valuable, and people spend a LOT of time in team chat tools. It is rational for businesses to pay a tiny fraction of the fully-loaded cost of their employees for the insurance that comes with support and mobile push notifications for their main collaboration tool.
(If you're using Zulip for something other than a server full of paid employees and contractors, see the Community plan and discounts for other use cases).
Finally, on the topic of cost to us: Supporting a business that is self-hosting complex, mission-critical software like Zulip is more expensive for us than having that business using Zulip Cloud. Hosting is cheap compared to humans who can debug anything, and there are big economies of scales in terms of human time for managing a large multi-tenant cloud installation.
Helping thousands of different people with varied skill levels self-hosted your application successfully is not cheap, even for a project like Zulip that is very focused on making self-hosting Just Work.
I think the only point you either didn’t get from the comments or have ignored is that there are some people who are willing to pay a small price just for push notifications while self hosting, but not needing support or anything else. That’s a rational thing to ask for. There could be many smaller teams or businesses self hosting precisely because the cost of the hosted solution is high for them. They’ve already been taking care of support for their self hosted platform. Now you’re asking them to pay the same amount that they’ve been avoiding.
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.
Would be great to be able to purchase push notifications (for self hosted), at a price point that wasn’t the fully loaded cost of the cloud seat subscription.
Really appreciate you chiming in. (Also, as much as I really don't like the pricing change, I do really appreciate Zulip and its features!)
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).
+1 to this. I am one of those "folks in a similar boat". I have spent the last month planning a migration of our team to self-hosted Zulip. I've utilized the great documentation and never once reached out to support for assistance. We are a team of 11, which means we now have to pay over $1k/year to use a fully-functional version of Zulip. We would have been happy to pay for notifications, but this is too much of a jump. I spent a portion of the afternoon researching Matrix Element as a possible alternative for our chat needs.
Thanks for the thoughtful response! I really appreciate it. I'm doing my best to be as transparent as possible, so here's a very long reply.
This is not a change motivated by short-term needs.
The problem statement is not that we need to fund the costs of delivering push notifications. We need to fund the costs of building Zulip -- the server, apps for every platform, support for a vast range of different self-hosted configurations, etc.
Yes, we are extremely capital-efficient with a small core team who have taken some very big pay cuts to work on 100% open-source software. But even so, we need a business model that makes sense. A business model based on charging a small markup on top of the marginal costs of delivering notifications can't fund investments in the Zulip main experience or the self-hosted Zulip experience.
The main revenue source for Zulip thus far has been Zulip Cloud, and it's proven hard to grow that business, largely due to competition with the $0 price of self-hosting Zulip, which gets you most of the features of Slack Plus ($12.50/user/month).
Zulip needs a healthy model where businesses that self-host Zulip (and rely on the SaaS push notifications service) contribute to its development, just like those that use the SaaS Zulip Cloud service. This doesn't specifically require the same pricing for the two products. But it does preclude a model where Zulip Business only includes push notifications and is extremely cheap.
On the specifics of pricing, we of course have had a lot of conversations with users prior to this announcement. Most of the objections we heard were from system administrators who told us they would struggle to convince their company to pay even $1/user/month -- either because it was a big company whose bureaucracy had "already bought Microsoft Teams", or because they were a startup that had a very very high bar for paying for software at all.
Meanwhile when we talked to leaders who make purchasing decisions for their company, they tend to think about budgets in comparison with other applications that their business relies on, or else compare with fully-loaded costs per employee, which are along the lines of 1000x the price of Zulip Business. Reactions tend to be: "$6.67/employee/month? That's nothing, I pay several times that for X, Y, and Z, which we use way less than our primary team collaboration tool."
If you think it's priced too high, I'd really appreciate it if you chat with whoever at your business would approve spending money on your Zulip installation, get their feedback, and send us an email. There may well be some categories of customers that we missed in those conversations, and specific examples are very helpful for considering whether there's a gap in our pricing model that we can patch.
It would be nice if there was a way to tell which users have mobile app installed and which users don't and charge us only for those users that will actually use the feature we are paying for.
+1 make it per user
This decision works against zulip long term, now we have to think before inviting/adding users to our server.
Third rug pulled from under us in a year: zerotier, rport and now zulip.
It seems pretty reasonable to say, “if you want to send a push notification from an app, you should be the controller of the app”.
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.
> The alternative would be that anyone could send notifications to an app
No, the alternative is that anyone with a password the app generates can send notifications to any app, which is (effectively) how WebPush and UnifiedPush work. The server that knows the secret URL can send a notification to that website or app.
Yes, there are a few technical reasons. They come down to battery, radio and mobile network overheads.
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.
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.
But for what it's worth, we're including support with Zulip Business, not consulting. Consulting is building custom features or whatnot that are just for a single customer.
Support is a guarantee that when you have a problem, you can ask for help and a human will investigate it and get back to you with what to do. It sounds like you've already received free support from us in the past.
Most of the issues that one helps a customer with in a support context are not unique to the customer -- but the support is still essential for the customer to actually have their problem solved, and investigating, debugging, and deduplicating reported issues responsively is effectively support work done by our (small!) team of people who need to make a living.
As noted in our email to customers, if you are seriously considering leaving Zulip because of this pricing, we'd like to hear from you. This pricing is intended to be very affordable as a cost for team chat for a business using it for their paid team, and the full price is intended primarily for that class of customer.
But without context on how you're using Zulip, I can't comment on whether your organization would be eligible for a discount or our community plan, but see https://zulip.com/plans/#self-hosted for several documented situations where an installation would not pay full price.
You can complain that $8/user/month is too expensive for hosting a service that probably does not require much in the way of infrastructure. Well, you can host your own, it's just a pain. And all of the code is open source, so if someone else thinks they can offer Zulip hosting for cheaper, they are free to do so.