Trust is an reliance on the integrity or nature of a entity.  It does not protect you.  Just assures you of its virtue of topic.  So, you can have trust of identity, trust of intent, trust of protecting your credit card number, etc.

Validation is what is used to determine the state of trust.

Website use SSL certificates to provide a level of security for users.  The nature of those certificates is built upon a "chain of trust" that emanates from their root certificate, held by some other entity usually.  So the reason you don't need to fear someone seeing your email on gmail is not that it has been encrypted per say, but that the only entity that can see that traffic is actually Google.  If Google sold their SSL certificates private key, they would risk exposing everyone's email to that buyer.  Hmm...quite a lucrative market there I bet.  :)

 Trust is a odd thing.  If you have to prove it did you have any to begin with?  So why call it trust, why not call it something else like Validated Identity Recognition - "I see that certificate and I have determined it to be proof of your identity so lets talk in private now".  You have essentially validated Google's identity in the example above, not placed trust in them.  Hey, they may not have a clue how to protect their servers or customers.

So why mention this distinction?  Well it seems that there is one current problem with open source - a lack of trust.  I don't play with guns because I don't trust them in the situations I would place them in; Leaving them unsecured for hours a day, etc. Trust isn't the only thing encouraging someone to buy a product though.  There are lots of reasons.  But I suspect companies see things differently.  Users (and companies) don't trust this stuff just because they could take a look at its code.  Most users have no clue how to review code.  They also have no reason to trust something based on its existence.  That's like trusting a bomb because you see it.  Exactly not what you would do.

So the point I'm making here is that somehow it becomes important to increase the amount of trust related to open source projects.  It therefore becomes necessary to give "outsiders" a standard method of accepting (or refuting) the measure of trust of a open source project.

So why not start creating a trust based solution for open source projects.  A way of saying "I've reviewed the project or part of it and I can validate it does what it is supposed to".  Repeated hundreds of times for a project and you can begin to see how "supporters" and developers" begin to assign levels of trust to specific people.  I trust ProjectX so therefore I trust developer John.  Or vice-versa.

Using things like certificates as a identity placeholder, you can associate Trust Points in some public manner that enforces the notion of trust in open source projects.  So as you gain Trust Points in general you may be generally more accepted regarding your input to a project.  This is kind of like the forum policing that moderators (and user) perform, but in reverse.  Don't focus on tearing a person down.  Instead focus on building up trust.  Those that continue to fail in that regard will not achieve much trust.  The same for projects.

I can see modules being implemented similar to blogs posts using Captcha, but signing with a public cert.  Since you can only sign once, re-signing is irrelevant and easily blockable.  Getting around the system becomes difficult and only coersion is a concern.  So could you either convince or force others to sign?  Of course.  That is certainly a risk here, but no more then other repudiation systems.  You could be notified and have the ability to renounce a signing (with limited options) and an impact on your Trust Status.

I think this idea of Project Trust has merit and could even be implemented in companies on a much smaller scale for internal projects.  More or less rated on their quality of work rather than the trust that they aren't putting backdoors in, but both are still relevant.

So validate the code, then trust the code.