Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Your hypothesis looks compelling written down, but it's entirely wrong in practice. This is the process where Linux comes from too, and Postgres is on that order of system software produced by an open source process.

Your error is the erroneous assumption that centralised control is even feasible. This assumption has been proven wrong repeatedly. You're assuming the bazaar development method is riskier, but the certainty offered by the cathedral method is that of project overruns and likely failure. Unless you fund it sufficiently for NASA-like certainty, which you're not doing.

(Note that Postgres has been done much more that way all along, and is famous for quality; the crappy alternative, MySQL, which is in practice a product showing the sort of qualities you describe, was a one-company project for most of its history.)

Go reread The Cathedral and the Bazaar http://www.catb.org/~esr/writings/cathedral-bazaar/ and note that it's been proven pretty much entirely correct in practice. (By the way, "agile" at its best is literally an attempt to port successful open-source development to commercial practice.)



I don't understand your classification of PostgreSQL as "the bazaar", and MySQL as "the cathedral"; if anything, MySQL exemplified the bazaar model of incorporating almost any half-baked idea in the rush to regularly ship features, while PostgreSQL has always taken the approach of shipping when it's done.

PostgreSQL's careful approach has always required "cathedral" centralization of technical management to ensure that things are done correctly, or not at all.

I also have to question the assertion that Linux provides an objective example of well-written software, when the code quality and issues present in Linux are most reminiscent of MySQL.

Relative to a so-called "cathedral" model such as FreeBSD's (or PostgreSQL's), Linux's software development model produces:

1) Code of considerably lower overall quality than that of FreeBSD in terms of bug count, maintainability, and simple consistency.

2) Poor (and often immediately replaced) architectural design designs that must be supported indefinitely.

3) Additional cost levied against downstream consumers of the product; simply shipping a reliable kernel requires considerable effort on the part of downstream distributions.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: