Ralph: > The ASF doesn’t “need” Tidelift. Nor do we need Google. But there are individuals who work on projects who would welcome the opportunity to be paid by them
I am being paid for part of my time with Google (among others). With contract that recognizes that I cannot "do stuff they want" if the community will not agree to it. Let's enable it for others and show them the path how to do it. Neither Google nor I needed Tidelift for that. I still do not see what Tidelift could provide to either me or Google as the intermediary if they cannot influence what individuals running the project will do. I am scratching my head over and over and I can't see what it is. Joshua: I read the doc carefully. Few times. And I still am puzzled on what Tidelift provides to either individuals or stakeholders who want to pay those individuals for ASF projects. The processes are there, maintainers are there, responsible disclosure is there. Why stakeholders or ASF or individuals would need Tidelift as an intermediary ? I don't get it. J. On Mon, Feb 28, 2022 at 7:30 PM Joshua Simmons <joshua.simm...@tidelift.com> wrote: > Good $localtime, folks! I just want to underscore a really important > section of the document I provided yesterday, as it seems this detail is > lost in the mix. Tidelift very deliberately does not direct development. > I'll remain on the sidelines here as y'all deliberate, but I want to make > sure we're operating from the same set of facts. > > > *Why Tidelift works with maintainers*We want the open source projects used > by our customers—your downstream users—to be as healthy and secure as > possible. We believe this requires directly supporting maintainers and > their work, both financially and through providing tools and resources that > make it easier for them to be successful. > > > *What Tidelift expects from maintainers*Maintainers provide two things to > our customers: information (licensing details, context on CVEs) and > continuity (comfort that the package is maintained and is highly likely to > continue to be maintained). We also expect maintainers to abide by a Code > of Conduct. Neither Tidelift nor our customers direct development of > Tidelift-supported packages. > > > *What Tidelift expects of projects*We only work with projects that meet > certain standards: there must be a responsible vulnerability disclosure > process in place, and clear licensing metadata. While mature projects have > these standards in place, many of the open source projects we work with > have just 1 or 2 maintainers, and it’s not unusual for them to implement > these standards as part of preparing to work with us. > > Some projects–such as those at the ASF–can’t implement those things on our > behalf due to policy constraints. Good news is that those projects tend to > already meet these standards! Our goal here is to promote good governance. > > Josh Simmons (he/they), Sr. Ecosystem Strategy Lead @ Tidelift > <https://tidelift.com/> > @joshsimmons <https://twitter.com/joshsimmons> | > joshua.simm...@tidelift.com > | bluesomewhere on IRC > TZ: US/Pacific; UTC-07:00 Mar-Nov; UTC-08:00 Nov-Mar > ad astra per aspera 🚀 > > > On Mon, Feb 28, 2022 at 10:24 AM Jim Jagielski <j...@jagunet.com> wrote: > > > 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. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > > For additional commands, e-mail: dev-h...@community.apache.org > > > > >
