Skip to content
Haiku OSNews Published Updated 3 min readViews unavailable

Haiku R1/Alpha 1 Ships as the Project's First Public Release

Haiku R1 Alpha 1 arrived on September 14, 2009 as the project's first official public release, distributed as an installable live CD.

Haiku R1/Alpha 1 was released on September 14, 2009 — the project’s first version made available to the general public as a working, downloadable, bootable image, roughly eight years after the OpenBeOS project began in the wake of Be Inc.’s acquisition by Palm.

A live CD — a genuine improvement over the original

Alpha 1 could be booted and run directly from a CD without installation, letting anyone try the system without committing disk space or going through an install process first — notably, this was something the original BeOS itself never offered, making Alpha 1 in this one specific respect a practical improvement over the platform it was continuing rather than merely a replica of it.

Still explicitly an alpha

The “alpha” label was accurate, not just cautious naming — Haiku at this stage had known gaps and rough edges, and the release was explicitly framed as a demonstrably working, usable system rather than a finished, general-purpose replacement for a daily-driver OS. That framing mattered for setting expectations correctly: Alpha 1’s significance was proving the project had produced something real and usable after years of below-the-radar development, not that it had reached feature parity with BeOS or any contemporary mainstream OS.

What followed

Three more alpha releases shipped over the next several years — Alpha 2 in May 2010, Alpha 3 in June 2011, and Alpha 4 in November 2012 — each incrementally improving hardware support and stability, ahead of the considerably longer stretch of work that eventually led to Haiku’s first beta release in 2018.

Why a public alpha mattered for a volunteer-driven project

Shipping something the public could actually run, rather than continuing purely internal development indefinitely, gave the Haiku project a much wider pool of people who could test the system on real, varied hardware and report back — feedback a small, mostly-volunteer contributor base couldn’t generate on its own no matter how much internal testing it did. Alpha 1’s release is, in that sense, as much a milestone in how the project sustained itself long-term as it is a technical one.

What “first release” meant

The September 2009 announcement described the first official development release, distributed as CD and virtual-machine images. It remained alpha software, not a production guarantee. A live image gave users a named baseline for installation and bug reports instead of an arbitrary nightly revision.

Haiku code had booted and circulated before Alpha 1. “First public release” therefore means first formally versioned project release, not the first day an outsider could run it. Release engineering—freezing a branch, testing media, documenting limitations, and operating mirrors—was itself part of the achievement.

The baseline it created

Later alphas could describe regressions and progress against a stable artifact. Reports became reproducible when they included architecture, image hash, hardware, and release version. That feedback loop mattered more than portraying Alpha 1 as complete.

Primary sources: official Alpha 1 announcement, Haiku project history.

Alpha 1 should be tested in period context. Current documentation, repositories, and hardware support may no longer match the 2009 image. A historical reproduction should isolate networking, verify image hashes, record VM hardware, and avoid updating the installation before capturing its original package and application state.

Known-issues lists are part of the artifact, not an embarrassment to omit. They define what the project had already reproduced, help distinguish a historical limitation from damaged media, and prevent present-day expectations from being projected backward.

Related:

Sources:

Comments