I think it means you should look more closely into the contract you have with the maintainers. Either you rely on trust, like you would do if you used OpenSSL or NaCl because the creators and maintainers are known to go beyond the required minimum, or you get an official contract.
This. There is no free lunch. Either you pay for quality or assurance, or you risk you might get something rotten that wasn't obvious at first glance and you can't do anything about it. That's the difference, when you pay, you might also get something rotten, but you can do something about it. Your options are of course only constrained by what you pay.
The problem, as I see it, is that a whole generation of programmers have grown oblivious to this implicit relationship, and when that relationship is actually exercised in some way, they default to what they understand, which is paid services and products, which results in both sides feeling like they got a raw deal.
Again, in my experience there is very little correlation between how much you pay for something and how rotten it is. And I find the opposite, when you get open source software and it's rotten, you can do something about it. You can patch it locally, even if the maintainer won't accept your patches. If you have a proprietary product written badly, paying money for a support contract will not magically make it a more secure product or guarantee that they will be able to fix your issues.
