Koki from the japanese site jpbe recently interviewed Michael Phipps the project leader of OpenBeOS. The original interview in japanese can be found here. Read more for the english version of the interview.
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.
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!
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
I really hope OpenBeOS succeeds, it’s great to see that they are making good progress!
One of the best reviews on OSNews in recent memory.
“Keep the faith”? Sounds pretty damn much like a religion of sorts….
A nice little interview. My favorite part: he guesses that in a year, it’ll only be in early beta, and that’s only R1. Maybe this will keep all those BeOS fans here from constantly posting about how OBOS is going to rock everyone’s world any day now.
When it comes out, it will be fun to look at. But it’s nice to hear some more realistic estimates of when it will be available than what the fanboys always post here.
I first tried BeOS in 1999. I’d grown sick of Windows and how much it kept messing up. I tried Linux (which I revisited a year later and switched to) and it just wasn’t good enough for a desktop for me. I then stumbled upon BeOS and it blew me away, so fast! So easy, exactly what i was looking for: MacOS for AMD. I never switched fully as I could never get my sound working, but I was seriously impressed nonetheless.
But now it is 2003, Linux and GNOME/KDE as well as Mac OS X have become seriously impressive, and are getting better all the time. Longhorn looks to push a few boundaries itself in 2006.
Is there really any place for BeOS in 2003? Or will it just appeal to a select few Be followers who refuse to let the past die?
A nice little interview. My favorite part: he guesses that in a year, it’ll only be in early beta, and that’s only R1. Maybe this will keep all those BeOS fans here from constantly posting about how OBOS is going to rock everyone’s world any day now.
…We’ve known that for a while before this interview.
The way I see it is this,
R1 is not a meager acomplishment, because once they have completed it they will gain a familiarity and intimacy with understanding the OS itself that could only have been gained via this route. They’re going to know their code inside out and I believe that once R1 is released, this will result in quick progress to R2. Because by then the gruntwork would have already been done, they just need to evolve it.
But now it is 2003, Linux and GNOME/KDE as well as Mac OS X have become seriously impressive, and are getting better all the time. Longhorn looks to push a few boundaries itself in 2006.
I don’t get this. Is Linux a server OS or a desktop OS? It’s definitely gonna need to do the server trade offs if it wants to be a desktop OS now don’t it? Therefor Linux can and will never be as fast as you can be OBOS =)
OS X is a different story, still I prefer the BeWay ™…
A year from now, BeOS will STILL be faster than OS X, Linux, whatever… because it is THE fastest OS around..
I don’t get this. Is Linux a server OS or a desktop OS? It’s definitely gonna need to do the server trade offs if it wants to be a desktop OS now don’t it? Therefor Linux can and will never be as fast as you can be OBOS =)
No, you DON’T get it. With Linux 2.6+ the OS is focused on desktop as well as on server tasks. You can now choose at compile time many options that enchances the desktop. Linux as of today scales REALLY well from almost calculator level (there’s even a Linux port for the TI series…), to big mainframes and clusters like NASAs new 512 x Itanium 2.
OS X is a different story, still I prefer the BeWay ™…
Honestly I believe OS X has got MORE of the “desktop trade off for server” in kernel than Linux.
Myself I still prefer BeOS, but not because it’s superior in any way. My Linux/KDE desktop is faster and more featureful in almost any way.
Still BeOS feels more right….
I don’t get this. Is Linux a server OS or a desktop OS?
Neither. Linux is a kernel, not an operating system. The Linux kernel is distributed in operating systems intended for desktop and server use, however.
No, I’m not nitpicking. I’m making a point. Linux by itself – Linux the kernel – is just fine for a desktop OS. But a desktop OS is much more than its kernel. The surrounding framework is what makes it comfortable – or doesn’t. The keyword is “surrounding” – *Linux* doesn’t have to trade off anything to be used in either a server OS or a desktop OS. The distributors chose the focus of their Linux-based systems.
But enough thread hi-jacking, let’s talk about OBOS.
Thanks Koki, I hope more of the resourceful Japanese community join the OSBOS movement.
the big problems with Linux involve Xfree and the bloat that runs on top. BeOS was nice and quick because it didn’t have an app communicating to the desktop manager communicating to the X server (or client, whichever terminology is in vogue this week) communicating to the kernel. Less overhead. More speed.
Trading speed for network transparency is great for servers, but hardly does a desktop user any good.
I’m impressed with the progress of OBOS, and waiting in the meantime for a Zeta I can use.
Nice interview
the big problems with Linux involve Xfree and the bloat that runs on top. BeOS was nice and quick because it didn’t have an app communicating to the desktop manager communicating to the X server (or client, whichever terminology is in vogue this week) communicating to the kernel. Less overhead. More speed.
Trading speed for network transparency is great for servers, but hardly does a desktop user any good.
Do you have any idea of what you are talking about, or are you just chanting? By the way, the kernel plays a key factor in determining how responsive the desktop is.
bad kernel != nice desktop
> Is there really any place for BeOS in 2003? Or will it
> just appeal to a select few Be followers who refuse
> to let the past die?
BeOS R5 I admit is not a truly competitive OS now. There are bugs in the media kit, networking is slow, modern hardware support is poor.
Looking through all those issues though – it is still a very elegant OS, with a more modern internal design that most “current” OSes. Windows XP still has the old Win9x C API at it’s heart whereas BeOS has a very nicely thought out C++ API, it is heavily multithreaded, and remains the most responsive OS I have ever used. I still use it 90% of the time as I much prefer the user experience over that in windows.
OBOS R1 will not come out tomorrow. OBOS R1 will not revolutionise the world, or contatin lots of new features. However, it will fix many of the annoyances with R5 (the media kit bugs, poor POSIX support, networking living in userland, 1 Gig memory bug, poor support for modern hardware, etc). On top of that it will be completely open source – so there is no danger that the OS will suddenly disappear (as happened with the original BeOS).
But the thing that I really like about the OBOS project is how the whole thing is integrated. The kernel, networking, the app server, the file system, everything is developed by one project. All the components are designed to fit together as a single, cohesive OS. All of them designed with the same thing in mind (giving the best user experience possible on a desktop OS). There won’t be any need for distributors to put all the pieces together, you won’t be expected to compile parts on your own – you can simply go to the OBOS website and download a complete, consistent OS.
Hopefully R1 will re-enliven interest in the BeOS platform, bringing more developers and with them more apps, ready for future releases which will be much more capable of competing with current OSes.
Besides OpenBeOS there are several other projects that have recreating BeOS as their goal (BeFree, BlueEyedOS, Syllable, etc.).
Just to set the record straight, Syllable is not a clone of BeOS. We are not a member of BeUnited, our API’s are not compatible, we are not trying to be BeOS. While I respect what Michael & the OpenBeOS team are doing, and I wish them the best of luck, it doesn’t help anybody when people look at all these projects and say “Hey! Why don’t you all work together; you’re all the same, right?”
Since Syllable when it reaches version 1.0 shall functionally be the same or better than BeOS, why are they duplicating several efforts to clone BeOS rather than working on Syllable? Syllable is more complete, and supporting legacy BeOS applications is probably not a good reason to clone the OS.
I’m hoping for SkyOS more than Syllable.
“I’m hoping for SkyOS more than Syllable.”
I was,but I can’t bring myself to support a closed source OS.Besides, Syllable is remarkably advanced too.
OBOS get a number of advantages by sticking to the R5 API:
– No time is wasted discussing new APIs.
– By and large, the API is consistent across kits, as Be Inc took 10 years designing it and improving it.
– Existing BeOS programs will still work.
– People who have done programming on BeOS before will instantly be able to code for OBOS.
– While R1 is being written, and with it a lot of insight gained wrt the issues that matter writing an OS, R2 with the API extensions can be planned.
– Keeps developers focused on writing code with the best possible implementation possible, without really having to worry about how the small part they are working in fits in the bigger picture.
A nice interview. Its good to see that there is substantial progress being made. Hopefully, in 2004 we’ll be able to get our mits on a Beta. Like everyone else the world of OS’s have moved on (I’m using OSX more and more had to get a new iBook G4) but I still believe that there is a place for a BeOS style OS. I still get amazed how fast R5 feels even when running on PII 500MHz Dell. Linux distributions have yet to get a desktop version right, its not the kinux kernel but due to KDE and GNOME. They are still not as good or consistent as BeOS’s GUI. There are things that I would like to see updated in the BeOS’s GUI, esp since I’ve been using OSX more and more, but I can wait for these to be implemented.
I’m looking forward to run, OBOS on my Shuttle XPC Nforce2, 1GB of RAM.
Don’t knock EQL. She was one of the most dedicated BeoS advocates around.
Harj
: o )>
WE are not a BeOS clone. As much as I actually like BeOS and I have used it for quite a while, I strive for something different. We don’t want to be a BeOS clone.
There will be no beta in a year’s time. When the project started two years ago, it was predicted there would be a downloadable iso in a year’s time! See a pattern there?
OBOS supports new networking technologies like zero conf.
I also hope they get Samba ported. those two things will make using OBOS much nicer on a mixed network with PCs and Macs.
also, what is their printing system? will they use Cups or is that not how they want to go?
Please re-read what I wrote, I was questioning the point of cloning BeOS at all and not suggesting Syllable be a BeOS clone.
> Please re-read what I wrote,
Heh. You do realize that you are posting anonymously?
—
Also, regarding OBOS, I see 2 fundamental mistakes (of which the 2nd will be their undoing):
1. They are going for this “binary compatibility” which is probably turning off many experienced devs (and thus they aren’t interested in joining the project). My guess is that an experience kernel/OS developer does not want to spend their time making sure every old app on bebits runs on their new creation.
2. They chose the wrong license. Although I think the MIT license is great for apps, or something you want distributed as widely as possible, it’s a poor choice for a desktop OS. Using the GPL would attract many more OS devs and allow use of already-available GPL’d OS code.
Even if OBOS were successful with the MIT, there’s nothing stopping some company from coming along, downloading the code, making their own “enhancements”, closing the code, patenting said enhancements, and then suing OBOS’ers at some point down the road for patent infringement.
This is particularly important for a project like OBOS which will have mass-market appeal. Corporations are cutthroat and will do anything legal (and sometimes things illegal) to make a buck. A successful OS project needs to protect itself.
You mean BeOS had a fixed-position-size GUI layout engine?
That was really a bad idea. It really, really sucks from a uability POV. At least for any non-english-speaker, it means you have to redo all the dialog layouts for each translation.
Madness! Primitive!
As for Binary Compatibility, I suggest you look at this (http://open-beos.sourceforge.net/nsl.php?mode=display&id=11#34)
Also, I disagree with you about the license, I believe that the license is perfect! First off, OpenBeOS will always be free, no company will really be able to compete with that, two, how can they patent something OBOS created? I mean, we don’t exactly have that problem with BSD, which is nearly the exact same license (save for that little quibble with ATT a few years back, which turned out to be their fault.)
Plus, the MIT license will attract companies who want to make drivers, and also commercial application development for OBOS.
They chose the wrong license. Although I think the MIT license is great for apps, or something you want distributed as widely as possible, it’s a poor choice for a desktop OS. Using the GPL would attract many more OS devs and allow use of already-available GPL’d OS code.
Seeing the difference between Linux and BSD today, we can definitely say Linux has attracted media attention and a huge amount of zealotry…. I’m pretty convinced OBOS wants to be spared from this no offense. BSD’s has been very successful and even today are gaining more and more developers and leading the serverplatform amoung the OSS options.
the MIT license will prove to be a very wise license in the long run. I’m still a bit scared about what will happen with Linux when media won’t keep it as their pet anymore and the zealotry becomes “uncool”….
I wish OBOS the best of luck and hope to use it someday…
Michael mentioned WinBE. What’s that?
Is it like using Windows NT as the base but getting rid of Explorer sort of like Litestep, instead having BE like kits.
Actually I would love the OpenBeos kits to be ported to windows. Then I would know all my hardware works.
If I’m not mistaken, it was a windows emulation layer for BeOS. Kind of like wine.
And what you just described is pretty impossible.
“how can they patent something OBOS created”
easy, I don’t think you need to prove YOU thounght it up. Just get to the patent office first. I heard MS has patents on the linux kernel.
And look at how much of a rut linux is in now, man they sure have suffered!
That’s not the point, the thing is that they could, at anytime,cause massive problems for linux.
wing wrote:
As for Binary Compatibility, I suggest you look at this (http://open-beos.sourceforge.net/nsl.php?mode=display&id=11#34)
And I hope it is just “3 easy steps”. But, you know what they say: the difference between theory and practice is much bigger in practice than in theory.
First off, OpenBeOS will always be free, no company will really be able to compete with that, two, how can they patent something OBOS created?
They won’t. Like I said, they can simply add some patentable technology to their fork and then patent *that*. Then, all of a sudden, everyone wants to use this new fork. Maybe later, the OBOS’ers (with their significantly dimiminished user base) add features to their original code that resembles the patented additions to the fork. This is when the sh*t starts to hit the fan.
I mean, we don’t exactly have that problem with BSD, which is nearly the exact same license
That’s because BSD is a server OS and doesn’t have the mass-market appeal that OBOS (a *desktop* OS) will have. Just wait till the right (wrong?) folks start to see dollar signs in their eyes.
Plus, the MIT license will attract companies who want to make drivers, and also commercial application development for OBOS.
I think that’s debatable.
Then Anonymous (cm-upc.chello.se) wrote:
the MIT license will prove to be a very wise license in the long run.
Why? To avoid GNU/Linux zealotry (as you’d referred to)? I’m not sure that the zealots are doing Linux any harm.
Zealotry aside, there’s a reason Microsoft hates the GPL so much. If GNU/Linux was all MIT licensed, do you think it would still be around? How many lawyers does MS have working on ways to eliminate GNU/Linux as competition?
And I hope it is just “3 easy steps”. But, you know what they say: the difference between theory and practice is much bigger in practice than in theory.
Okay, even though it’s been proven in practice (by the OBOS folks.) Have you done any research?
“Actually I would love the OpenBeos kits to be ported to windows. Then I would know all my hardware works.”
“And what you just described is pretty impossible.”
Really ?
http://alpha.luc.ac.be/~ef00/
http://burton666.neoni.net/TextViewShot.jpg
I thought he meant something like porting the underlying architecture (the servers, etc.) to Windows or something, which I don’t think is possible. I could have been wrong.
Hey Jack
long time no see 
“..Linux and GNOME/KDE as well as Mac OS X have become seriously impressive, and are getting better all the time. Longhorn looks to push a few boundaries itself in 2006.
Is there really any place for BeOS in 2003?”
Well let me tell it like this:
As long you really nead MM performance and you can’t afford SGI Machines ;-), there _will_ be a reason to push BeOS/Zeta or both.
I tried to work around with different apps, different Hardware on different platforms (x86 and PPC and Gx/OS X).
If you really looking for a performant MM OS, there is simply nothing better – unless you pay _way_ more.
– Capturing [DV & TV]
– Ripping [DVD & mp3/OGG]
– Editing Video & Audio
– Internet Radio Stations ( http://www.tunetrackersystems.com/ )
I think if the Audience just take a brief look that it is a shame how new OS’ses just bloat their OS to urge the user to buy steadily new more performant Hardware, wether they can afford it or not.
Even Apple is nearly at the end of the road in HW Ways. The G5 is a terminal attempt to get some %-ages in the big PC market back (hope they will).
But all of this is not _really_ needed: Keep your OS thin and clean and remind that MM Apps=low latencies in the OS.
If you sum it up, there is only one new OS which fit all these rules: BeOS/OBOS/Zeta.
That simple.
I think, the Devs have to review their Platform choice. It would be like a snowball effect: if some key Applications and Hardware Support is initialized (Zeta pushes that in a fantastic way), it’s up to the Devs which fight on and on on Wintendo Lunix or Applet, try to patch this or that or wait for even more performant hardware to be distributed.
There is no need for all that.
If you want to do MM Stuff, you have to revise all your opinions once you saw BeOS/Zeta…
We need more experient Coders and non-coward companies which step into a solution in which their software and or driver makes the most sense!
…
You mean BeOS had a fixed-position-size GUI layout engine?
Yes, just like MacOS X. I can’t understand how Apple could do that to the “most advanced OS”.
Yes, just like MacOS X. I can’t understand how Apple could do that to the “most advanced OS”.
I don’t know about OSX but there’s third party layout engines for BeOS, and I assume that there are for OSX as well. Though, I agree, it should be needed.
Enjoyed reading this interview. Thanks for posting it.
I definitely plan to use OBOS as it becomes available.
BTW if you have to “hijack” this OBOS thread to tell me how great some other OS is . . .
I enjoyed this interview; thanks for posting it.
About Michael’s guess as to when a beta of R1 will be available… hey, what’s wrong with a little cautionary positive thinking? Sure it could be delayed much beyond that guessed date, but that’s why he called it a guess and why he said things change with the wind in open source development.
Positive thoughts! 🙂