Cathedrals, Bazaars, and in Between(third-bit.com)
third-bit.com
Cathedrals, Bazaars, and in Between
http://third-bit.com/2015/01/05/cathedrals-bazaars-and-in-between.html
4 comments
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.
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.
>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".
Nobody likes fixing someone else's bugs.
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.
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.
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.
"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?
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?
"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.
What has O'Reilly attempted in regards to social engineering?
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.
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.
On a side note, doesn't that mean a higher sales tax favors larger institutions?
that's one of the rationales between a Value Added Tax instead of a sales tax.
Right, that would follow.
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.
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.
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.
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'd say yes. Another Cathedral bazzar is Meteor. Open source, but with a relatively centralized organization.
Who can do Cathedrals, do Cathedrals. Otherwise, do Bazaars.
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.