I've been re-reading the book "Social Architecture" by the late Peter Hintjens:
https://hintjens.gitbooks.io/social-architecture/content/
It's a great source of inspiration for how to run a successful Free Software project. It explains the Collective Code Construction Contract (aka C4 - https://rfc.zeromq.org/spec/42/), a protocol for managing projects like ZeroMQ.
One fairly radical guideline of C4 is that almost all patches should be merged! By reducing contributor friction, you will increase their investment in the project.
Another interesting point is that the "public contract", or API surface, of the project should not be broken unless the change is universally considered to be the right thing to do:
https://rfc.zeromq.org/spec/42/#26-evolution-of-public-contracts
This means that the project *should* be free to ship new releases regularly and users can upgrade without concern for behavior or API breaking changes.
The solution is to use new names for the changed "contracts" without changing the existing contracts. Not easy to do, but possible!
Another interesting point is that the "public contract", or API surface, of the project should not be broken unless the change is universally considered to be the right thing to do:
https://rfc.zeromq.org/spec/42/#26-evolution-of-public-contracts
This means that the project *should* be free to ship new releases regularly and users can upgrade without concern for behavior or API breaking changes.