OSNews

To Anonymous:

You state:
I remember when OpenBeOS said they'd be able to do it in a year.

That was to say that the system could be made in a year, but it would not be made right. That was also when there were over 50 developers willing to jump into the code.

Haiku (formerly OpenBeOS) CVS now hosts in excess of 3.2 million lines of code. Having the full CVS on my system, which I sync weekly (more or less), I have been able to watch the eveolution on an up-close and personal scale.

The team figured that because they were merely focusing on copying R5 that they would save a great deal of time in planning. And because they were starting with the NewOS kernel, which fairly closely matched how the team wanted the kernel to behave, it was believe that the system would be pretty much done in a year of heavy coding.

Haiku does start, you can run it on your system. However, the next biggest peice of the puzzle which is being written from scratch by an amazing talent (DarkWyrm), is in need of completion. Some of the various teams that are integral to the Haiku development also have decided to follow better ideas over R5 implementations. In fact, in some cases Haiku is doing what Be wanted to do, but did not due to various difficulties with old code in the system that they were trying to weed out. And of course, in some cases (memory management), the problem was so wide-spread that a great deal of the systems accessing memory would have to be revised. Be was in the market to stay alive and, in order to do just that, development cycles needed to stay as short as possible.

Microsoft does not have to worry about this as much because they own the market. If Windows Longhorn is months or a year late, it doesn't matter to them except for publicity and marketing timing, which of course means that if they start the wheels rolling prematurely on their massive propoganda and marketing engines (which usually starts to work against older versions of Windows, and for the upcoming release... not against 'competition'). (Also note, I am speaking od Desktop/Client Windows versions).

So what does all this mean ? It means that Be simply could not afford the delays to release of a money-making product. Why? Two reasons: #1, they are not Microsoft with a large enough purchasing install base to sustain life. #2 (Related to #1), the installed purchasing user base Be had, already purchased the latest version of BeOS, but would VERY READILY fork over when asked for the next version. The new user growth rate was the only thing keeping the business alive (that and a few $20 million donations by Intel and others), but it was only making it possible for Be to pay the employees, and enough of the bills to keep the office and the lights on in the office. That may be good, but what about all those code licenses? Money they could not make enough of.

So, how is this all related to the topic at hand, did I run off on one of my famous tangents? Probably at least a little. But it is all pertinent to the topic of discussion. As you will soon see.

Haiku-OS.org is a non-profit organization (finally). They have no need to make money in excess of survival. Currently, I believe that EVERY LAST LINE OF CODE has cost Haiku-OS.org nothing, or very close to nothing. So what can they now focus on that Be got into a position of not being able to? Yup, the product!

Haiku teams are going off on tangents and improving the underlying system, because they have the luxury of time. And they know what copying the Be model entails. In order to be binary compatible, it is fairly easy to say... *ALL* classes, class names, member functions, and ANY public data member must be named, stated, and return identically to that of R5. Sadly, that can also include some bugs. (of course, not if the bug was so bad that no code could survive with it... then that would be safe to fix, provided no change to any of the R5-compatible API is made).

So, it would seem that all these advantages would have made it simple for Haiku-OS.org to meat the one-year mark for a (even alpha) release. But, when there is freedom, there is always leisure. For product quality, freedom can be EXTREMELY bad.. if the freedom is the wrong kind of freedom (can take as long as they want, can do it however they want). OR, it can be just as awesome (can take as long as they want, but it needs to meet these guidelines, be written in this way, compile in this way, confirm, conform, commit, etc...).

The latter freedom is what Haiku-OS.org has setup, practically unknowingly for sure, but that is what has been created. This means that Haiku OS is not just going to be an R5 clone. It will be better than R5. The network kit alone is completely unlike what R5 had. We are talking kernel-space vs user-space difference. That is, integrated and optimized vs un-optimized and sitting in the corner across the room blaring music that no one can understand. Fibre versus copper if you will :-)

The product will be better than what anyone has planned, and thus it will take longer to come to market. I, for one, am not rushing it.

So I'm finally off.. I'm going to try and patch the Haiku OS kernel into R5 or Dano, and see where problems exist.

--The loon (not a member of Haiku-OS.org)