[FFmpeg-devel] STF SoWs

[Cosmin Stejerean]

> On Feb 6, 2024, at 10:17 AM, Michael Niedermayer <michael at niedermayer.cc> wrote:
> 
> if "merge to git master" is a requirement then iam not participating
> in this. The risk simply outweights the gain. I wont work for months to
> then be at the mercy of not a single of 2000 subscribers posting some
> "i object" and all 2000 know in this situation it would cause an
> inconvenience to me.


It doesn't have to be all or nothing. In addition to having smaller milestones so that it's not months of work that are at risk, the milestones can also split between things like initial design is ready, a functional prototype is built, the initial patchset of the final solution is ready for review, the work is merged, etc.

I believe the benefit of picking experienced developers (with over 100 authored commits) is that the work is done by people that have demonstrated they know how to get their changes merged. And they should have a good intuition for what kind of work is going to be accepted and what kind of work won't. Worst case scenario they can take it up wih the TC although building consensus on the approach ahead of time rather than after months of work might be preferable.

At the same time this work will be done by established developers who presumably have much more to lose from trying to game the system than they will get paid for a one-off project. If they do a good job there will likely be more work going their way in the future. If they try to cheat there probably won't be. So it should be reasonable to expect some good faith payments along the way even before everything is merged.

Given all that perhaps 75% is due at the time the work is ready for review and 25% after it is merged, etc. Whatever the split I do think it's important to have a reasonable part of the payment tied to getting the work merged, while at the same time not expecting developers to work for months and have 100% of the funds tied up in contentious patch review.

- Cosmin