Here's my perspective. I've been a technical writer (TW) for ~10 years. 3 at an IoT startup, 7 at Google. > The strengths of this process are also its weaknesses. A developer is, by definition, someone who spends the majority of their time doing development, which is to say writing code. Updating the documentation becomes a task that must be completed so that the code one has written can get committed so that one can…
Just curious. Where do you think that an open source project like PostgreSQL gets a budget to hire anyone? Let alone to dictate a new line of authority to the volunteers who are already maintaining it? And don't forget that there are valuable volunteers who are likely to go elsewhere if too many new rules are added that they don't want to live with.
There is a PostgreSQL core team (https://www.postgresql.org/developer/core/) that is a kind of steering committee, but does not make decisions concerning development. It consists of people from different companies.
The people who develop PostgreSQL are mostly hired by companies that have a commercial interest in the database and usually sell consulting, support, training, products that need PostgreSQL and customized closed-source forks of the database software.
There is no single authority in the PostgreSQL project. Decisions are made in mailing list discussions, cumbersome as that may be. The ultimate authority over the code is wielded by the committers (https://wiki.postgresql.org/wiki/Committers), which are highly trusted core developers who work for different companies. Development is slower than it might be with a single central authority, but that also part of the reason for the high software quality that PostgreSQL is known for.