One bit of nuance to this is how one defines "users". An existing open source project (or even perhaps an exiting proprietary product) is likely to think of its

One bit of nuance to this is how one defines "users". An existing open source project (or even perhaps an exiting proprietary product) is likely to think of its users as "those people who currently use the product", while a startup building a product to be sold to a future larger userbase is going to think of them more broadly. The problem with this is that the former is subject to selection bias. All the people who are currently using the product are by selection, those who have the patience to deal with its' usability warts. Therefore, if an outsider to a project wants to make a change in favor of usability, they have a much harder time overcoming the objection that changing the code might break things. The same is true on a second level: All of the existing developers of a project are those who are by selection already comfortable with both the development process and the resulting product. If someone wants to join, they have to already be familiar with how the project is structured and how it does things. They probably have to already be comfortable with this. Someone who hates working on projects without automated testing is very unlikely to join such a project and then convince the team to adopt automated testing. Of course, you can't just let random new people come into a project without pushing back on them; Often their ideas are genuinely bad ideas which come from a lack of understanding & context.