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

Tue Oct 31 18:58:57 EET 2023

On Sun, Oct 29, 2023 at 09:36:13PM +0200, Rémi Denis-Courmont wrote:
> 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.

yes, thats a good idea

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

If its announced and we point to the commit, maybe half the minor users
will remove it, maybe most of the bigger ones. If its not announced
noone would remove it. companies do not audit the FFmpeg commits.
They would remove it after seeing it but at that point it did what it
intended to to, inform users
again, like i said thats hypothetical and controversal. But basically doing
the same as companies which put advertisements in without asking either creator
nor viewer.
Also dont ignore the effect of the controversy around this ;)
It would be on many news sites that XYZ displayed a notice
that it used FFmpeg and asked for donations for sustainability.
All these news articles are free amplification of the message ;)
We could reach quite a few people with this. its just controversal

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

yes

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 1
"Used only once"    - "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20231031/388ecdd8/attachment.sig>