tabbott

Mozilla has had the unusual situation of having an enormous revenue stream from Google. It is reasonable in that situation to build some adjacent things that support the mission. MDN is amazing, for example! Rust was too! I do feel Mozilla has lost its way, and I think it would be crazy to spend resources available to the Zulip Foundation on projects that don't directly advance Zulip or its community.

I think the question presupposes that we solve the hardest problem for a new non-profit: Funding. We would be very lucky if Zulip with 1% of Mozilla's funding; we could do so so much with that scale of resources.

The biggest risk to Zulip's ability to succeed over the next few years is not risk of spending time on side projects. It's risk of not having the financial resources even to hire remarkable people who want to take a big pay cut to work on Zulip.

Like we always have. See https://zulip.readthedocs.io/en/latest/contributing/review-p... for the basics; but it's all written down in ReadTheDocs.

Like most large projects, we triage every new PR, and make decisions about which ones to invest what level of maintainer time into. We try pretty hard to efficiently review visibly high-quality PRs and those from highly engaged contributors who are visibly learning from the feedback we give.

Review latencies vary for myriad reasons. For example, when preparing to publish a major release like Zulip 12.0, there's about a month wherein we mostly only review PRs that might go into that release.

Historically, the great majority of PRs in zulip/zulip have been reviewed by two maintainers before being merged. First a "maintainer review", and then a second "integration review" by me. My reviewing everything is a quite unusual practice for a project of this scale, and I would not recommend anyone else try it. But it has worked for us, and everyone appreciated my having the complete context that comes with this practice.

All of our maintainers are very good at reviewing Zulip work. Thus, the great majority of those integration reviews involve my suggesting readability/documentation improvements, or merging the PR with just a comment thanking everyone who helped. So we're making the obvious adjustment wherein the other longtime maintainers also do integration reviews.

We've been writing a great deal of nice process documentation to support this plan (For example: https://github.com/zulip/zulip/pull/39290 details how I think about integration review, and https://github.com/zulip/zulip/pull/39229 greatly improves our database migration documentation).

I plan to hold regular office hours for more active project maintainers to use my time as they wish. It is likely that some of that time will be used doing reviews.

I hope this context helps!

There's new long-lived connection support in Zulip 12.0 that will enable the mobile app to do a lot better for startup in organizations with multiple 10ks of users.

I think it's expected to be enabled in the mobile apps in the next couple weeks.

As we do our best to explain in the post: The Zulip project is very much not being annihilated.

There are 220 people from all over the world who have contributed 20 or more commits to Zulip, and thousands more who've contributed code, volunteer translations, ideas, thoughtful questions, and in so many other ways.

Personally, I find remarks like this to be extremely disrespectful to all of those wonderful people and their open-source work.

Yeah I've often had the same thought! Ideas are very much appreciated.

I do like our current "organized team chat" quite a bit better than the original "group chat", which would often result in confusion with WhatsApp and its equivalents.

Historically, Zulip blog posts have actually gotten more engagement when they landed on the Hacker News homepage during off-peak times for regular news (After business hours and weekends) than when we've published them on weekdays mornings.

Fun fact: The original blog post announcing the Zulip Open Source project (https://news.ycombinator.com/item?id=10279961) was published on a Friday and I think got more attention because of that choice of date than it would have otherwise.

For those looking for more context on Zulip, we did a major release a couple weeks ago: https://blog.zulip.com/2026/04/27/zulip-12-0-released/.

I think the author misunderstands what is good about Python.

One of the big strengths of Python is legibility: most developers find it easy to read and understand.

If you are planning to have humans verify the code you're using in production, to confirm it implements your intent, the readability of the code you are producing is important.

Performance is valuable, but for a lot of code, performance is less important than correctness and ease of verifying it.

If you are imagining your codebase being one where nobody but Claude reads the code, you might as well do Rust for the better performance. But I don't think a lot of organizations are doing that.

It's interesting to me that the page doesn't describe the size of the rust binary (relevant for mobile app use cases where you would need to add the Rust binary to your app) or performance.

The webpage also does read like it was at least heavily LLM assisted, which makes it a bit hard to trust it.

That all said, this is definitely something I'd be interested in using for Zulip if is indeed going to be a well maintained open source project.

(We currently have a node server component that the Zulip server runs only the render LaTeX).

Funding to pay the core team (via revenue/grants/VC) requires a lot of leadership attention for any independent company that is developing an open-source project as its main activity. Yet more leadership attention goes into other administration (Taxes/hiring/legal/policies/etc.).

I don't have any direct context, though I have run an open-source business (Zulip) for the last decade wearing both the CEO and technical lead hats.

But my simulation is that the Bun leadership team might well be spending 2x as much of their time working on the technology than they reasonably could have as an independent venture-funded company, just because they don't have to do all that other stuff anymore. (There's of course probably a significant bias in that focus towards whatever Anthropic needs from Bun, only some of which other users may care about).

So I agree. Personally, I would not be concerned unless you see the tell-tale signs of the team being reassigned to other priorities at the buyer, which tends to be obvious, because, say, the GitHub project activity falls off a cliff.

We can and should advocate for preserving sideloading.

But boycotting a wonderful public-benefit program that Google has funded for 20 years over this sort of product policy issue seems crazy to me. Sure, GSoC does improve Google's brand.

But Google Summer of Code is one of the most effective charitable programs I've seen from any large corporation. And I think it's very telling that nobody else does anything like it.

Google is is the only company on the planet that cared about supporting the open-source community enough to invest, fund, and administer a program like this that has _no_ direct benefit to the company. (Many corporate grants/sponsorships to OSS projects are in exchange for something tangible).

The scale of GSoC is enormous, and the program has been very meaningful. A huge portion of our contributor community and about half the Kandra Labs team are people who I originally met via GSoC.

To me, it seems like the Pro tier is priced for using Sonnet a lot or Opus a little, and Max for using Opus a lot.

So that seems about what you should expect.

I find it interesting that folks are so focused on cost for AI models. Human time spent redirecting AI coding agents towards better strategies and reviewing work, remains dramatically more expensive than the token cost for AI coding, for anything other than hobby work (where you're not paying for the human labor). $200/month is an expensive hobby, but it's negligible as a business expense; SalesForce licenses cost far more.

The key question is how well it a given model does the work, which is a lot harder to measure. But I think token costs are still an order of magnitude below the point where a US-based developer using AI for coding should be asking questions about price; at current price points, the cost/benefit question is dominated by what makes the best use of your limited time as an engineer.

The original blog post for Mythos did lay out this safeguard testing strategy as part of their plan.

If your revenue doubles every month, then in the first month where you make $2.5B, your total lifetime revenue has been $5B ($2.5B this month, $1.25B the month before, etc. is a simple geometric series). But your current revenue run rate for the next year will be $2.5B x 12 = $30B.

They're not quite growing that fast, but there's nothing inherently inconsistent between these claims... as long as the growth curve is crazy.

Just about every UI component has been redesigned over the last two years. So your experience may be different these days :).

I lead the Zulip project and I'm not aware of any common crash issues with either our server or any of our apps.

Can you share details on what you're experiencing with us? https://zulip.com/help/contact-support.

I recommend that anyone who is responsible for maintaining the security of an open-source software project that they maintain ask Claude Code to do a security audit of it. I imagine that might not work that well for Firefox without a lot of care, because it's a huge project.

But for most other projects, it probably only costs $3 worth of tokens. So you should assume the bad guys have already done it to your project looking for things they can exploit, and it no longer feels responsible to not have done such an audit yourself.

Something that I found useful when doing such audits for Zulip's key codebases is the ask the model to carefully self-review each finding; that removed the majority of the false positives. Most of the rest we addressed via adding comments that would help developers (or a model) casually reading the code understand what the intended security model is for that code path... And indeed most of those did not show up on a second audit done afterwards.

What makes you want to believe the Trump Administration when it claims it doesn't want to do domestic mass surveillance?

An organization character really shows through when their values conflict with their self-interest.

It's inspiring to see that Anthropic is capable of taking a principled stand, despite having raised a fortune in venture capital.

I don't think a lot of companies would have made this choice. I wish them the very best of luck in weathering the consequences of their courage.

It's an interesting idea. The current endowment size of less than $1M is immaterial; the question with a project like this will always be how it is able to raise capital.

A way something like this could be interesting is if founders started donating 5% of equity when they started a company to an open source foundation like this one.

It doesn't impact the founder much financially: Success is very binary for founders. But in aggregate, if thousands of startup founders do this, there would be some hits and some of those hits could generate a significant endowment.

(You can also try to get people to donate who feel their success was built on top of open source, but I feel that after 10 years building a company to IPO, one's attention as a founder has likely been on business metrics and spending time with business people, not on technology and spending time with technologists, and that shift in attention can reduce people's feeling of gratitude for the amazing inheritance that is open-source software).

I feel like the articles on this have been very negative ... but aren't the Anthropic promises on safety following this change still considerably stronger than those made by the competing AI labs?

I encourage you to stop by and report things with screenshots/screencasts so we can get these fixed.

We were able to reproduce the search icon centering issue in mobile web, which is being fixed here:

https://chat.zulip.org/#narrow/channel/9-issues/topic/center...

This article looks rather rushed -- the description of Zulip is not accurate, and I suspect that folks working on the other products may feel the same way about how their projects are described.

I lead the Zulip project, and I'd like to clarify that Zulip's free community pricing does not have user limits, either in Cloud or self-hosting. The 10 user limit for free mobile notifications only applies to workplace/business use. Larger communities are encouraged to submit a simple form to get approved for notifications beyond 10 users.

And this complaint seems quite strange:

Even for self-hosted plans, anything above the free tier requires a zulip.com account for plan management.

How would a paid subscription work without an account for managing it?

This is an important and timely topic, but I wish a more deeply researched article was the one being widely circulated.

Zulip web is one of the best modern chat apps for intermittently offline use, and we put a lot of effort into making it that way.

For example, if you had it open on your laptop with a window open, suspend it, and open it up on a plane, you can read the last few weeks of message history, compose replies that will send when you regain network, etc. I do this regularly on flights.

We always have ideas for how to improve this further, and the mobile app doesn't do as extensive caching as the web app does, but it's not an issue of technical feasibility. The protocol was designed for mixed online/offline use from the beginning.

Bringing the recent conversations view for mobile is one of our main goals for next couple months!

Nothing is certain in this world, but I don't think that means one should give up and just use megacorp software.

And Zulip is specifically designed by some very capable people to be resilient. While we can mess up future versions, but you can always run (forks of) the older version. And as discussed on our values page, we've worked very hard to make the code readable and maintainable. (Various professors use Zulip as a teaching codebase).

We've made a lot of investments in the goal of having keeping-the-lights-on work for Zulip to be doable with a couple excellent people working part-time. It's good for our ability to spend our limited time on improving the product. But it also means that it doesn't require a lot of people to care in order for Zulip to remain functional and maintained. And I certainly care quite a bit.

So while I'd certainly expect other maintainers to introduce a lot more regressions, especially if doing significant changes... If you like the product today, probably the option will exist to continue using roughly that for a long time.

Are you using iOS? Safari 26 has several changes that break the mobile web app layout, and it's proven quite difficult to fix. I'd suggest using the actual mobile app on iOS if you've upgraded to Safari 26.

(My understanding is we are far from the only web app broken by Safari 26, and we're working on it).

For what it's worth, essentially every main view surface was visually redesigned over the course of the last 2 years. So while I can't promise you'll like the new design, it certainly isn't the same as it was 2 years ago.

One of the other nice features of the new design implementation is there are handy settings for font size and line spacing. It turns out that different people have very different desires for how dense content is in chat apps, and empirically there's a significant portion of users with just about every combination.

The nice general chat UI and per-channel permissions for it were new in Zulip 11.0 last year: https://blog.zulip.com/2025/08/13/zulip-11-0-released/. So probably you tested not long before this got built.