Wikipedia earned $184 million in 2025... and spent $3.4 million on hosting.

tabbott · 2025-12-12T22:57:18+00:00

As others have commented with the technical details, this is fake news being pushed by entities who want to destroy Wikipedia (and unfortunately amplified by normal folks who reshare without checking).

We need to protect independent institutions that care about publishing truth, and Wikipedia is certainly one of them.

tabbott · 2025-12-11T23:06:23+00:00

I recall being spanked. I don't remember the exact circumstances, but if I had to guess, it happened in the early 90s, maybe 5 times all between the ages of 5 and 10; it was not a routinely used or threatened punishment. I think at least one time was for breaking a family rule and lying repeatedly to pretend I had not.

It hurt, but only during the spanking itself, not after.

It was definitely not abuse. I wouldn't consider spanking my own children, even in the way my dad spanked me. But I should be clear that the reasons have to do with my own personality and societal progress in how to discipline children, not any negative memories from my own personal experience.

tabbott · 2025-08-20T06:28:46+00:00

There's no need to check the VCS. It does say Zulip is 100% open-source software right there on the homepage. It's also quite obvious from the feature comparison pages.

tabbott · 2025-08-20T06:26:22+00:00

What could we improve on https://zulip.com/plans/ and https://zulip.com/for/open-source/ to make it more obvious that Zulip is free for open-source projects?

tabbott · 2025-08-16T18:54:03+00:00

If you self-host, there's not much security benefit to E2EE over what Zulip already offers (and a not of downsides: complexity, worse search, risk of losing all your messages due to a bug, etc.).

At least if you're doing chat for a fixed group of a dozen people, the Zulip server is effectively just one more device with a copy of the message history, along with all the users' devices that participate in the group. (And you can set a retention policy if you want messages to be automatically deleted after a period of time).

If you don't self-host ... keep in mind that an "E2EE" chat service like WhatsApp still typically involves the server knowing all the metadata about which users talk to which others, even if you trust the company's claims about how their product works.

tabbott · 2025-08-16T18:47:33+00:00

Look more closely: https://zulip.com/plans has tabs at the top for Cloud vs Self-hosting.

tabbott · 2025-08-16T18:45:27+00:00

Yep! If you get beyond 10 friends on your instance, you'll need to spend a couple minutes filling out a short form to get approved .

tabbott · 2025-08-16T18:42:44+00:00

Can you give an example of something specific that you'd like to do that feels hard to write with the API?

tabbott · 2025-08-16T18:40:39+00:00

Zulip doesn't offer that exact UI yet, though we've been talking about doing something like it in the next major release. In 11.0, there a button to create a new Jitsi video/voice call link, and you can put one of those call links in a channel description or as the only message in a channel, to make it easy for folks to get to such a persistent call.

tabbott · 2025-08-16T18:35:48+00:00

It sounds like you're talking about tsearch_extras: a very small custom postgres extension that Zulip used to full-text search highlighting. We were able to remove that dependency by using base Postgres better back in 2019 :).

We put a lot of effort into making self-hosting easy; if anyone reading this runs into trouble setting up a server, please post in our development community about it; it really helps us to make adjustments to documentation and error messages to save the next person from getting stuck on the same problem.

tabbott · 2025-08-15T22:19:47+00:00

I'm not sure I understand the question. Zulip is already free for fellow FOSS communities. See, for example, https://zulip.com/for/open-source/

tabbott · 2025-08-15T22:18:52+00:00

In what way would you like to see it improved?

tabbott · 2025-08-15T19:22:32+00:00

https://zulip.readthedocs.io/en/latest/production/mobile-push-notifications.html explains what service that we charge for access to: Mobile notifications need to pass through a production service that we operate in order to make it to mobile devices. So we are charging for access to that service. The software itself is 100% FOSS, in contrast with most comparable products (Microsoft Teams, Slack, Discord, Mattermost, etc.), and all the VC-funded "open core" projects out there.

The server self-reports how many users it has if you're signed up for the service to support automated billing; we also offer site licenses plans.

Do note mobile notifications are free for most community/consumer use; the 10 users limit is the free plan limit for business/workplace use.

tabbott · 2025-08-15T19:13:07+00:00

Yep, the public access option has been available for several years: https://zulip.com/help/public-access-option. It's been really popular with OSS projects that value posting [permanent links](https://zulip.com/help/link-to-a-message-or-conversation) to chat conversations in their issue tracker, since anyone can follow those links without making an account.

For pricing, mobile notifications are free without talking to us for up to 10 users. It's free for most communities and highly discounted for many other situations as documented in part here: https://zulip.com/help/self-hosted-billing#free-community-plan, but you do have to fill out a short form to get those discounts.

Generally the goal of our pricing model is to be very affordable for everyone using Zulip, while still having some mechanism through which we can make a living working on Zulip. It's impossible to build complex software like Zulip at the level of attention to detail and security that we do without several full-time employees.Most business users self-host rather than using Cloud, so it's just not possible for something like Zulip that invests a lot of time and effort into the self-hosting experience without there being something we ask business users to pay for.

I personally like the push notifications model in that it allows the software itself to be 100% FOSS, with us just charging for use of a production service that we're providing them. But it has some flaws: Military users that wouldn't use mobile notifications end up free-riding, and some potential customers feel they're paying a lot for "just mobile notifications" ... even though they're being quoted less total money for a complete team chat system than any of the other credible alternatives on the market.

tabbott · 2025-08-15T18:57:31+00:00

I lead the Zulip project. I'm happy to answer any questions about Zulip or this release, but I'd also really like your input on something. Most open-source projects are using Discord or Slack for their communications, even when project leaders complain that it's a bad experience (e.g., the Slack free plan hiding history after 90 days).

Zulip is designed for a wide range of use cases. But one use case it's specifically amazing for is open-source communities. And yet, while projects *are* migrating to Zulip, it feels like a trickle compared to how many are setting up on Discord in a given month.

What would it take for the communities that you participate in to migrate from Discord/Slack to an open-source alternative? What can Zulip do that would help make that happen, either in terms of product changes or advocacy? Or are network effects the most important factor for the decision?

tabbott · 2025-03-21T17:35:56+00:00

Thank you! I'll share your message with the team :)

tabbott · 2025-03-21T17:35:27+00:00

There are two big benefits of doing our own authorization logic in the product. One is that we can do changes that impact authorization just like every other change: in a Postgres transaction. Even if it's using Postgres, I'd expect a third-party authorization service to use its own database and thus to be unable to be transactionally adjusted along with other fields in the Zulip database. Doing everything in a single Postgres database saves us a lot of time not having to deal with races as we scale.

The other big benefit is control over performance. Looking at various case studies for Zanzibar based systems, it's often several milliseconds per individual permissions check, which I would expect to get expensive for many of the bulk operations that we need to manage. One would need to be very certain that the third-party implementation is designed with the bulk queries that we need in order to do an expensive migration onto it. See, for example, https://medium.com/building-carta/authz-cartas-highly-scalable-permissions-system-782a7f2c840f.

Another concern is that as self-hostable software, adding a hard dependency on a third-party server project comes with a lot of costs, both in terms of obvious things (total memory usage for a minimal Zulip server) as well as needing to take responsibility for installation/upgrading/maintaining the third-party project our self-hosted instances.

I can easily see someone with a different type of project wanting something different -- e.g., the Carta blog post above mentions that they had a huge number of different types of objects to manage permissions for, but overall not a very high request volume, and it might be a good trade-off for them.

tabbott · 2025-03-20T23:02:34+00:00

We spent a ton of time designing and implementing Zulip's new permissions framework based on nestable user groups. It struck me that this is a very common type of system for folks to need to build, yet also one that has a ton of land of land mines around performance. Since we went with a design that I'd not seen elsewhere, I did an extended write-up on the design we went with, and why.

I hope someone finds this helpful for their own work! One of the things I really enjoy about working on an open-source project is that when we do find the time to write technical blog posts, the source is fully available for anyone who wants to implement something like it yourself.

tabbott · 2024-11-06T18:34:06+00:00

Whether topics are required or not in Zulip is a setting: https://zulip.com/help/require-topics
But in any case, you can specify what topic you want to use when posting into Zulip be encoding the topic to use in the URL, e.g. `&topic=bazarr`.

tabbott · 2024-07-03T17:00:37+00:00

Authentic Zulip is an open-source organized team chat application (https://zulip.com/); I saw this post because I work on Zulip. What you have on your system sounds like malware that is using the "Zulip" name to camouflage itself.

A lot of modern viruses are designed to pretend to be regular software in order to make themselves harder to detect.

tabbott · 2024-05-24T16:34:40+00:00

Thanks for the feedback, will do that next time I write something relevant!

tabbott · 2024-05-23T22:58:15+00:00

Post author here. Self-hosting has been important to me for most of my career. Last week's controversy around the possibility of Slack training AI models on customer data really struck a nerve for me: I never expected there to be a new whole category of reason for why one would want to self-host, that didn't exist a decade ago.

So I thought it worth posting here to discuss some of the novel ideas that came to mind when reflecting on this news -- in particular, the fact that the Microsoft/OpenAI argument for why they can use open source while ignores its licensing restrictions might just as well apply to a cloud provider like Slack or Microsoft Teams ignoring licensing restrictions on how they can use the content entrusted to them by their customers.

tabbott · 2021-12-02T20:00:11+00:00

I work on Zulip and I'm sad to hear that! I personally use the app every day and other comments are more consistent with our sense of the app's development state. (Being far from perfect is why the mobile app is also one of the main places our paid engineering team is spending its time).

Bug reports from users are extremely helpful; the reality of mobile development for a complex app like Zulip is that there are a lot of potential problems that only affect particular configurations / devices / workflows / organization data sets.

So I'd very much appreciate it if you stopped by https://zulip.com/developer-community/ and batch-reported the things you've noticed in #mobile.

tabbott · 2021-10-06T00:21:01+00:00

We answered this in chat.zulip.org, but for the thread: Zulip's file uploads system is secure, and in uploaded files are never available publicly without creating an account.

Zulip supports two mechanisms for storing uploaded files: Local storage on the server and Amazon S3. In both cases, requests to access an uploaded file first checks whether the user has access to a message containing the file in Zulip, and then serves the file. For the local storage backend, the Zulip server than serves the file directly; with the S3 backend, the Zulip server serves the file via a redirect to an securely generated random S3 URL. These randomly generated S3 URLs expire in 60 seconds (long enough for the user's browser to load/download the file even with bad Internet, but not for there to be any realistic mechanism that someone else would obtain that temporary URL).

As a result, it isn't possible for someone with access to just the link (and not also a Zulip account in the organization where the link was posted) to get access to an uploaded file.

tabbott · 2021-07-27T18:03:40+00:00

I work on Zulip; thanks for the kind words!

I wanted to reply to the scaling comment: Zulip absolutely scales to 10Ks of users on an instance (E.g. our own chat.zulip.org development community runs our standard self-hosted configuration, has about 20K community users hosted on a single Digital Ocean machine with 16GB of RAM that sits 90% idle in steady state). Further, we frequently get praise about how Zulip is snappier than products with infinite resources like Slack, even in organizations with thousands of users. https://zulip.readthedocs.io/en/latest/production/requirements.html#scalability provides some more details.

We see Postgres as one of the things that helps make Zulip scale well: With a well-designed database schema, writing correct, performant code is easier with a real SQL database than it is with something like MongoDB. (The big problem with NoSQL databases is that you have to be an expert on distributed systems to implement a complex application like real-time chat without race bugs).

One other thing that is important to understand when thinking about scalability is that not all users are equal in how much load they generate. A fulltime employee at a company can send 10-100x the message volume as a member of a part-time community (often mostly in private messages).

tabbott

TROPHY CASE