First of all, I am very flattered that our recent editorials over at OpenBeOS have received so many responses in the OSNews commenting section.I would like to address some of the issues brought up in the many thought provoking comments, in the order that I read them:
Doomed by C++ Virtue
Some people have opined that BeOS’ adoption of the most popular “object oriented” (yes, I know the Smalltalk people just gasped) language in the world was its doom. They talk about Fragile Base Class as one reason. Being an engineering type, the first response that I have is to say that FBC is an implementation detail of the compiler. There is nothing that *I* am aware of in the C++ spec that requires FBC to occur. And there are certainly ways around it in the compiler writer’s world. Many of them are hard and would take a fair amount of extra work. But they could be done. However, there is another side to this. There is *NO* language that will please everyone (watch for this to be a recurring theme here). C? Old school. Objective C? Too weird. No one knows it. Perl? Lisp? Awk? Forth? KSH? Cobol? If Be had happened to pick one of those, some people would have been happy, others would have hated it. The long and short of it is this – it is what it is. Be chose it. We could not even pretend to write OBOS and use any other language. If you want to argue that writing some other OS is a better idea, well, that is your decision. I would be interested in knowing where you could get a full design that is better.
Buying BeOS from Palm
This whole drama played itself out. A little known fact is that I personally ponied up some money to make it happen. I thought that this would have been a great option. Palm had/has *NO* interest. I know for a fact that many tried. And some are still trying today. Palm has liability in the code – all of the licensed code that is incorporated. They bought those rights, too, I would think. And Palm would have to, in all good conscience, have to pay people to rip that licensed code out. Not to mention the opportunity cost of paying engineers to do something that will never further *their* product line. No, the smart corporate decision from Palm is to put the code in a vault and sit on it. I don’t like it, either, but if you are trying to convince someone of something, you have to put yourself in their place. And their place is far safer here than releasing code.
Future Goals of OBOS (and copying of R5)
This is the one item that boggled my mind the most. We daily have posts and ideas about where to go from here. *EVERYONE* is interested in adding this feature or that option. I have to bat them back to reality. We have a cohesive design today. Implementing just what is already designed will be hard enough. Designing, coding, testing and documenting a dozen peoples’ vision of where the OS should go is more than we can do right now. With a stable and working R1, we would/will be in a far better position to make changes. Glass Elevator is *dedicated* to figuring out what to do with R2+. I personally have a whole notebook of changes that I would like to see made. The team leads, as they and their teams have coded, have grumbled about the way this and that works. Believe me, the biggest challenge that we will have post-R1 is to figure out what *not* to change. No matter what we do, whether we abandon compatability or remain strictly R5, half of the people will not be happy.
As an added thought, a new GUI was mentioned. For all of the moaning and groaning that I hear about the current GUIs in the world, no one seems to have actually *designed* a better approach. I hear a lot about how the desktop is dead, its’ time has come and gone, blah, blah, blah. But I don’t see a better design out there. Not even a Photoshop mockup. Why is that? I don’t think that anyone knows what the next big GUI design will be. If you do, contact me. 😉
Why protect corporate interests
Very simply, corporations write apps. Usually the big, ugly apps that no one else wants to write. Look around the open source community. Compare it to a CompUSA ad. There is a lot of software that OSS people don’t want to write. It isn’t an itch that they want to scratch. Example – accounting packages. Several corporations have come to me about using OBOS. They are very pleased about the licensing and direction that we are going in.
Come on, guys. 😉 We know we need apps. We know about the whole chicken and the egg thing. This wasn’t new when Be started. This is one reason that we have a goal of binary compatability with R5. If we do this right (and so far we have), everyone can keep Productive and Opera and so on. Furthermore, BU or maybe some rich distro maker can go to these companies and say “hey – this is an active OS with N users – can you port your software?”. Apps is a known issue. Part of the reason that OBOS tries to stay so open and up front is that we want people to get excited about our progress without promising the moon. The more excited people are, the more likely they are to write apps.
Again – this is not a surprise to anyone. One thing that I find to be encouraging is that more and more hardware is more and more compatible. Example – video cards – there are a *lot* fewer video card chipsets than there used to be. While I don’t consider this a good thing for the consumer, it is a good thing for us. USB is another good thing. The only solution that anyone has offered, so far, is to use a Linux kernel to use their drivers. Again – this is a solution designed to anger 1/2 of the people.
Releasing under GPL
The way that I see it, GPL takes rights away that the MIT license grants. GPL grants nothing that MIT does not. So, the way that I see it, we could do very much what Perl does, and dual license. It would neither help nor harm anyone. The only reason that I don’t is that I don’t see the point.
You would be very surprised how hard it is to come up with a *good* new name. We had > 3000 suggestions. Not one was so impressive that we all just said “this is it”. Many were acceptable. Some were too geeky, some were too bland. Some were to Be-like, some were too close to other similar products (Bindows, for example). We are still working away at this.
Dorks in Management
This is one of the biggest advantages of being an open source project. Sure, some OSS projects have management issues, too. But there are no accountants or MBAs who will tell the devs what to release and when with OBOS. That is both good and bad, I understand, but this particular issue is pretty easy to put to bed for OBOS, right now.
Corporate vs Hobbiest
“I am not in this for your revolution, Princess” — Han Solo
The point of OBOS is not to become Be, Inc. Go back and read that again.
We are not Be, Inc. We are here to make an operating system that is what we think is the best way to make a desktop OS. We all came together knowing that Be did a heck of a job on R5 and that continuing in that vein is a good direction. I want an OS that I can use happily. And recommend to my friends and family. I am not in this to form a company and make a billion dollars. I *certainly* would have picked an easier industry. I hope that some Red Hat comes along and makes OBOS a household name. I wouldn’t mind too much if they contributed back, either. But I am not counting on it. I am not quiting my full time, paying job to do this. This is all in my (and all of our) spare time and out of the desires we have to own and run a sweet OS. Being able to say that you built it doesn’t hurt, either.
I would just like to take a moment to thank all of those who encourage the OBOS developers and myself. Reading those emails straightens our backs a little, helps us to raise our heads and march on. For all of those who challenge our worldview, I thank you for keeping us honest. It would be wonderful to live in OBOS-world, where there was no other OS and the entire world was using R5 and awaiting our first release with a baited breath. 😉
Michael Phipps, OpenBeOS Project Leader