So here's a good example of how conventional 'best practices' in software development implicitly optimize for corporate usage rather than community projects: https://www.apollographql.com/blog/graphql/basics/designing-graphql-mutations/

"Don’t be afraid of super specific mutations that correspond exactly to an update that your UI can make. Specific mutations that correspond to semantic user actions are more powerful than general mutations. This is because specific mutations are easier for a UI developer to write, they can be optimized by a backend developer, and only providing a specific subset of mutations makes it much harder for an attacker to exploit your API."

This makes sense - *if* you're developing corporate software, where you control the entire stack! But if you're building a community project, then this design approach actively makes it harder for third parties to adapt and experiment with your thing, and ultimately centralizes control over how the software works, which is the opposite of what you want.

By itself, this is of course a relatively small thing - but implicit "corporate optimizations" like this are *everywhere* in software development, both in how tools are designed and in what people believe to be 'best practices', and they add up - and that puts grassroots projects at a serious disadvantage.