# Haiku OS: an open source desktop operating system built on BeOS ideas

> A C++ operating system from Haiku, Inc. targeting personal computing, with a Jam-based build, an app porting effort, and contribution routes for people who do not write code.

**haiku/haiku** — The Haiku operating system. (Pull requests will be ignored; patches may be sent to https://review.haiku-os.org).

- Repository: https://github.com/haiku/haiku
- Stars: 2,347 · Forks: 439
- Language: C++
- License: NOASSERTION
- Published: 2026-10-06 · Updated: 2026-10-06 · Language: en
- Canonical page: https://hysenlabs.com/projects/haiku-haiku

## What the project says it is, and what BeOS inheritance means

The README opens with a row of links rather than a picture: a homepage, mailing lists, IRC channels, an issue tracker on dev.haiku-os.org, and API docs on api.haiku-os.org. That layout is itself informative, because an operating system that expects users to arrive through forums and chat channels is not selling itself as a download-and-forget product.

The description line is blunt about process as well as purpose: pull requests will be ignored, and patches may be sent to review.haiku-os.org instead. The repository's own branch is named master, and the default branch setting matches that. This is an unusual arrangement for a project hosted on GitHub and it says something about where review authority sits. It also explains why the open issues count is zero: the tracker people are meant to use lives elsewhere.

The one-line description calls Haiku an open source operating system that specifically targets personal computing, inspired by the BeOS, and the README expands that into being fast, simple to use and easy to learn while still powerful. The BeOS inheritance is the interesting part of the claim, because it is not a skin. BeOS was built around a message-based kernel interface with a strong notion of a coherent, responsive desktop, and Haiku's stated goals of a unified desktop environment and minimal configuration are a direct restatement of that design instinct rather than a generic aspiration.

## Three goals that say more about audience than features do

The Goals section is short, three bullets, and worth reading closely because it is the clearest statement of who the project is for. The first goal is sensible defaults with minimal configuration required. The second is clean, clear, concise code. The third is a unified desktop environment.

Read together, those three are a specification for a consumer operating system rather than for an infrastructure one. Minimal configuration means the person at the keyboard is expected to be one person, not a fleet administrator with a configuration management system. A unified desktop means the same look and behaviour across applications, which only matters if a human is looking at all of them at once. Clean code as a stated goal tells you something about the intended contributor: someone reading the tree to understand it.

None of the three goals is measurable, and the README offers no metric, no conformance suite and no compatibility matrix to check them against. That absence is honest rather than evasive for a project of this size, but it does mean a prospective adopter cannot verify the claims from the repository. The only place the goals get tested in practice is by installing an image and using it.

## Nightly and release images, with a virtual machine as the sane first step

For trying the system, the README offers two download paths: pre-built nightly images hosted at download.haiku-os.org, and release images linked from the get-haiku page on the main site. Nightly builds are the interesting choice for an operating system under development, because they give you a moving target rather than the occasional polished release.

The README then handles the obvious objection from anyone who has read an operating system README before. It notes that Haiku is compatible with a large variety of hardware, but if you would rather not take the plunge and install on bare metal, you can install it in a virtual machine instead. For readers who have never used a virtual machine, there is a guide called Emulating Haiku on the same site.

That ordering is deliberate and worth copying if you are evaluating the system yourself. A virtual machine costs nothing but disk space, snapshots cleanly, and cannot brick the machine you are reading this on. The hardware compatibility claim is asserted rather than itemised in the README, so the list of what actually boots is not something you can check before trying.

## A Jam build in a source tree split into src, headers, data and 3rdparty

The repository tree is the part that tells you what building Haiku involves. Alongside the documentation files `ReadMe.md` and `ReadMe.Compiling.md` there are `configure`, `Jamfile`, `Jamrules`, a `build/` directory, and the four source roots: `src/`, `headers/`, `data/` and `3rdparty/`. There is also a `License.md` and an `AGENTS.md` at the top level.

The Jam build is the notable choice. Jam is a make-like tool configured by Boost.Build, and adopting it puts Haiku outside the CMake or Meson convention that most new contributors arrive expecting. It has the advantage of being the same toolchain used historically for this class of system, and the disadvantage that almost nothing on the internet documents it in the context you would want. The README does not try to teach it. It says to see `ReadMe.Compiling` and stops, which is an honest boundary rather than a tutorial.

The `3rdparty/` directory being a top-level root tells you how much of the tree is vendored code rather than Haiku's own. That is normal for an operating system and it also means the interesting reading is concentrated in `src/` and `headers/`. The separate `data/` root holds the files that describe an installation rather than compile into one, which is the part you would look at when you want to know what a Haiku installation actually ships.

## Patches go to review.haiku-os.org, not to pull requests

The contribution section makes the project's operating model unusually clear. Haiku describes itself as a meritocratic open source project with a large variety of tasks, and states plainly that if you cannot write code you can still help, listing designers, technical writers, translators and testers as wanted roles.

Code contributions have their own path. If you submit a patch, you are asked to follow the patch submitting guidelines on the wiki. If you cannot find something in the source tree, the README points at two web-based source browsers: an OpenGrok instance at grok.nikisoft.one provided by Niklas Poslovski, and Haiku's own git server at git.haiku-os.org.

That second browser is the more interesting of the two. A self-hosted git service and a code search instance hosted by a third party are two different bets about where code review and code reading should happen, and running both says that neither is assumed sufficient. Documentation has its own route, and the README is unusually specific about it: the main piece of documentation that still needs work is the API docs in the tree at `docs/user`, and the suggested method is to find an undocumented class, write the documentation, and submit a patch.

## Translations, app ports and infrastructure live in sibling repositories

Four further contribution categories each point away from the source repository. Translations are handled through the i18n wiki page. Software ports are collected in the HaikuPorts repository, which is where the effort to make more applications build or run on Haiku is tracked. Infrastructure work happens in a separate infrastructure repository owned by the same account. The native 64-bit porting effort and other such programmes are therefore coordinated outside the kernel tree rather than inside it.

This split is a reasonable answer to a real problem. HaikuPorts grows on contributions from people who want one application to work, and folding that work into the kernel repository would bury it. The cost is that the source tree alone does not tell you how much of the software world is usable on the system, which is exactly the question someone evaluating a desktop operating system needs answered.

Where does that leave someone deciding whether to try it? The repository gives you goals, a source layout, a build entry point and a contribution process. It does not give you a driver model, a filesystem list, a package format or a hardware support matrix. Those answers live on haiku-os.org, and the README's own structure, which is a paragraph on trying the system followed by a pointer to a separate compiling document, is a fair signal about how much detail to expect from the tree itself.

## Conclusion

Haiku makes most sense as a reference system and a hobbyist desktop rather than as infrastructure anybody deploys. Its three stated goals, sensible defaults, readable code and one unified desktop, describe a personal computing product rather than a server platform, and the repository reflects that: a `src/` tree, a Jam build and an app porting community, with the operational tooling you would want for a production host living on haiku-os.org rather than in the source. Start with a nightly image in a virtual machine instead of installing to bare metal, read `ReadMe.Compiling.md` before attempting a build, and judge the API documentation in `docs/user` first, because the README names it as the piece that still needs work and that is where a contributor's time goes furthest.

## FAQ

### What is Haiku OS and who maintains it?

Haiku is an open source operating system written in C++ that targets personal computing, inspired by the BeOS. The repository is maintained under the haiku account, which also hosts a separate infrastructure repository, and the README points to Haiku, Inc. as the provider of its own git server at git.haiku-os.org.

### How do I try Haiku without installing it on bare metal?

Download a nightly image from download.haiku-os.org or a release image from the get-haiku page, then run it in a virtual machine. The README recommends this route for anyone who does not want to install on real hardware, and links an Emulating Haiku guide for readers who have never used a virtual machine before.

### How is the Haiku source code built?

With Jam, configured by the `Jamfile` and `Jamrules` at the repository root, alongside a `configure` script and a `build/` directory. The README does not include build instructions itself and instead directs you to `ReadMe.Compiling`, which is a separate document in the tree.

### Why were my pull requests ignored on this repository?

Because the project's own description says pull requests will be ignored, and patches are meant to be sent to review.haiku-os.org instead. The README asks contributors to follow the patch submitting guidelines on the wiki, and the issue tracker people are meant to use is at dev.haiku-os.org rather than on GitHub.

## Sources

- [haiku/haiku on GitHub](https://github.com/haiku/haiku)
- [Issues](https://github.com/haiku/haiku/issues)
- [README](https://github.com/haiku/haiku/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/haiku-haiku