The hope would be, of course, that developers would resolve their differences with the contributors. But if they don't, developers can walk and take their code with them (shareware it, say, or take it to a third party)
This is also not very good for the developer. They have to perfect the software to please all the contributors before getting paid. How long until everyone agrees that it's ready? Where am I supposed to take it if I walk? I just wasted all this time writing code, thinking I was going to get paid and now I have to try and sell software that I didn't even come up with the idea for. At least with Rent A Coder, I don't have to please a group of random people.
Our election algorithm looks at a lot of metrics before deciding whether to pass a project. Our goal is to pass projects that have broad community consensus that they meet the project requirements. We obviously want to fail projects that have obvious stability problems, or that don't do what the proposal says. We're working hard to make it difficult to game the system, and I'd be interested in any thoughts you might have to make things more fair.
If a bunch of contributors vote 'no' and pull their money then how do I improve the project and get them onboard again if it's going to be OSS? With shareware, I can improve the product and catch them on the next release.
Contributors can only pull money if it's been more than 30 days since they made the contribution. After that 30 day holding period, they can walk. We've considered playing with that number, or letting it be variable.
Contributors don't have great incentive to let an election fail; if it does, they don't get any software (other than whatever demo the developer posted). While I'm sure there will be cranky contributors here and there, hopefully we can factor them out to some extent in our election process. At the macro level, people are going to want the project they contributed to released.