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