This is my from-the-outside-looking-in take on the matter. It seems to me that there's a clash of expectations/worldviews, both happening in this thread, and i

This is my from-the-outside-looking-in take on the matter. It seems to me that there's a clash of expectations/worldviews, both happening in this thread, and in the wider portions of the interwebz involved in the kerfluffle this article is about. A comment[1] from ddevault states two things: > 1. YOU are responsible for your dependencies. > 2. Open source participants are volunteers and owe you nothing. The above is true. But there's another aspect here, that of cultural norms, implied goals and the expectations derived therefrom. By my observation of mailing lists, hacker's blogs, my own attempts at contributing to various projects, and other things, there's come to be a set of expectations of the authors, maintainers, contributors, and even to some degree, users, of FOSS projects. These expectations are not set in stone; they can be shaped by the statements and actions of the maintainer(s), implicit or explicit, or the lack thereof. But there is nonetheless a default set of expectations. A set of social norms, if you will. One of the expectations I've observed, and discovered I myself had absorbed through cultural osmosis, is thus: A maintainer should make clear what a project's goals are, and earnestly consider patches/pull-requests offered in good faith support of a project's explicit or implicit goals. They should communicate clearly technical facts, concerns, and considerations when discussing or debating an offered patch. Said discussion should be focused only around the technical facts as they relate to the goals of the project and the offered patch. And if the patch is rejected, the maintainer should clearly communicate why. Said communication could be a long essay expounding on the technical trade-offs the project has had to make, or a simple link to a FAQ entry covering why such-and-such common patch type will never be accepted. (In that latter case, presumably the earnest consideration of that patch type had happened sometime in the past). A related norm, one tying back in to ddevault's post, is the contributor's end of that exchange. One offering a patch should accept a rejection with grace. A contributor can and should be willing to discuss and debate and try to persuade a maintainer how the offered patch actually does align with the project's goals after all. But he should do so only with technical facts and logical argument, not fallacies, emotional manipulation, name calling, threats, or other such juvenile BS. To persist and pester after a final decision has been made is a violation of that norm. Thus, it is as equally gauche for a contributor to tell a maintainer to die in a fire after a rejection as it is for a maintainer to state he doesn't accept patches from people who voted for the Labor party in 2017. None of the above invalidates ddevault's assertions. However, IMO, social norms serve as a sort of oil on the machinery of the human interaction inevitable in collaborative projects. A person rightly gets upset when those social norms are violated. But, there are right and wrong ways to respond. From what I've seen of this kerfluffle so far, it is a violation of those norms which led to this mess. Recall what I said about a project's goals, above. Rust's explicit goals of memory safety, thread safety, etc, IMO carry with them an implicit goal of making for secure programs, by making it easier to avoid the kind of mistakes that cause programs to become insecure. I'm not a rustacean, but it seems to me that at least part of the wider Rust community is working on making that implicit goal an explicit one. And so, by building your project with Rust, that goal of a secure implementation transitively becomes one of your project's goals, at least implicitly. If it's not, you had better explicitly state otherwise. And if you do, I don't think you should be particularly surprised when some push back. And so we come to the violation of social norms. I can't find any before-the-kerfluffle articulation of actix-web being a for-fun project. So, actix-web was seen as having the goal of being sound and secure, by virtue of being implemented in Rust. And here was Nikolay's virst violation: failing to make clear the goals of the project. If after that first instance of 'unresponsive maintaner', as steveklabnik puts it, Nikolay had made clear his main goals were being fast as possible and winning the benchmarks, that soundness and security were non-goals, and he had firmly and politely held his ground on that, I think the kerfluffle could have ended there. If he'd made those goals explicit then, then other users would have been able to take a look at the project, and see that all that Unsafe code was probably not something Nikolay cared about changing, and so know they need not offer patches for it. But since that wasn't done, we come to the next violation: not earnestly considering those patches offered in good faith -- or at least seeming to. Because of the impedance mismatch between Nikolay's actual goals and those seeming goals of actix-web, he seemed to not take seriously those patches offered. As I said above, there's a right way and a wrong way to respond to such things. And sadly, the response by some was to violate the contributor's end of the bargain: accepting a patch rejection with grace. By responding with out-of-line remarks like "please stop using Rust", the quality of the discourse degrades, and shit rapidly gets toxic. I don't think it would have been a violation of norms to call out all the use of Unsafe, and the various ways it was unsound, or even to advocate that others should not use actix-web, so long doing so stayed fact-based and did so somewhere other than the actix-web bug-tracker. As far as I can tell, the smoke test of HTTP clients did that. I haven't dug deep into the Reddit thread, but if there was personal attacks on Nikolay, I'd not be surprised. What have I learned from this, despite not being part of the Rust community? Well, if nothing else, it highlights the importance of clear communication. In any future projects, I will need to make what my goals (and non-goals) are as clear as possible. I will also need be willing to clarify things when there seems to be an impedance mismatch between my goals for a project, and what a contributor thinks they are or should be. And I'm going to have to develop a thick skin and the ability to de-escalate, because some people are going to respond with perceived rudeness from me with deliberate rudeness of their own. Perhaps that's a naive take on it. I welcome suggestions on how to improve it. 1. https://news.ycombinator.com/item?id=22075346 https://news.ycombinator.com/item?id=22075346