Re:Cathedrals, Bazaars, and in Between
by padraic7a on Monday January 05, 2015 @10:57AM
(#8839400)
A welll thought out piece rom someone who promotes open source software and is the guy behind 'software carpentry', an initiative to teach researchers [mosly scientists] basic software skills.
I like the way he pointso out problems with both the cathedral and bazaar models but identifies that "actually matters is the people who build them.".
My favouite line: "One king, one law" can sometimes be a great force for good, but what you usually get is collectivized agriculture and UML.
Re:Cathedrals, Bazaars, and in Between
by TheOtherHobbes on Monday January 05, 2015 @12:30PM
(#8839916)
The bazaar seems to have permanent and crippling ADHD and seems mostly dedicated to reinventing wheels. (There are exceptions, but maybe not as many as we'd all like.)
The cathedral is a centralised bureaucratic black hole.
This is another example where O'Reilly's attempts at social engineering have gone horribly wrong. Neither model is ideal, and both are somewhat wrong.
I'm surprised how little computer science is about project psychology, and how little effort has gone into defining the dynamics of successful and innovative developer teams.
There are a few heuristics that seem to work reliably - use a small number of the smartest people you can find, get them to peer review the design before anyone starts coding, and continue peer review as they work - but almost nothing (at least not much I've been able to find) about how to make innovative magic happen reliably.
Point is books like the C & B are story-telling designed to pander to a certain audience, not empirically tested science.
More of the latter and less of the former might do some useful things.
Re:Cathedrals, Bazaars, and in Between
by ethbro on Monday January 05, 2015 @12:38PM
(#8839962)
>The bazaar seems to have permanent and crippling ADHD and seems mostly dedicated to reinventing wheels.
ADHD at the strategic level, but hyper-focus at the tactical level. Because when you're a professional developer (as I'd imagine the majority of people writing non-core open source packages are) why doesn't "reimplementing {wheel} in {new language/framework/architecture}" sound more interesting than "bug fixes".
Re:Cathedrals, Bazaars, and in Between
by craigyk on Monday January 05, 2015 @03:03PM
(#8840781)
Nothing wrong with creating rounder wheels; especially for training.
I was at a conference where a panel of scientists were discussing how they manage research in their labs, and how to promote better productivity from their students with a focus on high-throughput methods. At this point, a single scientist on the panel interrupted with "we shouldn't focus on training for these intellectually bankrupt approaches, I'm interested in training scientists who can think."
When I was first learning to code I was completely overzealous with performance optimization and I implemented every single data structure and algorithm myself, from scratch. This included a lot of computer vision, and optimization and fitting code, and studying books like Numerical Algorithms, etc. While not efficient, I sure did learn a lot.
Re:Cathedrals, Bazaars, and in Between
by dalke on Monday January 05, 2015 @04:35PM
(#8841346)
"a single scientist on the panel interrupted ..."
The response from the other panelist wasn't going to be the correct one, which is "Duh! Not helpful!"
Is that scientist making the claim based on evidence, or based on personal belief? If so, what is the evidence?
Do we train everyone to think the same way? Do we train them to think about problems in specific areas? Do we train them to think about historical problems? Would improved knowledge of the literature help identify unexplored paths, and keep students from revisiting old, well-trodden paths, or should some old things be left mostly unvisited?
Re:Cathedrals, Bazaars, and in Between
by theoh on Monday January 05, 2015 @08:40PM
(#8842465)
"A Thousand Plateaus" by Deleuze and Guattari is a great example of success in the field of organisational metaphors, or an egregious bit of unscientific storytelling, depending on how you look at it. In particular their ideas of smooth and striated space map onto bazaar and cathedral to some degree.
Re:Cathedrals, Bazaars, and in Between
by btilly on Monday January 05, 2015 @03:21PM
(#8840886)
In economics there is a theory about why companies are the size they are. In a nutshell, it comes down to, "The point at which the internal stupidity of a large organization exceeds transaction costs between independent ones." This has all sorts of interesting consequences. For example the existence of widely understood standards reduces transaction costs which favors small organizations. The demands of designing a large new integrated system favors large organizations that can exert centralized control.
In software design, the commodity at question is not money but both forms of cost still exist and trade off with each other. For example compare iOS and Android. The centralized control from Apple did allow them to build something new and complex, and to get a better user experience. But once the interfaces are understood and standardized, Android is able to generate something reasonably good, albeit with a lot less consistency and more duplication of effort.
Re:Cathedrals, Bazaars, and in Between
by dgreensp on Monday January 05, 2015 @02:01PM
(#8840454)
I'd sure like more cathedrals in my life as an engineer. Whether we can build them is just a measure of our imagination, inspiration, wisdom, and ability to work together on a grand, well-conceived plan.
Re:Cathedrals, Bazaars, and in Between
by cpeterso on Monday January 05, 2015 @02:34PM
(#8840617)
Are giant open-source projects like Chrome, Firefox, or FreeBSD cathedrals? Unlike bazaar poster child Linux, these projects mostly control their own roadmap and releases, without many competing distributions.
Re:Cathedrals, Bazaars, and in Between
by DominikD on Tuesday January 06, 2015 @05:22AM
(#8843673)
Linux the ecosystem is bazaar, sure, but Linux the kernel is cathedral with Linus at the helm. Arguably this is what makes Linux kernel so successful and so widely re-purposed yet most distros lacking in getting any traction. There's, again, a clear exception in Ubuntu which is a cathedral amongst bazaars.
So at the end of the day I personally feel that bazaar is the best set of training wheels invented but quality ultimately gravitates towards cathedrals. Both parties do benefit a lot from each other, so mutually benefiting, implicit agreement is at play here, which is something "A Generation Lost in the Bazaar" piece fails to acknowledge.
I like the way he pointso out problems with both the cathedral and bazaar models but identifies that "actually matters is the people who build them.".
My favouite line: "One king, one law" can sometimes be a great force for good, but what you usually get is collectivized agriculture and UML.
The cathedral is a centralised bureaucratic black hole.
This is another example where O'Reilly's attempts at social engineering have gone horribly wrong. Neither model is ideal, and both are somewhat wrong.
I'm surprised how little computer science is about project psychology, and how little effort has gone into defining the dynamics of successful and innovative developer teams.
There are a few heuristics that seem to work reliably - use a small number of the smartest people you can find, get them to peer review the design before anyone starts coding, and continue peer review as they work - but almost nothing (at least not much I've been able to find) about how to make innovative magic happen reliably.
Point is books like the C & B are story-telling designed to pander to a certain audience, not empirically tested science.
More of the latter and less of the former might do some useful things.
ADHD at the strategic level, but hyper-focus at the tactical level. Because when you're a professional developer (as I'd imagine the majority of people writing non-core open source packages are) why doesn't "reimplementing {wheel} in {new language/framework/architecture}" sound more interesting than "bug fixes".
Nobody likes fixing someone else's bugs.
I was at a conference where a panel of scientists were discussing how they manage research in their labs, and how to promote better productivity from their students with a focus on high-throughput methods. At this point, a single scientist on the panel interrupted with "we shouldn't focus on training for these intellectually bankrupt approaches, I'm interested in training scientists who can think."
When I was first learning to code I was completely overzealous with performance optimization and I implemented every single data structure and algorithm myself, from scratch. This included a lot of computer vision, and optimization and fitting code, and studying books like Numerical Algorithms, etc. While not efficient, I sure did learn a lot.
The response from the other panelist wasn't going to be the correct one, which is "Duh! Not helpful!"
Is that scientist making the claim based on evidence, or based on personal belief? If so, what is the evidence?
Do we train everyone to think the same way? Do we train them to think about problems in specific areas? Do we train them to think about historical problems? Would improved knowledge of the literature help identify unexplored paths, and keep students from revisiting old, well-trodden paths, or should some old things be left mostly unvisited?
In software design, the commodity at question is not money but both forms of cost still exist and trade off with each other. For example compare iOS and Android. The centralized control from Apple did allow them to build something new and complex, and to get a better user experience. But once the interfaces are understood and standardized, Android is able to generate something reasonably good, albeit with a lot less consistency and more duplication of effort.
So at the end of the day I personally feel that bazaar is the best set of training wheels invented but quality ultimately gravitates towards cathedrals. Both parties do benefit a lot from each other, so mutually benefiting, implicit agreement is at play here, which is something "A Generation Lost in the Bazaar" piece fails to acknowledge.