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

[Michael Niedermayer]

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 at 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.
How many potential new developers do we reach, how many of them want to join?
how many try to join, and what are the true reasosn for thouse who do not
want to join or try and fail?
Do we even try to attract new developers ?
I think on a scale from 1 ro 10 we are maybe at a 2 when it comes to
new developers, theres alot we could do, theres a alot we should know,
a lot we could try.

The effect on existing developers also must be considered

Also even within the current developers there is friction. Solving this
friction would increase the number of active developers.
And if its not solved then i think maybe we are missing the problem
because gitlab even if it adds more people will also increase these
frictions even more. Because there are problems between people and not
just a email vs gitlab one.

What i belive would help is a way for people to develop modules
(codecs, demuxers, muxers, ...) externally.
That can be a plugin system, it can be something else

That way each group can use the development and patch submission
systems they prefer.

I think the problem we have is less one of aging developers who want new
people to come in and the tools being a problem. But instead the old
developers having increasingly rigid oppinions that both old and new
developers do not agree with. The solution here is to put some space
between developers so everyone can work on what they like using whichever
enviroment they like. While still somehow maintaining common communication

Consider this also in abstract terms
In an enviroment where everyone can block and object to everything
(at least temporary)
the number of potential disagreemnets will grow quardatically with the
number of people. This is not scalable

Now people certainly can work on their own fork but then users cannot
use it or combine these. Plugins would be one fix for this

A Decoder is a module that takes a 1-D list of bits and outputs
2-D array of pixels or several 1-D list of audio samples. That interface
is not so complex that it needs to be kept inside a monolithic
repository

thx

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

What does censorship reveal? It reveals fear. -- Julian Assange
-------------- 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/20240411/26596ebb/attachment.sig>