Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Nicolas George via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Cc: Nicolas George <george@nsup.org>
Subject: [FFmpeg-devel] Re: [RFC] Funded Task Ideas
Date: Wed, 15 Oct 2025 16:53:28 +0200
Message-ID: <aO-1aOM19ySVmewU@phare.normalesup.org> (raw)
In-Reply-To: <aO24BiJQWDvXqKFP@neo>

Michael Niedermayer via ffmpeg-devel (HE12025-10-14):
> As we are now looking for sponsors, we also should look for tasks to fund.

> PS: once we have enough yearly income we can look at hiring / funding
> people fulltime.

I will step into it:

This is severely misguided.

FFmpeg is a Libre Software project: its goal is to make beautiful and/or
useful software.

FFmpeg's goal is NOT to gain market shares.

FFmpeg's goal is NOT to turn a profit.

FFmpeg's goal is ABSOLUTELY NOT to get a livelihood for its authors.

The problem with people getting paid to work on FFmpeg is that it is a
misaligned incentive. It creates the incentive to push the code as is
instead of polishing it, instead of accepting suggestions to make it
better. It creates the incentive to work alone rather than seek the
insights of our peers.

I am sure some developers are able to resist the incentive and not let
the fact that they are paid for it reduce the quality of their code in
favor of speed at all. But I am also sure they are not a majority.

So, sponsorships?

Sponsorship in the form of hosting, absolutely!

Sponsorship in the form of hardware, server hardware that can benefit
the whole project as a FATE instance or remote development computer,
absolutely.

Sponsorship in the form of hardware personal for one developer in
particular: that is already more problematic.

Sponsorship in the form of funding people to code: this is where it
becomes difficult.

I think we can fund tasks that have a very precise scope:
straightforward tasks that require no creativity from the coder and
where the completion status is objective and unambiguous.

But beyond that, we should not try to fund: anything that requires
design choices, anything involving new API, etc., we should favor people
who do it because they want to do it.

We cannot prevent people from obtaining funding on their own, of course,
and neither should we. But at least we will not be in a situation of
conflict of interest: if the task is harder than they thought, if we
demand they do it better, it is between them and their sponsor, and we
are not in an awkward position.

Also, I think we should demand people to disclose when they have
specific funding like that, on pain of getting their Git write access
suspended if they neglected to do it and it gets known. We should know
when somebody's loyalty is to themselves and their sponsor rather than
to the project.

Regards,

-- 
  Nicolas George
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

  parent reply	other threads:[~2025-10-15 14:53 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-14  2:40 [FFmpeg-devel] " Michael Niedermayer via ffmpeg-devel
2025-10-14 19:16 ` [FFmpeg-devel] " Michael Niedermayer via ffmpeg-devel
2025-10-14 20:35 ` Michael Niedermayer via ffmpeg-devel
2025-10-14 22:28 ` Timo Rothenpieler via ffmpeg-devel
2025-10-14 22:52   ` Michael Niedermayer via ffmpeg-devel
2025-10-15  4:39     ` Kieran Kunhya via ffmpeg-devel
2025-10-15  8:31       ` Nicolas George via ffmpeg-devel
2025-10-16  9:28         ` Kieran Kunhya via ffmpeg-devel
2025-10-16 11:20         ` Michael Niedermayer via ffmpeg-devel
2025-10-15 14:53 ` Nicolas George via ffmpeg-devel [this message]
2025-10-16 11:59   ` Michael Niedermayer via ffmpeg-devel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aO-1aOM19ySVmewU@phare.normalesup.org \
    --to=ffmpeg-devel@ffmpeg.org \
    --cc=george@nsup.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
		ffmpegdev@gitmailbox.com
	public-inbox-index ffmpegdev

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git