One of the reasons I suggested that folks take a look at previous threads[1] is that phkamp clarifies his definitions of "cathedral != closed source / proprietary / commercial" and "bazaar != open source".
It's not obvious in the acmqueue essay but phkamp wants "cathedral" to be synonymous with "coherent architectural design". As a result, his example of having a bunch of open-source hackers add duplicate dependencies such as a TIFF library when the final build of Firefox doesn't even read tiff files is not "cathedral" and therefore not "quality".
The acmqueue article is not written very clearly because he uses metaphors "cathedral / bazaar" which makes people associate "cathedral" with entities like Microsoft which he didn't intend and not associate "cathedral" with pre-1980s commercial UNIX which he did intend. Obviously, he intentionally reused "cathedral/bazaar" because it was a refutation of Eric S Raymond's metaphors but nevertheless, recycling the same analogy sent multiple people down a road of imprecise arguments. Indeed, one of the comments in the 5-year old thread is an ex-Apple employee (jballanc) categorizing iOS development as "bazaar" but phkamp classifies it "cathedral". Talk about torturing metaphors until people talk right past each other!
[1] no need to read all ~300 comments, just Ctrl+f search for "phkamp": https://news.ycombinator.com/item?id=4407188
It may not be the quality he wants, but architecture is not about maximizing quality, but maximizing quality within a budget.
Yes, that was Eric S Raymond's[1] particular examples. However, phkamp extended it with phkamp's particular examples (Bell Labs UNIX (cathedral), Apple iOS (bazaar), Firefox (bazaar), Microsoft (neither bazaar nor cathedral?), etc).
I should emphasize that it doesn't matter whether phkamp's classifications are "correct". (Indeed, the previous thread showed many disagreed with his taxonomy and 2 ex-Apple programmers contradict each other on iOS.)
Whatever idiosyncratic definition phkamp wants to use for "cathedral/bazaar", the point is readers have to be aware of it to understand his acmqueue essay. (As I said previously, the freestanding article does not make his thesis clear so it lead to subsequent discussions that misunderstood what he wrote.)
[1] https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar#....
my observation has been that getting the first 90% of features/quality is pretty cheap and then as you start to try to close in on 100% features/quality for whatever your domain is the cost of improving software increases asymptotically somewhere short of 100% features/quality.
What people will pay for software seems to mostly depend of the costs of failure. 90% working software is almost always a better value prospect than 100% working software, unless your software failing means someone dies, or you place a trade that is off by $100 million.
In industries where the costs of failure are low (consumer, most internet, etc) the quality of software that the market will pay for is very low, and so the quality of the software being produced is very low.
At that point, work (in the Physics sense) is required to lift it back to the outer energy level -- that of both working and being understood.
In many cases, a reasonable option will be to leave it at the degraded level and continue to utilize it (after all, it still "works").
This all seems obvious to me for the first time, as I look at it from this perspective. But it has never dawned on me before, probably because every inch of my soul longs for the beauty of the highest level of the hierarchy -- "works and is understood".
First they sell you a REST API, then it is more of a RPC, so you have to restructure.
Later many endpoints return crap, even if they worked, so you start ignoring the responses.
etc. pp.
I think this is mostly because
> most [...] code I have to work with has an objectively worse quality than most [...] code I choose to work with.
So popular open source code will either be relatively clean and/or have other important qualities that lets people overlook how messy it is.
For proprietary code, on the other hand, we often don't get to pick and choose.
And deadlines are still a part of open source software development. Most the really widely used projects are heavily supported by corporate patronage, and you'd better believe that those companies are creating deadlines for the people they pay to contribute to those projects based on their own business needs.
For my part, to me it seems that "enterprise vs non-entperise" is a better predictor of code quality than "closed vs open source".
Deadlines are not the only reason for crappy code and projects without them are not necessary shiny examples of beautiful engineering. Whether closed or open, it often takes multiple attempts till you get architecture right.
I don't think the contrast he's drawing is bazaar/open source vs. architected/closed source. It's versus strongly opinionated & or clearly-led open source, e.g. varnish, qmail, Rails, sqlite etc.
Windows is even worse. It's amazing it works at all. Linux is generally cleaner in the auth department but has many other abominations.
The only clean software is either software nobody uses or software whose scope is rigorously limited. The latter is very very hard to defend when people are using it. Everyone wants it to do some new thing or be compatible with some other system.
In a large org it is never clear, who is responsible for what... ;P And the result is sometimes even more code duplication, workarounds and bad examples of Conway's law in operation, than in free software.
The problem is often that the economics does not favor the perfect. I'm working on a project for a client now where I know there are lots of ugly warts in the backend because we've been building abstractions in parallel with building the rest of the system and have not always had the time to go back and revise the old code.
I would love to go back and sort that out. But to the client it is an extra expense now, both in terms of money, but more importantly in time spent now, vs. paying for it increased maintenance costs for people to - hopefully - clean it up over time later.
But there's also often the other cost of learning and determining if a shared piece of code is appropriate.
E.g. there's about half a dozen Ruby gems for handling ANSI escape codes, but for a recent project I ended up writing my own, because none of them seemed to cover what I needed, and it's not clear they should. A lot of code duplication happens because the cost of trying to avoid it often far outweighs the cost of maintaining code you know is doing exactly what you want it to.
I do agree with his hate for the autotools family, though.