If you don't trust the vendor, don't let them handle your passwords, obviously. But the security properties non-open-source code are routinely analyzed and vulnerabilities found, etc. Plus the track records of the various solutions, a cartesian product of open/closed source, 'hosted' or not, etc speak for themselves.
> If you don't trust the vendor, don't let them handle your passwords, obviously.
The problem is you not only have to trust your vendor today, but you also have to trust them tomorrow. Every vendor is one acquisition or compromised senior executive or engineer [1] away from becoming untrustworthy even if they started out being perfectly trustworthy. Assessing present trustworthiness is hard enough. Assessing future trustworthiness is obviously impossible.
[1] They don't even have to be compromised. All they have to do is make a bad decision. Apple, the company that built an entire marketing campaign on trust, is now installing spyware on its devices.
Right, but this applies to big piles of security-critical software in general - a near tautology. It's really an argument in favour of my position that neither open-sourcedness nor hostedness are useful criteria in evaluating the security and fitness-for-purpose of a password manager.
No. If I trust the vendor today, and my code is open source, then I can control if, when, and how it changes. With closed source, the vendor can introduce a backdoor with every update. They can also force me to update by making the current code stop working by changing their servers. The potential for compromise due to an untrustworthy vendor is not zero, but it's vastly lower with open source.
