I'd like to see a better solution proposed for maintaining vendor neutrality while funding the individuals working on the project. If every workable solution is denied, then the only people who can afford to work on Apache projects would be rich people, retired people, and those who are being paid by another employer to do the exact same thing. In fact, this is probably relevant to the demographics here as discovered in D&I surveys.
On Thu, Mar 3, 2022 at 4:15 PM Craig Russell <apache....@gmail.com> wrote: > > I very much like the direction here. > > One other top post that falls into item 2 (rules of engagement): > > Apache does operate in the open with discussions, bug fixes, etc. all out for > anyone to see. Except for security issues. > > I'd like to discuss how we treat committers with security privileges with > regard to third parties who may be contracting for the committers' resources. > > Is it acceptable for committers to inform a third party of security issues > before the CVE is public because of their relationship with the third party? > > Regards, > Craig > > > On Mar 2, 2022, at 6:12 AM, Roman Shaposhnik <ro...@shaposhnik.org> wrote: > > > > Hi! > > > > top-posting here, since I'd like to summarize a few points to see where we > > can > > take this discussion. Before I do that I wanted to thank Bertrand and Jim > > for > > excellent, short emails/summaries and also special thanks to Chris for an > > extremely informative recap of his efforts. > > > > Personally, I'd like to focus on 3 things. Please let me know if I'm missing > > anything or you disagree: > > > > 1. building a robust list of what we at ASF perceive as potential value > > that can be offered to *our* members, committers and contributors > > by the 3d parties like Tidelift (again, I'm simply using them as an > > example here -- anybody else would do just fine). > > > > 2. building a list of "rules of engagement" that we feel must be met > > for these types of relationships to be compatible with the way we > > govern our communities. > > > > 3. document all the learning, pitfalls, etc. that we've collectively > > amassed by trying to solve this type of a problem on a one-by-one > > basis. > > > > To expand on those points: I really do think that 3d parties (if done > > right) can take care of a lot of pain points for us. Again -- I'm NOT > > saying that a magic entity like that even exists today (maybe Tidelift > > is really not the right solution for us -- dunno yet) -- what I'm saying > > is that I really would like to understand how that type of a service > > should look like. Or take Jarek's example of ridesharing: most > > of people focus on ridesharing companies just matching riders to > > drivers, but that's just the tip of the iceberg -- ridesharing companies > > solve huge amounts of arbitration issues (such as insurance, license, > > etc.). Common folk don't get to see those -- but that's a huge value they > > offer to drivers (and arguably riders) on top of just finding "customers". > > Same with 3d parties for us I have in mind (see Chris's list of gotchas). > > > > For now, I propose a few Cofluence pages under ComDev where this > > type of information gets collected. I'll do it later tonight -- so feel free > > to just add to this thread for now. > > > > Once we've collected that type of info -- we can then sort of "evaluate > > vendors" against that list and see what they are missing, etc. We can > > even issue a wide "call to apply" for various companies if we feel like it. > > > > Makes sense? > > > > Thanks, > > Roman. > > > > On Tue, Mar 1, 2022 at 9:43 AM Bertrand Delacretaz <bdelacre...@apache.org> > > wrote: > > > >> Hi, > >> > >> Le lun. 28 févr. 2022 à 21:15, Jarek Potiuk <ja...@potiuk.com> a écrit : > >> > >>> ...Proposal: > >>> I think we all agree that ASF meets the criteria of Tidelift already. > >>> Why don't Tidelift (in the places where open-source projects included are > >>> listed) explain that ASF projects meet the criteria, and any one is free > >>> to deal directly with the committers of all ASF projects directly... > >> > >> I'd say we all agree that *in theory* ASF projects meet Tidelift's > >> criteria, quoting from earlier in this thread, with my own numbering > >> added: > >> > >> Le lun. 28 févr. 2022 à 19:30, Joshua Simmons > >> <joshua.simm...@tidelift.com> a écrit : > >>> ...*What Tidelift expects from maintainers*Maintainers provide two > >> things to > >>> our customers: (1) information (licensing details, context on CVEs) and > >>> (2) continuity (comfort that the package is maintained and is highly > >> likely to > >>> continue to be maintained). We also expect maintainers (3) to abide by a > >> Code > >>> of Conduct.... > >> > >> I think for (3) we're good, the ASF will intervene if projects are not ok. > >> > >> But for (1) and (2) I think the ASF *wants* our projects to be good > >> citizens, and we work towards that and support them, but entities such > >> as Tidelift or others could add value by measuring and reporting what > >> actually happens. > >> > >> Does Apache FOO actually provide good information on security issues and > >> CVEs? > >> Timely response? What's their average/min/max response time, how many > >> "in-flight" CVEs? > >> Does Apache FOO release often enough? Maybe based on project maturity > >> categories, new, established, mostly dormant etc. > >> > >> We could of course measure these things ourselves, and we do have some > >> data. > >> > >> But I think having external entities provide factual data on how well > >> our projects are doing can be useful, and for customers of Tidelift > >> and the like that certainly has value. > >> > >> Whatever mechanism our contributors use to finance themselves, having > >> information on which projects are most worthy of trust can help end > >> users select and finance the right projects and people. > >> > >> -Bertrand > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > >> For additional commands, e-mail: dev-h...@community.apache.org > >> > >> > > Craig L Russell > c...@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
