It feels like there are two worlds of software.
In the first, iteration and moving fast are the priority. In this world we talk about continuous deployment. We talk about observability and testing in production. We often work in small teams, have short iterations. We think that not being able to confidently ship every day, including Friday, is a bad sign.
In the other world the priority is collaboration and - to an extent - stability. We prioritise consensus, large contributor base, wide deployment. We talk about release cadence rather than iteration. Beta features instead of feature flags and instead of testing in production. Shipping may finish on a Friday, but it probably didn’t start on that Friday. It probably didn’t even start the same week as that Friday.
Neither of these worlds are right or wrong. They’re trade-offs. Favouring broad collaboration over agility isn’t wrong, it’s just a choice, and vice versa.
We can be intentional about these choices. It often makes sense to favour broad collaboration for *platforms*, for shared infrastructure and software, for the bits where agreement and consistency are much more important than how hard or easy it is to respond to change and explore a problem space. But it can also - I believe - stifle good innovation when we insist on using heavier-weight approaches in areas that aren’t settled, that don’t need to find one way everyone can agree is best. It’s important not to see success in a context as success in all contexts.
The things that require broad agreement, that require long release cycles, should be small (where possible). They will be slow moving. They should be full of extension points and most things should be built on top, not built in. Because agility does matter, options do matter, disagreement matters, and - in the right context - therefore healthy competition, and iterating fast, matters.