tabbott

Do you think a law that nuclear meltdowns would send the CEO to jail would have stopped nuclear accidents from happening?

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".

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.

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.

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.