This article concludes that quality only happens if someone takes responsibility for it. Yes. You'll find no argument on that point from me. But cathedral's are not (edit: should say "not only") about one person taking responsibility for quality. They are about a priori design.

Quality control can happen ex post facto but creativity, once strangled, dies.

It seems to me that quality is about having someone on the top who is willing to give direction and vision to a project, instead of having every person who scratches their own itch full influence. Contributors are great. But letting everyone pull in their own direction doesn't lead to something that feels well engineered.

PHK seems to be calling this vision and cohesive design (a-priori or not) the "cathedral model". I agree strongly that for a project to work well and feel "high quality", it needs some source of a unified idiom.

If the suggestion of the article is that the only way to retain quality is to move back to the "single vision" world of a priori design, I'm sorry...that ship has sailed, the cat is out of the bag...whatever your favorite analogy, PHK is very right that the new generation has gotten used to not having instructions handed to them.

Of course, anyone is free to start a project with a single vision, recruit new members, and do their best to grow the project. I suspect, however, that such an effort would loose out to one that figures out how to develop a coherent vision without the need for a priori design.

Nobody belives in "a priori design" and I somehow doubt that anybody did. Brooks points out that the original publication of the "waterfall model" was meant as "how not to..." and people got that wrong.

But cathedrals are not about a priori design, they are about style, elegance, economy of means and coherency of design.

But my point in the piece is that the lost generation doesn't even know what a cathedral is in the first place, having grown up in the bazaar.

ESRs original prototype for the "Bazaar" was Linux. Do you feel that Linux is lacking in coherency of design? You refer to the dot-com bubble, but the problem with the bubble wasn't, I think, that it was the "Bazaar". Indeed, I don't think the dot-com bubble of the late 90s was characterized by much open source development at all!

It was, rather, consumed with "flashiness" and "wow factor". I definitely see the continued obsession with these things as a problem. I would say that, for example, much of the obsession with Node.js today is a consequence of this obsession. But that isn't a Bazaar.

It's a disco.

This is true. The OP has made several somewhat-arbitrary and vague assertions about what may or may not constitute a "Cathedral", on top of lambasting others for not agreeing with his definition ("Read Brooks Book")

Excerpts from the HN discussion :

"Windows and Office are actually not examples of cathedrals, because the architectural focus of Microsoft was not on software but on a near-monopoly market." -phkamp

"...iOS is very much a Cathedral and has a designer and architect who cares and who is in control." -phkamp

Does Apple not care about achieving market dominance? Did no version of Windows or Office have a lead architect who "cared"?

Frankly, the entire concept of a "Cathedral" - rigidly defined as it appears to be here - is a little nebulous and hand-wavy.

You're calling a ot of people out on using Microsoft as a cathedral example, so I assume you want the original bazaar-vs-cathedral reading of the paper. But if you do that, how can autoconf be a bazaar example, when it's GNU software?

With more open development communities there are tradeoffs, but often the result is that you can do stuff you simply wouldn't have the manpower to do in closed communities.

I think most of us would love it if every library and tool we used was pretty and elegant, but in the end, it's often better to have something, however much you'd ideally wish for it to be prettier.

Morever, a community in which different components are often the result of disparate teams with different thinking probably results in more attention paid to robust and simple interfaces between them, simply because that's the only way you can get everything to work. Systems composed of heterogeneous components with robust and simple interfaces between them, are, I think, a good thing. I suspect they tend to be more future proof than systems with everything designed by one person from the top down, because in the end, change is inevitable, so having to deal with heterogeneity from the beginning is an advantage.

It is not just that M4 is a horribly ugly, badly, inconsistent language. You also have about a million leaky caches in the build process to deal with. Autoconf rewrites the build scripts in three stages, each which is cached and also keeps an autom4te.cache directory around. So what happens is that you update something in the M4 build script and then have to spend hours hunting down why the change didn't change anything because some stupid autoconf cache wasn't flushed.

What autoconf has done is to separate free software developers into two categories. Those who can hack the source (the .c and .h files) and those who understand the "autoconf magic." It should be telling that people refer to it as "magic" - it's a fing build system, not rocket science.

The only reason this ugly piece of software has lived on is because people treat it as some kind of magical device and inertia. Configuring and building software is an easy problem. It gets even easier if you finally decide to drop support for 30 year old unices that no one uses. The autoconf team consistently refuses to do that which why the software wont ever become better.

CMake, SCons, Waf and probably half a dozen more tools all do a much better job configuring software than autoconf ever will. People really need to try those alternatives and I'm sure they will realize autoconf needs to die, die, DIE.

CMake, SCons, etc, all have their pros and cons. They are hardly paragons of virtue though. [Yes, even as a mere "consumer" of CMake (someone who occasionally needs to build packages that use it), I've been bitten and frustrated by it.]

As far as I've found, there really isn't any build tool that really gets everything right -- which suggests that the problem is harder than you suggest. [Although judging from the number of people who try to write their own build tool (most of which languish and eventually die, but cause some pain along the way), it's clear enough that many people think it's a simple problem...]

> autoconf needs to die, die, DIE

Decaf?

It doesn't matter for a "works fine" person how many faults their current tool has or how much smoother "your" tool solves all those problems, they won't listen. Logic doesn't work maybe because it is very hard for them to get used to something new. Maybe because if you haven't experienced any alternatives it is very hard to imagine that something could be better.