[FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

[Soft Works]

> > Signed-off-by: Nicolas George <george at nsup.org>
> > ---
> >  doc/developer.texi | 10 ++++++++++
> >  1 file changed, 10 insertions(+)
>
> Rather than repeat myself, I'll refer to my previous mails:
>
>     * http://ffmpeg.org/pipermail/ffmpeg-devel/2019-January/238740.html
>     * http://ffmpeg.org/pipermail/ffmpeg-devel/2019-January/238743.html
>
> I utterly and absolutely think no good will come from such a policy. It's
> divisive, exclusionary, inflamatory, witch-hunt-y, and privacy invading,
> among other things.
>
> I'm speechless. Words cannot describe how terrible I think such a policy is
> for current and future contributors, and I am of the opinion that adopting
> such a policy would see any work sent to FFmpeg by anyone involved in a
> company, which I may add, is a lot, utterly dry up.
>
> I've not much more to say on the matter, and I will not engage in flame
> wars after.
>
> - Derek
>
> (P.S. Just how do you intend to enforce this? How do you prove/disprove someone
>  has been paid in some form, directly, or indiectly? Do you just accuse them on
>  the list?)
>
> (P.P.S. I am aware my opinions hold little clout here nowadays, so take my response
>  as you will.)
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


My official contributions to ffmpeg are small and as such there isn't
much value in my saying "I agree as well".

By now I've got a much longer list of changes that I haven't submitted back
as patches to ffmpeg than those where I did.
This happened for various reasons none of which to blame ffmpeg for.

Many others are doing the same. That leads to fragmentation of the code base
of course. Fragmentation is not a bad thing per se - many changes are not suitable
for general inclusion.

But sometimes it can be even just small things keeping an individual developer
from submitting patches back when he's got the option to go with his own
"ffmpeg+custom" code base.

That kind of fragmentation is bad of course, when the common code base could
have benefited from a change.


Establishing a "transparency requirement" as described, would set up an additional
- for some even huge - impediment for contributing back their work.


So, while my consent is surely irrelevant (per my own conviction), I really
wonder if such a decision would be good for the project.

softworkz