barcist

Objective measures are a good thing. Otherwise you just end up with some subjective opinions nitting bro culture even closer together.

> 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.