Fri, 01 Sep 2006
The Future of NetBSD
There was an interesting thread in *BSD mailing lists, started by one of the founders of NetBSD. The thread is named The future of NetBSD, and the author states that NetBSD is losing its momentum because of the flaws in their development model (go read it now, I will wait :-).
A bit of personal history: my first UN*X on my own PC was 386BSD[?], version 0.1, then NetBSD 0.8, and for a short period also 0.9. I moved to Linux then, and never came back, altough I try to follow the news from all the *BSD projects.
In my opinion, the development model is the reason of success
of Linux. Not the enlightened leader (in terms of being superior software
designer and coder), not the support of big companies. Linus was always
open to the people who produced working code, provided that their work
did not try to rewrite everything from scratch, including few nearby
subsystems (Reiser4 :-), even though their code was not well suited for
all purposes. This is why current SATA/libata (ab)uses lots of SCSI
infrastructure, and this is why Linux has some things in /proc
and other things in /sys. But Linux has a working driver model
(including hotplug, device classes etc.), nicely coupled to the desktop
environment via HAL,
Linux has probably the best threads implementation from the free UN*Xes,
Linux had a NUMA-aware memory allocator before NetBSD even started to
implement large-grained SMP, etc.
In this sense, I can say that Linux development model follows the
Extreme programming[?] methodology:
the solution does not need to be perfect (nobody can design a perfect interface
suitable even for the hardware which is yet to be developed, for example),
but it should work and should not look obviously wrong. Using these
lightweight and not over-designed interfaces, Linux can avoid many pitfalls,
such as superfluous mid-layer (see libata or syncppp
parts of the Linux kernel for nice examples of how to avoid mid-layers,
and NetBSD DMA interface as an example of how to create them).
The openness does matter as well: the Linux kernel has patches flowing in at a rate of about 1000 changesets per week, and even though the interfaces probably gets rewritten more often than in NetBSD, they will match the actual needs of their users, not some hypothetical aestethical measures of their designers. I think the same loss of mommentum can happen also to OpenSolaris. They have a rigorous patch review process, which slows down the development. So far it seems that the main work is being done by Sun employees mostly.
I am not happy that NetBSD might be slowly dying, but I think the reasons of it are obvious: It is good to write a clean code, but it is definitely not good to let the emphasis on the design itself slow your development process down. Do not design for the future. The future will always be different, and the interfaces will have to be rewritten anyway. The closed and elitist attitude of the core developers also does not help.