Re: [FFmpeg-devel] Query from Reuters on XZ, open source, and Microsoft

[Paul B Mahol <onemda@gmail.com>]

On Thu, Apr 11, 2024 at 5:59 AM Vittorio Giovara <vittorio.giovara@gmail.com>
wrote:

> On Wed, Apr 10, 2024 at 9:19 PM Michael Niedermayer <
> michael@niedermayer.cc>
> wrote:
>
> > Hi
> >
> > On Tue, Apr 09, 2024 at 03:57:02PM -0500, Romain Beauxis wrote:
> > > [Apologies for continuing the conversation, Rémi]
> > >
> > > Le mar. 9 avr. 2024 à 14:05, Tomas Härdin <git@haerdin.se> a écrit :
> > >
> > > > mån 2024-04-08 klockan 13:13 -0500 skrev Romain Beauxis:
> > [...]
> > >
> > > > Also as someone who had to maintain a Gitlab instance at uni for a
> > > > couple of years, I agree with Rémi's points
> > > >
> > >
> > > My initial contribution was motivated by the argument presented in the
> > > original talk that bringing new blood is critical to the survival of
> the
> > > project.
> > >
> > > If so, then I do believe that there must be a compromise to be made
> > between
> > > being easier to join for new developers and changing the existing
> > workflow.
> > > I'm also aware that changing the existing workflow has been discussed
> > > before.
> > >
> > > I don't think that media is not cool anymore, as argued in the talk. I
> > see
> > > a _lot_ of interested developers in my other projects and all over the
> > open
> > > source landscape. That's why I believe that it's also important to
> > consider
> > > other reasons than the talk's argument.
> >
> > To bring some of the new blood into the project the project needs to
> > first understand why they dont. And asking thouse who manage with
> > difficulty
> > to join could be a biased oppinion.
> >
>
> In my experience this boils down to three points
> 1. there is a legit barrier of entry in a large codebase such as ffmpeg,
> but over time newcomers can learn about it
>

Yes, external and internal API is complicated mess in all libs,
Most libs code is out of date with current State of Art found in other
projects.
Also contributors came and go, you can not force them to stay and maintain
code mess.


> 2. the review process can be though and it's easy to miss a ping and
> patches get lost, very defeating for a new developer
>

Specially when single patch get lost in twenty trivial refactoring patches
that spam the list.
There should be at least separate list for refactoring patches, and keep
this list only for important stuff like new features and bug fixes, if no
switch to Github/Gitlab is wanted.


> 3. there is net negative help from trolls who spread toxic poison, which is
> confusing and uninteresting for the new blood
>

That is internal community reaction to 1. and 2. points. Think it about
like auto-immune reaction to state of human body.


>
> 2 out of 3 can be solved technically, while the last one needs a cultural
> shift - overall I think we're doing a good job at slowly changing pace and
> having a bit of a better structure to solve situations when they arise, but
> there is still a lot of work to do
>

Cultural shift - Cancel culture.

The only point I agree about above is very last part of very last sentence.


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