Wikipedia:Reference desk/Archives/Computing/2022 September 13

= September 13 =

Open source free from those with malicious intent
Hello! I've noticed that pretty much anything that is open source is pretty much free from anything that would break it. How exactly are open source projects able to avoid being vandalized? It'd seem like something that's open source would be an easy target to destroy by someone who just wants to ruin it. ― Blaze WolfTalkBlaze Wolf#6545 20:20, 13 September 2022 (UTC)
 * Most projects will have maintainers who review the code before it is accepted, and often code is posted for public comment before it is accepted. See for example  which is the mailing list that has proposed patches (code changes) for Linux.  Of course, review does not always work, and there are cases where bad actors submitted malicious code.  Here is a case where they were caught: .  RudolfRed (talk) 20:27, 13 September 2022 (UTC)
 * There is the infamous example of peacenotwar which revealed the problem some open source software had of blindly trusting dependencies without any review of their changes and consideration of their maintenance practices. Beyond being noticed very quickly, I think the truly dangerous part of that code was rendered inactive by the author or at least that's what they seem to be claiming on our article talk page, so the harm was minimal and the changes that resulted may make it a lot less likely to have a wide effect in the future. (Since the licence of node-ipc is fairly permissive it's possible some closed source software was affected too. I've never heard of any and it might not be publicly known.) Nil Einne (talk) 01:40, 14 September 2022 (UTC)
 * @Blaze Wolf Open-source software projects are often, like Wikipedia, counterintuitively successful and useful. The wiki model of content creation is not quite the same as the model typically used in open-source software development, but the same principle of collaborative editing underlies both, often providing very high quality results. Power is typically centralized in the possession of a comparatively small number of maintainers, which can be a problem: see the case of SIMH, wherein a single maintainer unilaterally relicensed the code under an unfree license; contributors promptly forked the code into Open SIMH. Generally speaking, though, it seems that voluntary collaboration usually works well in practice. Shells-shells (talk) 06:24, 19 September 2022 (UTC)