The History Channel: 2003 Interview with Michael Phipps

Q: In the name of the Japanese BeOS community, I would like to thank you for accepting our request this interview for JPBE.net. Please, start by telling us a bit about yourself.

Michael Phipps: I am from New York State. I was born and have lived here all of my 31 years. I am married with two lovely children. I graduated from the Rochester Institute of Technology in 1997 with a degree in Computer Science. I work in the telecommunications industry in Rochester, NY producing high throughput systems.

Q: When was your first encounter with BeOS and what did you think of it?

Michael Phipps: I was an Amiga user from 1988 to 1996. I built a PC and installed Windows 95, but I hated it very much, and started sketching out a more modern AmigaOS type operating system. I showed these 20 pages or so of notes to a friend at RIT. He said "That looks just like BeOS!". He showed me their site and I started to read the BeBook. I was shocked - I didn't know if I should laugh or cry - here was my design, almost exactly! The friend who steered me to their website had a BeBox with the fresh off of the presses DR8. I have never looked back!

Q: Let's now talk about OpenBeOS. Tell us when and how it all started. Was it an spontaneous thing or was there a grandiose plan from the very beginning? What were the biggest motivations? Was there any hesitation to start such a big project?

Michael Phipps: I have spent much of tonight looking through the old e-mails (I am a serious e-mail pack rat; if you have sent me an email, I still have it). Starting the project wasn't actually my idea, exactly. On the BeDevTalk list, on 8/17/2001 (the day of Be's announcement), there was a thread about what developers were going to do next. Cedric Degea proposed the idea and it proceded from there.

I had been working on an innovative alternative programming language that turns out to be pretty similar to Python, but simpler. I had a couple of years of time invested in it and didn't think that porting it to another OS sounded like fun. I had investigated Linux and BSD, but neither really "did it" for me.

What really strikes me is how close to the original vision we still are. From the very beginning, I realized that we should split the project into kit sized pieces. Normally, people work on a kernel first (Linus with Linux and Bill Jolitz with 386BSD, for example). I knew that that would push away all of the developers who are not into the raw 0's and 1's of working on the kernel. We are working on every kit in parallel. That has allowed us to make a lot more progress than we otherwise would have.

Q: OK, now that we know a little bit more about the history of OpenBeOS and the motives behind it, tell us about your development team. How many developers are currently working on the project?

Michael Phipps: Another thing that really struck me from reading the old emails is how many of our original developers are still here. I will go by kit:

• The Interface Kit has Erik, Darkwyrm, Gabe and Adi. Erik was the first team leader to volunteer, and Darkwyrm came along a few days later. Gabe and Adi are fairly new contributers, but have worked very hard to "catch up".
• The Game Kit is mostly on hold until the Media Kit and Interface Kit are finished. We believe that this kit should be fairly easy when the time comes.

• The Media Kit

  has always been pretty much Marcus Overhagen's baby, and what an outstanding job he has done!
• Preferences Apps have been generated by a number of people. This is probably the most typical OSS model we have - people just come along and develop an app or two.
• Storage Kit: Ingo and Tyler have done spectacular work on this kit; just waiting for the kernel, pretty much, before they can call it "done".
• Be File System (BFS): Axel and Bruno (BGA) quietly swept in during the night and completed (except for a few bugs) BFS.
• Input Server: Jason and Tony have this nearly completed.
• Midi: There are a few people, Jerome and Matthijs mainly, who put together the bulk of this. Only soft_synth remains.
• Printing: Ithamar was a bright star at the beginning of the project; he had a lot of free time so he poured it into the Printing Kit, finishing most of it. He is with YellowTab these days. Mike Pfeiffer has come along, added PDF and a bunch of other outstanding work.
• Translation: Mike Wilber has been the driving force in Translation; this kit is in Beta. Look for a new beta and for it to be declared "done" soon.
• Kernel: Axel is the star of the kernel kit. He has come along and driven it further and faster than anyone imagined.
• Networking is in a state of transition, and is one of the two places we need serious help (the kernel is the other). There are no active networking people, as all of the developers had real life issues.
• Screen Saver is a special kit to me. I wrote most of it, and then turned it over to Andew and Scott who are deep in the middle of finishing it.

Q: For this kind of long term projects, keeping the motivation of developers is one of the keys to success. How have the motivation levels changed over time, and how would you describe now on, say, a scale of 0 to 10? Is there anything you do to keep your team motivated?

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.

Q: 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.

Q: 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.

Q: 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.

Q: 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.

Q: 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.

Q: 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.

strong>Q: OBOS target for release 1.0 is to produce a system that is binary compatible with BeOS R5. In contrast, for Zeta yellowTAB is bringing in new features and technologies to the 5.x codebase, such as their locale kit, a new USB 2.0 stack, ODBC, etc. Do you plan to bring OBOS to par with Zeta in the future (post R1)? Are you exchanging any technical information with yellowTAB for that purpose?

Michael Phipps: Many of the things that YT has done are things that I have (personally) planned to try to get into R2. I have said publicly many times that internationalization is a tough nut to crack, and that we don't want to do it until we can do it right. yellowTAB's solution, if I understand it, is not what I would call "The Right Way". There are a number of issues that are not dealt with that I think are important. But doing it the Right Way means many far reaching changes to other kits, so it is an R2 thing. Other things (USB, for one) could easily be made independent of the OS; the same USB stack should run on R5, Zeta and OBOS R1.

Q: With regards to Zeta's locale kit, although it is definitely a great tool for localization, it may well fragment the application base since Zeta binaries that use it will not run in R5 (as of now). Are there any plans to implement a Zeta like (or compatible) locale kit in OBOS? We definitely think both yellowTAB and OBOS should do the BeOS community a favor and come to terms in this respect, so that there is a single, unified localization method accross the board (maybe beunited.org could step in here?). Any comments or information that you may be able to share with us?

Michael Phipps: As I talked about above, I don't personally care for Zeta's implementation. One example is that the GUI is still fixed width. If I have a label "Why?" in English and a Spanish user translates that to "¿Por qué?", the label may not fit properly. It could be chopped off, or it could overlap another view (which is a bad thing). My proposed solution is a totally different way to do GUIs where spacing is proportional. But that is *WAY* beyond R1. I would also introduce controls for calendar, time, currency, etc.

I don't mean to bash YT and Zeta. Please don't get me wrong here. I would assume that YT doesn't have the time and resources to "do it right", but needs to have as large a market as possible for their release. I might well have done the same thing in their shoes. But I am not in their shoes.

Q: Some of the shortcomings of R5 include 1GB memory limit, and a lack of HW OGL. Will OBOS address these shortcomings, and can this be expected on the first release of OBOS?

Michael Phipps: Our plan is that a few of the shortcomings will be fixed: the design issues. The 1GB RAM limit will become 2GB or possibly more. Sockets will be file descriptors. Select and mmap will work. HW OGL is a *HUGE* undertaking. It is a good thing and we would like to support it. But not for R1, unless we get a whole ton of very focused, very knowledgable people who want to work on it.

Q: It's WalterCon time now. It is great news that OpenBeOS will hold its own conference. Tell us all you know and can disclose us about this first OpenBeOS conference. When will it be held? Where? Who is your target audience for the event? What ideas are being entertained? Will you try to attract developers from the Linux arena? If so, how? Do you think or expect yellowTAB to attend the event?

Michael Phipps: Our tentative date is the weekend of the 26th of June, 2004 in New York City. That is not a promise, but it is the current plan. Our target audience is fans of the BeOS. I will be there, as will a number of the team members. We haven't decided exactly what we want to talk about. I anticipate speaking a few times, probably a few classes about different kits. I suspect a lot of R2 conversation will occur.

Q: Let's take a look about the future of BeOS and OBOS in particular. Where do you see OBOS about a year from? Make some wild guesses if you wish. What about Zeta? Where do you think will Zeta be then?

Michael Phipps: Let me say this - I AM GUESSING. With Open Source, and in particular with small teams and open source, it is very hard to project where we will be next week, much less 52 weeks from now. My guess, though, is that R1 will be "released", meaning that there is a burnable .iso on our website as a beta. I suspect we will be in serious bug fixing mode.

Q: Talking about the future, there is this project called Glass Elevator which not many people know. Can you tell us what it is and how it fits into the OBOS project?

Michael Phipps: Glass Elevator is all about talking R2 and beyond. All parties interested in discussing R2 are invited, provided they follow reasonable protocol. Many good ideas have been discussed. When R1 is complete and we fork the code to start R2, we will hopefully get a report from the GE folks containing suggestions and ideas.

Q: I am sure that you would like to get more developers to participate in the OBOS project. Give us in brief terms where a developer new to BeOS could start if he or she wanted to become involved with the OBOS project. Maybe we can attract some devs from the Japanese BeOS community!

Michael Phipps: I would love another 50 developers. :-)

Basically, if you have C++ experience, we are looking for you. There are many parts that could use developers. If you are a fairly inexperienced developer, the Preference Apps team could use your help. There is some porting and some fairly easy development that needs to be done. If you are a more advanced developer, there are a few places that we could use your help: the Kernel and Networking come straight to mind. Those two kits are the furthest from completion and need quality developers. The "problem" is that those are also kits that need very skilled people.

Anyone who would like to help should take a look at the teams section of our website. They should pick a team and a vague idea of the task that they would like to work on. Then they should email the team leader for help. If there are any problems or questions, they can certainly email me.

Q: Do you have any message to the BeOS fans in Japan?

Michael Phipps: A few things. First of all, thank you. I see applications and drivers from Japan on BeBits.com. Without your support, the BeOS community would be a poorer place. It is unfair to ask more of you, but I must. We need more help: more drivers, more applications and maybe even a few developers on OBOS.

Finally, keep the faith. I know that it has been a long time. And that there are fewer compelling reasons to run BeOS than there were 3 years ago. We know that, too. We have huge (but incomplete) plans to make OBOS an operating system that will make people sit up and say "WOW!" again.