[openbeos] My Big, Fat Catch-up Email

I'm done doing piece-meal replies to stuff that's 10 days old.  I'll 
just do my catch up and try to grab everything that I need to reply to 
in a single mail -- and beg your forgiveness up front for its length and 
redundancy. =P

On Helmar's Final Word:  guys, we gotta get real here.  Do you *want* 
GeForce3 drivers?  Nvidia doesn't seem too friendly to the idea of 
giving specs to opensource folks for the purpose of implementing 
drivers.  No, they like to keep that stuff in-house or under strict NDA 
with another *company*.  This is gonna be the case for a *lot* of 
hardware.  If nothing else, hardware companies are going to want to see 
that somebody is willing to run the risk of supporting the OS 
commercially before they'll invest in writing the drivers themselves.  
Unless we want this to wind up being a massive act of geekly 
self-flagellation with no real future, somebody is going to have to 
market/promote/commercialize this thing.  People have said it before, 
but it apparently bears saying again:  Linux, that shining triumph of 
opensource, would not be enjoying anything like it's current hardware 
and software support without the *major* efforts to commercialize it 
that have been made by Red Hat, etc.  To believe otherwise is, frankly, 
to live in fantasy-land.  Although I think Helmar's statement that 
"OpenBeOS == Death" is a bit extreme, I must agree in the strongest 
possible terms that for *any* implementation of BeOS to go anywhere, 
someone will eventually have to support it commercially, and Helmar & 
Co. have got the credentials and the passion for the OS to make it 
happen.  If Helmar & Co. and/or Palm can make this happen in the near 
future, we can count ourselves as being very lucky.  I don't know a damn 
thing about marketing, but I'm smart enough to know that without it, 
we're doomed to eventual irrelevance -- and that's not something I'm 
interested in wasting my time on.

On the existence of OpenBeOS:  if Helmar & Co. (or somebody else) can't 
cut a deal with Palm to continue development of the existing codebase, 
we have no choice for the future of the OS other than an opensource 
implementation.  The existing development and user communities are not 
going to hang around while the OS slips further and further into 
obsolesence.  Yes, a few of the total diehards will keep using it until 
it's just plain ridiculous to continue, but the majority of folks will 
bailout if nothing happens to update the OS itself.  Extensions are 
great, and I hope people keep making them, but without continued 
development, BeOS will be like Latin:  interesting to a few, and dead 
for everybody else.  As far as OpenBeOS being "a very different OS", it 
will only be as different as we make it.  We're commited to the goal of 
reimplementing the OS in a way that is _at_the_very_least_ source 
compatible with R5.  If in the course of doing this we add some extra 
nifty bells and whistles, I don't think anyone will complain -- we would 
simply be jumping ahead to R6, that's all. =)

On "a million different projects":  There are not, to my knowledge, "a 
million different projects all trying to achieve the same goal".  To my 
knowledge, there is OpenBeOS, BlueOS and the "Phoenix Group" (for lack 
of a better label) -- each of which is currently taking a very different 
approach to ensuring the continued development of BeOS.  If the Phoenix 
Group is successful, I have the distinct feeling that OpenBeOS and 
BlueOS will soon find themselves irrelevant to the majority of folks in 
the dev and user communities -- in fact, I think most of the devs in 
those efforts will lend their support to the Phoenix Group rather than 
messing about out in the weeds.  And if they aren't successful, I'm 
betting whichever reimplementation effort takes the clear lead, the 
other will soon either join forces or fade into obscurity.  Any way you 
slice it, we'll probably end up with one clear effort leading the way 
before very long.

On starting from scratch:  Neither OpenBeOS nor BlueOS is proposing we 
start from scratch.  OpenBeOS aims to make its work drop-in replacements 
for existing OS systems.  Both projects will be heavily leveraging 
existing opensource resources in their efforts.  Witness OpenBeOS's use 
of NewOS and BlueOS's use of the Linux kernel.  As far as ruining 
NewOS's chances of success, I'm not under the impression that Travis had 
"success" in those terms in mind for the project (feel free to correct 
me if I'm wrong, Travis).

On blowing off a possible deal with Palm:  Nobody's blowing off 
anything.  You may be familiar with the Boy Scouts motto:  "Be 
Prepared."  That's all we're doing -- being prepared for the most 
unpleasant of many possible outcomes of the Palm negotiations.  Any deal 
the Phoenix Group makes with them changes the landscape drastically, and 
everything will have to be reconsidered, whether we like it or not.  
Nobody's trying to antagonize Palm or anybody else -- we're just trying 
to keep the OS alive, which is what all of us want, right?  There are, I 
think, a few extra-enthusiastic members of the OpenBeOS effort who are 
pretty solidly in the "opensource or die" camp, but I don't get the 
impression that this represents the majority (or even a large minority) 
of the team.  By and large, we're open to the realities of the 
situation, and are quite pragmatic about how to achieve our primary goal 
-- BeOS's continued growth and existence.  We are *not* the enemy of the 
Phoenix Group, and the Phoenix Group is *not* our enemy:  there will 
always be those who think that commerical considerations are totally 
unnecessary, may even believe that they constitute selling out, but 
cooler and more realistic heads will prevail (hopefully).  What we all 
really want (whether we individually realize/admit it or not) is for the 
OS to be commercially viable, because that's how BeOS will get to be all 
we want it to be -- whether it's a Palm deal or OpenBeOS or BlueOS that 
gets us there will be, in the end, beside the point.

On moving to GCC 3.0:  From what I've seen GCC 3.0 is not really ready 
for prime time yet.  Yes, it's got oodles of cool new stuff, but now is 
not the time -- we have to keep the developer and user communities 
hanging in there, and heaping a (mostly) unneccessary binary 
compatibility break on top of everything that's happened so far would be 
tantamount to shooting ourselves in the head.  Once we've gotten ver. 
1.0 accomplished and regained dev and user confidence, *then* we can 
talk about GCC 3.0.  It's not like it's going anywhere. =)

On using a Qt/GTK/whatever port:  Ports of this software would be/are 
undeniably cool, and I whole-heartedly encourage non-OpenBeOS team 
members to pursue this as a worthy and very useful accomplishment.  They 
do not, however, get us any closer to our goal.  What, exactly, would a 
"native" Qt port sit on top of?  The interface kit?  We'd have an 
extension then, not a replacement.  BDirectWindow, or maybe 
BWindowScreen?  That *might* have some merit, but I would submit that 
the work necessary to a) make Qt work with either of those classes and 
b) write a BeAPI compatibility layer on top of Qt will, in the end, be 
at least as much as just writing the stuff from scratch.  You would 
still have the problems of actually making apps use that instead of 
using the pre-existing libs, providing classes that aren't widgets but 
are still part of libbe, and dealing with the fact that Qt is designed 
(as I understand it) to be used in a synchronous fashion, necessitating 
a lot of work to get it wrapped around BeOS's multithreading paradigm.  
In short, using Qt in this capacity *seems* like a tempting shortcut to 
the holy land, but that shortcut is only surface deep.  On a related 
point, the Interface Kit team *has* its requirements:  the BeBook! =)

On just moving to AtheOS:  This is a very tempting thing to do, and you 
can't discount Kurt's ability as an engineer -- he's obviously quite 
talented.  He is also, unfortunately, not interested in the idea of 
AtheOS being made into a full-fledged opensource BeOS clone.  He has 
different ideas for his OS -- that's his perogative, and I can respect 
that.  Some people have called for forking the code, which brings us to 
the next issue:  although BeOS and AtheOS are quite similar conceptually 
and architecturally, they are not the same, and important things to hang 
onto from BeOS (like existing apps and drivers) just aren't going to 
drop in.  A significant amount of re-engineering would be necessary, and 
I'm not convinced that we'd really save much time going that route.  
This sort of falls into the same category as the Qt port suggestions:  
looks like a good shortcut, but odds are it won't be in the end.  All 
this is not to say that we can't get a lot of great implementation ideas 
from AtheOS -- we can and absolutely should examine it quite closely for 
whatever insights we can gain.  One last thing:  some people suggest 
bailing out on BeOS altogether and just becoming AtheOS users.  All I 
can say to that is BeOS as it exists is far more complete and polished 
as an operating system.  Personally, I'd wait until AtheOS has gained 
that level before bailing out -- you'll only lose functionality before 
then.

On adding multi-user capabilities:  In my mind, there are two ways to 
define "multi-user".  First, is the classic *nix concept of multiple, 
simultaneous users which we all know and love (sorta).  Second, is a 
system which allows for multiple single users (if that makes any sense) 
where each user has his/her own home directory and, consequently, 
his/her own settings, etc, and where users are prevented from stomping 
on other users' home dirs and on the system as a whole (unless they have 
root/admin priviledges).  The first definition belongs, I think, to the 
realm of servers, which BeOS is not and, IMO, should not aspire to 
become.  After all, we have a perfectly usable and well-supported 
opensource server already in existence -- Linux.  Although people gripe 
about the quality of the Linux desktop experience, I don't think there 
are many folks outside of Redmond who will seriously bash it as a 
server.  To me, Linux and BeOS are the ultimate combination:  BeOS on 
the desktop, Linux in the server closet.  I would personally love to see 
the second definition of "multi-user" implemented in OpenBeOS.  It's 
more of a "multi-configuration" scheme, really.  I think it's do-able in 
a reasonable time frame and desirable.  The *nix definition will be very 
difficult to implement (for reasons discussed elsewhere, track them down 
if you're really interested), and not all that desirable.  This is not 
to say that BeOS shouldn't be used as the light-weight (in the best 
sense of the phrase) server that it is already capable of being.  But it 
shouldn't be forced into becoming the heavy-duty, industrial-strength, 
multi-user server that Linux is a great example of; there's really no 
defensible point to it.

On BeOS design flaws:  I'm neither surprised nor dismayed to learn of 
the glaring problems that JBQ has so kindly pointed out for us.  It is, 
unfortunately, the lot of shipping software to have these sorts of 
issues.  My primary work at the day job is maintaining a fairly popular 
and commercially successful Palm app, which is an absolute horror 
design- & code-wise.  The best we as engineers can hope to do is avoid 
problems when possible, and fix them when we can.  Regardless, I'm in 
BeOS 99% of the time at home (and that's no exaggeration) simply because 
it's more responsive and stable than Windows.  I've never been the type 
to monkey with alternate OSs just for the fun of it (I have *never* 
installed a Linux distro, for instance), and before R3 shipped, I was a 
die-hard Windows user and developer.  In spite of its flaws, BeOS still 
offers the best overall desktop experience.  I am, however, very 
grateful for what JBQ and Manuel and others are revealing; it will only 
help us in the long run, whether we end up going the distance with 
OpenBeOS or working on Phoenix Group code.  

On BeOS development:  I don't remember who suggested that developing for 
Windows and Mac is easier than developing for BeOS, but I actually 
laughed out loud at that. =)  I haven't developed for the Mac, but I've 
done *plenty* of development for Windows using the raw Win32 API, 
Borland's OWL and VCL (Delphi/C++ Builder), and some MFC, and unless I'm 
seriously missing the boat, none of these is as easy, sensible and just 
downright elegant as the BeAPI.  When I got to BMessage in the BeBook (I 
basically read it from cover to cover), I knew I'd found the holy land. 
;)

In conclusion:  our absolute best bet by a very long way for the 
continued viable survival of BeOS is Palm licensing to the Phoenix 
Group.  There is simply no two ways about it -- working from the 
existing codebase will save us *months* or even years of design and 
implementation work.  Sure, we've got an awful lot laid out for us in 
the BeBook and Be Newsletters, etc., but that just can't touch having 
the source.  And even *if* Palm were to just release the source (c'mon, 
do you *really* believe they'll do that?), we'd still need marketing 
muscle to keep things moving.  There's a very good argument to be made 
that Be's marketing is what killed them -- they did a great job of 
evangelising to the devs, but most everybody I've talked to about what 
I'm doing with my free time hasn't got clue one about BeOS.  And these 
are folks that are in the industry, following the trends, reading the 
magazines, using alternate OSs, etc., etc.  I've said it before, and 
I'll say it again:  I'm 100% commited to doing *whatever* it takes to 
keep BeOS alive and thriving.  My involvement with OpenBeOS is 
predicated on the possibility that Palm will *not* cut a deal and will 
*not* release the source to the masses -- but I sure would *love* to be 
proved wrong on that count.  Keep your eye on the prize people -- it's all 
about the BeOS, and that's the bottom line.

e

Data is not information, and information is not knowledge: knowledge is not 
understanding, and understanding is not wisdom.
        - Philip Adams

Other related posts: