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 !
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.