Tidelift's model, which expects that maintainers do have direct and almost unassailable control over a project, is not compatible with the Apache Way. Tidelift's model works well with projects in which developers and maintainers can "do stuff" without worrying about building a consensus around whether or not their contributions are OK or not.
I'd like to see how that model and Apache could fit together, but I'm at a loss to think about how. The main benefit that those who fund the work is not just an expectation that code will be fixed, etc, but a *requirement* that it be done. They are paying for the guarantee. This requires a development model in which those paid by Tidelift can forcibly introduce code and contributions at will. This conflicts with the ASF development model. > On Feb 28, 2022, at 12:50 PM, Jarek Potiuk <ja...@potiuk.com> wrote: > >> So while I agree with everything Bertrand said I don’t think it resolves > the real issue. > TideLift is providing a guarantee to its customers that projects it > sponsors meet certain > standards. The standards they are looking for should really be set by the > ASF, not > individual projects. > > This is the part I do not understand. What Tidelift can promise to their > customers and on what basis? > According to ASF rules where only individuals in the project can make > decisions - this means that Tidelift > has no mechanisms whatsoever to fulfill their promise. > > And if ASF sets the standards - why do we need Tidelift at all ? > To be perfectly blunt - I am afraid that until Tidelift resolves any > of the real problems of individual committers we mentioned with Bertrand > (including facilitating direct relationship commiter <> stakeholder), > I do not see what's the added value of Tidelift. Seems like unnecessary > intermediary. > > J. > > > On Mon, Feb 28, 2022 at 5:10 PM Ralph Goers <ralph.go...@dslextreme.com> > wrote: > >> First, I would like to clarify Gary’s email as I don’t think he >> characterized it quite correctly. >> The Logging PMC concluded we could not be part of an arrangement with >> TideLift and >> that the issues needed to be worked out at the foundation level. The >> primary issue was >> that TideLift had requirements on advertising and process details that >> required approval >> of the PMC in order for individuals to be able to be paid. We met with a >> Google >> security team in January and had similar issues where they required a >> process that isn’t >> aligned with the ASF’s requirements on how releases are to be performed. >> >> Second, from my point of view the ASF should have discussions with >> TideLift and Google to >> see if those issues can be resolved. The ideal scenario would be that >> TideLift and Google >> can simply sponsor individuals from any ASF project because all ASF >> projects must >> conform to guidelines that meet their criteria - i.e. the PMC doesn’t even >> have to be >> involved. But this obviously requires that the foundation work with these >> third parties to >> either improve our processes where needed or get the third party to accept >> our processes. >> >> So while I agree with everything Bertrand said I don’t think it resolves >> the real issue. >> TideLift is providing a guarantee to its customers that projects it >> sponsors meet certain >> standards. The standards they are looking for should really be set by the >> ASF, not >> individual projects. >> >> Ralph >> >> >>> On Feb 28, 2022, at 5:03 AM, Bertrand Delacretaz <bdelacre...@apache.org> >> wrote: >>> >>> Hi, >>> >>> Le lun. 28 févr. 2022 à 11:06, Jarek Potiuk <ja...@potiuk.com> a écrit : >>>> ...the relationships I have is direct relationship with the >>>> stakeholders. Let's deel, GitHub Sponsors, SAP Ariba are merely >> "removing >>>> bureaucratic obstacles" but they are not "between" me and my >> stakeholders. >>>> They are "on a side". They get a small cut sometimes (which I gladly >> pay) >>>> but I want to talk to the stakeholders directly without any >> intermediaries >>>> and establish a long-term relationship with them as an individual.... >>> >>> I think that's a key point, and listing such requirements for >>> platforms that can help our contributors get funding sounds useful. >>> >>> Here's a quick list of initial requirements that we might include: >>> -Contributors can get steady funding for their work >>> -ASF is out of the loop of financial transactions >>> -Contributors must use a standard ASF disclaimer (draft at [1]) >>> -Contributors can establish a direct relationship with sponsors >>> -Several "funding intermediaries" are available >>> -ASF might define the wording that contributors can use when >>> advertising themselves (based on facts, etc.) >>> >>> I like the idea of the ASF facilitating these things. >>> >>> Maintaining a comdev page that lists criteria like the above, with >>> pointers to the relevant ASF policies, and lists intermediaries that >>> our contributors have successfully used, might be a good start. >>> >>> -Bertrand >>> >>> [1] https://community.apache.org/committers/funding-disclaimer.html >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org >>> For additional commands, e-mail: dev-h...@community.apache.org >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org >> For additional commands, e-mail: dev-h...@community.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
