Team Murder No Brain No Headache.


The Plan To Spread As Thinly As Possible Is Pretty Much An Awful Plan

I can't say that I was terribly surprised to hear the mostly woeful assessment of the direction and evolution of NetBSD and this is entirely apart from the running 'BSD is dying' gag replicated in some many forums and comment sections of tech sites. I've always wondered how the hell something like NetBSD with the goal of running on as many architectures and devices as (in)humanly possible could possibly be organized. I know that work on new stable versions of Debian is often impacted by its commitment to so many different chip architectures but those folks are generally drawing on a much larger pool of people who take QA work (especially for stable) pretty damned seriously and will draw and quarter loudmouths who don't even out their complaint-to-lines-of-working-code ratio by providing patches, albeit some of them incomplete or just plain wrong, in attempts to rectify the problem that vexes them.

The system of organization does seem like a disaster waiting to happen as it does afford far too much time in the limelight to those who complain the most and not nearly enough to those who fix broken shit. If you're not giving top priority to pounding showstopper bugs flat they you're definitely doing something wrong. Decentralizing the control of the project seems like a good first step as placing more responsibility in the hands of the people actually coding the project will relieve a good deal of the tension. Having the hands of those who don't have a clue about what they're doing meddling around in your code is incredibly frustrating and even more so when that meddling is done through organizational tomfoolery instead of line edits to bases of code.

Another thing that sounds worrisome to me (and I probably need to state right here for those who don't know me that I have very little insight into how NetBSD works organizationally other than the things on the mailing lists and other places that I've read over the past couple of days) is the dependence on bringing in features from the other BSD projects without solving essential problems in their own bases. If you're a NetBSD user then the lack of sane threading and/or journaling in the filesystems should scare the hell out of you. The other problem with these sort of infrastructure shortcomings is that it makes the existing base of code much less appealing for the purposes of forks and side projects. If it's internally that broken then for folks outside the specifics of the project it might be easier to build on something that does sanely implement the aforementioned features which seem less like features now and more like something essential that is all but taken for granted in other operating systems. Proper threading is hardly optional at this point.

I think his examination of the leadership question is also worth considering as he brings up good points about how Linux is organized. The idea of limiting the "locking" to really important parts of a given project like the kernel that all others more or less depend on (the Ur-dependency) to a dedicated and competent team of developers is great but it should ideally work in conjunction with a more loose structure for more loosely related applications and associated pieces of code. There is nothing revolutionary about this as most of the larger and more established Linux distributions already practice variations on this pretty logical theme. It is kind of amazing that a project could flounder and stagnate for so long with models like these on the rise all the time. All of that said, I really hope that people take heed of the warning as it would be sad to see one of the BSDs just disappear due to bad organization and lack of leadership. The real question I guess is whether something like NetBSD is sexy enough to attract new blood?

Comments (0) Trackbacks (0)

Sorry, the comment form is closed at this time.

Trackbacks are disabled.