Michael Phipps: I think that the motivation levels are very high right now, probably an 8 or 9. Whenever there is a lull in development, someone steps up and commits a whole bunch of code, energizing everyone else around them. That is the beauty of this kind of team. Very few people have left OBOS for reasons of motivation - almost always there is an external issue that causes people to have no free time.
Besides OpenBeOS there are several other projects that have recreating BeOS as their goal (BeFree, BlueEyedOS, Syllable, etc.). A lot of us wonder if it were possible to gather all that brain and manpower into one single project so that things could move faster, instead of having what seems like fragmentation to many of us. Or are there synergies that work for the benefit of all projects? If so, can you give us specific examples where different projects benefited from one another?
Michael Phipps: There are some synergies and some duplication. We have shared code with BeFree, for certain, and Cosmoe. Since our code is MIT licensed, anyone can use it within the terms of that license. I would be very willing to bet that any BeOS clone project that approaches completion will use a significant portion of our code.
Since most of the other OSBOS projects are closed source, I cannot give a lot of specifics. For example, I believe Bill Hayden (from Cosmoe) is using some of our app_server code. He has also been checking in code cleanup stuff and some bug fixes. I seem to remember WinBe reusing some of our code, too.
We know that choosing the kernel for OBOS must have not been an easy choice and that there may have been differing views of what kernel OBOS should be based on. In retrospect, do you think you made the right choice by going with the NewOS kernel? Also, what were the most compelling reasons that influenced your decision?
Michael Phipps: This was one of the toughest decisions to make, but a key one. Linux, at the time, was not even close to acceptable in performance terms. I keep hearing that with this patch or that option it is very fast. I have never investigated that; we are too far down the road we have chosen. The BSD kernels were considered. The licensing is more in line with our choices. The problem is that BSD is a server OS, as is Linux. There are optimizations and tradeoffs that one makes for servers versus desktops. Linux and BSD choose to be servers, which is wonderful. We choose to be a desktop. We need to make different tradeoffs. NewOS was/is developed to be (in my opinion) "BeOS kernel done right".
On one hand, using a more complete kernel (like, say, a BSD) would have us probably code complete right now on the kernel. On the other hand, I think that because we chose NewOS, our final result will be more BeOS like. Overall, it has been a long, tough wait, but I believe that it was the right choice.
We know that OBOS has a development mailing list and that from time to time you may get questions from developers interested to learn about OBOS. From those instances, what do you think are biggest misconceptions about OBOS and the project? Name just a few examples for us.
Michael Phipps: Probably the biggest misconceptions are that we have an installable disk image or, conversely, that we haven't done anything because we have no disk image. Because of our multi-pronged approach, we have a whole lot done, but we are just starting to get to the place where the majority of the OS is in beta.
OK, let's change subjects a bit. It is now known that beunited.org is working on a SUN certified BeOS port of Java. How do you see this influencing the future of BeOS in general, and that of OBOS in particular? yellowTAB was said to be working on their version of Java; would you agree that it was a waste a limited resources to duplicate effort?
Michael Phipps: I don't quite understand all of the things that I hear about Java. Software for the desktop doesn't often seem to be written in Java. It seems like something that is either for college classes or enterprise level server apps. I would love to see some evidence otherwise. I don't see where a Java port brings any significant amount of software to the BeOS community. If it does, I will be very excited. As far as duplication of effort, that is hard to say without knowing specifics. Is everyone looking at the same version, or is there J2EE vs something else? Is YellowTAB using the Java code from Be as a basis? I don't know those answers. I do know that beunited,org will release their Java for free, which is good for OBOS and for the community.
Talking about yellowTAB, have you had a chance to try Zeta? If so, what do you think of it?
Michael Phipps: I haven't seen it, so I can't really say much about what it is or is not. I can say that I believe that the BeOS community will not wholeheartedly place their trust in another small company any time soon. That is where OBOS comes in. Imagine a world without an open source BeOS. Would you, the commercial developer, risk a significant amount of time and energy on it? Be, Inc., with its advantages over yellowTAB (more $$$, more engineers, IPO, etc.) couldn't succeed, so wouldn't it look to you like a low chance of success? Sure. But with open source, you know that the OS is far more likely to be around in 5 years. Zeta's existance doesn't change our plans at all. I think that a lot of people who can not run R5 can find a benefit in Zeta in the short term.
Has there been any communication with yellowTAB regarding finding synergies? It seems like, at some point, yellowTAB could use some of the codebase from OBOS, and viceversa. Anything you can tell us in the respect?
Michael Phipps: Bernd and I have emailed back and forth a few times. I can't really talk about what he and I have said without his permission. I can say that I have asked him to open source a few of the technologies that they have.
- "Michael Phipps Interview, Page 1"
- "Michael Phipps Interview, Page 2"
- "Michael Phipps Interview, Page 3"
