Re: [FFmpeg-devel] Democratization

[Soft Works <softworkz-at-hotmail.com@ffmpeg.org>]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Vittorio Giovara
> Sent: Thursday, January 30, 2025 7:35 AM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Democratization
> 
> On Thu, Jan 30, 2025 at 12:27 AM Soft Works <
> softworkz-at-hotmail.com@ffmpeg.org> wrote:
> 
> > >
> > > If you have reason to believe otherwise, then indeed the
> situation is
> > > more
> > > complicated. And then we may have a third faction consisting of
> some
> > > subset of
> > > (Michael, Timo, Fabrice, and possibly other people we were not
> made
> > > aware of).
> >
> >
> > You might be on a right track here, because I believe that the
> common
> > assessment as laid out by several supporters of the "community
> governance
> > model" matches reality just partially at best.
> >
> > The common telling is that there's Michael on one side with a
> number of
> > "his buddies" or "surrogates" and on the other side there's "the
> community"
> > who want the project to be led by "the community" - all in
> agreement.
> >
> > But that might be just wishful storytelling, as the situation is
> more
> > complicated indeed.
> > None of us have any figures, so we can't know exactly before any
> vote has
> > happened, what I want to point out though, is that this idea of
> "Michael +
> > Buddies" vs. "The Community" doesn't fit in its simplicity.
> >
> 
> That does not mean it would be worth trying something different. I
> already
> listed the incidents I've just seen happen before my eyes in this
> mailing
> list and these are not fun incidents. Ideally there should be some
> guarantee beyond Micheal's word not to repeat them again. What you're
> saying is "this is how it has always been, therefore we should just
> accept
> it", which is unfair, especially to the most active contributors.

I'm not saying you should accept it because "this is how it has always been".
I'm saying you should accept it because the project has a private ownership which "is how it has always been".
This has been clear ever since and for all contributors. The project doesn't own the code - you are free to fork at any time and run your own thing. But there's nothing from which you could derive any right to demand for a change of ownership, neither is there any basis on which you could demand any "guarantees" regarding the owner's actions.


> Once again, you are invited to the fosdem meeting and see for
> yourself what
> the community really wants.

FOSDEM != "the community"

> This "community" in its current form and appearance and the way it is
> > represented by its members is fundamentally incapable of leading
> and
> > executing control over a project like ffmpeg.
> > I'm aware that there are projects where this is working, same as
> I've seen
> > projects where all members are pretty much on the same line and
> when
> > there's a committee with a handful of members, persons leave, other
> persons
> > join, but that doesn't change anything because they all share the
> same
> > ideas and plans and all are working together hand-in-hand.
> >
> 
> This is like your opinion man.

Yes, this is my opinion and it gets confirmed almost any other day when reading the ML. That a deeply divided community cannot be given control over a project like ffmpeg is just common sense imo, even though I respect that you have a different opinion.


> > There are others who are watching this ML from a distance and
> thinking
> > about the same - just silently.
> > We don't know figures, but nobody should think it would be a sure
> thing
> > that all "non-buddies" would want and vote for a community
> ownership.
> 
> Including people who would like to join the community but are
> horrified by how things are. 

The type of e-mails you are sending to the ML making a substantial part of those most "horrifying things".

> And it's 2025, nobody will join a project where the leader can ban at will

Hardly anybody cares about that, because nobody wants to write a mail like the one you did and, then building up a big drama show around the fact that it has been moderated.
I think the procedure wasn't okay, but I also think that the e-mail wasn't okay, so ideally it should have been moderated by an established procedure, yet the outcome would have been the same, that's why I don't share the excitement expressed by some others.

> hussle sponsors

No new contributor will care about that.


> > Further, many developers here are working for the industry in one
> or
> > another form, and what businesses want is stability and
> predictability -
> > not a community where majorities might be volatile and it can
> quickly
> > happen that strategically important code is thrown out of ffmpeg by
> vote
> > from a group of ideologists who managed to gain an intermittent
> majority.
> >
> 
> Bold of you to imply that Micheal's decision are anything but stable ;)

I'm sure you are having your points here, but those are not decisions which businesses are caring about. Few years ago, some started a discussion about removing code which is supporting hardware with closed-source APIs and when it wouldn't have meant to also remove support for Nvidia, it might have gone even further. These are decisions relevant for businesses and that's why they won't support handing over such decisions to "the community".

 
> > Finally, there are also contributors who don't care about
> community,
> > membership or influence - they just want to get their code merged
> without
> > trouble. Will they vote for a community governance where every
> little nit
> > from someone will require to conduct a vote on it?
> >
> 
> Another "what if" of an unlikely scenario

Unlikely? That applies to all those contributors who I met in the past years, tried to make a contribution and walked away with the conclusion that it's pointless and not worth trying ever again in the future!

> in the unlikely case of conflict we have a TC that does what you describe when needed.
> I'm sure you understand 5 people have an easier time managing a case than the whole community.

This it totally ineffective. The current reality (especially for non-established contributors) is often something like this:


- You make a submission
  - Either nobody ever reacts
  - Or:
    - ffMember1 says "no" to A and B
    - ffMember2 says "no" to C
- Of course nobody told you what to do instead, so you need 
  to "guess" what they want and make an updated submission with 
  changes A1, B1 and C1
  - Then
    - ffMember1 says "no" to B1 (nothing against A1)
    - ffMember2 says "no" to C1 and now also D    
    - ffMember3 says "no" to A1 and E
- Next guessing to address issues with A2, B2, C2, D1 and E1
  - Then
    - ffMember1 says nothing
    - ffMember2 says nothing    
    - ffMember3 says "no" E1 and now also G
- Next guessing to address issues: E2 and G1
  - Then
    - ffMember1 says nothing
    - ffMember2 says nothing    
    - ffMember3 says nothing
- You bump, you ping - no response
- You bump and ping 
    - ffMember1 says "I have told you that B1 is "no" and A1 is "no"
      (has never reviewed A2 and B2)
    - ffMember3 says "like ffMember1 said, as long you don't fix A1, 
      it can't be merged" 
      (even though he had asked for A2 and seemingly accepted A2 by not 
      mentioning it on the next review)
- Now you stand there without even having a clue what to do to satisfy 
  everyone. If you are keen, you might ask again what to do instead, but
  while you can get lots of responses for the "no"s, you rarely get 
  responses on the "how then?" questions, probably because ffMemberX
  is too afraid of seeing an ffMemberY contradicting.

And then the contributor should contact the TC? 

- First of all, most don't even know about its existence
- If one knows about its existence, one might still not know how to contact it
- And finally, you don't even know exactly which question/request to make to the TC
  - It's not like you want X and somebody else wants Y
  - It's rather like some said no to A, A1, nobody said something to A2 and you would happily do A3 or A4 or A5 or A6 - because you don't care but you are tired of guessing 


What an external contributor wants instead is this:

- You make a submission
  - Maintainer says 
    - A needs to be done like A1
    - B needs to be done like B1
  - PersonInCharge  says
    - C needs to be done like C1
    - D needs to be done like D1
- You make changes A1, B1, C1, D1
  - Maintainer LGTM
  - PersonInCharge says C1 should better be like C2
- You make changes C2
  - PersonInCharge says LGTM
- Merged + Done


Hardly any external contributor is interested in any committees or having the community voting about their contributions. They just want to get attention and be told what to do to get their code into a form that it will get merged - as simple as that. 

Before calling for a vote, they will rather give up and walk away. But in case they already made a few contributions and are entitled to vote, they will surely not vote for something which makes their contribution process even more complicated, lengthy and unpredictable.


Let's Calculate

- Remainder = "The Commnunity"
  - minus "Michael's Buddies"
  - minus members like me who don't consider the community 
    capable of managing the project
  - minus members working for the industry
  - minus occasional contributors without interest in the project
  - minus all those who have other reasons against community 
    ownership

Conclusions

- It is not valid to make any claims like
  "The Community wants the project to be owned by the community"
- It is not even valid to make any claims like
  "The majority of the Community wants the project to be owned by the community"

The latter isn't valid because we don't have figures, so we just can't know.
For me, it doesn't look there's a majority for it, just a few people asking for it very loudly.

Besides that, it's already clear that this won't happen, even when a majority would want it, so it's probably more productive to accept that and rather participate in the suggestions that Michael is making, keeping in mind that he isn't obliged to do this at all.

sw








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