Daniel Reinhold announced last week that he was leaving the OpenBeOS kernel team. The announcement came as a shock to many: not only had Daniel been involved with OpenBeOS since its earliest days but was one of its more vocal supporters. Having been a member, a team leader, no less, of OpenBeOS and having followed the same path, albeit under vastly differing circumstances, I can well imagine how hard it was for Daniel to make the decision. By Daniel’s own admission, his involvement with the kernel code has been minimal, so his leaving will not create any problems there, but the fact that someone who was so intimately involved with the project for so long has left cannot be seen as an indicator of a healthy project. Whilst looking for material regarding Daniel’s departure, Google pointed me at one particularly interesting page - an archive of the kernel developers mailing list thread triggered by Daniels email (http://sourceforge.net/mailarchive/forum.php?thread_id=2675146&forum_id=671). Reading through the archive I was shocked by the replies - not so much the words, but the tone and underlying sentiment communicated to what was, after all, the loss of a long standing member of a small team.

There can be no doubt that managing any software related project is an undertaking of enormous proportions, and one that requires a special range of abilities possessed of precious few. When the project is open source there are additional problems that must be overcome, making the job at the same time more demanding and less rewarding. Whilst involved with OpenBeOS I talked to Michael Phipps over the phone at regular intervals (though sadly never got round to actually travelling to meet him). His decision to start OpenBeOS was a brave one, one that ignited a resurgence of positive feeling within the BeOS community and provided a project for people to rally behind. After calling for volunteers the 99:1 rule (1% of people expressing an interest will actually contribute) asserted itself. Not only did this take Michael by surprise but it also produced a situation where there was very little productivity for a project that appeared to boast such large numbers of developers.

The approach taken to organising the project reflected the way that BeOS was organised; a number of teams each with its own task. This seemed logical at the time as it allowed a parallel approach to the development with teams proceeding at their own, differing paces. While the pool of volunteers was large it appeared to be working well, every team appeared to be overflowing with energetic and willing members, but reality soon emerged. There were few people who were able to work on the code, many who were willing to test and even more who simply contributed criticism of ideas and complained at the lack of progress. Some teams floundered with barely a line of code, while a rare few pressed on at break neck speed (BFS being the prime example). Overall the projects mixed results showed few bright spots resulting in an overall impression of a project going nowhere are starting to stagnate.

While it’s easy to sit back and assign all the blame to those who were leading OpenBeOS, and they do have a large share of the blame, inevitably some of the blame must be shouldered by the community. Fledgling projects need room to grow and develop, room that the BeOS community has so far denied OpenBeOS. While there are several projects in existence aiming to fill the void left by BeOS, none attract the same attention or blind faith as OpenBeOS. Unrealistic expectations can destroy a project as quickly as a lack of volunteers; OpenBeOS has faced both problems since its inception. A perfect example was the creation of the Glass Elevator mailing list, seen by some as a place to develop ideas for future releases (of an operating system not even in existence), it was viewed by the majority (and project leaders) as a way of removing large amounts of noise from the main project lists. Although the Glass Elevator mailing list was successful in reducing the noise levels, its creation did result in a partial split within the community at a very early stage of the project and increased the attention being focussed on every action taken by OpenBeOS.

A simple fact that few people seem to grasp is that ultimately managing an open source project has little to do with coding ability! As with all forms of management success is measured by how well goals are met; the primary goal for a software project being to create an environment in which people can be productive while keeping them focussed on moving the project towards its end point. Most of the coders I know will happily code for 18 hours a day provided with such an environment - and food and drink of course! While in a physical office such an environment is normally concerned with physical items (desks, chairs, and soda machines), in the open source world where people are distributed around the world and are working for free, ephemeral matters such as respect and peer reward become the priority. Managing this type of environment, where the objectives cannot be directly assessed or measured, is harder than it seems. Often your only feedback, as the person in charge, is negative and the first sign of trouble is people leaving. This is an area in which OpenBeOS has never excelled, primarily due to the team leaders it has chosen, as illustrated only too well by the comments made in the email thread at the start of this editorial. (Please note that I’m not commenting on their abilities as coders here, just their abilities to manage/lead a team within OpenBeOS). This lack of a healthy development environment, coupled with the amount of attention focussed on OpenBeOS, has made it a project with little to offer newcomers. I have a great deal of respect for Michael but know from phone conversations that given the chance to replay history he would do many things differently thanks to the gift of hindsight, mainly in the area of management of the project.

If you’re expecting to find me propose some grandiose solution for OpenBeOS at this point then you may be sadly disappointed. I left that project quite some time ago - returning is not something I would ever consider. Following my departure from OpenBeOS I was approached by Frans van Nispen to join the group developing what would become the Sequel project. I was initially nervous of becoming involved with another project along similar lines to OpenBeOS, but the way that it would be setup was very different and closer to what I had become used to in other projects. I’ve been involved with Sequel ever since and it’s with a degree of trepidation that I’ve recently agreed to become Sequel’s spokesperson (trying to fill the shoes once filled by Frans won’t be an easy task). With Sequel I’ve been a vocal lobbyist to avoid the issues I saw in OpenBeOS and to date have been pleased with the results - a team of people who work very well together!