Re: [FFmpeg-devel] Sovereign Tech Fund

[Anton Khirnov <anton@khirnov.net>]

Quoting Michael Niedermayer (2024-01-30 01:15:54)
> > Self-imposed restrictions like these at the very least need a GA vote
> > IMO.
> 
> I dont think its a "Self-imposed restriction"
> The right to arbitrarily reject a invoice to a SoW never existed in the
> first place.
> But lets try this hypothetically.
> If the GA decides it has the right to reject an invoice to a SoW
> signed between SPI/STF/1 Developer.
> Where would the GA get that right from ?
> It can only have gained that right from the SoW/ or a contract
> 
> This is the same in GSoC
> if the GA decides a student should not be paid, its not going to
> work, its the mentors decission and googles.
> The GA never gave that right up, it never had it in the first place

My understanding of your
> There can be no late objections
> [...]
> objections after that cannot be considered!
was that reviewers of the code produced by an STF-funded project would
be restricted from rejecting the patches or demaning large-scale
changes. If that is not what you meant then my point does not apply, but
then this opens the developer to the risk of their code not being
accepted.


> > 
> > > Also once the person doing the work reaches the agreed milestone.
> > > She will submit an invoice with stefano and my help to SPI/STF.
> > > (in the unlikely case of a dispute on reaching a milestone
> > >  it would be decided by the technical committee if the milestone
> > >  has been reached from FFmpegs point of view)
> > 
> > Unlikely? I believe you are overlooking and/or trivializing the most
> > serious problems that need to be addressed before we can submit any
> > applications and not have it end in disaster.
> 
> yes, iam trivializing, i thought people would value a grant of 200k€
> more than arguing around.

IMO hasty actions and avoidable drama may cause damage to the project
far in excess of this sum.

> And sure some arguments are quite valid i just think we can postpone
> what needs to be postponed to get this grant and then for the next
> round we can adjust everything as people prefer (in case there then
> still is any wish to change something)
> 
> 
> > 
> > These are, IMO:
> > 
> > 1) How does the project protect itself from pre-approving some code that
> >    does not exist yet? This is not just some theoretical danger, it's
> >    easily possible that some project sounds good in theory, but actually
> >    implementing it comes with so many gotchas and caveats that it ends
> >    up being not worth it. Or there are fundamental technical
> >    disagreements about the specific way it's been implemented. Both
> >    cases exist in our history.
> 
> Lets see
> First STF is not about features but about maintaince. So the risk
> of really unexpected and unavoidable sideeffects are not that high.
> Also we dont need to do the really tough stuff in STF we can do the
> easy but boring stuff.

I do not see people queing up for such work.

> But whats really the problem here ?
> Lets imagine a example we agree to ABC
> and it turns out the implemtation of ABC unexpectedly needs 3 letters
> and this is unacceptable so we dont merge it.
> Personally I would for cases where we arent sure the code is acceptable
> for git master. Make this clear to STF before they accepting it and
> I would not put "merge into git master" in the SoW.
> 
> Now if we do put something in the SoW that we then do not achieve
> thats a failure. IIRC/IIUC this is possible but will not be
> tolerated many times. (certainly very dependant also on our
> explanation of why that happened)
> (thats what i remember, i cannot find the mail ATM where we where told that)

The question is, what exactly would be the reprecussion for failing to
achieve projects. To us? To SPI? Not to mention the developer not
getting paid.

> > 
> >    It's also very hard to accurately estimate the amount of work
> >    required to do something. What do we do when someone spends a month
> >    working before realizing the project needs 5x more time than it's
> >    budgeted for?
> 
> use a payment per time SoW.
> But honestly as a buisness partner to STF we should aim for delivering
> what we promisse at the price we request.
> Anything else will not be good for FFmpeg independant of all other things

So you're basically saying the developers have to take the risk onto
themselves. That's ridiculous and means this cannot be used for almost
any interesting projects.

As an example, my threading work took over twice the time I initially
expected. Are you suggesting I should have worked a year for free? And
it's not just my personal failing - it's widely acknowledged that
accurate time estimates for complex projects are somewhere between
extremely hard and unfeasible.

Of course the problem also works in other direction. If we go with your
suggestion, developers will try to protect themselves by playing it safe
and budgeting for the largest amount of time they think they might
possibly need. Which means in most cases they will need less time,
sometimes significantly less. Would STF be okay with us being so
wasteful?

> > 
> > 3) Who exactly will be judging what amount of money is appropriate for
> >    what amount of work performed? How will we avoid conflicts of
> >    interest, or endless bikesheds over who is getting too much money for
> >    too little work? We just bikeshud a thread to death over rather
> >    little money, now imagine what would happen with ten times the
> >    amount.
> 
> trivial ;)
> we start with a wiki page
> we add a some work with some monetary amount.
> We wait.
> If someone comes and is willing to do it for less, ok, if someone complains
> its too much, not ok.
> This seems the normal hire the "cheapest competent developer"

This is not serious. "someone complains"? Like any random person? Any
developer? In a project like ours, someone will always complain. Does
that mean anyone has a veto over anything else?

Besides, my main point is that the amount of work to be done on any
interesting cleanup is unknowable beforehand. That means you have to
budget for the worst case, which means in the median case you will be
significantly overpaid.

-- 
Anton Khirnov
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".