[FFmpeg-devel] Sovereign Tech Fund

[Michael Niedermayer]

Hi Anton,

CCing Jonatas as there are questions beyond my knowledge in here
and also iam not sure if my awnsers are all correct

On Mon, Jan 29, 2024 at 10:11:49PM +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-01-28 04:25:49)
> > There can be no late objections here to any project suggestions.
> > Objections must be before a project suggestion is submitted to STF,
> > objections after that cannot be considered!
> 
> 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


> 
> > 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. 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.

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)

Again i would suggest to word the SoW in a clear and honest way maybe
"work 1 year full time on ffmpeg-CLI multithreading"
NOT
"produce a finished implemtation of ffmpeg-CLI multithreading in a year"

than again iam not sure this above wouldnt be a "feature"


If this would be accepted i dont know. But its what i would do
It simply puts in words the truth what we can promise (that we will
work on this for that time and we also in such a case should explain why
we cannot state clearly why we cant promise a specific result at a specific time)


> 
> 2) How do developers protect themselves from spending vast amounts of
>    time on work they may not get paid for? As per 1), we may easily run
>    into fundamental technical disagreements which result in the work
>    having to be scrapped or redone entirely.

IIUC payment can be per milestone or per time.
in both cases the developer will send an invoice when reaching the agreed points.
I think its expected that the code would not be finished and in git master at that
point.


> 
>    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


> 
> 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"


> Contrary to the overall mood of this thread so far, I hope these issues
> can be overcome and some useful work sponsored successfully. But they
> need to be taken seriously first.

yes, also please CC jonatan on questions related to teh SoW paperwork stuff
and SPI. He is not subscribed he can just post without subscribing because
of magic.
We can also ask STF for specific things but iam hesitant to CC given the
heat in this thread could reflect badly on FFmpeg.


> 
> I'd also like to ask Jonatas whether anything requires the projects to
> be owned by individuals. Were I to propose a project, I'd much rather it
> went through FFlabs than myself individually.


[...]

thx
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20240130/dc50c7ad/attachment.sig>