Should you accept a pull request from a very bad person? (Part II)

Things you can and can't do when faced with this dilemma

November 19, 2018
Jonathan Libov

The question—What to do with a contributor to your open-source project who turns out to be a very bad person—is worth contrasting with what would unfold were you his manager at a firm: You'd fire the person. Employees at a firm are more than the sum of the work they contribute; they're also present in the cafeteria, where their objectionable views and, even worse, the manifestation of those views, might harm other staff members. The firm also pays for the office, so independent of the harm you suffer from listening to this person's views, your firm would otherwise be sponsoring something harmful were you not to fire them.

Your open-source project, of course, does not have a cafeteria. There have been occasional meetups and events supported by sponsors, which now makes you queasy, and there is an IRC for your project, which now also makes you queasy. Unlike a firm, however, the success of the project isn't much more than the sum of the work that people contribute. "Islands of conscious power", if you will.

Even if you opted to censor this person from your project, what is your recourse? Copying the code they submit and committing it under a different Github account is also unethical. Besides, if you blocked their Github account, what stops the contributor from opening a new, pseudonymous account from which to submit contributions?

I think there are three ways one could approach this.

1. Open-source code is uniquely neutral

Unlike code owned or sponsored by a for-profit, centralized firm, open-source code is purely meritocratic. As one commenter put it in the Hacker News thread about SQLite adopting the Rule of St. Benedictine for their code of conduct:

"Open source exists so that everyone can contribute their talents to something that benefits everybody. If Joseph Stalin or bin Laden wrote a great patch, I'd want it. We'd all be better for it. We can fight his ideas in a different arena."

Besides, there are mechanical concerns—such as the contributor opening a new, pseudonymous account—that make governing the character of the contributors to an open-source project unwieldy.

If this were your view, you’d accept the pull request and dismiss anyone’s judgment as misplaced.

2. No code is neutral, just as no technology is neutral

History is littered with conflicts between the advance of science and technology, on the one hand, and the morals of its contributors on the other. Everything is relative; choose as wisely as you can.

One thing that makes SQLite adopting a secular Code of Conduct more palatable is that an open-source project can always be forked and sustained by different people with different visions, objectives or values. If you don’t want be a member of a club that accepts a very bad person, not only can you leave but you can take all the IP with you.

If this were your view, accepting the pull request is a judgment call. This isn’t just an open-source project that you happen to control, it is your open-source project so long as you have the power to ban or deter people. You must accept that you will be judged one way or another whatever you decide.

3. Intention matters

No one blames Tim Berners-Lee for creating the protocol that has empowered very bad people toharm others on the internet. The buck stops with the firms which host the content , not the shared technology that enabled it.

Berners-Lee might be viewed differently had the internet immediately become a cesspool. We’d blame him more if he were profiting from it immediately. Since this didn’t occur, we treat him more like a scientist making a natural, inevitable discovery.

If this were your view, you accept the pull request, particularly because your project (presumably) does nothing to advance this person’s views or ability to act on them.

Onto Part III and why I think this thought experiment is timely.