[FFmpeg-devel] Soliciting sponsorship (was: WIP: avfilter: add Bungee audio stretch filter (PR #20697))

[Nicolas George via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>]

michaelni (HE12025-10-13):
> Also you would have to convince the community, that we want this. iam
> not sure how the community would think about it, but for example you
> could offer to donate a percentage of your profits from this to
> ffmpeg.

Hi. I procrastinated replying about soliciting sponsorships, but if it
looks like that I cannot anymore. Also, it must not be discussed in the
dark of an obscure pull request, it needs to be seen on the
mailing-list.

If this is how us soliciting sponsorships looks like, then we must
absolutely not do it.

“Pay us and we will consider ignoring the qualms we have about the
licensing issues of your contribution” is already very bad by itself. It
is even badder when we realize it is only one step from “pay us and we
will consider ignoring the qualms we have about the poor quality of your
code”.

Ideally, accepting contributions should be judged on the merits of the
contribution itself: is the code beautiful? does it bring practical
benefit to our users? Out of necessity we have to add: will this be
properly maintained? But no more.

We can solicit sponsorship, sure, but even the appearance that the money
is a tit-for-tat for getting one's code into the project, getting
excellent publicity and future maintenance work for cheap, would be
extremely detrimental.

> about the open source free libbungee, yeah, i think we do want support
> for that

I disagree. What would be the benefit for our users?

This library is not packaged by major distributions; the license is not
more permissive: no benefit in availability.

Multiple implementations for the same feature: users will have to
scratch their head to decide which one is suited for their needs, that
negates some benefits.

There is talk of medium speed improvement. That would need to be
confirmed, but that would count as a benefit. Though it is already a
very fast process, a drop in the bucked in comparison with video
encoding or waiting for real time.

There is talk of improvement in quality, but it is at best subjective
and very small, possibly imaginary.

On the whole, I would say the benefit for our users is not worth the
effort.

(A more intransigent version of this would be: If a contribution comes
with links to a proprietary version, the it is an immediate hard no. We
are not here to give exposure to your proprietary software.)

Also, if we considered accepting, it should not be as an extra filter
with its own set of options. It should be as a single filter with an
option to choose the implementation but common options for the shared
features.

Regards,

-- 
  Nicolas George
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org