Skip to content
Haiku OSHistory Published Updated 5 min readViews unavailable

The History of Haiku: BeOS's Second Life as an Open-Source OS

How BeOS's commercial rise and fall inspired a community to rebuild its technologies and user experience as the open-source Haiku project.

Haiku exists because a group of BeOS users and developers, in 2001, refused to accept that a well-loved operating system’s commercial death meant the system itself had to disappear. What they built afterward is, technically, a completely new implementation — but one deliberately aimed at continuing exactly what the original was trying to be.

Be Inc. and BeOS, 1990–2001

Be Inc. was founded in 1990 by Jean-Louis Gassée — a former Apple executive — together with Steve Sakoman, based in Menlo Park, California. The company’s goal was an entirely new operating system, written in C++, unconstrained by backward compatibility with any existing platform. Be initially built its own hardware to run it: the BeBox, released in October 1995, a distinctive dual-PowerPC machine with a front panel of activity-indicator lights and an unusual analog/digital expansion port. When the BeBox failed commercially, Be exited hardware entirely and ported BeOS to the PowerPC Macintosh and, later, to x86 PCs — chasing a viable path to market for the OS itself, independent of any one hardware platform.

The end of Be Inc.

That path never fully materialized. After a final pivot toward internet appliances (BeIA), Be Inc.’s assets were acquired by Palm, Inc. in 2001, and BeOS development ended.

OpenBeOS begins — literally the next day

Michael Phipps started the OpenBeOS project the day after the Palm acquisition was announced, aiming to build an open-source, backward-compatible continuation of BeOS from scratch — not by open-sourcing Be’s original codebase (which Palm now owned), but by reimplementing the system independently. The new project got a significant technical head start in 2002, when it forked NewOS — a modular kernel already written independently by Travis Geiselbrecht, a former Be Inc. engineer — giving OpenBeOS a working kernel foundation rather than requiring one to be built from zero.

The rename to Haiku, 2004

By 2004, Palm’s trademark ownership of the “BeOS” name made continuing to use “OpenBeOS” as a long-term project identity legally awkward. At the project’s first North American developer conference, WalterCon, held that year, the project announced it had been renamed Haiku — chosen by community vote, and a deliberate reference to the short, distinctively-worded error messages BeOS itself was known for displaying, in the style of Japanese haiku poetry.

From rename to a usable release

Development continued for years afterward before the project had something the public could actually run: Haiku R1/Alpha 1 shipped on September 14, 2009 — the first version available as a bootable live CD, a meaningful practical improvement over original BeOS’s installation requirements. Three further alpha releases followed through 2012, setting up the much longer stretch of work — including packagefs and modern package management, which went live in 2013 — that eventually led to Haiku’s first beta release in 2018.

Why “continuation,” not “clone,” is the right word

Haiku isn’t running any of Be Inc.’s original code — the kernel, the Kit-based API, and BFS are independent (re-)implementations, built by a different group of people over a different span of years. What makes “continuation” the accurate description rather than “clone” is intent and design philosophy: Haiku was built specifically to preserve BeOS’s particular architectural bets — a pervasively multithreaded kernel, a database-like file system, an object-oriented native API — rather than to imitate its surface appearance while making unrelated internal choices. A community that lost access to software it valued, in 2001, chose to rebuild the thing itself rather than settle for something merely similar — and the project, now in its third decade, is still doing exactly that.

Compatibility shaped the successor

OpenBeOS did not begin as a generic Unix desktop. Teams independently reimplemented BeOS kits and targeted source and, where feasible, binary compatibility with R5. That decision explains Haiku’s message-driven application model, BFS attributes and queries, Tracker and Deskbar, and the names of its native APIs. Clean-room work also meant the community could not simply publish Be’s proprietary source.

The project adopted the Haiku name in 2004. Alpha 1 in 2009 created a formally versioned public baseline; later alphas and betas integrated package management, toolchain, driver, kernel, application, and compatibility work. The long timeline reflects the scope of maintaining a complete operating system rather than adding a desktop to an existing distribution.

Governance outlived Be Inc.

Haiku, Inc., incorporated in 2003, provides a legal and financial home for donations, contracts, infrastructure, and trademarks while technical development remains community-run. Summer of Code participation, conferences, donated hardware, and paid contracts supplement volunteer work. This continuity let an abandoned commercial platform’s ideas remain independently maintained without claiming that Haiku is proprietary BeOS.

Primary project sources: Haiku history, Haiku, Inc., official release archive.

How to date Haiku accurately

Different milestones answer different questions: BeOS’s final commercial era, OpenBeOS’s 2001 start, Haiku, Inc.’s incorporation, the 2004 renaming, Alpha 1, and each beta. A history should not collapse them into one “Haiku launch.” Preserve announcement dates, release images, source revisions, and institutional records separately. That chronology shows an incremental reimplementation and release process rather than a single fork of proprietary code.

BeOS compatibility and independent evolution also coexist. Haiku can retain an R1 compatibility objective while replacing infrastructure, adding hardware support, and developing APIs beyond the original platform. Historical claims should identify which layer changed and which compatibility promise remained.

That distinction is essential when comparing releases.

It also prevents false continuity claims.

Related:

Sources:

Comments