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.
> 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.
Ah yes, this is why they fired the Servo team.
Mozilla has the unusual situation of having been fully taken over by a management layer that doesn't give a shit about the thing that caused that pile of money to flow their way. And the ongoing flow might even depend on Firefox remaining just underfunded enough to never compete against Chrome for real.
Nevermind the fact that Mozilla is sitting on a $1B fund that would be enough to do miracles in the browser space.
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.
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.
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.
I don't disagree with you in general terms, but what % of total commits or code change came from you and the three others leaving? A long lived long tail is great, but it still often dies out when you cut the head
If you’re not that familiar with the project then what’s it to you?
Personally, I think this is great and I’m going to send this to my boss who might have to make a similar decision someday. It seems to me like they could have just sold the product to them but went to lengths to keep it independent; that’s the type of thing we should encourage.
No offense intended but sometimes this type of comment sounds like the other side of the AI psychosis coin, like an anti AI psychosis.
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.
Thanks for your work on Zulip and for everything you did to increase its availability to the masses. Your work was important. Congratulations on your new position at Anthropic. I wish you well in this new chapter of your life.
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).
The `render` binary weighed 4.0 MB on disk when I compiled it a few minutes ago. Not sure if that's what you were looking for, but just in case it is, there you go.
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.
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.