I'll just say here that my particular psychosis when it comes to doing a project is, "if it's going to be done, it has to be done right." Even I recognize that this is not always the best path, but being able to enjoy the work is a major reason why I do it.
There are fifty things I would love to see in the kernel, including finishing off the SMP support and doing an AMD64 port. But many of those are things I would rather other developers do, particularly the SMP work for the network protocol stacks because its like 95% done already. They are important, but if I spend all my time there then we won't have a new filesystem at the end of the year. Having a new filesystem is a big ticket item for the project. In order to be able to work on the bits that are most important to my vision of the project I have to prioritize. Right now my priorities are: GPT support, a new filesystem, and the clustering goals. I am very big on supporting other developer's work. I'm there to help implement the supporting infrastructure and I am there to help finish off mostly completed work (such as NATA), and make it production-ready. I've just about handed SMP to people on a platter but so far no developers have taken up the baton on that one (and as I said, the filesystem is more important right now). Well, not everything works out the way one hopes. But I will remind the community that production stability is also extremely important to the project and there are certain pieces of infrastructure work, like SMP, that are very hard to do right and still have a stable system at the end of it (I think any FreeBSD developer can attest to that!). There's no point having a feature if the result is an unstable system. We have maintained most excellent stability in our releases and I think things can only get better as time passes. Consider for a moment that in one fell swoop just a short while ago (Feb-Mar), Simon and Thomas did an extremely major LWP commit that changed infrastructure in the kernel's handling of processes and signals and completed a MAJOR separation of the process structure. It went in so smoothly that there was nary a whimper on the lists. In fact, it went in so smoothly that I didn't even realize just how extensive the changes were until a few weeks later! Process/LWP separation was a major infrastructure requirement for being able to make all the related code MP safe. And maybe, just maybe, we now have two more developers who understand the kernel core well enough to do some SMP work (hint hint!) too. There is an excitement factor, too. Who'd-a-thought one could switch libthread_xu and libc_r on the fly? Now we can! In anycase, don't discount infrastructure work. Infrastructure work turns out to be a major enabling factor for future development AND for code longevity and stability. We've reaped many benefits from the approach that aren't readily apparent to an end-user because the psychosis that an end-user has is that the system 'not crash'... but we developers know that making a system 'not crash' is a lot harder then it seems. -Matt