Haiku Shipped Its First Beta in Two Years and the Thread Turned Into a Fight About AI

Haiku shipped R1/beta6 on 26 August, two years after the last beta and one week after the project's 25th birthday. The release notes credit over 530 resolved tickets and exactly one new developer gaining commit access.

We went looking at the release because the numbers in it are unusually candid. Then the Hacker News thread turned into an argument about something else entirely, and the two things turn out to be the same story.

What actually shipped

Beta6 is x86 only, 32 and 64 bit. The stated minimum is a Pentium II with 256MB of RAM, which tells you something about who this project is still building for.

The performance work is the substantive part. Per the release notes, MIME sniffing is 5 to 10 times faster, packagefs bookkeeping dropped around 20 percent, and a full HaikuWebKit rebuild went from 4h53m to 2h33m.

The git numbers are the ones that will matter to anyone actually developing on the platform:

Firefox is now officially available for x86_64 for the first time, along with LibreWolf, Waterfox, Floorp and Icedove. Go 1.26.1 has a working port. For a hobbyist OS, having a current mainstream browser is the difference between a curiosity and something you could plausibly use.

We did not run it, and here is why that matters

We have not installed beta6. Every number above comes from the project's own release notes, and we are flagging that rather than dressing it up, because the most useful report in the thread is a first-hand one and it is not ours.

HN user SyneRyder reported regressions serious enough to leave a ThinkPad X1 unbootable without safe mode, tracing kernel hangs to ACPI issues, and separately found that USB audio improvements broke Focusrite Scarlett compatibility badly enough to warrant reverting a driver.

The thread was not about the release

Beta6 hit 280 points and 85 comments within about 13 hours. Almost none of the discussion was about MIME sniffing.

In July, Haiku maintainers added an AGENTS.md to the repository root forbidding AI and LLM contributions outright, covering code, documentation and translations. The stated reason is licensing: the project cannot accept contributions under ambiguous or incompatible licences, and it treats most LLM output as falling into that category.

The thread relitigated that decision, and it got sharp.

KerrAvon argued the project should reconsider, suggesting that strong code quality gates could let AI assistance raise the output of what was directly called a very low-velocity project. 0x1d7 pointed at an ARM64 port as evidence that contributors are already routing around the policy in practice.

The pushback was more interesting than the proposal. cardanome asked why volunteer maintainers should review AI slop for free, warning that accepting low-effort submissions burns out exactly the people who stay for mentorship and relationships rather than throughput.

Then the argument moved somewhere unexpected. ethin questioned the premise entirely: why does it matter if your velocity is not as fast as everyone else's? dleslie answered that velocity is important because we all eventually die, describing decades of watching Haiku from the sidelines while friends passed away.

A thread about an operating system release became a thread about whether shipping slowly is a defect or a choice.

The release notes are an argument in the debate

Here is the connection nobody in the thread made explicitly. The release itself is the strongest available evidence for both sides.

Two years between betas and one new committer is exactly the velocity problem the pro-AI commenters are describing. You do not need to speculate about whether Haiku is resource-constrained. The project published the number.

But the same release also shows what that constraint produces: a 2.5 second git status where there used to be 15, from people who understood the filesystem well enough to find it. That is not the kind of work that emerges from lowering the contribution bar. It is the kind that emerges from a small number of people who have held the whole system in their heads for years.

Haiku is not choosing between fast and slow. It is choosing between a small number of contributors who can review each other's kernel changes, and a larger number who cannot.

This is not just a Haiku problem

Haiku is not an outlier. GCC, NetBSD, QEMU and OpenJDK have all landed restrictive AI contribution policies in 2026, and there is now a public repository cataloguing them. The licensing rationale is consistent across projects: provenance is unclear, so the contribution is unacceptable regardless of quality.

That framing is doing a lot of work, and it is worth being precise about it. A licensing objection is not the same as a quality objection, though the two get argued interchangeably. SyneRyder made this point in the thread: the policy is about copyright and provenance, not ideology.

The distinction matters because the two have different expiry dates. If the objection is provenance, it dissolves the moment tooling can attest to how code was produced. If the objection is really about review burden on volunteers, better attestation changes nothing at all.

Our read is that most projects have not yet worked out which objection they actually hold, and the ones writing policies now are going to have to. Haiku's AGENTS.md says licensing. The loudest defence of it in the thread said burnout. Those lead to different policies in two years.

Who should care

If you maintain an open source project, the Haiku thread is worth reading in full before you write your own AI policy, specifically for the gap between the stated reason and the defended reason.

If you were thinking of trying beta6, wait for the regression reports to settle, or at least do not put it on your only ThinkPad.

And if you have been dismissing Haiku as a museum piece, the git numbers are worth a look. Whatever else is true about the project's velocity, someone there is doing serious filesystem work.