FreeBSD grinds on one until it definitively works.
And what happens if it never works?
And what happens if it never works?
libkse was an attempt to implement M:N thread scheduling. This is something that can, in theory, provide significant benefits over 1:1 thread scheduling, but in practice, is extremely complicated to implement and has fallen out of favor across the board: Solaris abandoned the approach in Solaris 9, and FreeBSD abandoned it in (IIRC) FreeBSD 7.
Concurrent to libkse, libthr was developed by David Xu, and was also included in the FreeBSD base system. It implemented 1:1 threading, is far simpler than libkse, and has replaced libkse as the default threading library.
I would argue that in this case, FreeBSD's cathedral model failed; M:N threading ideally would have never been attempted, and it was wasteful to attempt to implement two distinct threading libraries. However, considerable thought and expertise went into the work, and the work (and decisions around it) were not made flippantly or taken lightly.
It was simple a case where despite best intentions and best effort, the wrong choice was made. At the same time, in what some might call "bazaar-like", David Xu maintained libthr as an alternative. It remained there, ready for adoption as the default threading library, until such time as it became apparent that M:N via libkse was a dead-end.
This was a mistake, but no entity is perfect, and the success rate of FreeBSD's considered decision-making remains statistically high. In this case where something never worked, it was replaced with something equally well-considered and far more successful.
Moreover, compared to Linux's gross missteps with their threading implementations (including such gems as setuid() being thread-local as an implementation side-effect), libkse was a minor fender-bender.
There seems to be some underlying assumptions of omniperfection hung of the "cathedral" meme in these parts. That is simply unfounded in both theory and practice.
Second, cathedral vs. bazaar is not really about governance, but about architecture, and they are two separate power-structures, although most organizations, including FreeBSD, mingle them, to their own disadvantage.
We can argue if attempting M:N was a wise or a factually based decision, but that has nothing to do with cathedral vs. bazaar, certainly not in this particular case: What happened was that M:N came first and that was that.
Only once it clearly transpired that it could not sustain its promises in practice (partly because every thread programmer assumed 1:1) did the actual decision making aparatus of FreeBSD kick into gear.
In Linux, (which is much more cathedral than FreeBSD) or OpenBSD (at the time even more so), that decision would probably have been executed practically instantly, but in FreeBSD which is mostly consensus driven, it took some time (and angry words etc.)
But overall the libkse vs. libthr saga has almost nothing to do with cathedral vs. bazaar, because architecture was not the driving force at any time during that saga.
That said, given your response, I think perhaps still don't understand the meaning behind your cathedral/bazaar dichotomy.
Indeed, throughout this discussion it has become clear that you regard anything with a sense of design and some amount of quality control as a "Cathedral". If you want to discuss the benefits of design and quality control, that's a perfectly fine discussion to have, but it also seems to be completely orthogonal to the original discussion of cathedrals and bazaars, which was wholly focused on the development process.
In fact, I wonder if your arguments would be better focused on the concept of "craftsmanship" (or lack thereof) in programming...keeping in mind, of course, that both cathedral builders and bazaar artisans have historically had a notion of craftsmanship.
I think it is plausible to describe the kernel as much more Cathedral-like, at least in parts where Linus is very strict about how components should be integrated. I can see where parent could have got this impression.
At the same time, there are parts of kernel that are bazaars. Virtualization/Hypervisor support is the area I'm most familiar with; the various hypervisor vendors basically crammed their paravirt calls and passthrough drivers in, without unifying the interface at all. Yes, Linus and others were very aggressive with maintaining the code quality, but less with the architecture. There are other areas of kernel (particular drivers), where we've seen similar situations.
While it's been years since I mucked about in Linux kernel space, I always remember it as being a very open and egalitarian community. Although I never made the attempt to contribute to any of the BSDs, I got the impression that they were much less open to newer contributors and divergences from "accepted wisdom" (this could be put more politely as being more discriminating (as in taste) and careful). That being said, the majority of decisions I was witness to on LKML appeared to be well-considered, and make no mistake that patches and design ideas were not just accepted willy-nilly. While Linux has stumbled across many missteps, I still personally prefer the wild possibilities and endless choices that eventually shake out a solution, at the same time keeping with a distribution (Debian stable) that filters out the issues for the end users (myself included).
I also find very interesting the parallels between this discussion and the "worse is better" essay, where UNIX was supposed to be in the "worse" camp, and now it's Linux.
It definitely is, in my experience. Most importantly, despite the obvious presence of "celebrities," even completely unknown people can jump into the middle of a conversation on an important topic, and if they have their shit together, will be accorded pretty much instant respect and be treated as an equal. There's very little sense of "needing to pay one's dues."
But you definitely have to have your shit together. If you don't, you will be quickly eviscerated.
It's really rather nice, especially compared to many dev communities where there's often much more sense of entrenched factions.