That's fine if your proposed changes are small enough to require minimal intervention from other folks, but typically in these kinds of orgs there are all sorts of dependencies that you simply can't account for in code and in a pull request alone.

As a hypothetical example, let's say you want to send an email nudging your users about teams under their purview who could do better in adopting parts of your product suite. Suddenly other product teams are worried the recipient will choose to simply churn from a product that their teams haven't adopted, legal starts talking to you about the GDPR, etc etc, and things start to look a lot less hopeful.

Your best bet is to try and account for these sorts of issues before you even start writing the code. If they're reasonable issues and your code happened to land anyway, you would have done damage. Even if they're not actually issues, you have made other people's lives harder. And if your code never ends up landing, then you've wasted your time!

So, you get out ahead of it and set up a team that can interact with all of the stakeholders that might actually be affected. It might take time, but at least the risks are lower and your code isn't being needlessly thrown onto the cutting room floor.

And that's even without mentioning any sort of technical concern, of which I'm sure there will be many for anything larger than the smallest bugfix. Other engineering teams don't like the way you've duct taped your thing to their thing, others still are not excited to have to maintain your new addition to the infrastructure. Hopefully your open source bazaar thing has a decent way of resolving these issues, but most of them just have a BDFL that you can only hope will be polite as they smite your unwanted PR.

In a "cathedral" team with decent practices, you just have other engineering teams as stakeholders. It's just an extension of the set of connections you've already built.

How does this differ from a bazaar, exactly? Isn't all this possible under that model too?

Maybe, but you can't know for certain that you have exhaustively captured all the stakeholders or passed around your request to every relevant person. Additionally, decentralizing heavily enough will make roadmapping basically impossible, and your customers probably want to know when their desired feature is actually going to land.

Finally, the mapping holds the other way. The problem described in the article is that too many people hold veto power, and so nothing actually got done besides the lowest common denominator. It would be entirely possible for your OSS project to suffer the same fate if enough people in the mailing list complained that your new change breaks their workflow. You can take a look at all of these open protocols and projects that end up building the least common denominator product just because they do not dare break arcane promises made in a different time about some bits being in such and such place.

Centralized decision-making is its own sort of effective, at least in making sure stuff like accessibility and design are kept consistent. Microsoft gets a lot of crap from us for a lot of things, but some of these things are necessities that could just as well be forgotten otherwise.

The solution is kind of the same in both situations:

* Minimize the list of people who have veto power

* Work with the people who must retain it so that they trust you when you want to do something a little unexpected or different (and manage your own expectations when they disagree with you)

* Ensure someone above the conflicting parties exists that doesn't always resolve ties in a way that is risk-averse (or guide them to a solution that isn't always risk-averse if necessary)

and you should be well on your way.