[FFmpeg-devel] Democratization

Niklas Haas ffmpeg at haasn.xyz
Thu Jan 2 17:38:07 EET 2025


On Thu, 02 Jan 2025 15:17:31 +0100 Michael Niedermayer <michael at 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.

>     The voting power will depend on how recent the last commit was. And the main
>     author will have a veto right and a 2/3 majority will be needed for "Constitutional" changes.
>     Persistent trolls can be excluded from becoming shareholders.
>     As new contributions are made, new shares will be created. This will happen on a quarterly base.
>
> Shares:
>     1 commit in           git master branch ==  1 shares
>     1 fixed ticket in trac                  ==
>     1 mail in ffmpeg-devel                  ==
>
> Time Multiplier:
>     Provides an incentive to return and contribute again,
>     favors recently active contributors

Do you mean:

  #votes = sum[ time_multiplier(commit) for commit in git master ]

or:

  #votes = # of commits in git master * time_multiplier(last_commit)

>
> 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?

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.

>
> thx
>
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> "Nothing to hide" only works if the folks in power share the values of
> you and everyone you know entirely and always will -- Tom Scott
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".


More information about the ffmpeg-devel mailing list