3,222 karma · joined February 9, 2010
I don't think this takes seriously enough the possibility that said CEO doesn't think the failure mode is likely and ignores it. Plenty of people are willing to take risks of the flavor "heads you win, tails everyone loses".
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 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!
I think it's expected to be enabled in the mobile apps in the next couple weeks.
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.
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.
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.
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.
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).
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.
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.
So that seems about what you should expect.
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.
They're not quite growing that fast, but there's nothing inherently inconsistent between these claims... as long as the growth curve is crazy.
Can you share details on what you're experiencing with us? https://zulip.com/help/contact-support.
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.
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.
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).
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...
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.
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.
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.
(My understanding is we are far from the only web app broken by Safari 26, and we're working on it).
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.