BeGroovy reports that David Reid, a very respected BeOS third party developer (ported Apache among others) and ex-OpenBeOS networking developer published a statement explaining his departure from the OpenBeOS project. David cited lack of direction, management in the project and even lack of engineering knowledge among the OpenBeOS developers. Update: Another important BeOS dev and friend of mine (as also in the case of David :), Frans van Nispen cited similar problems with the project. UPDATE 2: The OpenBeOS leader, Michael Phipps, sent us in his response to the issue.Our Take: Unfortunately, my sources agree with David’s opinions. The project doesn’t go as fast as it should have, and while at one point it had more than 100 developers signed up, only a handful actually dive into the code, and from them, only a few know what they are doing. Developing an OS is not like developing a (yet another) image viewer (BeOS users I am sure will ‘get’ the joke. 🙂
Michael Phipps’ response:
In response to this recent unpleasentness
I would like to start by thanking a number of people. Eugenia and Nutcase for being responsible journalists. Axel and others that have posted. And David and Frans for their time, their opinion and their code.
I want to start with David’s case, because I am more familiar with it. He brings up a number of interesting points, some of which he and I had discussed and some which I am not so sure that we discussed. I would like to consider David a friend. We have spoken numerous times, at great length on the telephone. His knowledge of POSIX and kernel things is vast. He is a really good guy. Sometimes, when I am reading things that he has written, I can hear his voice in my head. He contributed a mountain of work to OpenBeOS, including the Networking port from BSD. He will always be well thought of for that work.
The first issue that David brings up is interpersonal skills. This is a difficult topic – it is hard to nail down exactly what these are and how to deal with them. Who judges who has these skills? How do you deal with people who don’t have these skills? Should you tell them? Should you tell everyone else to avoid them? How, as a leader do you deal with people with poor interaction skills? Especially in a volunteer organization, when you depend on the good will of others? Carefully. That has to be the first answer. Being too lenient (letting people abuse others) is not a good solution. But neither is shutting down frank and honest communication. There has to be a reasonable middle ground here. I thought (and think) that we were at a pretty decent level with this. Not one that everyone will agree to. But a pretty decent level. In the particular case that David is bringing up, here, someone believed that they found a bug in David’s code. They “fixed” the bug and checked that co!
de in. I am not about to debate the technical merits of the change. It really doesn’t matter. What does matter is that the developer in question thought that he was helping David. I saw (and see) that as a good thing. David saw it as impolite and incourteous. That is his right. But I will always encourage my team members to help each other and to fix bugs. If the fix turns out to be wrong, well, in CVS it is the work of seconds to revert to a previous revision.
The second issue that David brought up is broken confidences. I absolutely agree with him on this. What happened was wrong. And I have dealt with it, in private and internally, where it belongs. One case of airing private things can not be fixed with airing another.
David’s next points are about organization. Teams, team leaders and crossing team boundries. I would like to draw an analogy or a parallel, here. If Linus told Miguel de Icaza that he couldn’t contribute to Linux because he is a Gnome guy, the whole OSS community would turn on him like rabid dogs. I want developers to work on what makes them happy. That is really what OpenBeOS (and all OSS) is about. If they want to work on something other than their “assignment”, well, so be it. I certainly won’t stop people who want to donate good code. Whether it be in the area that I think that they should work or not. As far as the organization of teams versus other possible organizations, well, to be honest, I don’t see any other. Neither do any other OSS projects that I have looked at. BSD and Linux both seem to do it. Maybe it is a bad idea. And if so, maybe we will all realize it someday. But until someone suggests something better, I will stick with what seems to work for OBOS and !
everyone else.
David’s comments on the Kernel Team strike home, since I am the Kernel Team lead. There are some facts that make some of David’s observations make more sense, though, that I think that you should know. Yes, the kernel is enormous and it has not attracted enough experienced folks. I would love to have another 20 experienced people. Rewriting the VM system from scratch was not something taken on for fun, or because it is interesting, though, as David implies. It was taken on for good reason – the NewOS VM system has subtle bugs (according to Geist) and it doesn’t have an integrated filesystem cache. Furthermore, VM design is hard and there is *NO* documentation for the design in NewOS. None. While I have made some forays into it, I am still not sure that anyone other than Travis really understands it. And to try to add major features to a piece of code that you don’t fully grasp, is not documented and has subtle bugs is not a trivial task. Neither is writing your own VM. So, g!
iven the choice, I chose what I thought was the lesser of two evils. I have learned a whole lot about VMs and how to build them. I know the code intimately and when it is done, I think that it will be a quality piece of code. As far as a sense of direction, I do not understand this comment at all. I don’t know what sort of a sense of direction people need. There are major pieces of the kernel that haven’t been looked at, yet. Anyone can go and do that. I don’t believe that developers need someone to hold their hand and say “OK – you go work on fork today”. A self motivated developer can find something to work on on their own and go and do it. Really. Lots of them do it every day. David certainly did. And I thank him for it.
To finish up with David’s comments, a lot of this is growing pains. I will freely admit that I have never managed an OSS project before. There are not very many people in the world that have successfully managed a project the size of ours. Linus hadn’t when he started. We are growing and learning. We have changed our focus from working as a design team to a more traditional model of accepting patches. That seems to be a success so far. The fact of the matter is that we need more people who are willing to take the ball and run. To use another Linux example – Alan Cox just started submitting patches to things that he thought were broken in Linux. Eventually, he ended up being in charge of many and various things. I need people who are willing to go and do. Who are willing to take the bull by the horns and get things done. David was and is one of those people. I very much regret him leaving the project. I have very fond memories of working with him. And he has an open invitatio!
n to return.
As for Frans’ case, there is a lot less that I can say. When we started, we were not doing *ANY* kernel development, other than drivers. The reason for this was simple – Travis and co were doing a lot of work on NewOS and replicating that work did not make any sense at all. He (and they) had a design, a goal, a plan and a lot more momentum than we did. We worked on some drivers, studied the code, made some small contributions here and there and generally tried to get ready. I don’t remember telling anyone that the team was “full”. If I did so, it was a mistake. Very simple. A mistake. I make those. I know that I did tell a lot of people that we weren’t doing a lot at the moment. Now that we are forked from NewOS and following our own code path, there is a lot of work to be done. Was not forking the day we started OBOS a bad idea? I don’t know. In retrospect, maybe. Maybe not. I don’t know how things might have gone. I know that I made the best decision that I knew how to at !
that point. Based on conversations with Geist and looking at the situation.
As far as credit for Frans’ work disappearing from source control, we are looking into this. If this is indeed the case, it will be restored immediately. This has happened before, often innocently, and when it was brought up to us, that credit was restored. If anyone out there has had this happen, please let the team lead and myself know.
Frans, I am very sorry that these things happened. If there is some way that we can work this out, email me.
Everyone seems to have a different expectation of OpenBeOS. Many people expect us to replace Be. They write to me about marketing, sales, QA, etc. They write to me about how we shouldn’t overlook the PPC market, or how we should have used the Linux kernel or how great it is that we are not GPL. Everyone has a take on what OBOS should be. That is fine and good. I am glad that people are interested. Everyone needs to be aware, though, that no matter what we are, someone will not be happy. Some people would have us more regimented in our approach to things. Other people would not be interested if that were the case. Only when there is a clear and compelling one sided arguement for changing things should we do so.
Everyone, too, please remember that while we are putting a professional face on this, we are volunteers. Every minute of time on this is unpaid volunteer work. Our time is given freely. We work the way we are most comfortable with toward the ends that we choose. If you are not comfortable with the way that we work, you may certainly suggest changes which we will carefully consider. You may work in your own way and submit patches and changes without really being part of the group. Or you may choose to go elsewhere. We are doing the best we can, and giving it away as a gift.
That is really unfortunate. BeOS has/had some of the most exciting technology innovated, most in part because of this man.
How’s BlueEyedOS coming along? I’m not sure about the name, but it was something with Blue..
I think they are almost as equally a long way off from delivering something that works as OpenBeOS is. Cosmoe too.
Syllable (http://syllable.sf.net) is closer though. I mean, the thing works and it works pretty well (sure, lots of work still needed).
Port the already written OpenBFS on it, port OpenTracker/Deskbar on top of it, change its API to support the BeOS API calls (by borrowing some of the Cosmoe changes), and here you go.
You will have something that _works_ in 1/10 of the time.
His statement reflects the feeling I’ve had about the project since it began. The impression the project gives is one of being loosely organised. Maybe they should think about opening a public relations team along with the programming teams.
I mean, sure, the NewOS kernel _is better_ than Syllable’s and it has more clean code (Travis has made an excellent job there!), but what matters in the OpenBeOS case is not to create an OS just to learn how to write one (as it happens in other hobby OSes), but it is a project to fill the missing BeOS from the BeOS users.
I believe thata modified Syllable/atheOS/Cosmoe + some newOS code inside, would create something that works, it will be delivered _fast_ to the users. Even if it won’t have any binary compatibility. Source compatibility is the one to look for.
that was exactly the same reason I departed from the media-team (wallpapers, sounds, themes, ui-design etc). They had absolutely no direction. I will admit this was quite a while ago, so things might have changed. However, hearing things like this makes it easier for me to justify my decision.
Well, I was thinking that OBOS was doing much better than this though now it begins to make sense why in most of the areas, they haven’t made much progress.
Hopefully David’s statement will help to fix these problems.
I had a feeling that BeOS was going to die like this. Right when OpenBeOS was announced you could tell it was just thrown together. I thnink if no other projects like BlueEyedOS, and others were made then I think that OpenBeOS would have had more focus. What needs to happen is take any donation they can get and put it into management and start working on promotion. The easiest way to promote BeOS is do as follow. Take a big list of BeOS people that you trust, give them 20 copies of BeOS Professional in the box, and 50 copies of BeOS Personal bootable CD-R disk. Have some management team setup something with MicroCenter, or CompUSA or some other really big computer store where the first friday of every month BeOS people can have a small area. I’m sure they wouldn’t mind, if you take up 5 feet of there space. Next you bring your computer with you, or laptop with BeOS on it. You show people the system, ask questions, etc. Next you offer them a ‘free BeOS cd’ but that you take donations, you have to figure they will at least give you a dollar, maybe 5 or more which the cd’s shouldn’t cost but 20-30 cents per cd if you buy them in bulk. Next you give free tech support there, the first friday of the month. They know you will be in there, and you can help them with anything which will always help show others just how easy BeOS is. Even though you won’t be making much money you will be doing the best thing of all, promoting BeOS. As well as that you can have OpenBeOS sells items, such as posters, t-shirts, mugs, and others which will go straight to the OpenBeOS funds which hopefully will get management. Look at NextStep clones, they should have had that done but GNUstep is not even close to it, Amigia clones… they used to be a lot of them but none seemed to be done, even Windows clones they all died too. I hope that is a big lesson for OpenBeOS.
>The easiest way to promote BeOS is do as follow
What the freaking are you talking about?
BeOS does not run on most new hardware and as time goes by, new stambling blocks are unveiled because the OS hasn’t been updated for 2.5 years now. You can’t market the BeOS 5 PRO to _anyone_ today. The OS was made to run up to PIIIs. It was never tested for anything above that. THIS IS WHY projects like OBOS and BLueEyedOS were created.
Because without the source code BeOS 5 (which _cannot_ and will not be open sourced) you can’t pinch it to anyone anymore. Please get your facts together, I don’t want to mod down your comment for… un-information.
What’s happening with Leonardo? Does anybody know? What stage have they reached?
http://www.intuiware.com/leonardo/
They are also working on reviving BeOS.
Also another one, Zeta/yellowTab. I haven’t seen any info on OSNews about these two Leonardo and yellowTab. What’s happening with these two companies/organizations and their BeOS OS?
YellowTab will be a distro of one of the OSBEOS projects.
Leonardo is supposed to be the same goal of OBOS, but different people and different code.
Time to move on people. Beos is dead and none of these other projects are going to be able to resurrect it. And no handing out cd’s of an old OS at compusa isn’t going help. Using niche OS’s is fun and should be encouraged, but by the time a “compatible” beos 5 OS is made it will be years from now. So great in 2005 you’ll be able to finally recreate a OS from the late 1990’s, whoopdeedoo.
Trust me 2.5 years from now OSX or Linux or even Longhorn is going to seem a hell of alot better than some OS which had fast OpenGL, weak networking, poor driver support, and little to no ISV and OEM support. By then if not way sooner whatever kernel’s these other OS’s run will far outperform the extremely limited areas in which BEOS used to have an advantage.
I think this counts as a success for Opensource. In a normal company, a lot of programmers would just be sick of the project and waste a lot of cash while the project lumbered towards completion.
I understand that BeOS fans are disappointed though. It’s easy to see why companies like Microsoft aren’t going away anytime soon, because of their culture which supports programming.
2.5 years is nothing if you look at how long the Amiga Community has stuck with their platform. They platform has been dead (pretty much) for the last 10 years, and only know, they are reviving it.
AmigaOS is a commercial platform, OBOS or other projects are open soruce and far more likly to sucseed! There are so many BeOS equivalents out now, all most all of them will survive.
BeOS ant dead, yet! give it another 7.5 more years
Where’s the other side of the story Eugenia?
IMO its just trash journalism in its present form.
OBOS was up front about David’s departure at the time it happened . . . and they thanked him for his contributions.
Well, we can all “express concern” for a living; what good does that do? Look, not everybody is going to be happy. Its not possible.
And something that may have been fun the first time or two can lose its appeal. It happens. You get to have a life.
Stop comparing the leaders of OBOS to perfection. Why not compare them to other leaders . . . starting with the compensation they get and how hard they work.
I cannot think of a more challenging task than to work closely together on a large software project . . . because the nature of the work forces tight concensus on so many little details. In most lines of work you have some slack where you can wave your hands and say “you know what I mean” . . . but software is unforgiving that way.
Also I say rubbish to the general claim that current BeOS doesn’t run on modern hardware a view repeated over and over here which I personally know to be false. But that’s another story.
I’ve heard tell that the Linux kernel can run really quickly when patches appropriately…and with the crazy-fast processors we have these days, it might (might!) be fast enough.
The thing that makes Linux a lousy desktop operating system is…okay, there are lots of reasons. Arguably, XWindows is a contributing factor…everything that makes it a great server tool makes it a lousy desktop tool (generalization, I know, but bear with me).
Here it comes, the big oversimplification from a non-programmer: Since the UI elements (tracker, deskbar) are already open source, could those elements somehow be rewritten to work on top of Linux so that Desktop Linux will benefit, while all these OSBEOS things get worked out?
I don’t mean this in the way one of the OSBEOS projects (I forget which one) is already merging the BeOS API and UI elements with Linux kernel and drivers…I mean, use Tracker and Deskbar to make a better GUI for Linux outright?
(let the flames begin)
In response to:
“Also I say rubbish to the general claim that current BeOS doesn’t run on modern hardware a view repeated over and over here which I personally know to be false. But that’s another story.”
Some folks have been very nice trying to help me in this one, but the fact remains that BeOS doesn’t like my (modern, but not cutting edge) Soyo Dragon motherboard components.
There’s no supported driver for the onboard LAN, so I use an old 3COM card. The audio driver for the onboard C-Media audio works beautifully, unless I use the Savage video driver for my Savage DVI card…in which case, the system locks when the media server starts. If I use my CRT-DVI NVidia card, I can get a DVI output, but it won’t sync no matter what I do to app_server_settings.
Meanwhile, Linux distros that couldn’t recognize my motherboard components and video cards a year ago now work beautifully with everything — the latest Gentoo Live CD even knows my flawed Gateway FPD1500 monitor/NVidia CRT-DVI card needs really bizarre settings to work out of the box, something no other distros could do until this week.
Linux folks continue to add driver support and improve things. BeOS has people working to recreate things as they were over a year ago. This is the good and right thing for them to do, but as long as that’s the primary focus, running on a broad selection of modern hardware will remain a secondary — and little acted-upon — goal.
Respectfully,
-D
>Where’s the other side of the story Eugenia?
Well, if anoyone from the OpenBeOS project would like to email us or post here, we will be delighted to update the story and post their opinions on the matter.
All I did here was to link an already existed story on begroovy and add what I have already heard as well from _many_ others.
>Also I say rubbish to the general claim that current BeOS doesn’t run on modern hardware
Most of the new hardware does not support BeOS correctly. Either the CPU won’t work, either the video card, either the modem or the sound card. BeOS ain’t good enough anymore to FULLY support the new PCs. This is a fact, it is not a “claim”.
<running on a broad selection of modern hardware will remain a secondary — and little acted-upon — goal. >
Correct.
I know you’re right from many similar first hand experiences.
My thinking for a long time is we have no chance to win at this “ala carte menu” game . . . so I started looking for a different strategy where we could win.
The best immediate opportunity IMO presented itself in the new highly integrated socket 478 Intel 845 motherboards. They run BeOS with Pentium Celerons and also P4’s. So I chose several (3 totally different product form factors) and went to work.
These opportunities were not available to Be, Inc. say 2 years ago . . . and the cost / performance was so much different.
I am staying with BeOS. I see firsthand it has a better “present” than it ever had . . . but it is thanks to the open source work, most definitely including prior work by David Reid, and also by the ongoing work of the entire OBOS team that is has a future.
In fact a dramatic event which just happened . . . nVidia and Intel both joining ATI in publishing graphic driver specs (perhaps the single toughest driver area) would never have happened without these open source efforts.
BTW, if that onboard LAN was on an integrated mobo I cared about I would move heaven and earth to get it running (or more precisely beg someone competent to help me out).
I would be happy to share info about the BeOS systems I have running now. Just email me at [email protected] . Decide for yourself if this is a time to be crying or smiling:-)
The nice thing about this is that this is an open source project. Its okay if it occasionally wanders around directionless once in awhile, as long as at least once person keeps at it. And I’m guessing there will always be at least one person fighting to keep OpenBeOS alive. Look at GNUStep or the Hurd. They’re still trudging along. It would be nice if it were finished more quickly, but at least there is hope that the project will at some point be finished.
<Most of the new hardware does not support BeOS correctly. Either the CPU won’t work, either the video card, either the modem or the sound card. BeOS ain’t good enough anymore to FULLY support the new PCs. This is a fact, it is not a “claim”.>
Maybe we agree the vast sea of hardware, past and present, unsupported by BeOS . . . is increasingly irrelevant.
Systems keep getting smaller, more powerful, and far more highly integrated. Its cheaper to buy a new one than to fix the old one. Its cheaper to buy a new one that to replace a part on an old one. And each year the product is pitched more like a fashion industry as well.
Hey, I am not saying I like the new Gateway Profile 4 vs. Apple iMac ads . . . just it reminds me its now a fashion industry.
I switched my objective to being competitive in 3 different desktop system form factors using highly integrated Intel Socket 478 motherboards. (Those many of you who strongly prefer AMD over Intel just stopped listening, but honestly I am agnostic on that topic. That is not the point.) Thanks to everyone who helped me I’m feeling quite good about the results.
I have no interest in supporting every motherboard out there as long as they are no better than the ones I do support . . . and I am dealing at the system level not the component level.
Look at the number of devices (i.e. chipsets) on a highly integrated motherboard. Look at how small that board can be. Price it out compared to how we did this in the “old days” (2 years ago).
IMO further consolidation seems probable. Far fewer drivers will cover a higher percentage of the hardware and far higher percentage of devices are providing specs due to open source trend. IMO Be has moved from hopeless “ala carte menu” situation to far better opportunity today than ever before.
No, it’s not bad journalism – it’s just a bit offensive
Note, I am also contributing to OpenBeOS, and I don’t agree with much David had to say – I’ve put a longer comment at http://news.begroovy.com/comments/367 though.
And keep in mind, we are an Open-Source project – we don’t pay anyone, we don’t have to get anything done, etc.
We just *want* to get something done; of course it might have been faster to take the linux kernel and work from that one (BTW why always the linux kernel, what about all those nice BSDs??). But we are stupid; we are spending our precious time with developing an alternative operating system, how could you take us serious?
And keep in mind that none of our (future) users should see any need in recompiling the kernel; we want to have a fast, modern and very modular kernel, and I really think that NewOS was a good choice, even if others ways would have been faster.
Remember, we are doing this for personal entertainment. And of course, like almost any OSS project out there, we can still use many dedicated developers 🙂
Overall, the open letter is a good thing – David pointed the problem that in Open Source development everybody wants to be a developer and nobody wants to be a manager.
OpenBeOS project is very small and it’s sad to see people leaving but implying stricter rules will not help too much.
I’m really impressed with cool and clear tone David posted his opinion, as weel as very grateful comments about his depature from OpenBeOS team.
Comparing to bitterness of original exchanges on the mail list it seems like a sign of healthy project.
Yes, stuff happens, good coders left, more coders gets disapointed.
There are few things of course, to get the project improved – manage CVS repository better is one of them, e.g. granting rights to main tree only to leaders. Perforce has published a good read in Dr.Dobbs Journal about how good coders could be poor code mainteners.
Meanwhile, NewOS is striding alone. kernel, VM, framebuffer.
And it looks like Trey helping Travis a lot now. Hey, a couple extra ex-Be bodies and we may get something really usable soon.
You are forgetting the fact that even though BeOS is 2.5 years old like you said most users are still using hardware and an OS just as old. The fact is the average user still has a 333 megahertz computer with 64 megaram. That was the most sold computer and the most sold OS is still Windows 98. So you can still give out copies to people for awariness, it doesn’t mean it will work on there computer, it could work on there computer since most people have older hardware anyways. Geeks keep foregetting the term ‘most users’ or the ‘average’ user. You keep screaming at the fact that BeOS doesn’t work on your Dual Athon and 200 gig hard drive that you spent 5 grand on. The fact is you don’t have to get everyone to try BeOS, in anyway, you only need to spread awarness. They don’t even have to take a free copy they just have to see it in action and the term BeOS and OpenBeOS in thier head. If they ‘upgraded’ which some how you assume everyone has, then they still should have that old 333 sitting around. So don’t tell me you can’t promote BeOS and talk about it at CompUSA, and MicroCenter when the people that go there is still using Windows 98. Geeks wont’ be sitting there listening to someone talk for a hour about BeOS in the first place, they would be smart enough to already know what it is.
I totally agree with you and have thought about this a lot
ever since tracker and deskbar where open sourced…
i think it would be sweet to be able to run that gui on top
of Linux…that would ROCK!
but….
i heard it’s next to impossible due to it having an enourmous
amount of calls to the beos kernel or something and would
be too difficult to port to the linux kernel?
(maybe someone else can elaborate on this…)
on top of that to make it worthwhile you would have to make
the window manager compatible with kde/gnome so that you
could have some sort of integration with existing
applications…(again, someone else would have to elaborate
more on this one as well)
oh…and no X isn’t that bad with the correct drivers…like
somebody stated in a previous article here if you want
performance look at some of the commercial X servers which
work a lot better then xfree86
Hi! (Iam not involved in this project)
But as a SystemAnalyst I think the project need to be rebuilt.
If you are a teamlead for let say FileSystem(Bruno) then stay and give 1000% to you team and to your area. Some people are are writing more code for the kernel then they do for its own team. (just an idea).
And try to keep the team status pages updated, I saw that the BMenu wasnt implemented, so I was thinking of doing it, so I started to ask Questions in the OBOS channel on IRC, then someone told me (that he was working on it).. hey what is that, why dont they update the page if someone is working on it. The TeamLead should should be the only one that could accept Patches, also he/she should be the only one that updates the status page (job, %done etc).
I really suggest that OBOS (teamleads and MPhipps have a longer talk, maybe evaluate a Heirarchy and a method (DSDM) how they should continue) Many people really put their faith in you guys/girls)
Laws:
“In any large system, complex system, 80% of the output is done by 20 %”
The law of requisite hierarchy:
“The weaker and more uncertain the regulatatory capability, the more hierarchy is needed in the organization of regulation and control to get the same result”
What Iam trying to say is that be harder to the teams, make rules, but remember to have fun!
Good luck!
/Konrad
BRUNO is just a fiction name!!
I just wanted ppl to adopt my thoughs eaiser =)
Sorry BRUNO (BGA)
/konrad
Everyone seems to love to mention that BeOS only works on old hardware. But I believe you are just as likely to get BeOS to work on most new systems as old systems. I’ve been running BeOS 5 on my new Dell 2ghz P4, 512MB RAM, 80 GB Hard Drive. I was almost sure that BeOS would not run on my new P4 system, since I had heard that BeOS doesn’t support modern hardware. To my amazement the system worked completely except for a CNet network card, which I switched out with a compatable NetGear card. Never did I think I’d be able to burn CD’s on a newer high-speed CD-Burner under BeOS, or watch DivX or DVD’s under BeOS, but I can do it all.
I have also installed BeOS 5 on numerous other computers running P4’s, without problems.
The problem with BeOS supporting hardware is often that people are too stupid or lazy to figure out that some 3rd party drivers need to be downloaded to get gear to work which was not compatable at the time 5.0 came out. Others don’t want to look into BeOS limitations, such as the 1GB RAM limitation; so they assume BeOS doesn’t work on their computers.
The argument that BeOS doesn’t support modern hardware isn’t a very valid statement. A better statement is that BeOS has a limited but expanding driver compatability. The point I am making is that if you were to try to install BeOS 5.0 on an older system (i.e. a PII 333Mhz, with 64MB)and a newer system (P4, with 512MB) you would have the same chances of successful hardware compataility. It may or may not like your motherboard chipset…you may or may not need to replace an unsupported PCI card.
BeOS seems to get more and more hardware and software support all the time. For instance on BeOS installs I did for friends, there was one partially supported video card and one unsupported sound card that have gotten support in the last couple months. Also my laptop sound chipset is now supported .
Geeks keep foregetting the term ‘most users’ or the ‘average’ user
…
So don’t tell me you can’t promote BeOS and talk about it at CompUSA, and MicroCenter when the people that go there is still using Windows 98
Curious, what are you going to promote? The fact that BeOS will not run on modern hardware? The fact that most hardware is not supported, or if it is, not fully. The fact that BeOS doesn’t support hardware accellerated 3D? The fact that there are thus no top-selling games on BeOS? The fact that it lacks a decent web browser? The fact that there are no mainstream commercial applications available for BeOS?
The fact that BeOS will not run their old Windows 98 programs at all? The fact that the company who created BeOS has effectively been out of business for almost 2 years, so there’s no hope of an update, ever. Etc. etc…?
But… it does play mp3’s! Woohoo!
Good luck!
-fooks
After reading this article I took a look at the OBOS website, and frankly I’m not surprised that there is confusion and wasted effort going on there, since there is a lack of communication.
Each team has a page which is supposed to say who is working on what and how far along they’ve got. But if you look at the MidiKit one for example it looks like absolutely nothing’s been done, no tasks planned, no tasks assigned, no tasks completed.
Then you look at the forum and you find that actually a fair bit of work is going on and some bits were submitted as far back as April! And elsewhere information is lacking.
It seems to me that communication is the key, when programmers are in the same room then this happens automatically, the more spread out become the more deliberate it has to be. I would suggest that maybe what the OBOS guys need to do is look for a “secretary” for each team, who’s job would be to keep communication and documentation up to date. Specifications and requirements need to be documented, progress needs to be checked up on, when things are submitted if the developer doesn’t actually say what they’ve done, what they’ve added, what’s missing, then someone needs to go back and ask them… and so on.
Once people really know what’s going on and what needs to be done, then they can optimise their efforts.
I personally would be the world’s worst person for this kind of thing, but I often see people posting on open source discussions saying “I wish I could help, but I’m not a programmer”… well maybe this way some could.
“The course of true love never did run smooth.” — The Bard
It’s great that as much got done as it did. All these alternative operating systems are like one giant fractal soup kitchen.
Eventually something edible comes out, but often times it is not deluxe food. It’s tough to run a soup kitchen on a next to nothing budget.
However, not to despair.
I predict the good ideas of BeOS will find a home on Linux.
#p
AROS went through a similar period of “all talk and nom action” before
the project finally settled down and started to produce code.
http://www.aros.org/background.html
If an Open BeOS project gets off the ground, it will still be several
years before it produces a usable OS. AROS is getting nearer to that
stage now, but there is still a lot to do.
I sometimes wonder whether time might not be better spent coding
application software.
It’s sad to see developers go. I do hope that they tried to solve the problems before leaving the project. As it seems several people have had the same experience maybe they could try to do a joined effort to fix the problem. ( If they arn’t frustrated already )
Sad to see you leave.
Just two more comments:
First, of course, not every team is doing as good as it could – if the Midi Kit page isn’t updated, that’s a problem, but it only affects that team, not necessarily the whole project (and remember: we don’t get paid doing this).
Second, if you want to contribute code, yes, you can’t always trust the team status page. Although a lot of effort is done to keep them up-to-date, it’s obvious that it’s not always the case.
So, if you want to do something contact the team leader, don’t let you shy away from any other person than the team leader. In the rare cases where you can’t access the team leader (well, such things are happening, sometimes people left for some time, sometimes they just download their mails automatically on another machine they forgot about [inside joke])), contact some other people, like Michael Phipps.
Don’t start to do something without any accord.
As a developer, I can say that the development is easy until 3-4 dev people involved. If you need more people, the problem starts to be management.
For the open source dev, I’m skeptical, these people doesn’t work for money so they need some stuff to enjoy, they are more politically involved, or like technology A or B. The problem is to make everybody happy…
For the proprietary software development it’s easier, just pay people enough (and make them happy if you can).
Perhaps I’m biased because I work for money 😮
About OBOS it’s sad that good people leaving the project, because I believe that OBOS is more an OS for the desktop than Linux. Who will make a bit of competition against MS to make MS more reasonable about their licenses?
I have the impression that the only reason for you to ramble about yet another BeOS replacement is to dilute the efforts of OpenBeOS, which you didn’t like from the very beginning. You were so damn sure it won’t achieve anything, it sure hurts your ego that they got off so well. And yet, they never got any support from you, only criticism.
Don’t hink your support for Syllable fools me: you were so damn sure that it’s impossible to re-create a BeOS replacement environment, you don’t change colors this quickly and say “hey, but Syllable is going to make it”. Sorry, I have a long memory. And as much as I could accept your dismissal of OpenBeOS, I really feel that your attempts to sabotage OpenBeOS are Despicable.
This is my impression. (As someone who reads all the ML’s but is currently too busy to actually partake in the project)
David seems an excellent coder, but his background apears to be in big more commerial projects such as apache.
This would seem to be Michael’s first open source project.
I think what one has to appreciate here, is no one is getting paid. It is my impression that David liked the stricter guidelines of the larger OSS projects, that would have less people getting in his way. While OBOS is mainly made up of first timers (in terms of large projects such as this) who lack the experience. What has been achieved is an amazing look at what they have learnt, but there is still a lot more to learn and achieve.
I don’t think this can be artificially speed up though, after all it is an unpaid project for fun, if you enforce stricter rules than the majority of devs will put up with then you will lose the majority of devs.
If these more experienced devs aren’t willing to slow down a little and let the project mature by itself, then OBOS is unfortunately better off without them.
Of course a little compassion and understanding the other way is needed too, but in the end the majority rules.
I believe OBOS does still have a lot of momentum.
I think the project is still maturing.
And in time it will be successful.
Everyone just needs to relax a little and have fun. We’re not out to save the world, just recreate a tinny OS that used to inspire some of us about the future of computing.
In the end I don’t think anyone is really to blame here, something’s just aren’t meant to be.
Just one thing: if a good coder doesn’t fit into a team, that’s a problem for the team. If people can’t work well together, they probably shouldn’t.
So even if a “good” coder leaves the team, that can be good for the team as a whole.
Of course, we also have places where we could use such people (the famous one-man projects), but on some teams, like the kernel, you have to be able to work with other people in a productive way.
First: don’t blame Eugenia – I really don’t have the impression that she tries sabotage us. In fact, (constructive) criticism is welcome. And every doubt that we get something done is okay – we’ll do it anyway. I had my own doubts before I joined the project.
Well, and another thing: you don’t have to trust that David is the only one with OSS experiences in our team – that is just plain wrong. He just is not able to differentiate between the roles he played in those projects in the past, and the one he would have to play with OpenBeOS.
In OpenBeOS, it’s not that he would submit small (or larger) patches to the core team (to get something to work on BeOS, or even fix some bugs). Those channels are well established and well working on projects like apache. In OpenBeOS, he was part of the core team, and he obviously couldn’t handle this well.
It’s really not that we are all unexperienced nice guys, and David was our only professional. Far from that.
Let me turn my attention to the OpenBeOS organizational problems. I am a big fan of OpenBeOS, and wanted to contribute right from the start. Not as a programmer but as a proejct or subproject manager. I was told they don’t need a project manager, just people who can code. Well, fsking A, they do need project managers!!!
Someone (or someones – plural) who will take charge of
– Team R&D efforts and milestones
– Code readiness
– checking the documentation
– checking the team websites
– making sure everybody has something to do
– making sure the best people are doing what they do best
There is one other function that OpenBeOS would benefit from, and that’s an engineering liaison, even a team of liaisons. In an opensource project, that would mean gold for the efforts of the developers! One thing I really liked about OpenBeOS’s mode of operation was the “shit or get off the pot” attitude. Well, an engineering liaison would help in that respect, too, but also in most of the project manager’s tasks listed above. Why is a team’s website not updated? Ask one of the liaisons to investigate. Why is this particular module not implemented yet, why is this class still wating for an owner? Again, send the liaison to contact people in that matter.
There is also a democratic yet hierarchic way to make all this work, and I have suggestions how to set up the hierarchy and the decision making, too – but you always have to remember what is the greatest enemy of such organizations: ego. Almost any project, no matter how shittily organized, can achieve a level of success, if people can control their ego suffeciently.
I wasn’t trying to imply he was the only ‘professional’ (sorry if you or others felt this was the case),
just that he was less willing to put up with the less experieced members. Which is a shame, but it is better to have one or two disgruntled devs than a whole team of them.
You can never satasfy everyone all the time, as a result things like this will happen, but maybe more can be put in place to minimise such occurances.
I don’t believe David is at fault, he has/had a philosphy of how it should be done, the majority disagreed, so he left just like almost anyone else would of in his position.
“First, of course, not every team is doing as good as it could – if the Midi Kit page isn’t updated, that’s a problem, but it only affects that team, not necessarily the whole project (and remember: we don’t get paid doing this).”
I picked on a major example, but I would say that from what I saw most of the team pages could do with some extra updating, including the comments associated with tasks. I haven’t checked every single task, but of the ones I looked at most had absolutely no comments, a few had one line such as “most functionality working”, and one was very informative (David Shipman’s comments on the System Audio Mixer).
I quite understand that programmers don’t want to be bothered with the “paperwork” side of things, we’re generally pretty bad at it when we’re paid to do it and our jobs might depend on it. When we’re volunteering then there is even less incentive.
That is why I suggested finding some people who are not programmers who want to get involved, and getting them to tackle that aspect of each team. With all the BEOS fans out there surely there must be 14 who have the neccessary temperament and the time to help with this side of things?
“Second, if you want to contribute code, yes, you can’t always trust the team status page. Although a lot of effort is done to keep them up-to-date, it’s obvious that it’s not always the case.”
But if we don’t know what’s working and what isn’t, then we don’t know if we can be of help. For example I’m presently working overtime doing 2 jobs right now, so I wouldn’t have time to get deeply involved, or indeed make any commitment. But since audio and video are specialties of mine then if I see that there is a problem with the mixer, then maybe when I’ve got some time free I might take a look at that code and see if I can help.
People in general like the chance to shine. Programmers are far less likely to contact the OBOS group and ask “Is there any way I might be able to help?” than they are to get in touch saying something like “I saw the spec on BXXXXXX, I’ve done something similar before and I reckon I can handle it”, especially when we’re talking about a volunteer project. Who wants to commit to something when they have no idea what is involved? But if they can see that a task is achievable in a couple of months of evenings and weekends, or they see that someone is having a problem in an area they have experience of, then maybe they can find the time.
Just to finish off, I want to say that overall I am very impressed with what the OBOS team have achieved to date. I am just trying to suggest ways in which the project administration could be improved so as to take full advantage of the skills and enthusiasm of all involved.
Geeks never have been good at self-organization.
They are all pretty much like anti-flowers.
They only open up when they are alone in the dark.
I hope they listen to your wisdom.
#p
Hey,
Say all y’all want about OBOS possibly being doomed. Don’t worry, it isn’t. They simply didn’t follow the original plan because of false optimism brought forth by the massive early onslaught of code, coders, and volunteers.
I am certain, that when we get a working BETA out of a near-complete OBOS skeleton, that we will see people like David Reid come back to help some more. Now, I know what the biggest problem is with the project, and it is actually that they are trying to tackle too much at once.
They should focus on replacing the kits one by one onto R5. No kernel consideration or app_server considerations yet. Do the BFS, do the add-ons for DriveSetup. Then move on the net_server and media kit, and debug_server, and input_server, and then the app_server, then by the time that is all done, you should have a near-complete library replacement set. Don’t worry about the API, don’t add, subtract, adjust, or even repair until it is time to do so.
The command line tools, IMO, don’t need to be replaced… they are GPL for the most part. For now, the preferences shouldn’t be replaced, unless it is needed to make the new kits work.
My qualifications for making this decision? You ask?
Simple:
I have developed and released three BeOS distros. Far superior than even the hopes and desires of OBOS team for R1. Which is understandable because they are rewriting every component. I just hacked the existing ones, and used various kits from various version of BeOS. Id did at most 10 lines of C/++ coding… ‘cuz I didn’t know C/++ at the time.
I am now a cool d00d in the folds of yellowTAB. Our product will be extremely professional, and will aide to breath even more life back into BeOS (it has its second wind), and should give OBOS a little break from people expecting them to rush, when they are trying to do what 50 extremely talented programmers took 5+ years to do!
OBOS will live. We have axeld, among others, who can handle the coding on certain kits or replacments until we have a slow migration toward OBOS. This is the only way it will ever work.. even if we had 50 talented non-Be programmers.
The only real way it would happen in 6 months from start date (complete OS) is if we got the ENTIRE Be team to do it for us.. which ain’t happening. Though it would certainly be helpful if we could get some ex-Be engineers who could, and would help the project.
Until then, I am trying to save up enough money to hire a kernel programmer to aide out for a few weeks or more… anyone want to start a fund?
–The loon
First it was “Does BeOS have a future?” now it is “Does OBOS have a future?” What’s next?
Hello everyone,
First: Full disclosure. I’m a member of the OpenBeOS Creative Design Team. I am a member of BeUnited.org. I’m also the “owner” of the BeWine project (yeah, remember that?).
I have to say that all is normal. Don’t get too upset about any one person’s comments, no matter how valuable they may be, individually. Leadership and volunteering often do not go together, just as coders are often bad designers (and designers suck at code, like me). The Creative Design Team had some of these same problems (some wanted to just make stuff, others wanted direction, disagreements arose) but the problems were addressed by Michael Phipps (because the issues were brought to him with articulated concerns) and I now feel the leadership and direction of our team makes sense (though I bet a few people would suggest that I have it backwards, again, there’s always different ways of looking at things).
OpenBeOS is a large project in its scale and scope (what it hopes to accomplish). It has accomplished much already if you consider all the negatives (no funding, no pay, no time, inexperience, lots to do). There are bound to be disagreements and dissent among contributers and members. I can hardly work in any professional environment for a month before I see dissent among the ranks. It’s natural and even more likely in a volunteer organization.
I empathize with David Reid’s complaints because I like to have structure, order and good management in my projects as well. I also have to agree that if he was not happy in the team, it is better for him to move on to a place where he is happy. Why should he force himself to work in a position that is frustrating?
My desire for order and information is why I volunteered to take over web management for BeWine. At the time, there was no updating being done to the web site. No way for the community to know what was happening. The truth was that not much was happening, but I tried to take the initiative to make it clear to the community what was not happening and why and what was needed to get things going again. The BeWine project is stalled, but there’s never been a lack of “knowing why.”
Oppositely, there is truth to what was said about ego. I have met a lot of opposition to order (in many environments) due to ego. Either the person trying to create order and structure has ego issues, or the people being structured have ego problems. Again, it’s natural. The trick is to be capable of making compromises. Either the organizer accepts reasonable amounts of disorder or he leaves. Either the members work together or nothing gets done.
Every team and project of grand design will have this. It does not mean gloom and doom. It does not mean the end of the project. That’s if there are still people dedicated to the original goal. In this case, that goal is to create the best operating system for regular folks (while still being powerful, technically advanced and intelligently designed).
I agree with all the comments about liasons and updates to team pages. These are good comments. However, it is anti-productive to blame anyone for the current state of things. There is so much to do that things will get ignored at times.
Now, if you are a person that can fulfill the objectives of liason or web/info manager(nag the developers as needed, collect the info, respond to community questions and publish info) than please contact Michael Phipps and explain what you would like to do and how you will accomplish it. Make the offer and stand by your convictions. But please do not volunteer to do this if you cannot follow-through. If you have poor communication skills (meaning, you’re bad at conveying and understanding meanings and do not take correction very well) or think there is the slightest chance you will not keep at it, let someone else with more interest take the role.
My point: OBOS is young and new and it is “your” project if you want it to be. There are, and will always be, issues relating to leadership and management. There’s no way to avoid them. However, there’s no reason to claim all is bad, attacking the project or its leaders.
OSS people are fond of replying to attacks against OSS software with “so fix it yourself or shut up.” I often find this offensive, but there is a small amount of logic to it sometimes. If you want to see the project go forward, do what you can. If it isn’t for you, then so be it but please don’t discourage others.
Any questions, comments, etc… feel free to contact me. Thanks for reading.
I think one of the mistakes the OBOS team made was choice of kernels. Newos is a fine kernel and will be a great kernel when its finished but its immature.
I would have gone with a BSD kernel. OBOS still could have used the MIT license and they would have gotten a kernel with tons of drivers, VM and gnu tools already there.
Why try to grow an apple with an orange seed? There are completely different design ideas involved throughout the concepts of these two products. The decision was made for reasons valid to the goal. Quicker? No. More appropriate to the goal? Yes. 🙂
I did it, didn’t I? I compared apples to oranges! NOOOOOOOOOOO!!
Seriously, at its base any BSD is just a kernel, like Newos, that is why I was in favor of it. But the choice has been made. I just OBOS rights their ship soon.
Reid wasn’t happy where he was, he left, the OBOS folks were pretty decent about this, and now, BANG, stabs em in the back with “constructive” critiscism. He was a great great programmer and all, but that has nothing to do with his social skills. One can code like a god and still be a low class backstabber when his time comes. I say it stinks. I hope the remaining OBOS programmers will turn this into something contructive. Axel Dorfler sure is taking it the good way, but once again, he’s always cool with everything, and he gets the job done. Every opensource project should have at least ten guys like him on their side. I still believe in the openbeos project, no matter what happens, there are still people working hard on it, and they have all my respect. End of story.
I am STILL waiting for PalmSource to announce the return of BeOS! Call me “David from A.I.” but I will wait for ever…
ciao
yc
These clone projects will always have slow progress compared to other, creative projects. Why? Because good developers like to create, not just imitate. That is why the most successfull open source projects are the ones that create something new and not just clone and rehash old solutions. OBOS is a good example of this.
Why would I as a developer want to do code for OBOS when what they are asking for is BeOS? I’ve already seen that, nothing new and it leaves no room for creativness and no reward. If they’d actually say that they where creating an operating in the spirit of BeOS then they might get some developers but just to clone it? That is stupid.
> I have the impression that the only reason for you to ramble about yet another BeOS replacement is to dilute the efforts of OpenBeOS, which you didn’t like from the very beginning.
Then, it is only your impression. I have nothing against OpenBeOS. I WISH IT WILL COME TRUE SOON.
MY problem is that by rewritting a whole OS from scratch (it took Be 10 years to bring BeOS to that state!) it is just a way too much of a big job, that will take way more time. And at this point, we need a replacement _fast_. This is exactly why I proposed Syllable, because it already works. It boots, it has a fully working app_server, it is posix compliant, it “kinda understands” BeOS (as they have similar architecture). In other words, by porting OT and OBFS plus the Cosmoe BeOS API enhancements, it would bring a “beOS-alike” system in NO TIME.
Please, all of you, get your facts straight before starting pointing your finger to me.
I have nothing against OBeOS. But speaking from the person I represent at OSNews (“the User”) and especially driven by the fact that we need something fast, to me, a Syllable fork with enhancment code from NewOS/Cosmoe and the open sourced BeOS code, it would bring us all closer to source compatibility with BeOS (forget binary for now – leave that for the future) and an environment that it is closely alike to our beloved BeOS.
I said all this last year as well, BEFORE the OpenBeOS started. Last year’s May, if you remember, I made an article on BeNews introducing AtheOS and wrote another one as well, titled “Will AtheOS be the Messiah for BeOS”? and everyone got upset. I knew back then that Be did not care about BeOS, but no one was listening… >:(
> First: don’t blame Eugenia – I really don’t have the impression that she tries sabotage us
Thank you Alexd.
I hope everything goes well on OpenBeOS indeed.
As I remember, OBOS shot out of the starting gate like a race horse. It appears to this casual observer that they have moved forward greatly over the past several months. So maybe they are in a “three steps forward, two steps back” mode right now. So what? In a big project where you often don’t know what you don’t know until you get there, this adjustmemnt will happen at least once. Why are so many ready to throw stones? It ain’t over til the fat lady leaves the sinking ship!
I cannot understand why everyone posting here is so negative?
Recreating an OS over the internet isn´t 1-2-3 and done. Off course
iits hard to corporate togheter, but hey, you´ve gotto learn!
The OBOS team done alot of incredible stuff latley, just look at OpenBFS
for example!
>>>>So don’t tell me you can’t promote BeOS and talk about it at CompUSA, and MicroCenter when the people that go there is still using Windows 98.
Like supermarkets, YOU have to pay CompUSA and MicroCenter some money for slotting fees (shelf space) and for presentation fees (for sales presentations and demos).
What do you think — that they would just let you put a demo booth on their premises without you paying them some cash up front.
I never said you are promoting BeOS and OpenBeOS for people to come in CompUSA and turn around and never use Windows 98 again. The fact is you just want to spark interest. I hate people like you that have the belief that some how people can change and know things with out someone sitting there and promoting it. Like Dr. Martin Luther King could have just sat in his apartment everyday and said well I’ll be free someday, I have a dream but no one wants to believe it. No you go in MicroCenter and show off BeOS and your goal is just one, awareness and that is it. Sure it doesn’t run on all hardware and someone that tries it out should know that, but you want them to leave having the name and the idea of BeOS in there head. You want someone that get excited to look at BeOS then go on online and read information then figures out what can they do to help, or what computer can they use to use BeOS, because they saw it and they just need to try it out. Mom, and Dad don’t need to try out BeOS but someone that has a little bit of geek in them might. Geeks want to sit in there little bed rooms with there computer, have BeOS and they don’t want anyone else to know about it because they are not special enough. Fine be that way. But I saw if you even want the word BeOS and OpenBeOS out there, and have people have an image in there head of something different then it’s an easy way to get computer people have it in there head. You can always let them know what MicroSoft has done, and others. The fact is you want people to have so much in there head when OpenBeOS comes out and maybe a vendor that sells OpenBeOS computers that someone actually wants to try it. Remember thousands of people go to those stores daily. Did I ever said you are trying to target everyone. NO. But if you just get lets say one person that came in just one store on the first friday of every month then you at least have 12 new users, and that is just one store. Now think about 100 different stores doing the same thing then thats 1200 new users and out of those maybe 30 of them are programmers or interested in programming, that helps OpenBeOS in ways it needed help. The fact is OpenBeOS will die and the user base will long be forgotten if you don’t get someone to join. So how do you suggest getting people to join? Sit in your dark room half naked with a bag of Dorietos on your lap?
William,
You are right ato say that raising awareness will help the project. The problem is, as sam tried to point out, that what you propose costs money which, in my opinion, could better spent in development (ie., of drivers, etc.).
That is, of course, if we had the money…
Koki
Sit in your dark room half naked with a bag of Dorietos
on your lap?
Works for me.
People, ask yourselves a question, how much can we do without money. How much? A whole lot I tell you. There’s already so much done that every single twit who said a year ago that it was impossible to recreate the OS has so far been proved wrong (remember when Be inc. was bought and everybody met on the forums and argued over this and that and that it was stupid to even try and blah blah bullshit bullshit). Well this much is done, and it ain’t stopping anytime soon. And I still believe it was better to try doing it than spend hours bitching on the forums. Of course it’s a HUGE task, and it’s hard to believe anybody will end up doing something usable. But software is as solid as dreams. When a lot of dreamers get to it, things just start to happen. Oh the process might seem sloppy and some of the developpers might leave but the heart of the whole thing lives on. And it stands strong. The corporate way is not the only way to create computer stuff, remember that..
No I dont think it will cost money, in fact it will make money to have displays at MicroCenter. Okay lets say I give out 100 free copies of BeOS Personal which I only ask for a donation. Lets say I only get 1 dollar for each CD, which I assume some people will give me more then that, but lets assume each person at least gave me 1 dollar. Then it cost me 20 cents to make the cd which would be 20 bucks to make 100 of them. I still made 80 dollars now even if I keep half of that for myself then I still give OpenBeOS 40 dollars it can use for whatever it wants.
Now lets say out of those 100, 50 people get it to work some what or at least take the time to install BeOS. Out of those lets say 25 actually use it or at least get it half way working. Out of those 10 get it to work and enjoy using it and out of that 5 like it so much they want a copy of BeOS Pro Edititon. Those 5 come back the next month, same time same place and pick up a copy of BeOS Pro 5 being sold for lets say 40 bucks, but we actually got it for 20. Then you get another 20 dollars right off the bat, and lets say out of that 2 of those want a copy of Gobe and we sell that for 40 but again bought it in bulk or at whole sell value for lets say 20. Then I made another 20. Even if you don’t sell any BeOS Pro cd’s you are still making money and awareness off of BeOS Personal even if they don’t install it. And maybe all stores will not let you come in and setup for free, but I”m sure a lot of big time computer stores wouldn’t mind as long as it is organized, and not taking up to much space. Actually it could help them bring in buisness, or buy hardware, or even older hardware, and so on. Even if you have to pay them lets say you made 80 for that day, then you just give them let say 50 then you still have 30 that you give back to the OpenBeOS team. I fail to see where you are losing money.
Rewriting the VM system from scratch was not something taken on for fun, or because it is interesting, though, as David implies. It was taken on for good reason – the NewOS VM system has subtle bugs (according to Geist) and it doesn’t have an integrated filesystem cache. Furthermore, VM design is hard and there is *NO* documentation for the design in NewOS. None
Doesn’t this then tell you that you might have made the wrong decision by going with NewOS? I don’t know, but for some reason I get the feeling that OBOS went with NewOS because it was written by an ex-BeOS engineer. I would love to know what the perceived advantage are that the OBOS kernel hackers find in the NewOS kernel, as opposed to another free kernel (think Linux, BSD)?!
Personally I would rethink the whole NewOS adoption. Hmm, come to think of it, NewOS would not even be an option if I had known that the VM was not integrated with the FS cache system.
To use another Linux example – Alan Cox just started submitting patches to things that he thought were broken in Linux. Eventually, he ended up being in charge of many and various things. I need people who are willing to go and do. Who are willing to take the bull by the horns and get things done.
Here’s a radical idea, adopt the Linux kernel and replace your NewOS fork with it! People like Alan Cox will indirectly work for you then. We all know that the world only has a few people like Alan Cox. Personally I see that as the only way OBOS will ever amount to anything (no offense to the kernel team hackers, but that’s just the way I feel).
hey write to me about how we shouldn’t overlook the PPC market, or how we should have used the Linux kernel…
Oops, got me there! 🙂
I guess there are quite a lot of folks who feel that adopting the Linux kernel might be the best choice, now.
-fooks
No I dont think it will cost money, in fact it will make money to have displays at MicroCenter. Okay lets say I give out 100 free copies of BeOS Personal which I only ask for a donation. Lets say I only get 1 dollar for each CD, which I assume some people will give me more then that, but lets assume each person at least gave me 1 dollar. Then it cost me 20 cents to make the cd which would be 20 bucks to make 100 of them. I still made 80 dollars now even if I keep half of that for myself then I still give OpenBeOS 40 dollars it can use for whatever it wants.
Here’s the deal:
Practic what you just preached i.e. go to Microcenter and give out 100 free copies of BeOS Personal Edition. Make sure that you get at least $100 in donations. You can keep $40 yourself, and donate the other $40 to OpenBeOS. I will match your $40 and double it, for a total of $80 in donations to OpenBEOS if you succeed in giving out 100 copies at Microcenter and collect at least $100 in donations (that should be $1 per person right?).
Good luck!
-fooks
I’ve deleted two posts in response to your idea here instead of submitting them, but COME ON !?!?!
The store looses money just letting you take up space they could devote to more profitable items. They loose money just having to talk to you (and later when they escort you out of the store
. They don’t sell old hardware. The hardware they do sell likely doesn’t run it. They aren’t going to coordinate with you to only sell hardware that will support it. In fact they already have an OS on them, in case you haven’t noticed how Windows got so popular. They don’t sell BeOS software. Why would they promote something that will cause them to loose future business in the form of Windows or Mac software sales?
Its bad enough being accosted by Mac Evangelists at the store. At least they have a good product with good support to back up their enthusiasm. Where is a user going to get support for BeOS? In fact where are you going to get all these copies of BeOS Pro? Go around to these stores and ask where they dumped their unsold stock when Be went under?
I’m all for dedicated people trying to keep what was good about BeOS alive by building an actually supportable chunk of software in the form of OpenBeOS, but be realistic! You would be doing a great disservice trying to sell people a dead, unsupported product whose only real chance for a future outside of the exotic OS tinkerer crowd is nowhere near a finished state.
I agree with some people saying that this is going to take a while, and its ok, because I’ll wait as long as I need to wait… its true that many expected that somehow OBOS would just appear from nowhere all nice and finished. Well, its not.
The OBOS team took the right path by cloning BeOS and not doing a BeOS-like system; this way general direction exists and the goal is there, in front of us. Even if you get bored at developing you leave it aside for a week or two, but then you remember that an open source working BeOS system is waiting for you if you put some work into it. Also, as far as driver support goes, the first couple of years are going to be rocky, but, eventually the driver base will build up.
Beginnings are always difficult – you have almost nothing to work with and you know that there is a lot of work ahead of you… The more time goes by though the sweeter it’s going to get. Slowly, we’ll get a working system and from then on beautiful things will start to happen… devs will start seeing all their improvements and changes in effect as opposed to working with and abstract system right now. Comparing to the present situation this will produce an enormous amount of development at all levels – from low level system to user space.
It’s an excellent idea to have non-coders do management jobs… It will give them a sense of being actively involved in development while being of enormous help to the actual coders. They could email team members on regular bases asking them about the current code they are working on, and then posting that info in a sort of status table present at each team web page.
We cannot compare this open source project to anything else done until now. We are not developing a stand alone kernel here nor are we doing some user space app. It’s a complete OS, from ground up, complete user and app environment, so organization is absolutely crucial. This is what is going to ruin us or make us glorious – and I’ll be damned if we fail.
Also, absolutely only team leaders should be allowed to write to the repository – all code should be sent to them, so that they can review it. Maybe, if someone has previous positive history within a particular team he could be granted write access, but that should bring certain responsibilities with it (must be informed on happenings as far as his area goes so no double development is going on).
As far as motivation is concerned we are doing this for the love of it. If someone feels like he is not enjoying it anymore he is free to leave. We’ll certainly be sad to see him go, but, hey, that’s life; in a couple of days I personally will wake up and forget all about it, sit in front of my comp, see the snow out my window, and continue working on BEOS.
About team member knowledge: you don’t talk about projects and the involved like that. If you don’t have anything good to say don’t say anything at all. Yes, many are learning about various areas while working on OBOS but that’s their business. Whatever he told the team members before he left was enough. By publicly stating his opinion he just brought unnecessary panic and questioning into the story. It’s ok though, this is just another problem and small crisis that we’ll overcome.
All the best to everyone here, relax and take it easy. If a little thing like this has shaken your faith in OBOS or BeOS in general ask yourself if this is where you want to be. I hope it is.
Ps. this is a long post for my taste
– we should talk less and do more
Ivan
The reason OBOS (I think) didn’t go with the Linux kernel was because that wanted a more commercially friendly license, which the GPL isn’t. They went with the NewOS kernel and the MIT license. I would have gone with a BSD kernel, therefore you could have used a BSD style license, got commercial development and tons and tons of drivers and other things from a proven, stable kernel.
Fooks asked some good questions, albeit in a sort of pointed way. 😉
I want to try to answer them.
Why NewOS? Well, I first saw NewOS, oh, I think that it was June of 2001. I was just looking around the internet and I happened upon it. I d/led the source and read through it. It was clear, concise and made sense. The algorithms were clean and good, it was easy to follow and I thought that it had a lot of things going for it.
When August rolled around, I remembered NewOS and took another look at it. It was much more advnaced than it had been and it looked like a good place to start.
NewOS’ VM has a lot of potential. And I am sure that at some point in time, Travis will do very good things with it. But we don’t have forever. And we need a good implementation now.
The VM not being everything that we want it to be is not enough reason to change kernels. The VM is a part, but not all of the kernel. No other kernel that I know has the sort of thread support that NewOS does. Threads are first class citizens, just like BeOS. They are implemented that way from the get go. Not as an add on idea. The kernel is small. Unlike *so* many kernels out there. There is no cruft, it is new and very BeOS like. I think that adapting some other kernel and trying to make it more BeOS like would be more work than finishing our current kernel. Really. Especially since, as Fooks points out, if we were using some other kernel (let’s say a BSD kernel), we would not want to change it too much, or the maintainers would never roll our changes in.
I still believe that NewOS’ kernel is the shortest road to get us to a first release that is BeOS like and will get us to where we want to go. If you don’t think so, give it a try. All of our source is in CVS. Download it and make it work in some other kernel. Let me know how it turns out.
What planet are you from, William? Slotting fees are normal business practices in all retail establishments — including web portals. In fact, US senate has a committee looking into it (including computer software retailing) right now.
QUOTE
Senator Kit Bond, whose Committee on Small Business held hearings on slotting fees last September, praised the Commission for having now “finally taken the bull by the horns” in its challenge to a widespread practice that has been “destroying small manufacturers and limiting consumer choice at grocery stores and many other types of retailers.” He also disclosed that his Committee has expanded its own probe in this area “into an even wider range of products, including books, COMPUTER SOFTWARE, compact discs, consumer electronics and fresh produce.”
END QUOTE
http://www.antitrustinstitute.org/recent/60.cfm
Slotting fees for web portals
http://www.business2.com/articles/mag/print/0,1643,12948,00.html
>>>>>Lets say I only get 1 dollar for each CD, which I assume some people will give me more then that, but lets assume each person at least gave me 1 dollar. Then it cost me 20 cents to make the cd which would be 20 bucks to make 100 of them. I still made 80 dollars now even if I keep half of that for myself then I still give OpenBeOS 40 dollars it can use for whatever it wants.
First you have to pay CompUSA or MicroCenter $500 for a booth in their store or a spot on their website.
And the saddest part of this is that you people are probably the same people who blamed Be’s VP (marketing) and VP (sales) as incompetent and for failing to put BeOS on the shelves in your local computer store. Well, Be didn’t have money to pay for the slotting fees, and didn’t have money to pay for demo booths in your local computer store.
At least for games, you need to pay CompUSA $25,000 – $30,000 to have one product on their shelf. It might not even stay long on the shelves for that price. That’s the numbers I heard in 1999. I don’t know if it has changed much since then.
Who agrees that he should be a politician? He seems to be a very good one.
Re: This isn’t a tangent, I swear
I was thinking the same thing in the unlikely event all the 3/4 OBOS projects fail. As much as I love BeOS & use it for my dev work, I could probably survive on W2K if only it wasn’t so MS, & if it had half the class (Fungsui ??) of BeOS & the Tracker, well atleast it has all the apps.
I was even thinking of doing a native PowerDesk Explorer replacement but totally BeOS themed but alas I have other projects to complete. When I saw the WinBe project I then thought of directly porting the OT project & asked the opinion of this from WinBe developer & OT mail list. Their response was much more positive than I would have thought, but there are a few issues to take care of & not all the Tracker features could be supported, but it is another fallback case & no more crazy than Cosmoe.
And as ELQ has said, the Syllable/BeAPI_mods+OT is another fast track I wouldn’t mind seeing , but there are only so many capable devs around, but certainly a good fallback. On one of the Syllable threads, I suggested this, but it seems clear the Syllable folks have their own course & it isn’t BeOS.
Anyway as for the article, this kind of thing is hardly surprising, I thank all the OBOS projects devs for their work.
Stay the course, ladies and gentlemen(beos community has the most vocal geekiest best looking awesome women in all the computer world! Mwah!)
Slow and easy finishes the race. Steady as she goes, full speed ahead.
We got some kick *ssieness that no one can stifle. We got people that can program supercomputers from start to operational.
Let’s get this party started! Right?
We have not yet begun to kick *ss. D*mn the competition!
…. “lack of engineering knowledge among the OpenBeOS developers.”….
Sorry, BeOS not quite good enough to replicate BGA, YNOP, MikeP, axeld, and many other talented, NO– GODLIKE coders. They tried a programmer replicant, and it just didn’t quite have madcap approach.
It’s not a lack of engineering knowledge, it’s a lack of quantity of quality coders in specific areas. Some types are hard to find.
I want a correction.
You are not going to get a correction, because if you had read the whole article, you will see what I actually write:
‘It it had more than 100 developers signed up, only a handful actually dive into the code, and from them, only a few know what they are doing.’
In other words, we are saying the same thing. That there are a few good coders, but these good coders are not many. The rest, they either don’t code, or they just don’t know what they are doing. I stand by it.
Threads are first class citizens, just like BeOS. They are implemented that way from the get go. Not as an add on idea.
http://kerneltrap.org/node.php?id=422
http://people.redhat.com/drepper/nptl-design.pdf
Surely this shows us that thread support is being taken very seriously in Linux. Now think about it some more, in future you will have to do something similar for OBOS if you want to be competetive! And that’s not all. You will need things like:
o USB (2.0) stack
o Firewire stack
o (Pro) Audio support
o Graphics hardware support
If I look at the amount of engineering power that goes into these things on other Open Source platforms I’d say you have one hell of a task ahead. And the bad thing is that you’ll have to reinvent all this because none of these thing currently exist under a MIT style license (none that you can easily adopt that is).
-fooks
…but is almost an year that i say this.
Open Source is great but without coordination *any* project will fail…
We’re trying to help developers building specific (free) web-tools: if you could contribute, do not hesitate to contact me or browse our forum:
http://more.at/osportal
Thanks !
A BSD kernel would work with the MIT license and you still get all thopse nifty built in things, but they’ve made their choice.
Hi,
I’m still wondering if the NewOS kernel was a good choice though, i’ve read than the thread-support of BeOS bring difficulties to code bigs applications, so i think than a modified BSD kernel would be better; even though it won’t be R5 compatible, we’ll get many others advantages..
Anyway, i’am not a developer and i thanks anyone who spend efforts and time to make a BeOS’s successor.
Linux kernel is trying to mimic UNIX kernel
*BSD is UNIX kernel.
BeOS is not UNIX, never was and never meant to be.
Try to compile Linux kernel and make it less than 1Mb.
I mean kernel itself not bzImage which is compressed kernel.
It’s Mega not micro kernel.
I’m not so much into FreeBSD – I installed it only couple dozen times, but for what I know it’s not a small kernel either. Compare it to NewOS kernel.
Sure, VM in FreeBSD is nice, but VM in Solaris is better -and this is what Travis is targeting. Picking the best.
Remember that the goal of OBOS is re-creating the OS and not making some kind of BeOS emulator to run Gobe productive, OpenTracker and other apps.
NewOS with it’s immaturity has latency times which Linux kernel is only now approaching with super-duper patches.
NewOS has devfs built in from design not introduced as a patch. What release of FreeBSD has devfs ?
If your complain is about driver support then you better switch to Windows. No other system will ever have better driver support than Microsoft’s one (as far as I can see).
I mean kernel itself not bzImage which is compressed kernel.It’s Mega not micro kernel.
Apparantly you don’t know what a micro kernel is. Hint: it has NOTHING to do with size! There are micro kernels that weight in at a couple of megabytes! Yes, I’m comparing usable kernels. And even worse, the BeOS kernel is not a micro kernel! It is a hybrid with both monolithic/microkernel features. Linux is a monolithic kernel with loadable modules support, which is really sweet since you get modularity without the speed penalty, not to mention the mess, typically associated with (true) microkernel designs. I had to do some course coding on a true microkernel os, MINIX, and it was quite horrible!
(this was Anrdrew Tanenbaum’s class). FreeBSD is similar.
NewOS with it’s immaturity has latency times
Too bad it doesn’t support any (pro) soundcards, unlike Linux. And by the time it does, Linux will be 2 steps further (both in latency and hardware support). Sad no?
-fooks
What the fsck is that? Did I just fall in a 10-year long coma and just now woke up? Well, at least by the end of 2002 Linux didn’t support any pro soundcard that I know of. Worse, even, it didn’t support MIDI on any soundcard at all, putting it well behind such lowly OSs as BeOS. Worse, it didn’t support any internal synth, nor did it support loading of soundfonts in the card’s internal memory. Nada. Good to know those dark times are over ;o) I still remember those morons trolling about timidity, when I was asking how to access the internal synths of some Creative cards. “well…. but you have timidity”.
I’d like to very much thank Michael Phipps for his thorough response to David’s open letter. The OBOS members (and all Beers actually) can consider themselves blessed by having such a well spoken, polite and patient leader!
WRT status on team pages, there has been much improvement since every team lead is able to quickly bring it up to date directly. I’m not sure this is the perfect area for non programmers to offer their help. By the time the team has successfully explained what they are working on and where the problems lie, they could have written it on the webpage themselves…
But there _are_ other areas to help. Look into the FAQ: http://open-beos.sourceforge.net/faq.php#project
What the fsck is that? Did I just fall in a 10-year long coma and just now woke up?
Either that, or you’re just ill informed. One example:
Go to http://www.rme-audio.com
Lookup the RME Hammerfall series ($600 a piece BTW)
Get the driver at http://www.alsa-project.org, or simply install the latest 2.5 Linux kernel.
Finally, get your free multichannel hard disk recorder at
http://ardour.sourceforge.net
Back in 1995, before I got my BeBox, I wrote a module player for Linux that used my GUS MAX’s onboard wavetable synth to play al those cool S3M and XM files. The MIDI ports were also very well supported since I hooked them up to the BeBox MIDI-IN ports and fed the BeOS built-in synth from my GUS running Linux.
I’m not sure about Creative cards though, personally I think they’re all crap! Even the Audigy, which doesn’t do 24/96. It’s basically just a glorified game audiocard!
-fooks
WRT status on team pages, there has been much improvement since every team lead is able to quickly bring it up to date directly. I’m not sure this is the perfect area for non programmers to offer their help. By the time the team has successfully explained what they are working on and where the problems lie, they could have written it on the webpage themselves…
I totally agree! It’s the developers that write the juice of the technical documentation, everywhere in the world. Tech writers are there to provide the headers, the basic template, and to take care of the nitty-gritty of the publishing. This is an overhead that OpenBeOS can not have, i.e. they can’t afford to have “tech writers”. but they do have the need for
– project manager(s)
and project managers have need for
– engineering liaisons – because this is an opensource project, with distributed development and not 100% committed individual developers.
But I think I explained this really clearly in my original post.
I understand that at the moment there are teams headed by a technical lead. And I have the impression that Michael is a technical lead, too. There should also be a project manager overseeing the -whole- project, which means R&D, testing and documentation. And these three areas should have their subproject managers. And even though documentation is mostly done by the same people tha do R&D, it still needs steering, overseeing (uniform quality) and metrics.
Testing would need a subproject manager that would be in charge of overseeing the creation of test cases (yes, all teams should create test cases, that’s easy and very, very useful) and the organization of test implementation. That would make everybody’s life easier, included the betatesters. One day, the creation of performance tests will also come, we all hope.
R&D should have it’s own subprject manager that would greatly simplify Michael’s work. The tasks of this role I explained earlier.
As I did WRT liaisons.
And nota bene, all these people need not be programmers, at all. And yet, they would simplify the task of the developers and testers greatly and improve the project in many ways and values.
Anyone can compile here a list of features, in colums, from BeOS, NewOS and Linux features? For exemple:
BeOS NewOS Linux
– Type: Mono/Micro Micro Mono/Makro
– Latency: 2ms ….. ….
– Posix Layer: yes yes yes
Some candidate? (Could be you too, Eugenia!)
Thanks a lot!
Michael Vinícius de Oliveira
BlueEyedOS Webmaster
…so long as the end result is as close as possible to what users of current versions of BeOS enjoy. Maybe I’m crazy, but I like downloading driver packages that consist of: a zip file containing one folder, which in turn contains the driver binary, a symlink titled “drop driver here to install”, and a shell script titled “run me to re-start such-and-such service”. It doesn’t get any simpler than that.
Whether they accomplish that on NewOS, Linux, *BSD, or Crazy Joe’s Discount Kernel, I don’t give a shit – as long as it works. Pragmatism’s a wonderful thing.
Look, if you like the Linux kernel so much, check out Blue Eyed OS or Leonardo, or perhaps even Cosmoe.
I think OBOS’ decision to go with the NewOS kernel is a good one. The Linux kernel isn’t well designed to work with a BeOS-like system. The other projects that use Linux will have a hard time implementing some BeOS features in it. Also, they can’t make radical changes to the kernel, or else they would lose the advantages of using the Linux kernel, like driver-compatibility.
I don’t fault the other projects for using the Linux kernel–I think they will add to our knowledge of porting the BeOS API, and give it more cross-compatibility, but I see no reason why all the clones should be using the kernel, for the reasons I listed above.
The Linux kernel isn’t well designed to work with a BeOS-like system. The other projects that use Linux will have a hard time implementing some BeOS features in it
Like?
-fooks
I agree with OpenBeOS decision of choose NewOS. I agree with BlueEyedOS for choice of Linux, too. Each project, have, in yourself, the same goal. Ok, OpenBeOS want be so closed in BeOS R5. BlueEyedOS WANT source-compatibility, new features and several improvements (being having until 10x more linux performance!!!!)
NewOS is very nice! I love it!
Linux too!
BeOS, too much!
Come on! use your minds, guys! The community only want our beloved OS running and pulsing again!
Michael Vinícius de Oliveira
BlueEyedOS Webmaster
The Linux kernel isn’t well designed to work with a BeOS-like system. The other projects that use Linux will have a hard time implementing some BeOS features in it
Like?
Like multithreading and the BFS attributes. I’m not saying that they can’t do it, I am saying that they can’t do it without making some compromises in their design, and possibly breaking compatibility with Linux in general. If they break compatibility with Linux, then some of the reasons for using the Linux kernel, such as being able to use Linux drivers and software, will be lost, or at least compromised.
Again, I think that the API is the important point of reference across the projects. Being able to port the same API across different platforms and kernels is a good thing, but there are difficulties and compromises that have to be made. Using the Linux kernel involves its own difficulties and compromises, and is not necessarily a better or worse choice than using a BSD kernel, the NewOS kernel, or building a kernel from scratch.
So, like I said, if you don’t like the NewOS kernel, then fine. Work with the other projects, and leave OBOS alone.