> As a maintainer of a security-oriented open source library, the paranoia of "is this person trying to help or to exploit?"
That's an excellent mind set when reviewing code, no matter security or not. But especially for security. How could this be wrong? What are the corner cases? How could anyboy break this? What do we need to test? That kind of scrutiny is crucial for keeping the quality of your code base high, no matter who posts the PR.
In a corporate proprietary code base this is REALLY easy. Just commit a bug. Happens every day, everywhere. Just that normally these are mistakes. You can easily mask a deliberately inserted exploitable bug as a mistake. Make the code a bit convoluted, leave out a crucial corner case from your test, slip this in in a moment when your code reviewers have time pressure and/or are stressed somehow, and even if you are caught, the plausible deniability is convincing. How many eyes will see it after the fact? None.
> potentially all your users might go with the fork
That's the issue right there. Why would you care?
Clearly, the maintainer is invested in having a "community". Why? They must expect something positive coming out of it, so they are invested in having that community, which then means they have something to lose if that community moves somewhere else and they are left behind.
That's what enables this social exploit. A takeaway can be not to get so invested in having a community. These are users of your software, and their "utility" is in helping find bugs, perhaps suggest improvements or even provide patches, making the thing you as the original author made better. But that can clearly become a burden.
The trick is to align the metrics with company goals. It's not easy, but not impossible either.
For example, if quality is your goal, then the metric you give your devs is "number and severity of bug reports coming in from customers". If unsatisfied feature requests are part of that number, then the devs have to strike a balance between churning out features and preventing bugs (and fixing discovered ones).
Obviously your customer support needs a different metric.