...

Statements of Work and milestones (by definition) are for features.

The SoW suggestion/need came from a lawyer that jonatas asked IIUC. so i can just suggest to put work like what you list above into a SOW like framework. Or maybe Jonatas can clarify, in case i misunderstood

My point is that ongoing maintenance can't be split into discrete pieces of work, nor arguably can a given timescale be associated with cleanup. For example YUVJ is difficult, until you remove it and see the bugs you don't know how long it will take. This is not suited to the bounty/SoW methodology. We don't need STF to be funding features, we need maintenance, infrastructure etc which all lends itself to salaried work. Kieran

Note: I have no idea what YUVJ is (I assume you want to remove it, not to implement it?) and I forgot to mention "reverted work" (likely in the form "work not yet merged or reverted within 30 days after being merged"). The goal here was to make easier to understand what's expected. Of course, I can help with legalese if you explain to me and review it afterwards, just let me know in such case. Att. Jonatas L. Nogueira (“Jesusalva”) On Sun, Jan 28, 2024, 16:20 Jonatas L. Nogueira <jesusalva@spi-inc.org> wrote:

That's not a problem at all; because you can divide the work into discrete pieces after it's done (on the invoice), just like liberal professionals (eg. accountants, lawyers, administrators, etc.)

The SOW defines what is acceptable on the invoice (so in the YUVJ case, for example, it could be "code related to YUVJ implementation and bugs arising of it, as well as review of the PRs/MRs associated with it, but not tagging issue tickets, duplicated work or code formatting" — I have no idea, this is just for inspiration), as well as the timeframes by when they should submit the invoices (and if they need to submit any other proof of their work, what and when). It should also define how payment works (typically by hour or by code line, there's some leeway here though), what's the maximum budget (specially if the metric is exploitable), the value of which unit of work (defined before) which must not be above the market price.

Contributors are not employees, they don't need to login at 8 and logout at 17 for a fixed wage. In fact, they might not do anything and thus no money be due to them at all. That's why we make a SOW, it makes clear what they can do, how much they can earn, what will not be paid (usually unrelated work) even if they do, and by when they should submit invoices and evidences of the work they did to receive payment.

Do say if there are still questions, I'll be happy to answer and help here.

Regards,

Jonatas L. Nogueira (“Jesusalva”)

On Sun, Jan 28, 2024, 15:59 Kieran Kunhya <kierank@obe.tv> wrote:

...

...

Statements of Work and milestones (by definition) are for features.

The SoW suggestion/need came from a lawyer that jonatas asked IIUC. so i can just suggest to put work like what you list above into a SOW like framework. Or maybe Jonatas can clarify, in case i misunderstood

My point is that ongoing maintenance can't be split into discrete pieces of work, nor arguably can a given timescale be associated with cleanup. For example YUVJ is difficult, until you remove it and see the bugs you don't know how long it will take. This is not suited to the bounty/SoW methodology.

We don't need STF to be funding features, we need maintenance, infrastructure etc which all lends itself to salaried work.

Kieran

While it's true a traditional SOW breaks work into milestones, we're going for a simplified one here out of need. Think on when you ask for consulting, not when you ask for a feature. You should not assume we want to write eg. "Finish removing YUVJ by date X" ─ that's not the plan and as you said it makes no sense (even less when you consider the SOW are individual agreements, and we're likely going to have multiple people working on it). The timeframes aren't "finish X by Y", they're "report what you did by date Y". In a sense, the report is the actual deliverable. The Scope of Work isn't "only touch X", but the conditions on which payment is acceptable (or not). As you said, the sponsorship is for maintenance work, so it should make clear that features aren't eligible (on that SOW at least). Otherwise, someone could make a feature nobody asked for, even less needs it, and want to be paid for it. Or find some busywork which doesn't help in the slightest and come wanting money. So if you had to refactor a whole code because you're working on X, that's fine, but if you decide to refactor the code because you think it's ugly and wanted to refactor it then it might not be what you want to pay for. Or maybe you want, refactoring can improve code readability and no one normally does that. I'm not writing the scope, you are, I at most convert it to legalese when/if required. No one is getting paid for signing a contract and merry be merry, and it's not acceptable to just give money "as we deem fit" (just think of all the possible complaints and hours you'll waste with people questioning why you paid more for A than for B). That would be poor governance, I also doubt STF would be willing to sponsor if there's not even a scope of work. I am attaching a quick example draft (actually a mockup) I made just now in hopes to make it easier to visualize what is expected from the SOW. ****This is not for review, it is for illustration purposes.*** *It is a quick draft/mockup with random information written under a hour just for visualization, and will not be used when the actual SOW is prepared, I just wanted to make it easier to see what I'm thinking about for the SOW. The first thing to prepare is section 2 (Scope of Work), as we need to report it to STF beforehand. It is what STF is (or is not) willing to pay for, and by consequence what FFMPEG is (or is not) willing to pay for. It is the priority, as there *is* a deadline to finish it and deliver it to STF (Feb 12th). Of course, it probably could have said "tasks with a 'maint' label on the issue tracker" or whatever, it's not like I ran this mockup by a legal counsel nor anything. Section 3 and 4 will likely later be required by STF as they have to do their own audit, but this likely can be delayed for after the grant is approved. It also seems to be somewhat controversial at the moment, so I suggest that instead of straying into heated debates over publicity of the invoices, conflicts of interest and whatnot, we focus on securing the funding first (which means the first page of the mockup). After we have a solid scope of work to present to STF, we can worry about how the funds will be distributed (the mockup is hour-based and monthly, but as I said, there are other ways to distribute them) and how the approval process will go. (And in theory, the person could provide their own hourly rate, although I see no reason why anyone would do so). Again, I'm available to answer any questions you may have. And on that note: I believe the same as Michael regarding OFAC restriction as unlike Russia or North Korea, there is no ban against China residents, but we can ask the legal counsel on the specific cases if the need arises. Regards, -- Jonatas L. Nogueira (“jesusalva”) Board of Directors Member Software in the Public Interest, Inc.

Quoting Kieran Kunhya (2024-01-28 20:34:46)

The threading changes took the best part of a year and are still ongoing.

Over two years actually. I started working on it in November 2021. And I agree that estimating the amount of work needed is a HUGE problem, in both directions. -- Anton Khirnov

Also it has to be said, that the example is hypothetical, you are not going to do that work. You seem more interrested in arguing against anything related to SPI

This is a completely false accusation. I have no issues with SPI as an organisation. The hardware I bought and host was reimbursed promptly and efficiently by SPI. I find the attacks (to coin your favourite word) unacceptable. Kieran

Both work fine really. For example iam not employed by FFlabs and the work i did for them is just by sending invoices, while what i do qualifies maintenance probably close to 100%.

Fflabs is a private company that can choose however it likes how to distribute its funds. STF/SPI/FFmpeg are not the same. Would you like every invoice you make to be on this mailing list and discussed in depth in public? And if that invoice was voted against by the GA what would you do? Kieran

Hi Kieran On Sun, Jan 28, 2024 at 08:42:00PM +0000, Kieran Kunhya wrote:

On Sun, 28 Jan 2024, 20:37 Kieran Kunhya, <kierank@obe.tv> wrote:

...

Both work fine really. For example iam not employed by FFlabs and the work

...

i did for them is just by sending invoices, while what i do qualifies maintenance probably close to 100%.

Fflabs is a private company that can choose however it likes how to distribute its funds. STF/SPI/FFmpeg are not the same.

Would you like every invoice you make to be on this mailing list and discussed in depth in public? And if that invoice was voted against by the GA what would you do?

Kieran

Remember the outcry about SDR that literally drove people away from the project? Well imagine that for one of your invoices.

Do you mean it would drive them away because of how much or how little i work for ? Or becuase of what i work for ? I do somewhere have an invoice from a porn related company i should search for that and post it :) but iam not sure i can without that company agreeing too. BUT let me try to return to the topic even if its more fun not to. We have an opertunity here to have some FFmpeg work payed by STF/SPI and we should try to use this oppertunity to pay some FFmpeg developers. Iam sure neither STF nor SPI will mind if we reject all the money. But I dont think thats a very wise choice, so lets rather work towards making a list of projects, agreeing to them and submitting an application to STF before the deadline feb ~ 12th thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB What does censorship reveal? It reveals fear. -- Julian Assange

Please keep in mind we're a public charity using public money from taxpayers, which means we need a criteria for payments and that said payments must be issued objectively. The GA might be able to distribute money with subjective criterias... But not this specific money which is being discussed. I mean, anyone would get mad if their elected officials did that with tax money, so obviously the same will extend here. (Remember the time when an infamous mayor used public money to fix only the roads surrounding his home? Yeah, let's not do this, alright?) If commits are a no-go because FFmpeg has internal governance issues on how those happen, we can think of something else, as long as it retains the objectiveness expected from the use of public money. But we're putting the cart ahead of the horse. Please don't get bogged down by the details, move forward with the scope of work — that's the written version of how STF funds can serve both STF as FFmpeg's purposes. A journey of a thousand miles begins with a single step, if you focus on the future steps you'll trip, fall, and lose the opportunity for the sponsorship. There are only a couple weeks longer to finish the Scope of Work, and that blocks pretty much everything. STF said itself that the other details can be discussed later. Michael: It's not very dissimilar, no. X.Org recently made something similar to Outreachy, the Endless Vacations of Code program (EVoC), if you prefer to make it more similar to that it might be possible. A few things to keep in mind in such a case: The stipend is fixed and agreed beforehand, there are less reports and payments to make, you can only hire in an educational capability (so not the staff you're looking for), it is less suitable for continuous tasks (which was the original issue), and you still need the Scope of Work before it begins. I believe you can actually do both via contracts as via education programs if you wanted, but the latter might be of limited use to you. Att., -- Jonatas L. Nogueira (“jesusalva”) Board of Directors Member Software in the Public Interest, Inc. On Mon, Jan 29, 2024 at 3:32 PM Kieran Kunhya <kierank@obe.tv> wrote:

On Sun, 28 Jan 2024 at 21:47, Michael Niedermayer <michael@niedermayer.cc> wrote:

...

Hi Kieran

On Sun, Jan 28, 2024 at 08:42:00PM +0000, Kieran Kunhya wrote:

...

On Sun, 28 Jan 2024, 20:37 Kieran Kunhya, <kierank@obe.tv> wrote:

...

Both work fine really. For example iam not employed by FFlabs and the work

...

i did for them is just by sending invoices, while what i do qualifies maintenance probably close to 100%.

Fflabs is a private company that can choose however it likes how to distribute its funds. STF/SPI/FFmpeg are not the same.

Would you like every invoice you make to be on this mailing list and discussed in depth in public? And if that invoice was voted against by the GA what would you do?

Kieran

Remember the outcry about SDR that literally drove people away from the project? Well imagine that for one of your invoices.

Do you mean it would drive them away because of how much or how little i work for ? Or becuase of what i work for ?

You refused to acknowledge the public outcry over SDR for months and pushed patches the community clearly objected to (see andreas thread).

That could clearly apply to invoiced work that the community disagreed with. What would you do then? You weren't willing to compromise last time for your hobby, what makes you willing to compromise in that situation?

I mean it basically happened already with SDR, just without an invoice.

"I think you should try to bring the work you want funded into the framework that they told us to use. Instead of complaining"

And now you follow the same tactics with Derek. Accusing people of disagree with you of spreading resentment.

Kieran

Sent from my mobile device

On Mon, 29 Jan 2024, 18:54 Michael Niedermayer, <michael@niedermayer.cc> wrote:

...

You weren't willing to compromise last time for your hobby, what makes you willing to compromise in that situation?

This insult is unacceptable. I just a few days ago stated that i intend to implement SDR within what the community prefers or as a seperate fork. So thats completely the opposit of what i stated

I obviously just dreamt up the most serious schism in the project since the fork. I mean there's SDR related code in git right now, you're literally gaslighting at this point. Kieran

I guess that conculdes the "most serious schism in the project since the fork" until the next most serious ?

If you think that was the sole consequence of your attempt to ram SDR into ffmpeg then I have no words. Kieran

Hi Kieran On Sun, Jan 28, 2024 at 08:37:17PM +0000, Kieran Kunhya wrote:

...

Both work fine really. For example iam not employed by FFlabs and the work i did for them is just by sending invoices, while what i do qualifies maintenance probably close to 100%.

Fflabs is a private company that can choose however it likes how to distribute its funds.

yes, so can microsoft, google, any many others

STF/SPI/FFmpeg are not the same.

yes, they are transparent publically funded, open, ...

Would you like every invoice you make to be on this mailing list and discussed in depth in public?

If it provides entertainment to someone, honestly, i dont care much _BUT_: Thats not implied by SPI/STF here anyone can propose a project under a pseudonym. I belive she would have to provide her real name to SPI & STF but not on the ML and WIKI even with refund requests, I think some people have used pseudonyms so if someone wants some privacy, it can be done. Maybe not 100% against a sophisticated attacker but being employed certainly doesnt provide that either.

And if that invoice was voted against by the GA what would you do?

I would cry ;) seriously, I have said very clearly in my first mail that there can be NO late objections to a STF/SPI Project. objections must be before its submitted to STF. So theres no way the GA could object to an invoice, the GA could object to the project before its started only I do remember this concern from you and the FFlabs CEO. thats why i made sure that this case would not be possible. So no the GA definitly cannot object to an invoice for a project that the GA approved previously. That said I do not belive the GA (which is made of adult intelligent humans) would block an invoice for a project that was previously approved. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already.

...

[...] the GA definitly cannot object to an invoice for a project that

Keep in mind I only receive messages if I'm explicitly in the To field. I'm with only half of the context, so my messages may sound weird, out of context, repetitive, etc. In any case. the GA approved previously.

"The General Assembly is sovereign and legitimate for all its decisions regarding the FFmpeg project."

When working with a contract (and a SOW), the General Assembly won't be able to block an invoice. Because the General Assembly will already have exercised its sovereignty before the work started. And unless the GA becomes a nation, any court of law would uphold the contract. So the first statement which I have no context of would be correct with SPI's approach; the GA would not (realistically) be able to object to the invoice, unless it is in breach of the contract/SOW. (But if it is in breach of the contract or the SOW, then SPI will refuse to pay anyway).

You misunderstand this community. There are disagreements going on for decades.

I've worked with worse. FFmpeg asked to divide the work in milestones, so focus on where you agree with. Whatever there's disagreement, you can always apply later for more funding. (At least from what I've understood). For example, everyone can agree improving code readability is a good thing, even if not how. That's a good start. Ask for funding for it. The "how" can be done later (see the PS).

Would you like every invoice you make to be on this mailing list and discussed in depth in public? And if that invoice was voted against by the GA what would you do?

There's no need for that, you know? One of the reasons to have a SOW is exactly to avoid such fights. After all, the scope of work is decided before (and you need to do this anyway, to ask for STF funding). In an ideal scenario, invoices only need to be checked for legitimacy ─ if the issuer is the one who worked, if the work is on the scope, if the time spent isn't absurd, etc. So there would be no need for the whole assembly to involve itself, unless it's an appeal. But of course, if you want every invoice there, it likely can be done, as long that privacy laws are observed.

I am sure neither STF nor SPI will mind if we reject all the money.

SPI is a public charity, so if you want to reject the money, that is not our problem. We're here to support you if you do decide to accept, though. SPI handles non-technical administrative tasks, after all. Do keep in mind that SPI acts as a fiscal sponsor. This means that we're taking care of all the paperwork involved, but also assuming the risks. So if e.g. some payment is improperly documented and must be returned, SPI has the duty to return it. You can do it with some other entity ─ SPI is a public charity, we honestly don't mind ─ but do keep in mind that if you don't document everything adequately, SPI will not be held responsible if it didn't pass by SPI.

lets rather work towards making a list of projects, agreeing to them and submitting an application to STF

This is pretty much the Scope of Work, and that would account for half of a SOW (and also the most important part of it). One of the reasons why SPI insists on doing the SOW is because we concluded it would present better governance (so less risks for you, for STF, for SPI and for the contributors) and that it would be expedient to do (as you're already going to do the upper half when asking the funding). The bottom part (schedule, deliverables and payment) do need your input on what works best for FFmpeg, but ultimately it is mostly operational guidelines expected from contributors and SPI alike. *When do you want contributors to report their work, and how?* *How will the due amount be calculated? When should the invoice be sent? When should it be paid?* That's pretty much what's required to fill out the proposed SOW. If you cannot get a scope of work, you definitely cannot get funding (and if you get funding, then what you used is most likely an acceptable scope of work, so it likely won't need changes either). If you cannot decide the other details, then odds of being required to return the money are high. Asking for a SOW might sound like asking for a lot of work, but it is paperwork, and you can count on SPI to do paperwork for you. But SPI acts on your behalf (and never you on SPI's behalf), so you do need to instruct us on how you want it to look like. "How can SPI and the contractor know that something on the invoice is (in)adequate?" That's the sort of thing the bottom of the SOW worries about. And I already said this earlier, but the bottom part is not important right now. Securing funding and the scope of work take precedence. In the worst case, we can just ask our attorney to draft the SOW altogether. He'll make a few questions, you answer them, and we use whatever comes out of that. SPI is here so paperwork doesn't block you, and if paperwork does block you, then SPI will not be doing a very good job, right? PS. in the code refactoring example, usually whatever procedure you use to transform a PR/MR into a commit is ideal. I like using commits as deliverables because most projects have all their internal governance set before it is merged. So when it becomes a commit (on master branch), it means the project as a whole already agreed with it. I'm not sure how FFmpeg does this, though, that's a problem for you to figure out and not for an outsider to intervene. Also, sorry if I'm seen to be overstepping my bounds here. I, as well as the whole SPI Board, wish you to succeed. However, I admit my enthusiasm might have gotten the best of me in some earlier messages. That aside, I do hope the SOW is slightly more clear and easier to understand now. -- Jonatas L. Nogueira (“jesusalva”) Board of Directors Member Software in the Public Interest, Inc.

...

...

[...] the GA definitly cannot object to an invoice for a project that the GA approved previously. "The General Assembly is sovereign and legitimate for all its decisions regarding the FFmpeg project."

When working with a contract (and a SOW), the General Assembly won't be able to block an invoice. Because the General Assembly will already have exercised its sovereignty before the work started. And unless the GA becomes a nation, any court of law would uphold the contract.

In this project, acceptance of a patch is based on the technical contents of a patch, not a few vague paragraphs in a SoW. These decisions are made by the Technical Committee and the General Assembly. Tying the project contractually is unacceptable. There are plenty of "corporate" open source projects where this is fine, but there is a reason we are not one of those full of corporate friendly code like binary blobs, intrinsics, SDKs etc. Kieran

Again, this sounds like a misunderstanding. The SOW is subservient to the merge, not the other way around. In other words, the SOW don't require you to merge, but when/if you do merge, then the SOW will require the payment to the contractor, which SPI handles. So the SOW makes clear that if FFmpeg refuses to merge, there'll be no payment. This is also why there's no need to review the invoices, and no risk of a legitimate invoice being rejected: Because the deliverable will likely be the commit (unless the GA objects beforehand and asks SPI to use something else), so until it (the MR/PR) is accepted, there's no invoice to start with. And as STF is footing the bill, there's no reason to FFmpeg concern itself if it turned out expensive or not when reviewing, and can focus in actually improving the program (SPI and STF will place some budget limits, so contributors/contractors know what to expect and the money won't run out). The goal of the SOW (and of having SPI onboard) is to allow the GA to focus on stuff actually relevant to FFmpeg (like what's going to be merged) and delegate the worldly concerns like payments and contracts to SPI. Who is signing the contracts (and thus being bound and tied to it) is SPI. This is why it sounds a lot like a misunderstanding. What is actually required from the GA is what the GA does — managing and leading FFmpeg. That means deciding aspects which SPI cannot and will not decide for you, like the scope of work ("what do you want done and sponsored by STF?"), and what SPI cannot answer for you (such as how FFmpeg does things). Do note that if someone do a MR/PR and then the technical committee or the GA refuse to merge, without a SOW, almost every court (in the US or in Germany) will force FFmpeg to pay not only the invoice but also the legal costs. That would be unacceptable for SPI, as it puts other projects in risk as well. We must kindly request that FFmpeg's General Assembly avoid such dangerous behavior. Feel free to make any other questions you may have, Att., Jonatas L. Nogueira (“Jesusalva”) SPI Board of Directors On Mon, Jan 29, 2024, 12:02 Kieran Kunhya <kierank@obe.tv> wrote:

...

...

...

[...] the GA definitly cannot object to an invoice for a project that the GA approved previously. "The General Assembly is sovereign and legitimate for all its decisions regarding the FFmpeg project."

When working with a contract (and a SOW), the General Assembly won't be able to block an invoice. Because the General Assembly will already have exercised its sovereignty before the work started. And unless the GA becomes a nation, any court of law would uphold the contract.

In this project, acceptance of a patch is based on the technical contents of a patch, not a few vague paragraphs in a SoW. These decisions are made by the Technical Committee and the General Assembly.

Tying the project contractually is unacceptable.

There are plenty of "corporate" open source projects where this is fine, but there is a reason we are not one of those full of corporate friendly code like binary blobs, intrinsics, SDKs etc.

Kieran

...

Hello Kieran On Mon, Jan 29, 2024 at 03:02:24PM +0000, Kieran Kunhya wrote:

...

...

...

[...] the GA definitly cannot object to an invoice for a project that the GA approved previously. "The General Assembly is sovereign and legitimate for all its decisions regarding the FFmpeg project."

When working with a contract (and a SOW), the General Assembly won't be able to block an invoice. Because the General Assembly will already have exercised its sovereignty before the work started. And unless the GA becomes a nation, any court of law would uphold the contract.

In this project, acceptance of a patch is based on the technical contents of a patch, not a few vague paragraphs in a SoW. These decisions are made by the Technical Committee and the General Assembly.

Tying the project contractually is unacceptable.

"the FFmpeg project" is not a legal entity, so thats probably not even possible if one wanted. Also FFmpeg has been part of Google summer of code for many many years and also in the past in outreachy. All these projects payed "students" for work they did. From a legal point of view, these are probably very similar Mysteriously, there was a total absence of similar drama there. I wonder how it could have been possible to do that for over a decade with not one instance of drama or problems like here. We had students passing the mentors review, being paid but code was found not be clean enough yet for git master and was not yet merged I remember no fight about any such case. There also where the normal cases where students failed to reach the goal and did not get paid abd code was not merged, and the ones that succeeded got paid and code was merged.

There are plenty of "corporate" open source projects where this is fine, but there is a reason we are not one of those full of corporate friendly code like binary blobs, intrinsics, SDKs etc.

Iam glad there is one thing we agree on :) thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship: All citizens are under surveillance, all their steps and actions recorded, for the politicians to enforce control. Democracy: All politicians are under surveillance, all their steps and actions recorded, for the citizens to enforce control.

Le maanantaina 29. tammikuuta 2024, 19.27.14 EET Michael Niedermayer a écrit :

Also FFmpeg has been part of Google summer of code for many many years and also in the past in outreachy. All these projects payed "students" for work they did. From a legal point of view, these are probably very similar

Mysteriously, there was a total absence of similar drama there. I wonder how it could have been possible to do that for over a decade with not one instance of drama or problems like here.

Google funding GSoC students to work on FFmpeg. And nobody objected agains the core idea of STF funding developers to work on FFmpeg. The "drama" is about how and through whom the funding goes. That drama couldn't be had for GSoC because how was however Google decides, and there was no intermediary to go through (money went straight from Google to the students). -- レミ・デニ-クールモン http://www.remlab.net/

Le maanantaina 29. tammikuuta 2024, 20.11.19 EET Michael Niedermayer a écrit :

...

The "drama" is about how and through whom the funding goes.

ok, elaborate please

All FFmpeg money has always been handled through SPI or associated entities

It was already a bit of a stretch to compare GSoC students with (hypothetical) STF subcontractors. So sorry but I simply don't think that the funding for mentors is comparable at all. In fact, it seems completely normal for the GSoC mentor funding to go via open-source foundations, and other GSoC projects presumably operate the same way.

Its under the control of the community and its transparent

You always have the control of the community at the time of review and merge. You can argue all you want that more open is better. What I see is that this more open is already turning into a train wreck (as predicted last year).

And very important what do you propose ?

We already went through this in the previous thread last year. This is not going to work in the light of what Jonatas politely calls FFmpeg "governance" challenges. It was already clear that finding agreement within the GA would be at best very difficult and untimely. People (including myself) already suggested to arrange that sort of things via an IT service company (*not* necessarily FFlabs). Or you could even go through a "porting" company in your country if you can't find an existing agreeable company and don't want to register your own. Of course those are not perfect solutions but they seem far less fraught with problems than going through a foundation, especially a US-based foundation. You can review the archives for details. And it certainly does not help that this only became public so late in the process, which is intrinsically suspicious.

Should we reject the maybe 200k € grant we could get from STF now ?

Again, nobody objected to getting funding from STF as such.

...

That drama couldn't be had for GSoC because how was however Google decides, and there was no intermediary to go through (money went straight from Google to the students).

SPI handles all the GSoC mentor money. And lets just assume it would handle the students money too, what difference would that really make ?

It would cause similar arguments to this one. And that's if Google would even agree to such a setup (which I guess they wouldn't). What is the point of going through SPI for *this* (as opposed to regular donations)? -- レミ・デニ-クールモン http://www.remlab.net/

Le 30 janvier 2024 00:43:39 GMT+02:00, Michael Niedermayer <michael@niedermayer.cc> a écrit :

Hi

On Mon, Jan 29, 2024 at 11:01:05PM +0200, Rémi Denis-Courmont wrote:

...

Le maanantaina 29. tammikuuta 2024, 20.11.19 EET Michael Niedermayer a écrit : [...]

...

Its under the control of the community and its transparent

You always have the control of the community at the time of review and merge.

You can argue all you want that more open is better. What I see is that this more open is already turning into a train wreck (as predicted last year).

I do have to disagree on this specific point The people predicting it to be a train wreck are the people who now make it a train wreck.

That's clearly false and defamatory against me. And given that you were the one to ask for feedback and project ideas that also constitutes entrapment. You should step down from the CC IMO because that's very unbecoming of a CC member (as are your attacks against Kieran) In these conditions I maintain that this process is inane and discriminatory. Lastly the FFmpeg community should bot to be taken hostage in one person's personal feud against FFlabs and/or other companies. (This is purely hypothetical and not an accusation against anyone in particular. If you feel targeted, that's on you.)

Hi Rémi On Tue, Jan 30, 2024 at 08:30:56AM +0200, Rémi Denis-Courmont wrote:

Le 30 janvier 2024 00:43:39 GMT+02:00, Michael Niedermayer <michael@niedermayer.cc> a écrit :

...

Hi

On Mon, Jan 29, 2024 at 11:01:05PM +0200, Rémi Denis-Courmont wrote:

...

Le maanantaina 29. tammikuuta 2024, 20.11.19 EET Michael Niedermayer a écrit :

[...]

You should step down from the CC IMO because that's very unbecoming of a CC member (as are your attacks against Kieran)

If you believe i have done something wrong towards kieran, you should contact the CC about it. I will certainly not vote on myself. But i will also not back down from my position that 1. STF is a great oppertunity for FFmpeg, and people should be thankfull for the chance to get a ~200k € grant. Not fighting 2. If we dont mess it up now, we will have future opertunities If we act like we do ATM there maybe will not be.

In these conditions I maintain that this process is inane and discriminatory.

Then we should work together to make it better as soon as thats practical

Lastly the FFmpeg community should bot to be taken hostage in one person's personal feud against FFlabs and/or other companies. (This is purely hypothetical and not an accusation against anyone in particular. If you feel targeted, that's on you.)

I dont feel targeted. No For the record, i multiple times pushed for compromises between the party hating FFlabs and the party leading it. On one day i chatted for 6 hours with the one not liking FFlabs to try to find a solution. I dont think i succeeded but i tried. So no, i do not hate FFlabs. FFlabs pays me, and iam thankfull for that. That said, I do have disagreements related to FFlabs but that does not belong here. What i can say about FFlabs is that I believe SPI is the better entity to handle FFmpeg Grants, Donations and FFmpeg funds in general. Like anton suggested SPI could pass money on to FFlabs for individuals who want to be working through FFlabs (or another company). I dont see a problem there, From the point of view of STF/SPI the company is the contractor doing the work, how teh company internally handles it is a matter within teh company. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus

On Mon, 29 Jan 2024, 22:23 Cosmin Stejerean via ffmpeg-devel, < ffmpeg-devel@ffmpeg.org> wrote:

...

On Jan 28, 2024, at 7:54 AM, Kieran Kunhya <kierank@obe.tv> wrote:

So work like Anton's threading, YUVJ removal etc, that couldn't be funded via bounties as they have no direct commercial value but require expertise in the codebase. Statements of Work and milestones (by definition) are for features.

I'm not sure those are the best examples to make that point given that both multi-threading and YUVJ removal were funded by commercial SOWs.

- Cosmin

A commercial SOW with a private company that took the commercial risk on that contract taking longer or being more difficult than anticipated or someone else doing the work without telling them. The terms of that contract were discussed in private and don't affect the project itself. Kieran

On Tue, 30 Jan 2024 at 10:12, Nicolas George <george@nsup.org> wrote:

Kieran Kunhya (12024-01-29):

...

A commercial SOW with a private company that took the commercial risk on that contract taking longer or being more difficult than anticipated or someone else doing the work without telling them.

The terms of that contract were discussed in private and don't affect the project itself.

It does not affect the project itself except in resulting in a patch series that was developer all alone, wasting the benefit of having several competent people contributing ideas for the core design, and an attitude of urgency and closed-mindedness for anything that would delay applying the series once it was posted, even if it was severe breakage of features.

The patches were on the mailing list for months, there was a presentation at VDD (livestreamed too). Though you are proving my objections to this statement of work fallacy which is great. Kieran

On Tue, 30 Jan 2024 at 10:31, Nicolas George <george@nsup.org> wrote:

Kieran Kunhya (12024-01-30):

...

The patches were on the mailing list for months, there was a presentation at VDD (livestreamed too).

“But Mr. Dent, the plans have been available in the local planning office for the last nine month.” — Douglas Adams

So you agree the proposed Statement of Work idea in this thread isn't going to fly as it won't cover actual code review? Kieran

On Tue, 30 Jan 2024 at 10:46, Nicolas George <george@nsup.org> wrote:

Kieran Kunhya (12024-01-30):

...

So you agree the proposed Statement of Work idea in this thread isn't going to fly as it won't cover actual code review?

If that is what you read in what I wrote, I suggest you take reading lessons intended for an early age.

Thank you for proving my point that you will be the first to block a Statement of Work. Kieran

...

On 1/28/2024 3:25 AM, Michael Niedermayer wrote: As others have said, the whole model of using discrete projects here seems opposed to the actual intent of the STF - maintained and stable OSS long term.

The whole suggestion here is based on what STF and SPI said. There was a conference between SPI and STF where they worked the details out. Also all the things SPI told us had STF in CC.

What SPI convinced STF is best is not necessarily the same. Also notably missing here is the community (as in, more than just Thilo) having any access to review, comment, or help direct this.

I think you should try to bring the work you want funded into the framework that they told us to use. Instead of complaining

Vibes of "shut up and stop dissenting". Nice. I will not be sending any more replies.

...

Furthermore, we *already* have a bunch of money sitting in SPI funds that *is* suitable for use on discete projects, but it never gets used. It is a poor way to encourage useful work, IMO.

Theres a very big difference. we have around 100k USD in SPI

STF has a lower limit of 150.000 € so we actually need to ask them for at least 150k to be qualified IIUC And honestly if you reject that, i just dont understand you. "Estimated costs: The cost of the work described in the application must exceed €150,000 (current minimum)."

AT no point could we have done anything with SPI money in a similar magnitude. In fact trying to use SPI money for any work failed because of it not being enough.

I have yet to see an actual project of "this magnitude" materialize as a proposal. - Derek

On Mon, Jan 29, 2024 at 8:22 PM Michael Niedermayer <michael@niedermayer.cc> wrote:

...

I have yet to see an actual project of "this magnitude" materialize as a proposal.

you can suggest one ?

libavscale! or there is nothing you want improved in FFmpeg ?

Or only if SPI isnt involved or iam not sure what exactly you want different ?

I, for one, would love to stop seeing flame threads about funding FFmpeg that lead to nowhere. This is not something that should be discussed on a public ML and the lack of visibility and clarity on how SPI/STM got involved this time around is at least disingenuous IMO. -- Vittorio

Le 29 janvier 2024 22:15:39 GMT+02:00, Derek Buitenhuis <derek.buitenhuis@gmail.com> a écrit :

Between this, the unaswered NAB questions, the second vote ridiculousness, the accidental email to the ML from Thilo where he admits he has purposely not replied, etc.,

Also - Reject FFmpeg project's free invitation to SCaLE because he wouldn't participate, rather than pass it on.

On 1/29/2024 8:19 PM, Anton Khirnov wrote:

I, for one, see a much bigger problem in the fact that it only starts being discussed on the ML this late, after so much underground dealings that bypassed the community entirely.

+1 - Derek

Hi On Mon, Jan 29, 2024 at 09:36:27PM +0100, Vittorio Giovara wrote:

On Mon, Jan 29, 2024 at 9:19 PM Anton Khirnov <anton@khirnov.net> wrote:

...

Quoting Vittorio Giovara (2024-01-29 21:09:42)

...

This is not something that should be discussed on a public ML

Where do you think it should be discussed then?

IMO anywhere with a more limited set of constituents, such as the GA or the technical committee.

For the record, the group that was contacted initially by STF was everyone on the consulting page at the time. This probably made sense to STF as they after all wanted to fund people working. And that page would supposedly list everyone who was available to do work. From there on mainly only one person cared and continued to work on this. For the record, the list of people on the CC also evolved over time, one from STF was added, some people seemingly having no interrest disappeared multiple people related to SPI where added. I guess i understand why noone wanted to send this to the ML and i had to ... seriously, i dont think anyone had any bad intend here. Yes i wanted it on the ML long ago and others wanted to first make sure this was real and actually possible. This ended up being 2 weeks before the next STF meeting but really everyone just tried to do what they thought best for FFmpeg thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong.

On Mon, Jan 29, 2024 at 9:10 PM Vittorio Giovara <vittorio.giovara@gmail.com> wrote:

On Mon, Jan 29, 2024 at 8:22 PM Michael Niedermayer <michael@niedermayer.cc> wrote:

...

...

I have yet to see an actual project of "this magnitude" materialize as a proposal.

you can suggest one ?

libavscale!

Not being a regular, this may not count for much. But this sounds like a great opportunity, lets not pass it up. Projects i have seen on the mailing list over the last two years or so that i remember and should be of interest: - swscale rewrite/update/extension - deal with the libavdevice situation - remove postproc - Nicolas various utility proposals for strings, options, etc - hell, even a better infrastructure for dealing with incoming patches and tests surrounding them, using pull requests, automatic CI fate runs upon incoming pull requests, etc. These are issues that are either maintenance or infrastructure work, unlikely to be funded by companies, but can help the whole project forward. I know a bunch of these are contentious, but they are worth exploring. You all probably have ten more better ideas since you know the project better. Please focus on getting something together. I fail to see serious issues. This is not a vehicle for some company interest or closed source interest to influence the project. This is not a vehicle for some unpopular minority opinion on a direction the project should take to get pushed through. This is not unfair in its distribution by nature--suggest something you'd like to work on, this is a good chance to get it funded. I understand there are potentially legitimate issues around project management that come up here again. Of course these should be discussed. But do so in parallel to moving forward and putting an application together. All the best, Dee

On date Monday 2024-01-29 22:11:49 +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.

...

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.

These are, IMO:

The following are good points, I propose some possible solutions. I think these should be based on the assumptions that failure can occurr, and the system should be designed to be robust to failures.

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.

The design and investigative work should be covered as part of the SOW. In other words, the SOW should also cover the preliminary design and experimentation. In case it leads to no committable work (which is unlikely but not impossible), the output should be a document/report documenting the result of the initial investigation, and the project might be aborted at that point. This should protect both the developer and the project. In each case it should be assumed that the final result of the investigation would not lead to committable deliverables, but to design documents which might lay the foundation of further work (possibly in a different direction).

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.

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?

Assuming a SOW can be split in several parts, the first one being the initial investigation, and assuming that the developer can split her work in parts, and that only the first one (the one about the initial investigation) can be invoiced in case there is no consensus about the actual implementation. Again, I don't think this is very likely to happen, but we should have a mechanism to handle this (and protect both the project and the developer committing the work), in order to minimize the risk.

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.

The amount of money might be defined based on economic parameters related to the living country of the developer and according an estimated amount of time. This is not perfect but it's probably the best we can come around. As per the final decision (e.g. in case there is no community consensus after the investigatory stage) probably the Technical Committee should be involved. This assumes that once the TC committee reaches a decision, this cannot be reverted. At the end this is one of the reasons why the TC exists in the first place, use delegation to reach consensus in case the overall community cannot find it.

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.

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.

Also it would probably help to define the areas for the candidate projects, I can think several things related to documentation for example like completing/reviewing the documentation for the missing parts which belong to low-risk area (note: I would not be able to apply for any SOW given my employment status). Probably it would help, if rather than discussing these things in general, we would have some concrete project and candidate to get a measure of what it could be like. I hope that if even we don't end up with enough proposals, this should help to gain more experience to understand what can and cannot work.

On date Wednesday 2024-01-31 13:30:50 +0100, Anton Khirnov wrote:

Quoting Stefano Sabatini (2024-01-30 00:53:25)

...

On date Monday 2024-01-29 22:11:49 +0100, Anton Khirnov wrote: [...]

...

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.

The design and investigative work should be covered as part of the SOW. In other words, the SOW should also cover the preliminary design and experimentation. In case it leads to no committable work (which is unlikely but not impossible), the output should be a document/report documenting the result of the initial investigation, and the project might be aborted at that point.

This should protect both the developer and the project. In each case it should be assumed that the final result of the investigation would not lead to committable deliverables, but to design documents which might lay the foundation of further work (possibly in a different direction).

That might be a viable direction, but it does not really solve the problem. Initial investigation only gets you so far and some issues simply do not become apparent until quite far in the development process.

E.g. my recent threading work (that keeps getting mentioned in this thread as an example of what a cleanup project could look like) was largely composed of many "sub-projects", each disentangling a specific feature or area. And there was no reliable way to predict in advance whether a given sub-project would take two hours or two weeks.

So let's tweak the format. It might be formulated as something as: --------------8<---------------------------------------------------- This project covers doing this and that. It will be split in several stages lasting a given amount of time (e.g. two months per each stage). At the end of each stage the developer will provide a report giving an overview of the findings and of delivered code, which will be the subject of the invoice. --------------8<---------------------------------------------------- In this way we drop the requirement on achieving a specific goal in terms of committed code, and require instead a report to document the changes/finding (which will be subject to validation). Maybe José can provide some guidance about the viability of this specific format. Assuming this format is acceptable on the STF/SPI side, the next problem is to understand who is going to provide the validation based on the report. The SPI liaison might be involved but only to sign-off, not to provide the actual validation, which must be agreed upon by the project according to some agreed internal procedures. Other issues might arise in case the work is delayed due to various circumstances (e.g. the developer getting sick or having other external impediments or having more urgent tasks to attend). In this case I can foresee a few possible outcomes: the developer will delay sending the invoice, or the invoiced sum is reduced accordingly. It seems to me we need to design these validation processes in advance or we risk to turn each invoice delivery into a potential flamefest.

Hi all I just now realize you already CC-ed jonatan and he already awnsered sorry for the noise On Tue, Jan 30, 2024 at 01:15:54AM +0100, Michael Niedermayer wrote:

Hi Anton,

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

[...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Whats the most studid thing your enemy could do ? Blow himself up Whats the most studid thing you could do ? Give up your rights and freedom because your enemy blew himself up.

IMO hasty actions and avoidable drama may cause damage to the project

What would be a hasty action? I've seen far too much people calling action over stuff discussed for weeks/months as "hasty" in attempt to stall into endless discussions, so you might want to clarify.

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.

So you're basically saying the developers have to take the risk onto

Given the current goal is to fund continuous maintenance tasks, it'll only be a large problem with unpaid people if final state isn't better than initial (eg. code gets more bloated instead of less). Otherwise, even if some specific task cannot be completed, that's not an issue by itself, the time already spent can be paid, as long that there's something to show for it. (That's also an issue, but thankfully a debate for later). Of course, if everything ends up unfinished that'll only scream you're terrible at planning or outright don't know what you're doing. Repercussions could make harder for you to acquire funds in the future and likely comments that SPI should follow its projects more closely. So mixing some easy but boring tasks is definitely a good idea. themselves Could you explain what exactly the risk devs are taking is? I can help if you can make the usual risk assessment table (what risk, likelihood, and impact/consequence).

it's widely acknowledged that accurate time estimates for complex projects are somewhere between extremely hard and unfeasible.

developers will try to protect themselves by playing it safe and budgeting for the largest amount of time they think they might

I don't think a year is a question of accuracy, it usually indicates that the code is becoming lasagna (if no result can be provided), ravioli (if result can be provided but it doesn't work) or spaghetti (when it can be provided and works... sometimes). That sounds exactly like a good use for a maintenance grant, identifying where the existing code base is problematic and trying to tidy it up. That's also not something you can say "will be done by X", it's just something you pour hours and hope end result is easier to work with than the previous state (even if it's still pasta). That's why the Scope of Work (which is the current task) for this is less concerned in end results or deadlines, but in goals which can be attained within a time frame (even if they're "making better" or can only be partly attained, which would cause STF to believe you to be overambitious but is not as problematic as not attaining anything at all). possibly need. Which means in most cases they will need less time, sometimes significantly less. Would STF be okay with us being so wasteful? No one is going to get paid according to their budget, the payment is over how much time they actually spent. Budget is a limit, so the developer has a good idea since the start of how long they can take. If they notice it'll go over budget, they can stop, reevaluate and propose new budgets or partial deliveries (or whatever the GA/STF decides to be acceptable). More often than not, they'll have run in an unforeseen issue which could warrant a fund/budget on its own. So if you budget 15 hours and work 5, you'll be paid for 5 and the surplus of 10 hours can be given to other projects or assigned somewhere nearing over budgeting so it can be finished (or at least, delivered).

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.

I agree it's impossible to know, and I am sure STF is aware of that as well. That's also why particulars usually don't fund these things, but public funds like STF are willing to. But there will be no overpayment, as you're paid for what you do (up to budget). If you finish with less than budgeted, that means the surplus can be used to clean another code. (And if there's a concern of fake hours, there are mechanisms which can be used and can be discussed later, after the budget is made, which is after STF returns their approval and the exact terms). I hope this addresses some of your concerns. Att., Jonatas L. Nogueira (“Jesusalva”) On Wed, Jan 31, 2024, 09:59 Anton Khirnov <anton@khirnov.net> wrote:

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

...

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

My understanding of your 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

On Wed, 31 Jan 2024 at 14:10, Jonatas L. Nogueira via ffmpeg-devel < ffmpeg-devel@ffmpeg.org> wrote:

...

IMO hasty actions and avoidable drama may cause damage to the project

What would be a hasty action? I've seen far too much people calling action over stuff discussed for weeks/months as "hasty" in attempt to stall into endless discussions, so you might want to clarify.

The FFmpeg community was told about this three days ago. Kieran

Forgot to mention, but you also don't need to set the values yourself. You can simply post "we're looking to have X task done, interested parties please send us a quote" and see if it fits the budget. -- Jonatas L. Nogueira (“jesusalva”) Board of Directors Member Software in the Public Interest, Inc. On Wed, Jan 31, 2024 at 1:00 PM Jonatas L. Nogueira <jesusalva@spi-inc.org> wrote:

...

The FFmpeg community was told about this three days ago.

Fair enough if it's true (I'm an outsider, after all)

...

There are arguments in this very thread how we cannot discuss things in detail and must instead ACT NOW OR ALL THE MONEY IS GONE. Naturally this makes the mood more tense, especially given the other circumstances.

What I noticed (as an external observator), was putting the cart ahead of the horse. There's no money right now, but STF is willing to grant around 200k if FFmpeg is able to submit a Scope of Work in time for their meeting (happening on Feb 14th, materials however should be submitted 48 hours before). The scope of work is, in other words, a letter of intentions of what to do with such money. They have already informed about the restrictions (e.g. should be maintenance or security related, that it is too early to ask for feature projects but it might be possible in the future, etc).

A Scope of Work is a bit more than a wishlist because it assumes the work is actually going to be done, so it cannot be too overambitious. That's what needs to "act now or all the money is gone". The question currently presented is, "if FFmpeg had 200k euros to work with maintenance, what would FFmpeg do?" ─ this will become the Scope of Work (we can have people to word it into legalese later, if needed).

Of course, all that will end in a Statement of Work (SOW) later, describing how the wishlist in the Scope of Work will be attained as everyone knows that money doesn't magically solve problems. And from what I've seen as an external observer, there is a lot of discussion pending for this. But that's alright, there's probably over a month for that. Of course, without a Scope of Work, there'll be no SOW, and any discussion made on this will become a waste of time.

If I were the one doing it... I would first make a wishlist in a shared document with all tasks eligible (3~5 days, so completion until Feb 5th latest). There are time constraints, though, and FFmpeg takes decisions collectively, so... I would make a vote between Feb 5th and Feb 12th (yes, the deadline) to elect the tasks which will be on the Scope of Work. I would improvise a bit: ask the submitted tasks to also have a proponent (who is asking for the task to be done) and a budget (how much money the proponent thinks that will be enough to attain it). The budget here is nonsense, it is just to have a metric to decide how many options will go to the Scope of Work. The proponent is to answer questions the voters may have.

With that laid out and once in motion, the remainder of discussion would be held. How much to pay the contributors, the actual budget for the approved projects, how it'll be tracked, what's more fair for deliverables, how they'll be checked, if you'll contract the developers directly or with an intermediary, etc. There's no point discussing any of that unless you're sure the scope of work can be delivered in time. Multiple Statements of Work are also possible, so there's no actual need for one-size-fits-all in those questions. If project A, B and C can be divided into commits but project D cannot, it's fine to have different rules for project D. Also why it doesn't make much sense to hold these discussions now, when you can't even answer what would be the projects.

That, however, is not my call. I can provide suggestions, but actually coming with a Scope of Work in time is yours and yours alone.

...

So far it does not seem we have an abundance of volunteers, so it seems more likely we'll struggle to spend all the money.

Coincidentally, that happens a lot. No reason to let it hinder you, though, having money gives the option to make job postings, and you might even be able to ask for help in spi-general list.

...

only a minority of time is spent typing code.

Don't I know it... I'm also a programmer for The Mana World, pretty familiar with "I changed a couple lines and now nothing works, spend two hours trying to figure out that I forgot a curly brace".

That is among the discussions I believe FFmpeg should have, although you might want to have the Scope of Work rolling before starting this. (And there are many possible solutions, so I expect quite some time to be spent finding all of them and picking out the best one).

If you start discussing how to properly pay for the hours spent hunting simple typo mistakes now, you'll never be able to tell STF what actually needs to be done in time.

-- Jonatas L. Nogueira (“jesusalva”) Board of Directors Member Software in the Public Interest, Inc.

On Wed, Jan 31, 2024 at 12:17 PM Kieran Kunhya <kierank@obe.tv> wrote:

...

On Wed, 31 Jan 2024 at 14:10, Jonatas L. Nogueira via ffmpeg-devel < ffmpeg-devel@ffmpeg.org> wrote:

...

...

IMO hasty actions and avoidable drama may cause damage to the project

What would be a hasty action? I've seen far too much people calling action over stuff discussed for weeks/months as "hasty" in attempt to stall into endless discussions, so you might want to clarify.

The FFmpeg community was told about this three days ago.

Kieran

I take that to mean that SPI has been involved with those discussions for months in a private and closed process

Not really, however STF did ask for a meeting with SPI concerning the possibility to sponsor FFmpeg on January 18th (so roughly two weeks ago). To make clear, the request was on the 15th, the actual meeting on the 18th. There was some back-and-forth between both, Thilo and Michael commented on some specifics as STF or SPI asked, and we concluded SPI could indeed receive a sponsorship from STF on behalf of FFmpeg project on January 23th. Not long after, STF confirmed to SPI that it would be discussed in Feb 14th internally and that FFmpeg should send a Scope of Work by the 12th in order to confirm the sponsorship. That request was sent on Jan 25th. I'm not sure when this information was sent to this mailing list, but Michael and Thilo were informed on the same day. That's what happened recently on the SPI side in any Earthly time metric. But I should mention that in July 2023, Stefano and our contractors reached out to me and the vice president asking for, among other things, the Master Service Agreement which SPI uses and some general and everyday discussions about SPI policies regarding the payment of individual contractors/developers. I believe they also mentioned the possibility of getting a sponsorship from STF in the future, but discussions were centered on how SPI could pay for individual developers, which is why I didn't remember about this until I searched for it today. I guess you could say SPI was "aware" of the possibility since then. The first and last message from this message chain were on July 11th and July 23rd respectively, although I assume they made questions to non-board members before reaching out for SPI's VP and me. There was no further contact with SPI about that between July 24th and January 15th. Miscommunication happens. Do not assume malice, if you need any further information from SPI just reach out, we'll be happy to provide.

misrepresent any challenge to SPI proposed *process* as an attempt to reject the idea of STF sponsorship, under the convenient pretext that there is not enough time.

Just in case, it was STF who asked for a Scope of Work to be presented by February 12th. I'm pretty sure it is possible to ask them about the possibility of postponing the topic for their next meeting (which I assume to be in March) ─ STF may decline, though, and it might not be possible to turn back on this decision or postpone further. I'm not STF's contact, it is someone from FFmpeg who is, so they'll need to do this. (also why I didn't mention that earlier). SPI is not conducting these discussions, after all. That's something you have to decide by yourselves.

This is ostensibly being to ignore all the objections that were already brought in October [...]

SPI is not aware of any such objections.

But that will take place without the consent of the GA

I'm not sure SPI would accept the sponsorship from STF without the consent of the GA, although we do expect to hear from Stefano the position FFmpeg is going to take. Which does mean that if STF sends funds to SPI but Stefano says he doesn't know what they're about, SPI will return the money post-haste (and will be less willing to receive potentially unwanted money later, as returning funds is not without costs).

I have to infer that Thilo, Michael and SPI already knew of the STF plan and concealed that key piece of contextual information back then.

I can only agree with Anton that this looks like an attempt to strongarm

SPI usually doesn't *do* anything until it is asked to. We were aware in July 2023 that FFmpeg was considering asking STF about a sponsorship, although we weren't informed of whatever happened until STF asked for a meeting with us on January 15th. (Some of the SPI Board members even presumed FFmpeg had given up and forgotten altogether). the community. SPI is not trying to strongarm you into anything. Unless you try to do something illegal and we're required by law to intervene, I guess, which was discussed (e.g. "can the GA refuse to pay an invoice which is due?", which I made clear SPI would pay the invoice despite the objection, because the law requires it to be done). SPI as a rule of thumb does not interfere in its projects' management and decisions. If you want to give up on the sponsorship we'll honor the decision, if you want the sponsorship in different terms we can discuss if it's possible (and if it's not, SPI will not accept, because as I said earlier SPI is bound by the law). And if you want for more time to discuss, you should be asking that to STF, I can only help you as an agenda UNDER THE PRETENSE that FFmpeg is actually interested in meeting with STF request. If FFmpeg is not interested in attending STF's request of delivering them a Scope of Work by February 12th, I'll stop posting agenda-like reminders or suggestions. Att., -- Jonatas L. Nogueira (“jesusalva”) Board of Directors Member Software in the Public Interest, Inc. On Wed, Jan 31, 2024 at 1:11 PM Rémi Denis-Courmont <remi@remlab.net> wrote:

Hi,

Le keskiviikkona 31. tammikuuta 2024, 16.10.02 EET Jonatas L. Nogueira via ffmpeg-devel a écrit :

...

...

IMO hasty actions and avoidable drama may cause damage to the project

What would be a hasty action? I've seen far too much people calling action over stuff discussed for weeks/months as "hasty" in attempt to stall into endless discussions, so you might want to clarify.

Would you care to clarify which astronomical body do you count weeks and months in? I believe that it is customary to use Earth units when you do not specify. And in this case, the topic was brought to the community just about 0.5 week, or 0.11 month ago.

Sarcasm aside, I take that to mean that SPI has been involved with those discussions for months in a private and closed process. Michael asserted that an open inclusive process is better than the usual closed approach whence the funding goes through a company.

It looks to me that those SPI discussions were just as opaque and closed, and all the talk of openess is just pretense. It does not help that Michael, and now you too, misrepresent any challenge to SPI proposed *process* as an attempt to reject the idea of STF sponsorship, under the convenient pretext that there is not enough time.

This is further aggravated by the context that Michael brought forward the idea of funding developers through SPI 3 months ago (in actual Earth units). From your statement, I have to infer that Thilo, Michael and SPI already knew of the STF plan and concealed that key piece of contextual information back then.

In hindsight, it feels hypocritical to me that they were arguing for the SPI path, and against the corporate path, on the basis of openess already then, to be honest.

I can only agree with Anton that this looks like an attempt to strongarm the community. This is ostensibly being to ignore all the objections that were already brought in October and are being brought again now, with the complicity of SPI. I can't say that this looks well on SPI, but that's just my personal opinion.

With all that said, I don't think anybody will attempt to prevent this from happening (if they even can?). But that will take place without the consent of the GA, without any legitimacy on the claims of openess and inclusiveness, and obviously without any form of preclearance from the technical appropriateness of the resulting code contributions.

-- レミ・デニ-クールモン http://www.remlab.net/

On Wed, 31 Jan 2024 at 18:03, Michael Niedermayer <michael@niedermayer.cc> wrote:

Hi Jonatas, Remi

_THIS_ reply shows why i LOVE SPI

I mean this is transparency, anyone try to get something similar from a corporation

Just in the last 48h i have seen a reminder from a CEO about "shareholder agreement" and privacy

If you want transparency, where is the agreement between SPI and STF? Where is the agreement for the NAB booth? Kieran

On Wed, 31 Jan 2024 at 18:40, Jonatas L. Nogueira <jesusalva@spi-inc.org> wrote:

I assume you don't mean National Association of Broadcasters by "NAB", so I would need to know what booth you're talking about.

That is what I mean. Kieran

On Wed, Jan 31, 2024 at 3:22 PM Kieran Kunhya <kierank@obe.tv> wrote:

...

On Wed, 31 Jan 2024 at 18:03, Michael Niedermayer <michael@niedermayer.cc> wrote:

...

Hi Jonatas, Remi

_THIS_ reply shows why i LOVE SPI

I mean this is transparency, anyone try to get something similar from a corporation

Just in the last 48h i have seen a reminder from a CEO about "shareholder agreement" and privacy

If you want transparency, where is the agreement between SPI and STF? Where is the agreement for the NAB booth?

Kieran

On Jan 31, 2024, at 11:07 AM, Michael Niedermayer <michael@niedermayer.cc> wrote:

On Wed, Jan 31, 2024 at 06:22:41PM +0000, Kieran Kunhya wrote:

...

On Wed, 31 Jan 2024 at 18:03, Michael Niedermayer <michael@niedermayer.cc> wrote:

...

Hi Jonatas, Remi

_THIS_ reply shows why i LOVE SPI

I mean this is transparency, anyone try to get something similar from a corporation

Just in the last 48h i have seen a reminder from a CEO about "shareholder agreement" and privacy

If you want transparency, where is the agreement between SPI and STF?

...

Where is the agreement for the NAB booth?

I did search my inbox and spam folder fro NAB but nothing looked related to a booth agreement. I have someoen trying to sell me an "Attendees Database" for NAB since 2018 though and lots of can nab is spam.

So either i searched for the wrong term or i was not CC-ed on such an agreement

This is most likely referring to the email from Thilo that an anonymous corporate sponsor is providing ffmpeg with a booth at NAB 2024 https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg154158.html Seems off-topic for this thread about SPI and STF. - Cosmin

On Wed, Jan 31, 2024 at 08:19:04PM +0000, Kieran Kunhya wrote:

On Wed, 31 Jan 2024 at 19:17, Cosmin Stejerean via ffmpeg-devel < ffmpeg-devel@ffmpeg.org> wrote: [...]

...

This is most likely referring to the email from Thilo that an anonymous corporate sponsor is providing ffmpeg with a booth at NAB 2024

https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg154158.html

Seems off-topic for this thread about SPI and STF.

- Cosmin

It's really not off-topic. It's about agreements that are made on behalf of the project without consulting the community, which is what appears to be [...] We love transparency in this project, right?

Yes, i cant awnser your questions but i have some questions myself after looking for NAB related things who did the 2023 booth on NAB for FFmpeg (W3323) ? here: https://www.linkedin.com/posts/videolan_nabshow-activity-7054494677881769985... We can clearly see FFmpeg logo and FFmpeg text in this Also in the reactions, i dont recognize any except you. and where was that discussed with the FFmpeg community? Iam reading there where no FFmpeg developers on that booth just buissness people from someone who vissited, so iam a bit confused. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you drop bombs on a foreign country and kill a hundred thousand innocent people, expect your government to call the consequence "unprovoked inhuman terrorist attacks" and use it to justify dropping more bombs and killing more people. The technology changed, the idea is old.

On Wed, Jan 31, 2024 at 09:54:05PM +0000, Kieran Kunhya wrote:

On Wed, 31 Jan 2024 at 21:43, Michael Niedermayer <michael@niedermayer.cc> wrote:

...

On Wed, Jan 31, 2024 at 08:19:04PM +0000, Kieran Kunhya wrote:

...

On Wed, 31 Jan 2024 at 19:17, Cosmin Stejerean via ffmpeg-devel < ffmpeg-devel@ffmpeg.org> wrote: [...]

...

This is most likely referring to the email from Thilo that an anonymous corporate sponsor is providing ffmpeg with a booth at NAB 2024

https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg154158.html

Seems off-topic for this thread about SPI and STF.

- Cosmin

It's really not off-topic. It's about agreements that are made on behalf of the project without consulting the community, which is what appears to be [...] We love transparency in this project, right?

Yes, i cant awnser your questions but i have some questions myself after looking for NAB related things

who did the 2023 booth on NAB for FFmpeg (W3323) ? here:

https://www.linkedin.com/posts/videolan_nabshow-activity-7054494677881769985... We can clearly see FFmpeg logo and FFmpeg text in this

Also in the reactions, i dont recognize any except you.

and where was that discussed with the FFmpeg community?

Iam reading there where no FFmpeg developers on that booth just buissness people from someone who vissited, so iam a bit confused.

Thilo was on the booth (when he felt like showing up) and j-b was on the booth along with other Videolabs people. Julien Navas, myself and other Videolabs people built the booth in our own time free of charge.

I have no idea who the " buissness people" you talk about are.

Where did you discuss the creation of this Booth with the FFmpeg community ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship naturally arises out of democracy, and the most aggravated form of tyranny and slavery out of the most extreme liberty. -- Plato

On Wed, Jan 31, 2024 at 10:45:50PM +0000, Kieran Kunhya wrote:

On Wed, 31 Jan 2024, 22:40 Michael Niedermayer, <michael@niedermayer.cc> wrote:

...

On Wed, Jan 31, 2024 at 09:54:05PM +0000, Kieran Kunhya wrote:

...

On Wed, 31 Jan 2024 at 21:43, Michael Niedermayer < michael@niedermayer.cc> wrote:

...

On Wed, Jan 31, 2024 at 08:19:04PM +0000, Kieran Kunhya wrote:

...

On Wed, 31 Jan 2024 at 19:17, Cosmin Stejerean via ffmpeg-devel < ffmpeg-devel@ffmpeg.org> wrote: [...]

...

This is most likely referring to the email from Thilo that an anonymous corporate sponsor is providing ffmpeg with a booth at NAB 2024

https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg154158.html

...

Seems off-topic for this thread about SPI and STF.

- Cosmin

It's really not off-topic. It's about agreements that are made on behalf of the project without consulting the community, which is what appears to be [...] We love transparency in this project, right?

Yes, i cant awnser your questions but i have some questions myself after looking for NAB related things

who did the 2023 booth on NAB for FFmpeg (W3323) ? here:

https://www.linkedin.com/posts/videolan_nabshow-activity-7054494677881769985...

...

We can clearly see FFmpeg logo and FFmpeg text in this

Also in the reactions, i dont recognize any except you.

and where was that discussed with the FFmpeg community?

Iam reading there where no FFmpeg developers on that booth just buissness people from someone who vissited, so iam a bit confused.

Thilo was on the booth (when he felt like showing up) and j-b was on the booth along with other Videolabs people. Julien Navas, myself and other Videolabs people built the booth in our own time free of charge.

I have no idea who the " buissness people" you talk about are.

Where did you discuss the creation of this Booth with the FFmpeg community ?

thx

Ask the people who paid for it and staffed it.

So you, for free helped to build a FFmpeg stand for the "for profit videolabs company" I am a little confused here. What is your relation to this company ? Where you a employee, shareholder, contractor, executive of videolabs ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "You are 36 times more likely to die in a bathtub than at the hands of a terrorist. Also, you are 2.5 times more likely to become a president and 2 times more likely to become an astronaut, than to die in a terrorist attack." -- Thoughty2

I can't find anything in SPI related to NAB either. I can ask the officers if they're aware of something from NAB, but I don't think that would be the case. I can find some old booths for FOSSEM, FOSDEM and whatnot though. Can you double check? (Also: What's the relation between NAB and this sponsorship?) Regards, Jonatas L. Nogueira (“Jesusalva”) SPI Board of Directors On Wed, Jan 31, 2024, 16:07 Michael Niedermayer <michael@niedermayer.cc> wrote:

On Wed, Jan 31, 2024 at 06:22:41PM +0000, Kieran Kunhya wrote:

...

On Wed, 31 Jan 2024 at 18:03, Michael Niedermayer < michael@niedermayer.cc> wrote:

...

Hi Jonatas, Remi

_THIS_ reply shows why i LOVE SPI

I mean this is transparency, anyone try to get something similar from a corporation

Just in the last 48h i have seen a reminder from a CEO about "shareholder agreement" and privacy

If you want transparency, where is the agreement between SPI and STF?

...

Where is the agreement for the NAB booth?

I did search my inbox and spam folder fro NAB but nothing looked related to a booth agreement. I have someoen trying to sell me an "Attendees Database" for NAB since 2018 though and lots of can nab is spam.

So either i searched for the wrong term or i was not CC-ed on such an agreement

thx

[...]

-- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The educated differ from the uneducated as much as the living from the dead. -- Aristotle

On date Wednesday 2024-01-31 18:10:57 +0200, Rémi Denis-Courmont wrote:

Hi, [...] Sarcasm aside, I take that to mean that SPI has been involved with those discussions for months in a private and closed process. Michael asserted that an open inclusive process is better than the usual closed approach whence the funding goes through a company.

It looks to me that those SPI discussions were just as opaque and closed, and all the talk of openess is just pretense. It does not help that Michael, and now you too, misrepresent any challenge to SPI proposed *process* as an attempt to reject the idea of STF sponsorship, under the convenient pretext that there is not enough time.

This is further aggravated by the context that Michael brought forward the idea of funding developers through SPI 3 months ago (in actual Earth units). From your statement, I have to infer that Thilo, Michael and SPI already knew of the STF plan and concealed that key piece of contextual information back then.

José already provided and excellent summary from his side. On my side I can say I was involved in the discussion, and that this was mostly about the feasibility and the groundwork of approaching STF and later SPI. So in my opinion there was no need to involve the community at that early stage, especially given that until the past week there was still no evidence that STF was providing a grant (and BTW, still this needs to be substantiated with a SOW and then it will have to be reviewed and approved on the STF side). Also SPI was involved at a later stage, after the investigation about using the donors fund for active development (which also involves the handling of SOW from SPI to the individual contributor). The main result of that investigation was discussed in the open and can be found here: https://ffmpeg.org/pipermail/ffmpeg-devel/2023-October/315702.html If I undestand it correctly, it was never committed because there was a disagreement about where to put it (ffmpeg or ffmpeg-web) and about the general intent, then at some point the discussion died off before a conclusion was really reached. Note that the focus in that case was to make good use of the donations fund (keeping it in the account is not a good use for it).

In hindsight, it feels hypocritical to me that they were arguing for the SPI path, and against the corporate path, on the basis of openess already then, to be honest.

I can only agree with Anton that this looks like an attempt to strongarm the community. This is ostensibly being to ignore all the objections that were already brought in October and are being brought again now, with the complicity of SPI. I can't say that this looks well on SPI, but that's just my personal opinion.

SPI was involved at a later stage to act as fiscal sponsor for STF. Just to reiterate, SPI involvement was requested, and was not actively seeked by SPI itself. I cannot read any attempt to strongarm the community, nor I see why this should challenge the corporate path (which has a different focus and has its own merits).

With all that said, I don't think anybody will attempt to prevent this from happening (if they even can?). But that will take place without the consent of the GA, without any legitimacy on the claims of openess and inclusiveness, and obviously without any form of preclearance from the technical appropriateness of the resulting code contributions.

It's unfortunate there is a tight deadline - one option would be to try to delay the deadline and ask General Assembly for a vote before the application is sent - we might probably want both things to avoid the feeling that this is done against the "community" and create a tense environment, but any of this might probably result in voiding the opportunity. Also, it should be assumed that this proposal was done in good faith, in view of the sustainability discussions done in the past months.

This is the courtesy reminder we've agreed on, to remember there's a week left to finish the Scope of Work if FFmpeg wishes to deliver it by February 12th as requested by STF. Att., Jonatas L. Nogueira (“Jesusalva”) SPI Board of Directors On Wed, Jan 31, 2024, 21:16 Stefano Sabatini <stefasab@gmail.com> wrote:

On date Thursday 2024-02-01 00:15:03 +0100, Stefano Sabatini wrote:

...

José already provided and excellent summary from his side. On my side

I meant Jonatas, sorry.

On Tue, Jan 30, 2024 at 2:48 AM Michael Niedermayer <michael@niedermayer.cc> wrote:

Hi all

after people said they would help and start a wiki page (no not thilo dont blame him) I again wrote one myself. This is really early WIP it contains the application we would send to STF, this is NOT written by me and a few random projects

the structure of the application at the end is i think fixed so that can be edited but the general structure is specified by STF i think

the stuff above the application is ours and can be changed without limitation

I mainly created this page so people can start collaborating on turning this into what they want it to look like. My version is trash as is, iam aware of that thats also why i was waiting and hoping someone who is actually good at this would start it

https://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2024

Sorry but this feels a lot like "thanks for your feedback, I'm going to do this anyway". -- Vittorio

On Tue, Jan 30, 2024 at 11:07 AM Nicolas George <george@nsup.org> wrote:

Vittorio Giovara (12024-01-30):

...

Sorry but this feels a lot like "thanks for your feedback, I'm going to do this anyway".

Sorry, but this feels a lot like “I gave an objection, you have to treat it like a veto”.

Sorry, but this feels a lot like “I have nothing to add to the conversation, but I feel like I need to speak up anyway”. It's not a veto when multiple eminent contributors outlined the problems with the current proposals, and I don't think ignoring them is beneficial to the community. I'm surprised I have to explain this *once again*. -- Vittorio

On Tue, Jan 30, 2024 at 11:15 AM Nicolas George <george@nsup.org> wrote:

Vittorio Giovara (12024-01-30):

...

Sorry, but this feels a lot like “I have nothing to add to the conversation, but I feel like I need to speak up anyway”.

Well...

...

It's not a veto when multiple eminent contributors outlined the problems with the current proposals, and I don't think ignoring them is beneficial to the community. I'm surprised I have to explain this *once again*.

When several people say no and several people say yes, at the end, whatever the chosen answer, some will feel they have been ignored. But it is just a feeling.

I am surprised to have to explain this at all.

Thanks for derailing the conversation and proving my point while at it. -- Vittorio

On 1/30/2024 1:48 AM, Michael Niedermayer wrote:

https://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2024

Not to derail this fine thread, but what forks does the Merge Forks project refer to? - Derek

On Wed, Jan 31, 2024 at 09:55:00PM +0000, Kieran Kunhya wrote:

On Wed, 31 Jan 2024 at 21:45, Derek Buitenhuis <derek.buitenhuis@gmail.com> wrote:

...

On 1/30/2024 1:48 AM, Michael Niedermayer wrote:

...

https://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2024

Not to derail this fine thread, but what forks does the Merge Forks project refer to?

- Derek

I also added a note that 70 USD for coverity is way too much. I picked a random issue 1503073 and within a minute saw that it was a false positive. I don't deserve 70USD for that.

you forgot to add yourself with a lower price its weak to claim something expensive (which is true) but not willing to do the work at a lower price about antons comment "Objections: (Anton) Coverity (and other static analysis tools) are notoriously prone to false positives. I am concerned that this might lead to a large number of patches that "fix" such false positives, but make the code worse." It was me years ago who brought the number of coverity issues down to a small number. It has exploded since. anton, where does this misstrust come from ? When i did all that fixing of covertiy issues long ago i closed many i think about 1/3 where real issues IIRC 2/3 where false positves or "intended" i closed the false positives and marked them accordingly as false or intended or whatever was correct. Why should i suddenly do something different ? I did it for 100% free back then and here it wouldnt even make sense, closing false positives also counts as resolved. Its less work even to get 70USD ;) and about the 70 USD. Its a point at which i hoped someone else would add himself, apparently its enough someone complains but noone wants to do it still. hmm and about 1min, the average time it takes to analyze issues is definitly going to be above this unless the issues look very different than previosuly though also you will surely find a dozen similar ones where you can close each in 5sec. on average 30min per issues with all analysis, double checking documentation 1/3 of the time writing a patch, testing and submitting is more real. So you could make 140USD per hour IMHO at 70USD per issue I think thats realistic unless the issues are different now than years ago (the 30min estimate includes a saftey factor which one has to include for this kind of work) thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Modern terrorism, a quick summary: Need oil, start war with country that has oil, kill hundread thousand in war. Let country fall into chaos, be surprised about raise of fundamantalists. Drop more bombs, kill more people, be surprised about them taking revenge and drop even more bombs and strip your own citizens of their rights and freedoms. to be continued

Le torstaina 1. helmikuuta 2024, 19.59.14 EET Anton Khirnov a écrit :

...

Why should i suddenly do something different ? I did it for 100% free back then and here it wouldnt even make sense, closing false positives also counts as resolved. Its less work even to get 70USD ;)

What's with this hurt-feelings tone? You ASKED people to comment on the proposals, so I asked a question. You can just answer it, no need to get all emotional about it. I don't stalk you or your commits, why do you expect me to know that you worked on such issues "long ago"? I don't even know one can close coverity issues manually.

What I do know is that I've seen similar initiatives run into this pathology in the past, hence my question.

Yeah, well there are two sides to this issue. The obvious one is that it reviewing code takes time and is not exactly the most rewarding job. This is especially true for reviewing dull issues like Coverity's, but it is generally true. The lesser obvious flip-side is that somebody should also review the handling of Coverity issues, even those that end up marked as "False positive" or "Intentional". This gets even worse if everybody knows that someone else is paid. Then the incentive to review on one's free time gets even lower in my experience. I don't know how to address that paradox generally speaking, but I do think that bug triaging, bug fixing and code review should be paid per hour, not per bug report (and I count Coverity issues as a type of bug reports). This is not just theoretical. I have actually previously worked in an organisation that paid contractors per bug as a unit, and of course people gamed the system to get paid more with little extra work. -- 雷米‧德尼-库尔蒙 http://www.remlab.net/

On Wed, Jan 31, 2024 at 09:55:00PM +0000, Kieran Kunhya wrote:

On Wed, 31 Jan 2024 at 21:45, Derek Buitenhuis <derek.buitenhuis@gmail.com> wrote:

...

On 1/30/2024 1:48 AM, Michael Niedermayer wrote:

...

https://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2024

Not to derail this fine thread, but what forks does the Merge Forks project refer to?

- Derek

I also added a note that 70 USD for coverity is way too much. I picked a random issue 1503073 and within a minute saw that it was a false positive. I don't deserve 70USD for that.

I fixed 2 coverity issues yesterday and it took me over 3 hours I cant do this for 70USD per issue (you can see the ML for the 2 patches) In the first, the issue depended on fbw_channels to be 0. If you look at its initialization that is possible if you have a mono LFE channel but is that possible and can the code be reached in that case. For someone who hasnt worked at that specific code it takes some time to build an argument that this should not be possible The second issue, its obvious a bug but how do we even reach that code? No fate tests .... luckily there are examples in the docs but it took me several tries to get the code to execute with similar testcases. now looking at it, i suspect the patch i posted probably should be split so we need a 2nd iteration and looking at the clock when i posted this and when i started yesterday fact is it was 3-4h work for these 2 issues did i pick these randomly? no, i started frm the top and skiped a few i really did not want to work on like the flac parser. Some coverity isssues are dead easy and need seconds to categorize or even fix. But for others its difficult Also to categorize coverity issues one needs to understand the affectd code. coverity telling you that after 355 conditions theres a out of array access, you need to know if the 355 conditions are inconsistant and contradicting. If they contradict its a false positive otherwise its a bug. similar when you check the return code of a function most of the time coverity will create an issue for cases where its not checked. Thats trivial to fix IF you know the code. But IF you do not know the code that can some decent time too. And i think noone knows all code. Either way, iam interrested in helping with coverity work while at the same time this environment where peole finger point and say "is way too much" is something i dont feel comfortable to work in. maybe doing it per hour instead of per issue is a safer way thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- Aristotle

On Feb 5, 2024, at 18:21, Michael Niedermayer <michael@niedermayer.cc> wrote:

On Wed, Jan 31, 2024 at 09:55:00PM +0000, Kieran Kunhya wrote:

...

On Wed, 31 Jan 2024 at 21:45, Derek Buitenhuis <derek.buitenhuis@gmail.com> wrote:

...

On 1/30/2024 1:48 AM, Michael Niedermayer wrote:

...

https://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2024

Not to derail this fine thread, but what forks does the Merge Forks project refer to?

- Derek

I also added a note that 70 USD for coverity is way too much. I picked a random issue 1503073 and within a minute saw that it was a false positive. I don't deserve 70USD for that.

I fixed 2 coverity issues yesterday and it took me over 3 hours I cant do this for 70USD per issue (you can see the ML for the 2 patches)

In the first, the issue depended on fbw_channels to be 0. If you look at its initialization that is possible if you have a mono LFE channel but is that possible and can the code be reached in that case. For someone who hasnt worked at that specific code it takes some time to build an argument that this should not be possible

The second issue, its obvious a bug but how do we even reach that code? No fate tests .... luckily there are examples in the docs but it took me several tries to get the code to execute with similar testcases. now looking at it, i suspect the patch i posted probably should be split so we need a 2nd iteration and looking at the clock when i posted this and when i started yesterday fact is it was 3-4h work for these 2 issues

I think work on two to three issues in spare time per day is a rough but reasonable number, with one to two being easy and one from medium to hard. 210$ isn’t that much, especially for overtime pay. Many people have working on open source for free (as in beer) for many years, but it doesn’t mean that their work not worth like 70 $.

did i pick these randomly? no, i started frm the top and skiped a few i really did not want to work on like the flac parser.

Some coverity isssues are dead easy and need seconds to categorize or even fix. But for others its difficult

Also to categorize coverity issues one needs to understand the affectd code. coverity telling you that after 355 conditions theres a out of array access, you need to know if the 355 conditions are inconsistant and contradicting. If they contradict its a false positive otherwise its a bug. similar when you check the return code of a function most of the time coverity will create an issue for cases where its not checked. Thats trivial to fix IF you know the code. But IF you do not know the code that can some decent time too. And i think noone knows all code.

Either way, iam interrested in helping with coverity work while at the same time this environment where peole finger point and say "is way too much" is something i dont feel comfortable to work in.

maybe doing it per hour instead of per issue is a safer way

thx

[...]

-- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into despotisms. -- Aristotle _______________________________________________ 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".

Hi, I don't believe it is appropriate to hold the vote before Derek's question is addressed. We don't really know what we're voting on here. Le 1 février 2024 20:22:14 GMT+01:00, Derek Buitenhuis <derek.buitenhuis@gmail.com> a écrit :

On 1/31/2024 9:44 PM, Derek Buitenhuis wrote:

...

On 1/30/2024 1:48 AM, Michael Niedermayer wrote:

...

https://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2024

Not to derail this fine thread, but what forks does the Merge Forks project refer to?

I do not believe this has been answered.

- Derek

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

On Sun, Feb 4, 2024 at 11:03 AM J. Dekker <jdek@itanimul.li> wrote:

On Sun, Feb 4, 2024, at 10:49, Rémi Denis-Courmont wrote:

...

Hi,

I don't believe it is appropriate to hold the vote before Derek's question is addressed.

We don't really know what we're voting on here.

Le 1 février 2024 20:22:14 GMT+01:00, Derek Buitenhuis <derek.buitenhuis@gmail.com> a écrit :

...

On 1/31/2024 9:44 PM, Derek Buitenhuis wrote:

...

On 1/30/2024 1:48 AM, Michael Niedermayer wrote:

...

https://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2024

Not to derail this fine thread, but what forks does the Merge Forks project refer to?

I do not believe this has been answered.

- Derek

The vote is unclear for me and also it was not explained who ‘the same person as before’ is, no reply or answer to this either. Hope Michael can clear this up.

- jd

FFmpeg project is dead.

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

Hi, Le 4 février 2024 14:41:15 GMT+01:00, Michael Niedermayer <michael@niedermayer.cc> a écrit :

Hi

As said on IRC, i thought people knew it, but ‘the same person as before’ is Thilo.

Ive updated the price design suggestion for the merge task, its 16€ / commit limited to 50k€ this comes from looking at pauls fork which has around 500 commits in 2 months thus 250 commits per month, 12 months, and if we allocate 50k that end with roughly 16€ / commit if activity stays equal.

It's very different if we're talking about librempeg or some other unspecified fork. I could make a fork that removes MMX et al, and claim that I'm merging a fork.

The task has ATM no developer on it. If a developer adds himself, he can change teh task and specify what he proposes to merge.

I am totally perplexed why every dot on every i is such a big thing.

That is the whole point of a statement of work. And I agree that it's tedious and possibly outright annoying... Indeed I don't think that a semiformal open-source community with a lot of strong and varied opinions will carry such dotting of all i's very effectively. That has been one of the arguments for delegating this to a contracting IT company rather than to FFmpeg-devel and SPI.

We are doing GSoC for a decade and noone cared about voting about anything in it.

Again, I don't think it's a fair comparison. GSoC rules are a given set by Google. Maintenance is not allowed nor are vague broadly defined tasks. Also the mentor payment is not really a proper compensation, nor is it intended to be.

The difference here is FFmpeg developers are benefiting from the money.

That's a pretty major difference.

We send an application and a scope of work.

That's exactly why we need to have a precise scope of work to vote on this.

Hi, Le 4 février 2024 21:28:44 GMT+02:00, Michael Niedermayer <michael@niedermayer.cc> a écrit :

On Sun, Feb 04, 2024 at 03:38:43PM +0100, Rémi Denis-Courmont wrote:

...

Hi,

Le 4 février 2024 14:41:15 GMT+01:00, Michael Niedermayer <michael@niedermayer.cc> a écrit :

...

Hi

As said on IRC, i thought people knew it, but ‘the same person as before’ is Thilo.

Ive updated the price design suggestion for the merge task, its 16€ / commit limited to 50k€ this comes from looking at pauls fork which has around 500 commits in 2 months thus 250 commits per month, 12 months, and if we allocate 50k that end with roughly 16€ / commit if activity stays equal.

It's very different if we're talking about librempeg or some other unspecified fork. I could make a fork that removes MMX et al, and claim that I'm merging a fork.

There are so many reasons why this wouldnt work (first you would have to lie, i dont think you would, then it would not be left that way on the wiki, not being sent to STF that way and not being accepted by STF and more)

But assuming one could get away with that in the short term Why would anyone do something like this to destroy our all opertunity to obtains grants in the future ?

I don't know. That was purely an example, and I prefer to be the fictional bad guy in my examples, so nobody else feels insulted. But you can't blame people for being distrustful when a proposal is brought forward on short deadlines even though it was privately known for months.

...

Indeed I don't think that a semiformal open-source community with a lot of strong and varied opinions will carry such dotting of all i's very effectively. That has been one of the arguments for delegating this to a contracting IT company rather than to FFmpeg-devel and SPI.

If the FFmpeg team can make decissions about what to fund then we do not need any contracting IT company.

Let's face it: FFmpeg is not the healthiest of open-source communities as of now. But that's not even relevant here: OSS communities are typically focused on development and maybe support and promotion, *not* HR and payroll, nor waterfall-style project management. Ergo, there would be no shame in conceding that FFmpeg would suck at those tasks, and a company whose job those things essentially are would be more effective at it. And I'm not saying this out of self-interest, just pragmatism (call it cynicism if you will).

OTOH If the FFmpeg team is not able to make decissions, thats a far bigger problem and it needs to be understood and corrected

I don't think the technical development lists of an OSS community should concern themselves with funding matters. Well-funded foundations surely need to concern themselves with this, but they don't mix it with development. And FFmpeg is not sl well-funded in the first place.

Because whoever controlls the income of developers effectively controlls the project.

As long as there are several parties involved, and a single trust doesn't dominate the GA and the TC, I don't see that as a major problem. Or rather, it's a lesser problem than loosing competent developers because they need to work on something else to earn their living.

An emloyee has to do what she is being told be her employer. So if the main developers become employees payed to work on FFmpeg that would hand FFmpeg to some CEO on a silver plate,

200000€ are not remotely enough for that to happen. You'd need 2-3 orders of magnitude larger investment, without competition, to get there at minimum. So I don't see a risk here. But it's up to Thilo really, if he insists on going through SPI or not applying for STF at all.

This would change FFmpeg from a Free software project to a commercial company. I do NOT agree to this, and i belive many others also do not agree.

I think a lot of people would rather get paid to work on Ffmpeg, and would in fact contribute more effectively if they were. And conversely, quite a few contributors seem to be acting for their commercial employer already. Also, as a consultant or maybe an associate for FFlabs, it's a rather contradictory position for you to hold.