posted by Thom Holwerda on Mon 14th Sep 2009 06:04 UTC

So people clap your hands

So people clap your hands

Despite the demise of Be, the BeOS remained popular among its fans, of which I was one. I joined the Be community very late in the game, somewhere 2001 or 2002, but ever since, I'm hooked. Applications were still updated, new programs ported, but in the end, it became ever clearer that the BeOS as it existed in 2000/2001 was having ever more trouble running on modern hardware (not even a code leak of a more recent version could help). What was needed was something to bring the BeOS up to speed, to allow it to continue to be developed for modern hardware.

But how? BeOS is proprietary software, and as such, you can't really improve any of it in a way that is considered legal. To remedy this situation, the OpenBeOS project was started in 2001, which aimed to recreate the BeOS as open source software, using an MIT license. The initial expectations by ex-Be engineers weren't particularly high. In August of 2001, after talking about it with several ex-Be engineers, Eugenia presented the following conclusion:

I am sorry if I sound negative, but after discussing details about the Open BeOS project with several ex and Be engineers the last few days, they all came to (an easy for them) conclusion that this project is going nowhere. Exactly because there are shortcomings in the BeOS design, and because not all bugs or features of BeOS are known from outsiders, it will be impossible to replicate the technology without having the original BeOS source code. But what the team CAN do, is to aim for source compatibility, not binary. While the threading, bugs(!), locking and other details will behave differently between the BeOS and OpenBeOS, it is already times easier to port BeOS applications to OpenBeOS than trying to run them unmodified. This way, if the team become really dedicated, we may see some good progress in less than a year, otherwise it will take years to come even into an alpha state.

It turns out Eugenia was indeed right when it comes to the years and years it would take to reach an alpha state, but the conclusion that the project would go nowhere turned out to be somewhat off the mark. It has been a very difficult and rocky road, a long road, but here we are, about eight years after the project's creation, and I'm looking at my computer screen, where the first Haiku alpha is merrily chugging along.

Why has it taken so long? Well, obviously, it's not easy to rebuild a complete operating system, without having access to the source code, in such a way that it retains binary compatibility, while still updating several aspects of the system, and fixing loads of bugs. At the same time, it has to run on modern hardware as well as 'old' hardware, and you're all doing it for free.

On top of the practical reasons why it took so long, there's also a more philosophical reason. The Haiku team members and developers are very aware of the concept of public image, and are very careful about promoting the project as being stable or usable. With the release of an alpha, the team is making certain promises about quality and stability, and they want to ensure they can keep those promises. In addition, the geek world is filled with former BeOS fans, and a lot of them will use the alpha as their first acquaintance with Haiku, and the team wants to leave a positive impression. They don't have the luxury of pulling a KDE 4.0.

Table of contents
  1. It's tough to walk without strings
  2. So people clap your hands
  3. I do my dance in the round
  4. I wanna do it right this time
e p (45)    136 Comment(s)

Technology White Papers

See More