Yeah. This is exactly my worry: as soon as solutions to technical problems like this start going in the direction of "we'll offer a monolithic solution and charge users for access to it" instead of "we'll make it as generic as possible even if the alternatives for now are flawed", it makes me wonder about the long term trajectory of the project.

I don't mean to cast aspersions on the developers—I respect everybody's right to try to get paid for good work, and this looks like good work. I am just not convinced it's the right option for my specific needs.

It's not a technical problem, it's a policy problem from the mobile vendors. You'd basically be paying them to deal with Apple's and Google's messaging infrastructure through their (zulip's) infrastructure.

I think it's right to worry about this. However, the Zulip project has a long (10 year?) history and track record with a stable team.

Can someone explain to me why we should do engineering work to build features where the stated objective is to help corporations use our product without paying for it?

Remember, self-hosted mobile push notifications already have a free community plan!

I can't say whether Zulip might be a fit for your needs. But you can always email our lovely sales/support team. https://zulip.com/help/self-hosted-billing#paid-plan-discoun... should give you a sense of our policies.

> Can someone explain to me why we should do engineering work to build features where the stated objective is to help corporations use our product without paying for it?

I'm not sure what you mean by this. I am looking for a replacement for Discord for my small community of friends, and before today I had never heard of Zulip and knew nothing about its pricing or policies or history.

> our product

It's either your product first or an open source project first. If you care more about having a marketable product then it's fair for people who care about open source to go elsewhere.

What would "as generic as possible" look like in practice?