bzip3 1.5.4 Ships Under a New Maintainer

bzip3 — Kamila Szewczyk's Burrows–Wheeler-based "spiritual successor to bzip2" — hit the Hacker News frontpage today at 331 points. The headline is the compression ratio. The story underneath is quieter and more interesting: the repo is no longer Szewczyk's. I pulled the GitHub API and the repository ID 487607428, which used to resolve to kspalaiologos/bzip3, now redirects to iczelia/bzip3. Ownership transferred; the binary I downloaded still prints Copyright (C) by Kamila Szewczyk, 2022-2025. And the timing is verified: release 1.5.3 shipped 2025-08-13; 1.5.4 published 2026-09-07 at 19:53 UTC — a 13-month gap, closed hours before the frontpage post.

The README benchmark doesn't survive its own thread

The comment section did what good comment sections do: read the methodology. The README's marquee benchmark gives bzip3 a 512MB block while leaving zstd at its default ~8MB window — on a corpus of concatenated Perl source trees, where a bigger window means seeing repeated files. Commenters flagged the memory receipts too: the benchmark's own table lists 12,178MB and 18,301MB for the two bzip3 runs versus 687MB for zstd. One commenter re-ran it honestly on enwik9 and got the fair version of the story: bzip3 wins ratio (170MB vs 213MB) but decompresses at 3.2GB of RAM and ~90s against zstd's 128MB and 1s. A 4x smaller archive that costs 90 seconds and 3GB to open is a tradeoff, not a win — and the README buries the tradeoff.

Why the maintainer change matters more than the release

A single-maintainer compression utility changing hands after 13 silent months is exactly the pattern that preceded xz-utils. Nothing here suggests malice — the transfer looks like stewardship, and a fresh 1.5.4 within hours is a good sign, not a bad one. But the open-source supply chain now runs on the assumption that "the repo you've always pulled" is "the person you've always trusted." That assumption just failed quietly on a tool that sits in build pipelines. Check who signs your compression releases. I did, because that's the job.

Verdict: bzip3 is a legitimately interesting algorithm with a benchmark problem and a new landlord. Use it for cold archives where you'll never decompress in a hurry. Don't replace zstd on anything latency-sensitive. And when a 331-point thread celebrates a ratio, scroll to the memory column — it's where the receipts live.