From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 213AA478FC for ; Fri, 27 Oct 2023 13:39:04 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id A323468CB3B; Fri, 27 Oct 2023 16:39:01 +0300 (EEST) Received: from mail-qv1-f54.google.com (mail-qv1-f54.google.com [209.85.219.54]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id E981368C965 for ; Fri, 27 Oct 2023 16:38:54 +0300 (EEST) Received: by mail-qv1-f54.google.com with SMTP id 6a1803df08f44-66d0169cf43so14193836d6.3 for ; Fri, 27 Oct 2023 06:38:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ob-encoder-com.20230601.gappssmtp.com; s=20230601; t=1698413933; x=1699018733; darn=ffmpeg.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=wgFFUAne1LWQTNM0pMOkBB28yeJ8SXKB3IWFKU9ru7o=; b=LaLiGGUNdOL9KELo8rbXoZUuXRR374jfZkjRUr24KzwBYRHyp7FlnvvZ8EaXsInN8g MQSgZFJveFwn73ZXMlnyOh3gp94Dz+k6SmQlSEwYc2I/EJ6MF/J9Ux6uOhzsCxMJu+XW Nk3LAPyOvXjPw90KpO+J8norOnbKSBzjekN+4gCK3lHLCSSwGXIQZYueARgPvWY8il1K Z6doZHwQR5Tk5c8TB5J2pbHUaX3KSq9zz96XjCn0sbonMO1sqEosrrcNHBo5hJE0T9rP iKhw382NISew9OI/p3ujBKYA3skWGOSZPNPLH8Y2LFv6Zl18Cl3ZQRFn8oXocYskMoej QaeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698413933; x=1699018733; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=wgFFUAne1LWQTNM0pMOkBB28yeJ8SXKB3IWFKU9ru7o=; b=piHjdLfZXzDvo4h9GQgtTMLMw7lgSvgDodcqNkuq8SIZKLKOoc22qQxrqrNepKVcrS C0wd9CfdWLUnIDhJR71oJ12XQvXdhy8cdcARkXTfhbiiNBBBJJobBYcIiNLz09Wl2+sa n2h6M/VCDahHue7wa98FfCX4uXqfz872XgPn6pCt2OPrcNCDm21RVHMfGISTNgKJf2Sv K6AQicly90R5GIqpny5tlbF5i/xmjQuF4WBvwktPC/vj+Ok6MWXzmN9aWjTsrEQIm7gP XKSuehwGs1ZIlWG63orIyQ/RMc3avfvoGfK41ELuLpTNepSLGSun+kcUaaZ8o8/+oEyq EAOw== X-Gm-Message-State: AOJu0Yz/RDKAI4yGezDaYvzr4NV7iMYmKYqugW/JVq1h7el2GHxVFIrj ki+7cE+pQ0nIM3lCU0gPq/XkTZsZWggauouXpM1i96ZbHHijpqWwG70= X-Google-Smtp-Source: AGHT+IFvMSNxK1bEzF9SCECVna94Qq7h8QJH1A+ZHy8ruowrvq0PwPi3Vc/rEav4AcZ3tZpwZV/XAuuOLLHZFpQPfj8= X-Received: by 2002:a05:6214:2265:b0:668:7b47:dc96 with SMTP id gs5-20020a056214226500b006687b47dc96mr3194166qvb.42.1698413932544; Fri, 27 Oct 2023 06:38:52 -0700 (PDT) MIME-Version: 1.0 References: <20231026154523.GI3543730@pb2> <9dc06c51-3aa0-3b71-b0a6-12a5e4cfe662@mail.de> In-Reply-To: From: Kieran Kunhya Date: Fri, 27 Oct 2023 06:38:41 -0700 Message-ID: To: FFmpeg development discussions and patches X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [FFmpeg-devel] [RFC] financial sustainability Plan A (SPI) X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Cc: Thilo Borgmann Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Fri, 27 Oct 2023 at 03:23, Thilo Borgmann via ffmpeg-devel < ffmpeg-devel@ffmpeg.org> wrote: > Am 27.10.23 um 03:28 schrieb Kieran Kunhya: > > Hi, > > > > On Thu, 26 Oct 2023 at 12:41, Thilo Borgmann via ffmpeg-devel < > > ffmpeg-devel@ffmpeg.org> wrote: > > > >> Of course. FFmpeg has a donations account. So the money is already there > >> and > >> already used for the reimbursement requests. Whatever we spent it for > >> needs to > >> be decided by the community. Spending more money instead of just watch > it > >> growing is a good thing. That this will lead to more "disaster" is an > >> assumption > >> without basis. Even if this does happen and fails, its still better than > >> not > >> having even tried. > >> > > > > Reimbursement requests for clearly defined things like travel costs with > > receipts, or hardware that the project owns is in no way comparable to > > consulting work, contracts, statements of work etc. And the current > swscale > > proposal is far from this too. > > Yes, of course they are different. Most importantly sponsored development > needs > to be agreed upon beforehand. That does not imply sponsored work is not > clearly > defined. I miss your argument about why it can't be done in this. > Do you seriously think this project will have a sudden outbreak of professionalism and suddenly start producing detailed contracts and statements of work? It'll end up being a few lines on the mailing list. >> Also, you just advertised FFmpeg and asked for more financial support in > >> your > >> talk at Demuxed [1] - so I figure your prefered way of doing that would > be > >> to > >> channel money into some company without the community being involved? > >> > > > > Actually if you watched the presentation, I said big companies need to > > support maintenance (not the same as bounties) of FFmpeg by hiring > > employees to work full time as they do with Linux Kernel maintainers. Or > > failing that they can donate to the community - but as you know well the > > numbers we have are not enough to hire full time maintainers. > > I'm totally fine with you asking big companies to hire devs for FFmpeg > maintenance. That does not relate to my question, though. Do I assume > correctly > that your prefered way of doing that would be to channel money into some > company > without the community being involved? > Contractually yes, this is a better solution. It allows the company to be in charge of delivery of the maintenance work with a contract behind it. Do you seriously think big companies will suddenly hand over money to the community that's got weekly drama around it? This point was raised to me by a big company that shall remain nameless at Demuxed. > Agreement via mailing list for money is a recipe for disaster. What we > need > > are clear statements of work that are voted on by TC. > > That's not the purpose of the TC. We of course need to have a good way of > approving or disapproving proposals and of course we need these to be > clearly > defined. I again miss to see your argument why that shall not be possible > on the > ML - everyone on this list knows where your suspicion comes from but > again, > without even having tried, it's just your assumption and should IMHO not > stopping us from trying to implement such a procedure. > The mailing list isn't the be all and end all of all communications and decision making in the world. History shows it's atrocious for making decisions. Many people make valid and succinct points that are outright ignored, whoever writes the longest wall of text (often with conspiratorial ramblings that I'm sure go down well with potential donors) seems to get the most attention (i.e quantity vs quality). Lots of people have left the project (e.g Derek) because of the toxicity of this mailing list. Even the Linux Kernel realised their mailing list was toxic and changed. > > We can't even agree on patch reviews, throwing money into the mix is > > throwing gasoline into the fire. > > Being in conflict about a patch is completely different to conflict about > some > feature we might want. And no, not everything is as controversial as SDR > or gets > controversial just because it would be sponsored. You think there would > have > been real and non-resolvable opposition against bringing multi-threading > into > ffmpeg.c? You assume a proposed sponsored AV2 decoder will raise such > opposition? > However, since I agree with you that there will be different oppinions, > why > would you think that a e.g. a vote/committee or whatever we will choose > could > not resolve how we deal with these cases? > A conflict over a patch would lead to lack of payment which would enflame the situation more. I don't see why this is difficult to understand. Yes, I would say a proposed AV2 decoder would be a bad idea since it would be better to build one on top of dav1d. AV2 will likely have a lot of similarities to AV1. The introduction of money into the voting process isn't exactly a great idea. > And since you also advertised explicitly for FFlabs - what is your > relation > >> to > >> FFlabs? I own 25% of that company and I am not aware of any > relationship. > >> You > >> just did advertise FFlabs because... FFlabs exists? FFlabs is a company > >> co-owned > >> by some FFmpeg developers, it's not FFmpeg nor can it represent it or > act > >> on its > >> behalf. > >> > > > > I linked to the consulting page and also to FFlabs which as far as I know > > is the only company offering an SLA on FFmpeg. > > If others existed I would have included them. > > Nothing wrong about bringing attention to ff.org/consulting or FFlabs. > My question is what your relationship with FFlabs is? > Since you say you are a shareholder, I don't understand the need for this performative and insulting question you obviously know the answer to. Like I said, if Collabora or Igalia or Redhat or provided an SLA for FFmpeg I would have included them. > >> As soon as we pay developers via SPI it can become a good zero-trust > >> environment > >> for donators to offer tasks & money to FFmpeg and handle the money flow > >> via SPI. > >> The donators can be sure that their issues are handled properly in the > >> project > >> (on the ML) and do not flow away into some other sink and the developers > >> can be > >> sure to get their money from SPI because the offer is public and backed > by > >> the > >> FFmpeg SPI account. Sounds like a quite trustworthy and most importantyl > >> transparent way to handle things and build up trust in potential > donators > >> that > >> the money they spent actually end up with FFmpeg. > >> > > > > Do you really think the way SPI funding is managed currently matches your > > description? > > That's exactly the point, to find a procedure that works for sponsored > work. > > > > Stefano approves by saying "Approved on my side, pending Michael's > > approval." > > That won't change because SPI demands it. Done. We can change the names > Stefano > and Michael into whatever, but that's it. > Ok, so you agree it's not actually community driven? > > This is not at all a community driven process where one person can veto > > everything. > > What needs to be setup, is a procedure to find FFmpeg's decision about it. > Who transports it to and approves it towards SPI is completely > uninmportant > because it cannot be done against the will of FFmpeg - and yes, SPI checks. > Also blocking by a single individual cannot be done already, doesn't even > matter > if it's Michael or Stefano. > I am not able to parse this paragraph. > >> I don't think developers should be paid via SPI for this reason. > >> > >> I think supporting FFmpeg developers via SPI fits perfectly into what we > >> have > >> SPI for in the first place - an independant entity that handles the > >> community > >> funds with absolute objectivity and no intrinsic interest whatsoever. In > >> contrast to any company, including (my own-ish) FFlabs. > >> > > > > If there is disagreement (which will be inevitable) SPI will not step in. > > Only if non-resolvable. If we setup a procedure, that is solved. > There are a million more important things that don't have a procedure right now. > > Money is only going to make our current ML drama situation worse. > > Circling again. I think everyone long enough on this list agrees with you > that > we have drama potential on almost everything here. However, CC & TC > instanciation proved that we have a way of putting an end to the drama. > We haven't even managed to elect a new TC to even make a decision on anything. > So why don't you want to give it a try at least? > Because it's clearly going to make a bad situation worse. Regards, Kieran Kunhya _______________________________________________ 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".