Hi all, As I was confronted with the question of how commercial support or paid feature development and Apache would work together. I came up with this way of handling it: If I am offering any form of commercial support or feature development I say: "I will fix your problem. The fix then can become part of the open-source project, but if the project decides to decline It, I'll make it available to you in a fork that I create for you." This should work for Tidelift or any similar form of platform too.
Chris -----Original Message----- From: Jim Jagielski <j...@jagunet.com> Sent: Montag, 28. Februar 2022 19:24 To: dev@community.apache.org Subject: Re: Effective ways of getting individuals funded to work on ASF projects 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
