Brief items

In other words, I would argue that security for most open source projects (by number, at least) is a resource problem, not a persuasion problem. Their authors are not investing in engineering process improvement in large part because they don't have time to both do that and to do the work on their project that they find fun and that inspired them to release it as open source in the first place.

That implies that the solution to look for isn't a winning persuasive argument, but instead is a way to get the developer more resources, either by somehow getting them more time to work on their project or by making the cost of better engineering process substantially smaller than it is now. GitHub's automated pull requests for dependencies with security vulnerabilities is a good example of the latter.

For a start, it genuinely was the case back when a lot of these apps were written that you couldn't so easily go out and "buy one off the shelf", so to speak. But there's also the whole idea of dogfooding, and the ecosystem. Again there's a historical angle to this: it wasn't just for us but for the whole industry that it was more common to build stuff in-house than outsource absolutely everything besides your "core competency", as is the management fad these days. So for us to build our own infrastructure was kind of a proof-of-concept that Fedora *was* a suitable environment for *anyone* to do that: at least at the time we felt that there was value in demonstrating that Fedora provided an environment in which you *could* build and deploy and maintain and use, you know, calendaring systems! and authentication systems! and election apps! and so on and so forth.

I agree that this has fallen out of fashion to an extent, and the "let's just outsource everything that isn't actively building bits into OS images" mindset is in tune with Current Industry Thinking and there is a sustainable logic behind it. Personally I still think it comes with significant issues, though, because there were a lot of what management is pleased to call "intangibles" that went along with doing all that work. We had an awful lot of "in-house" knowledge about a whole range of stuff because we *did* build and maintain and deploy and support all of these bits.