Hi Niklas On Thu, Jan 02, 2025 at 04:38:07PM +0100, Niklas Haas wrote: > On Thu, 02 Jan 2025 15:17:31 +0100 Michael Niedermayer > <mich...@niedermayer.cc> wrote: > > Hi all > > > > I was working in the last few days a little on drafting a democratization > > process > > > > Heres the current draft: (very preliminary and will certainly change alot) > > also I still need to find out, if more than 3 developer actually care about > > this > > > > But either way, this is intended to be an open and public process not a > > process behind closed doors > > > > Iam posting this mainly to show that i have not been ignoring the call for > > democratization > > (originally wanted to wait longer so its more fleshed out before posting > > but well, posting > > now, maybe it makes some people happier) > > > > Summary: > > People will have shares proportional to their contribution to FFmpeg. > > Just to nitpick the terminology a bit: This would no longer be a democracy, > but rather an oligarchy, since the vast majority of the voting shares would be > held in a very small handful of people on account of the exponential > distribution of commit count per contributor.
Let me provide several independant arguments here.
in the GA system
someone spending 2 days to submit 20 patches and not caring about FFmpeg has
1 vote
someone spending the last 20 years working every day on FFmpeg and
authroing over 20000 commits has 1 vote
A. this is not fair
B1. It is exploitable, the 2nd man could just submit 200 commits each under
100 pseudonyms to receive 100 votes
B2. It is exploitable, anyone can just hire 20 developers on fiver and
have them sign NDAs and for less than maybe 20k $ get 20 votes, these are
fully KYC-able, they can even travel to a meeting, they are real people
payed to do some work in FFmpeg, not distingishable from others who
currently work on ffmpeg for money. In fact the current developers
already WILL TODAY vote the way their employer wants them to
now if you compare this to the system proportional to commits, it is much
more robust. You can still hire someone to do 20000 commits but thats MUCH more
expensive. They get vote power but they have to pay in contributions to FFmpeg.
Really if voting power is not proportional to effort by the developer then all
kinds of problems arise. (as shown above)
[...]
> Do you mean:
>
> #votes = sum[ time_multiplier(commit) for commit in git master ]
>
> or:
>
> #votes = # of commits in git master * time_multiplier(last_commit)
Both these are options that can be considered
>
> >
> > Majority
> > Constitutional changes require 2/3 majority
> >
> > Veto-holder
> > There is one veto holder, they can block decissions that
> > would cause harm to FFmpeg. The veto holder must always
> > have named a successor. In case the chain of successors
> > breaks. The available person with most authored commits in git master
> > becomes the new veto holder.
>
> How is this meaningfully changeng the status quo of you having veto power
> over everything?
1. It would be a formal system where iam below a set of rules
2. If iam hit by a bus it would clearly define the consequence and not lead to
chaos
3. Power would shift to the people holding vote power, currently the louder
on the ML carry a premium.
>
> In general I am not sure what this proposal would actually change, except
> using a more complicated system to determine who has the most power; which
> in the end, of course, will be you.
I have always tried to do what the community wants, so a system that does
what i want or what the community wants would not really change anything.
A change would be if i simply resign and someone who has no intend to do
what the community wants would succeed to fill the vaccum created by that.
Thing is, i spend a very significant portion of my life in FFmpeg
i have no intend to give that up and resign. I see no reason why I should
Some people try to shame me or something for wanting to hold on to what i
have helped create.
That just makes no sense. Thats like having someone spend 20 years build a huge
house for himself and the community and then be expected to leave with nothing
because some people just dont like him
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
