[FFmpeg-devel] [RFC] financial sustainability Plan A (SPI)

[Rémi Denis-Courmont]

Le sunnuntaina 29. lokakuuta 2023, 18.12.58 EET Michael Niedermayer a écrit :
> On Sun, Oct 29, 2023 at 04:35:35PM +0200, Rémi Denis-Courmont wrote:
> > Hi,
> > 
> > Le 28 octobre 2023 21:01:57 GMT+03:00, Michael Niedermayer 
<michael at niedermayer.cc> a écrit :
> > >On Sat, Oct 28, 2023 at 07:21:03PM +0200, Michael Niedermayer wrote:
> > >> Hi ronald
> > >> 
> > >> On Sat, Oct 28, 2023 at 12:43:15PM -0400, Ronald S. Bultje wrote:
> > >> > Hi Thilo,
> > >> > 
> > >> > On Sat, Oct 28, 2023 at 11:31 AM Thilo Borgmann via ffmpeg-devel <
> > >> > 
> > >> > ffmpeg-devel at ffmpeg.org> wrote:
> > >> > > What this is about, is to set up a way to properly spend the SPI
> > >> > > money
> > >> > > aside
> > >> > > from travel & hw. Why we should not do it because some companies
> > >> > > beurocracy, I
> > >> > > cannot see.
> > >> > 
> > >> > I sincerely don't think the above description is what Kieran meant
> > >> > when he
> > >> > talked about sustainability at Demuxed, which this thread seems to be
> > >> > a
> > >> > response to.
> > >> 
> > >> a quick reply here. I have not watched kierans presentation from
> > >> demuxed yet. So theres absolutly no chance anything i wrote till now
> > >> can be a respone to it.
> > >
> > >some more words about what the intend of this plan was, again not a
> > >respone
> > >to any presentation of anyone else
> > >
> > >Donations from people vs companies: both really.
> > 
> > I think Ronald's point is that you need to pick one, and clarify which it
> > is, because as Ronald explained, it's unlikely that a *good* plan could
> > address both (conversely a plan that tries to address both is probably
> > poor and flawed).
> > 
> > In other words, if you want to cover both cases, you need two separate
> > plans.
> you are correct, i agree here but this is a RFC so its not a final
> plan.
> 
> i think for the donations from users the real question is how many
> of our users can we reach to explain them that they are using FFmpeg
> and a tiny donation would help us alot.
> if thats only a few thousand users then this will not work
> 
> > And unfortunately, I do believe that Ronald is correct in pointing out
> > that big companies will want oversight in exchange for money. This is
> > very much counter to the current project setup, which (depending whom you
> > ask) is governed by the GA, or by Fabrice Bellard through his delegates.
> > 
> > This is not to say that these corporate wishes should or should not be
> > accomodated. It is just an observation of those wishes.
> if i look at spi.txt, it says
> "SPI needs a contract in place which describes the work to be done. "
> 
> so if we have someone do some payed development work be that one time or
> continous. There would be a contract that says what is going to be done.
> That also would have been approved by the community or GA or whatver and
> the company paying would have a say in whats in that contract, really
> limited by what we are ok with and what the law allows

Unfortunately, that is missing the point. If a company wants to pay someone 
for some specific tasks, they can already do that, with or without the 
intervention of SPI. And they already know that they can do that, at least 
without SPI. Your plan A is unnecessary for this case. If SPI has any benefit 
here, it's maybe fiscal. If there is really a tax benefit, you could emphasize 
on the website and social networks tha SPI is available as an option.

Some companies could be willing to provide more sustainable funding for more 
general maintenance, but they would probably require something like what 
Ronald mentioned - especially for FFmpeg whose community has a poor 
reputation.

> > How do you plan to gain visibility from those billion users? Call me
> > pessimistic but this has been a known problem for 20+ years, and I have
> > yet to glimpse a credible solution.

> It depends on the community. If the commuity wants to do it
> Just look at some online service which annoy you telling you to disable a
> add blocker we could detect a specific usecase we intend to target and
> print a simple message once that will not annoy the user a 2nd time
> This is very controversal and iam not sure if 99% are against it or find it
> funny. Iam just awnsering the "how it can be done" not saying iam in favor
> or against

That's not a credible solution for a library. All reverse dependency 
developers would disable that before they ship affected FFmpeg versions, or 
worse, just stop updating their vendored FFmpeg.

The FFmpeg CLI tool print stuff, but that's going to be seen by a tiny fraction 
of the user base.

-- 
Rémi Denis-Courmont
http://www.remlab.net/