3 ms·
The amount of votes required is definitely not 100%. That would be way too hard for any developer. Our election algorithm looks at a lot of metrics before dec
by drewcrawford 18y ago
The amount of votes required is definitely not 100%. That would be way too hard for any developer.
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.
- deleted 18y ago[deleted]
- tsetse-fly 18y agoWhat happens if I vote 'no' but the project still passes? Do I still have to pay even though I wasn't satisfied? 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.
- drewcrawford 18y agoIf the project passes, the developer gets paid. If there's some sort of dispute, we can manually arbitrate. Again, our metrics are for broad consensus and having the shipped product match the original proposal. If those two conditions are met, I think in all fairness, the developer should be paid. 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.