This piece is excellent. The backstory on the zeromq and nanomsg projects is fascinating and generously detailed. The trick of reaching out to gather rejected contributors is good humanity and practically clever. The rule about monitoring contributor entrance and exit rates, I get.<p>But I&#x27;m struggling with the implemention of the rule.<p><i>In almost every case, it is better to merge even a bad patch than to turn away a contributor for the projects I already struggle to maintain. So I try to get the patches improved, but I merge them even when I can’t. Even bad patches are better than none.</i><p>With all due respect to the OP and everyone who have poured blood, sweat, and tears on these projects and as maintainers of others, this point is hard to swallow. How bad of a patch is ok to let through? How complex? How much of a deviation from the original design? Is the contributor going to be around to fix regressions impacting other users? If the patch is complex and taking the software in a different direction, is it a good direction for existing users and will people get on board to do the work to update the rest of the code? I think these questions are vitally important for maintainability, correctness, and performance of software in general. I would guess hashing them out is a significant portion of the actual work in open source projects and are why people fight on mailing lists and say no to patches in the first place. We fight because we care?<p>Working out the answers to these questions is so, so much work, and people just want their patches taken and maintainers just want to get on with their lives, so taking anything that comes along as a means of keeping the project moving may be the only hope in some cases. But I find it hard to believe it doesn&#x27;t backfire more often, on grounds of user support and principles of software maintainability.<p>To name a couple projects that have had some success with different approaches, I&#x27;ve noticed the Clojure project seems to maintain a vibrant contributor rate while also exercising strict design control from the top. Project leadership takes heat for rejecting, in particular, feature requests, but from what I&#x27;ve seen they will work with you if you will take the time to work out your design in a way that fits the language and the maintainers&#x27; vision.<p>Secondly, the Waf maintainer strictly will not merge patches that change APIs, break anything for users, or do much of anything wonky internally, but from what I&#x27;ve seen he will work with anyone introduces new functionality that doesn&#x27;t break old code and is in line with his view of the project. He worked with me to whip a shoddy patch into shape. I was grateful he bothered at all, and it would have been disastrous if he&#x27;d just merged it. Somehow he walks the balance of rejecting bad patches and protecting users while also merging quite a few hit-and-run contributions. The maturity of the project and decoupled architecture finely honed for the problem space may help support this style of maintenance.<p>So at least in those two cases the answer lies in a very skilled balance of engineering and social concerns, but not necessarily any patch is better than none.